Openhab-addons: RFXCom lighting1 commandString channel

Created on 26 Oct 2019 · 9Comments · Source: openhab/openhab-addons

I've updated to the latest snapshot and was expecting to see the commandString channel on the Paper UI "Configuration , Things , RFXCOM Lighting1 Actuator" page but it is not there. Is the version of the binding containing that channel not in the snapshot builds at present. Is there another way of installing a version of the binding that does have the commandString channel ?
Thanks
Tim

bug

Source

TimScottz8

All 9 comments

Looks like it was added in https://github.com/openhab/openhab2-addons/pull/5795 so it's only available in 2.5.0 milestone/snapshot builds created between now and 4 months ago.

If you still don't see the channel try recreating your thing. It's a known issue things don't get updated when their thing type definitions are updated. There's a PR for fixing that (https://github.com/openhab/openhab-core/pull/1027).

wborn on 2 Nov 2019

I now have the commandChannels exposed thanks and have been trying them out. I have subsequently found a small bug. The address that gets sent the commandString seems to always be the last one that received on ON command. So if I have two dimmers on address A1 and A3 I get the following result.
I send A1 ON and then A3 ON so that both dimmers are now ON. I then send an A3 DIM commandString and as expected A3 physically dims. If I send an A1 DIM commandString A3 dims.
If I now send A1 ON command then sending A1 DIM commandString causes A1 to DIM but sending A3 DIM commandString also causes A1 to dim.

TimScottz8 on 4 Nov 2019

👍1

but sending A3 DIM commandString also causes A1 to dim

Maybe @martinvw has an idea what might be causing this?

wborn on 4 Nov 2019

Could you elaborate on the rules or any other way you try to trigger these? And maybe also enable debugging for org.openhab.binding.rfxcom so we can see what is going on. Thanks!

martinvw on 4 Nov 2019

Hi
Here are the rules I'm using

```rule "quad swipe1"
when Item Quad_SceneSwipe1 received update
then
val String json = (Quad_SceneSwipe1.state as StringType).toString.split("\W+").get(2)
val String type = transform("JSONPATH", "$.direction", json)

logInfo("INFO","swipe 1")
if (LivingRoom_WallLights.state == ON) {

    if (type == "INCREASE"){
        LivingRoom_WallLights_CS.sendCommand("BRIGHT")
    }
    if( type == "DECREASE" ) {
        LivingRoom_WallLights_CS.sendCommand("DIM")    
    }
}

end

rule "quad swipe3"
when Item Quad_SceneSwipe3 received update
then
val String json = (Quad_SceneSwipe3.state as StringType).toString.split("\W+").get(2)
val String type = transform("JSONPATH", "$.direction", json)

logInfo("INFO","swipe 3")
if (LivingRoom_Chandelier.state == ON) {

    if (type == "INCREASE"){
        LivingRoom_Chandelier_CS.sendCommand("BRIGHT")
    }
    if( type == "DECREASE" ) {
        LivingRoom_Chandelier_CS.sendCommand("DIM")    
    }
}

end

rule "quad scene1"
when Item Quad_Scene1 received update
then
logInfo("Info", Quad_Scene1.state.toString)

if (Quad_Scene1.state == 1){
    LivingRoom_WallLights.sendCommand(ON)}    
if( Quad_Scene1.state == 1.1  ) {        
     LivingRoom_WallLights.sendCommand(OFF)}

if (Quad_Scene1.state == 2){
    LivingRoom_Uplights.sendCommand(ON)}    
if( Quad_Scene1.state == 2.1  ) {        
     LivingRoom_Uplights.sendCommand(OFF)}

if (Quad_Scene1.state == 3){
    LivingRoom_Chandelier.sendCommand(ON)}    
if( Quad_Scene1.state == 3.1  ) {        
     LivingRoom_Chandelier.sendCommand(OFF)}

if (Quad_Scene1.state == 4){
    Outside_Lights.sendCommand(ON)}    
if( Quad_Scene1.state == 4.1  ) {        
     Outside_Lights.sendCommand(OFF)}

end
```

It seems that the dim or brighten command gets sent to whatever address was the last to receive an ON command. This is identical to the PLCBus reaction when I use a KR22 switch. Maybe it's part of the PLCBus protocol. If that's the case then sending an ON to the address prior to sending a DIM/BRIGHT command will fix it but will also add delay. Better will be to have a state variable that hold the address of the last ON command so that ON is only sent to and address where it is not the address in the state variable.

p.s. Don't know why the code is being formatted as above on the comment. I've tried to use the code block command but it hasn't worked.

TimScottz8 on 8 Nov 2019

Okay, I see now what is going on, the behaviour you see is caused by #2103, especially this part:

The way an X10 SS13 (for instance) works is that the BRIGHT/DIM buttons
send an X10 DIM/BRIGHT command to the 0 (all units on house code X)
address and any dimmable device that last saw ON for itself acts on it.
That is to say if the last ON seen by A1 was addressed to A1 and an A0
DIM comes in then A1 will dim but A2 won't. Since this only works in a
pure X10 world we keep track of where the last command was going and map
incoming BRIGHT/DIM commands to INCREASE/DECREASE commands for the last
thing ON'd. This allows an X10 SS13 to operate as designed, both as
an on/off switch and as a dimmer controller simply by attaching the
switch's item to the switchable/dimmable thing's dimmer channel with no
rules necessary.

N.B. When sending INCREASE/DECREASE commands to an X10 device we change
the X10 address to be the all-units address. It would be better to
direct the command to the specific device required however I have not
tested whether this actually works or not (lack of working PLM).

I am not fully aware why it was exactly changed like this, I hope that @mjagdis can help us with some more information. And especially what the correct rules would now be.

PS: the multi-line code block should be quoted with triple backticks.

martinvw on 9 Nov 2019

In the encodeMessage method of RFXComLighting1Message read the comment and change it to always set data[5] to unitCode. My understanding of X10 and my guessing at how the RFXCom API maps the actual protocol says it SHOULD work but like the N.B. says I blew my PLM (and have since decommissioned the last of my X10 stuff).