Why does Openhab overwrite my rfxcom protocols selection?

Add-ons Bindings
, ,
1

This started with having a Chacon DiO 54781 433Mhz door sensor - I’m proceeding to see if it might be usable in Openhab with my Rfxcom: it seems popular with Domoticz Rfxcom users and, if I understand well, it uses the AC protocol… So, let’s see !

The setup is Openhabian on Raspberry Pi 3 with a Rfxcom. I set it up a couple of days ago - I am a Debian admin of twenty years and an Openhab newbie. My Hello World was getting temperatures from a couple of Oregon Scientific probes - so the system works.

Since I have not found an Openhab binding that looks suitable, I decided to take a look at what the rfxcom:undecoded thing delivers out of the 433MHz soup. But of course, Openhab has to get the AC frames. So, using node-rfxcom, I checked if the Rfxcom was configured to trawl for them:

[12:14:34] root@ouakam:/home/openhabian# cd /home/openhabian/node_modules/rfxcom

[12:14:36] root@ouakam:/home/openhabian/node_modules/rfxcom# service openhab2 stop

[12:14:41] root@ouakam:/home/openhabian/node_modules/rfxcom# npm run set-protocols -- --list /dev/ttyUSB0

> rfxcom@1.0.3 set-protocols /home/openhabian/node_modules/rfxcom
> bin/set-protocols.js "--list" "/dev/ttyUSB0"

Trying to open RFXCOM device on /dev/ttyUSB0...
Serial port open, initialising RFXCOM device...
433.92MHz transceiver hardware version 1.3, firmware version 1022 Ext 2
Enabled protocols:  OREGON
Disabled protocols: AC,ARC,ATI,BLINDST0,BLINDST1,BLYSS,BYRONSX,FINEOFFSET,FS20,HIDEKI,HOMECONFORT,HOMEEASY,IMAGINTRONIX,KEELOQ,LACROSSE,LIGHTING4,LIGHTWAVERF,MEIANTECH,MERTIK,PROGUARD,RSL,RUBICSON,UNDECODED,VISONIC,X10

Only the Oregon Scientific protocol is enabled - let’s enable AC:

[12:14:41] root@ouakam:/home/openhabian/node_modules/rfxcom# npm run set-protocols -- --list /dev/ttyUSB0

> rfxcom@1.0.3 set-protocols /home/openhabian/node_modules/rfxcom
> bin/set-protocols.js "--enable" "AC" "--save" "/dev/ttyUSB0"

Trying to open RFXCOM device on /dev/ttyUSB0...
Serial port open, initialising RFXCOM device...
433.92MHz transceiver hardware version 1.3, firmware version 1022 Ext 2
Currently enabled: OREGON
        Change to: AC,OREGON
Saved to non-volatile memory

And to confirm:

[12:15:42] root@ouakam:/home/openhabian/node_modules/rfxcom# npm run set-protocols -- --list /dev/ttyUSB0

> rfxcom@1.0.3 set-protocols /home/openhabian/node_modules/rfxcom
> bin/set-protocols.js "--list" "/dev/ttyUSB0"

Trying to open RFXCOM device on /dev/ttyUSB0...
Serial port open, initialising RFXCOM device...
433.92MHz transceiver hardware version 1.3, firmware version 1022 Ext 2
Enabled protocols:  AC, OREGON
Disabled protocols: ARC,ATI,BLINDST0,BLINDST1,BLYSS,BYRONSX,FINEOFFSET,FS20,HIDEKI,HOMECONFORT,HOMEEASY,IMAGINTRONIX,KEELOQ,LACROSSE,LIGHTING4,LIGHTWAVERF,MEIANTECH,MERTIK,PROGUARD,RSL,RUBICSON,UNDECODED,VISONIC,X10

Good - the AC protocol is enabled on the Rfxcom.

Now, let’s start Openhab, stop it and check again.

[12:15:12] root@ouakam:/home/openhabian/node_modules/rfxcom# service openhab2 start

[12:15:36] root@ouakam:/home/openhabian/node_modules/rfxcom# service openhab2 stop

[12:16:35] root@ouakam:/home/openhabian/node_modules/rfxcom# npm run set-protocols -- --list /dev/ttyUSB0

> rfxcom@1.0.3 set-protocols /home/openhabian/node_modules/rfxcom
> bin/set-protocols.js "--list" "/dev/ttyUSB0"

Trying to open RFXCOM device on /dev/ttyUSB0...
Serial port open, initialising RFXCOM device...
433.92MHz transceiver hardware version 1.3, firmware version 1022 Ext 2
Enabled protocols:  OREGON
Disabled protocols: AC,ARC,ATI,BLINDST0,BLINDST1,BLYSS,BYRONSX,FINEOFFSET,FS20,HIDEKI,HOMECONFORT,HOMEEASY,IMAGINTRONIX,KEELOQ,LACROSSE,LIGHTING4,LIGHTWAVERF,MEIANTECH,MERTIK,PROGUARD,RSL,RUBICSON,UNDECODED,VISONIC,X10

WTF ? Does Openhab have its own idea of what protocols should be enabled on the Rfxcom ? Is it normal behaviour ? Should I tell Openhab to enable the protocol, instead of the Rfxcom directly ?

2

Setting the protocols on connecting is a feature of the rfxcom binding and, i believe, enabled by default.

You can set the binding to NOT configure the transceiver, if you don’t want openHAB to manage the protocols. To do this, set ignoreConfig=true in the configuration of the bridge thing.

Otherwise, you can just enable and disable the protocols you need. Here is an example from my things/rfxcom.things textual configuration file:

Bridge rfxcom:bridge:rfxtrx433e [
  serialPort="/dev/rfxtrx433e",
  transmitPower=0,
  disableDiscovery=true,
  ignoreConfig=false,
  enableLighting4=true,
  enableOregonScientific=true
] {
    // Outlets
    Thing lighting4 00000_A [deviceId="349269", subType="PT2262", pulse=318]
[...]
1 Like
3

Thank you - I was wondering where all the bridge configuration parameters I found at https://docs.openhab.org/addons/bindings/rfxcom/readme.html were supposed to go… I was fearing that the setMode way was mandatory and I do not have any Windows at hand…

I guess that disableDiscovery=true is what will spare me the ugly stack traces for lack of JD2XX - nice !

I’ll go in the direction you point to and report back here.

things/rfxcom.things did not exist… I would have supposed that the already running things (the two Oregon Scientific temperature probes) would be declared here… Since they aren’t I guess the things configuration is persisted elsewhere - so… Doesn’t that make it two different things configuration persistence locations ? If I configure stuff both in PaperUI and in the configuration files, how are conflicts handled ? Can I have rfxcom:bridge:rfxtrx433e parameters passed in things/rfxcom.things and its dependent things declared in PaperUI ?

Well - I guess that I’m about to discover most of that experimentally…

Also, in my newbie confusion, I declared the serial port in several places:

  • rfxcom:serialPort=/dev/ttyUSB0 in /etc/openhab2/openhab.cfg which I created
  • EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0" in /etc/default/openhab2
  • And now I have serialPort="/dev/ttyUSB0" in things/rfxcom.things

I feel that configuration isn’t supposed to be redundant like that (and the gnu.io.PortInUseException: org.openhab.binding.rfxcom.internal.connector.RFXComSerialConnector I am now having is a rather strong hint…) - which place is the right one ?

4

This is needed for JAVA to know that you want to use this ttyUSB0 for something (otherwise Java does not let you access devices).

This is needed when you configure the rfxcom things in a things file. If you configure your rfxcom in the PaperUI (which I believe you did), then you seleted this from a dropdown.

The PaperUI/Habmin/etc… configs are not saved in the textual config files. The PaperUI would never know how you like your text config to be structured and indented, so it just doesn’t touch it. Also, you cannot change textual configured stuff from the Web UI. It will just say “Forbidden”, so don’t be scared to try. It won’t break.

Because you already have configured your rfxcom gateway in the PaperUI, you can just continue to use that and reconfigure the gateway in the PaperUI. For that, please delete your rfxcom.things file again and go to your Rfxcom thing in PaperUI:

image
image777×810 69.6 KB

Then click on the Edit button:

image
image791×516 18 KB

Here you can make all the settings I did in my textual config. I have highlighted some of them with the names I used in my config. Just flick the switches to your liking and click the tick on the top of the page to save:

image
image791×882 62.6 KB

Oh and disableDiscovery will just stop the binding from automatically adding new things to the inbox. My neighbors are using those lighting4 remotes a lot and my Inbox is full of things of them, so I disabled it.

1 Like
5

Thank you for these explanations - rfxcom configuration makes much more sense to me now !

I thought that the “pencil” icon meant that I was in “edit mode” so I was surprised at the lack of settable parameters and it did not occur to me that it was actually a button to do just that… The “checkmark” button has “Save” tooltip - maybe the “pencil” button should have an “edit settings” tooltip ? Should I file an UI bug ? I looked at https://github.com/openhab/ but can’t find the repository for the PaperUI…

Since I had my Oregon Scientific probes working, I guess I got it right once… And forgot about it… Lack of sleep because of 3 AM tinkering doesn’t help memory and I was looking at configuration/bindings/rfxcom instead of configuration/things/view/rfxcom:bridge

And back to the matter that got me here - I got Openhab to work with the Chacon DiO 54781 433Mhz door sensor, with the AC protocol through the Rfxlan… I’m pleased !