Another plugin update

Added a new state variable: IPPort. This can be used by those who want to connect their RFXtrx transceiver using wifi adaptor. It can be set to the desired IP port. This setting does not appear in the RFXtrx settings dialog since it will probably not be used by many. When using the normal USB connection, setting the IPPort value will have no effect.
Added the signal strength to the data shown in the Managed Devices tab. Also removed signal strength and battery state from the Temperature and Humidity page.
Added ability to decode messages from Kangtai and Cotech devices. These will be seen as door sensors.
Lots of code changes to improve readability by implementing classes. Improved use of binary variables.
The attached zipfile contains all the files but only 4 are changed:

Thank you tinman for the update. I’ve been on version 1.0 for a long time and was happy to find this upgrade. I was also happy to find that a problem I had with deleting devices is now resolved.

I have a new issue as well though. I’m no longer able to disarm my KAKU devices. Arming works, but disarming is simply ignored. The logs (with debug) implies that RFXtrx is trying to set “armed” to 0, but after that the value armed is set from 1 to 1.

08 09/03/18 20:15:49.553 JobHandler_LuaUPnP::HandleActionRequest device: 277 service: urn:micasaverde-com:serviceId:SecuritySensor1 action: SetArmed <0x71624520> 08 09/03/18 20:15:49.554 JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=277 <0x71624520> 08 09/03/18 20:15:49.554 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:SecuritySensor1 <0x71624520> 08 09/03/18 20:15:49.554 JobHandler_LuaUPnP::HandleActionRequest argument action=SetArmed <0x71624520> 08 09/03/18 20:15:49.554 JobHandler_LuaUPnP::HandleActionRequest argument newArmedValue=0 <0x71624520> 08 09/03/18 20:15:49.554 JobHandler_LuaUPnP::HandleActionRequest argument rand=0.46216635069513257 <0x71624520> 50 09/03/18 20:15:49.555 [b]luup_log:82: RFXtrx: dbg: setArmed DS/L2.0/0E19A26/10 target 0 <0x71624520>[/b] 06 09/03/18 20:15:49.555 Device_Variable::m_szValue_set device: 277 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 1 now: 1 #hooks: 5 upnp: 0 skip: 0 v:0x1237428/NONE duplicate:1 <0x71624520>

It’s the same for all KAKU sensors. I’ve tried this with Z-wave sensors as well and those disarm normally.
I hope you can help me!

OK, I’ve found a problem in the code. I’ll have a fix very soon.

That’s awesome :). Meanwhile I’ve rolled back to 1.0 to get things working again.
For my curiosity and improving my own widget-writing skill: where should I have looked if I’d wanted to find the bug myself?

Attached is a zip file with all of the plugin files. Only two have changed:
L_RFXtrx.lua - fix a bug encountered when arming or disarming a security sensor
J_RFXtrx.js - only a small cosmetic change in displaying temperature readings.

Works like a charm, thanks again for looking into this so quickly.

Glad I could fix it quickly. As for how to find problems - in general note the last time everything appears to be working properly and then when it isn’t. Inspect the code in between. The debug output you posted shows the target as 0 but the setting became 1. The VAR_ARMED variable should be a boolean so the value received in setArmed should be checked and the appropriate boolean value sent to setVariable.

Good man! Thankyou! :smiley:

Has anyone upgraded RFXTrx with firmware type Pro1 and got it to work properly with the current plugin version?

I’m working on updating the plugin to recognize the new firmware types. It’s going to be a few days until it’s ready.

Thanks for your commitment tinman, looking forward to this since the Pro firmwares really solves a lot of coexistence issues between different protocols.

The changes I need to make only involve displaying the receiving protocol settings appropriate for the firmware type. The only problem with the current plugin version is thinking the firmware type is ‘unknown’. I don’t think it will impact the functionality of the plugin using the existing settings of the RFXtrx transceiver which you can make or view using the RFXmngr.
Can you give me some info about the improved coexistance you’re describing? I’m just curious.

Nice work with this. Suddenly I can add new devices again. Thanks ! :slight_smile:


I updated with the 1.51-version, and now when I go into “RFXtrx Settings”, it just shows an empty window, all the protocols are gone. What happened? How do I get them back?

Have you checked the serial port settings? Go to Apps -> Develop Apps -> Serial port configuration and make sure the Used by device setting indicates your RFXtrx. And that the baud rate is 38400, data bits is 8, stop bits is 1 and parity is none.

Good Afternoon,
I am not sure if that is the right place, but I tried since hours to get a brand new RFXtrx433 XL with latest Firmware 1031 working with a Vera Lite on UI7 latest Firmware 1.7.1040 to work. I used all files from “trunk” or from your “Zip 51”. When I connect the RFXtrx433XL to the Vera Lite, LED switch on the RXFtrx like they should, but whatever I do, I cannot see the device in the Serial Port connection. That page is just empty. And believe me I reloaded Luup, I switched power off/on…
I downgraded down to Version 1027 using each Version on the RFXtrx433XL on the PC. I just do not see it in the Serial Port connection.
According their Webpage, the RFXtrx433XL to the RFXtrx433e are 3 different subbandwidth, more memory and now it comes: different USB chip to communicate with.
Any idea how to fix this or someone with the same issue? For me it looks like a bug in the Vera Lite Firmware.
Thanks for help

I don’t have a Vera Lite or the new RFXtrx433 XL so I can’t really test anything. I do have another serial device which I’ve connected to my Vera Plus using a USB hub and it works fine. It uses the FTDI ft232rl chip. I don’t know what the RFXtrx433 XL uses.

edit: my problem disappeared after a Luup reload.

:slight_smile: :slight_smile:

@tinman: Thanks, I gave up with the vera light. I ordered a vera plus, which came today, plugged it in, connected the RFXtrx433xl and it worked immediately with trunk51 files and the described steps. Looks like the vera light has an issue with it.


@ Evel Knievel: I see your problem too late because I order a 433XL for my Vera lite. And I confirm that I’m in the same case than you. With my previous RFXTRX433 (w/o Somfy compatibility), no problem for several years. With this new XL, Serial Port Configuration desesperatly stays empty on Vera Lite with UI5 (“connect your device on USB and restart luup engine”).
I also try UI7, changing RFX firmware and use an external USB supply without sucess.
Here is the answer from RFXcom team “The RFXtrx433XL has another FTDI chip but it is compatible with the FTDI in the RFXtrx433. The FTDI driver supports both.”

On my side I change for RFXtrx433E which has been already tested succesfully on UI5 and Veralite.