Plugin for the USB RFXtrx from RFXCOM

Here is how I see the plugin to be as generic as possible. This is not very structured !
There will be a main device with files D_RFXtrx.xml D_RFXtrx.json I_RFXtrx and S_RFXtrx files. We could implement in particular the reset function on this device.
Then there will be one child device for each kind of message managed by the RFXtrx. For example, for the TEMP2 message, we will define a TEMP2 device with files D_RFXtrx_TEMP2.xml and S_RFXtrx_TEMP2.xml files. An additional json file will be required for other kind of message. This device will of course implement the generic temperature service too. The RFXtrx_TEMP2.xml will define all the variables included in the TEMP2 message. Decoding a TEMP2 message will then consist in identifying the correct TEMP2 device from ID (create automatically the device if inexistent) and set all the TEMP2 variables, finally the temperature will be set from one (or severa) of these variables. There will be a decode function that set the variables + a encode function that build the message from variables (to send commands, for example to switch light ON or OFF). A function will get the ID from the message too. The device altid format could be RFXtrx__, for example RFXtrx_TEMP2_47603 where 47603 is the ID included in the message. For sending command, the service will define a “high-level” action. The action will consist in setting variables on the child device and then call the encode and send functions.

Is it clear and what do you think about that ?

My USB RFxcom is shipping tonight, so expect some input from me soon :wink:

As a user or as a developer for the plugin ?

Both :slight_smile:

Finally, that makes a lot of people for one plugin :slight_smile:

Quniten, what kind of devices do you manage with the RFXtrx ?
Do you have already an experience with Vera plugin development (that is not my case) ?

redeyedrob, any news on your side ?

Now I hesitate to start, that would be waste of time if everybody spend time to do the same thing.

I will be using the RFXcom mainly to see the events my Visonic alarm generates, and hopefully the messages from my Bye Bye Standby switches. Cherry on top would be some control of Bye Bye Standby modules, but that’s not essential since I am replacing those with Zwave at the moment.

I’ve developed (well, copied and modified an existing plugin) a plugin to update my MySQL database with events from the VeraLite. No where near ready for release, and I am still picking up on plugin development as I go along. I am a software developer by trade though (C), so once I get the hang of Lua and UPNP, I should have no problem churning something useful out.

I have had a little more time, and have been wasting it pursuing my bottom up approach…

Having satisfied myself I couldn’t tlak to the RFXtrx via straight ssh commands, I moved onto Lua.

Good news is I’ve satisfied myself I can’t talk to it in Lua either :wink: Serial port comms in reference Lua are handled as files, no problem setting up the RFXtrx as a file and opening it for read and write, however once the reset and status commands were sent and I tried to read the response it just hangs. I suspect serial settings are the issue again.

Plenty of third party serial comms libraries, some of them fairly popular but I didn’t want to start messing with things that aren’t on the box by default.

This leaves me up at the level I should have started at - Luup :wink:

I started looking through some other plugins, not really got my head around the structure yet - I could say your approach makes sense lolodomo but frankly that wouldn’t be much of an endorsement at this stage. I’m away tonight, however next time I get a chance I’m going to try and write myself a hard coded on / off button for some switches I can see from my PC. Once I’ve actually made the thing signal something from the Vera I’ll be considerably less frustrated. Certainly don’t hold back on doing anything on my account, if I do anything I’ll post it here.

I’m running a Vera 2 - will check firmware later, however the Micasa guys reinstalled it remotely themselves because my ZWave dongle wasn’t working. I’m on UI4.

Thinking about it, my feeling is that we could (should) have shared files between the RFXLAN and RFXtrx plugins, at least for the files required to describe the specific devices.
But the merge could be done in a second time… First, let’s try to communicate with the RFXtrx.

I’ve just plugged my RFXtrx in a (powered) USB hub, but although I have the device created, I am not seeing any of those messages that you both see?

[font=courier]root@MiOS:~# dmesg
root@MiOS:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0001
root@MiOS:~# ls -la /dev/ttyS*
crw-rw-rw- 1 root root 4, 64 Mar 1 23:11 /dev/ttyS0
crw-rw-rw- 1 root root 4, 65 Jan 1 1970 /dev/ttyS1
root@MiOS:~# ls -la /dev/usb*
crw-r–r-- 1 root root 189, 0 Jan 1 1970 /dev/usb1
crw-r–r-- 1 root root 189, 128 Jan 1 1970 /dev/usb2
root@MiOS:~#[/font]

What gives? I’m running on a VeraLite with UI5 btw.

Doh! Forgot to plug my USB hub back into the VeraLite when I disconnected it to pair it with a new module…

[font=courier]root@MiOS:/tmp/log/cmh# dmesg
usb 1-1: new high speed USB device using rt3883-ehci and address 2
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.1: new high speed USB device using rt3883-ehci and address 3
hub 1-1.1:1.0: USB hub found
hub 1-1.1:1.0: 4 ports detected
usb 1-1.4: new full speed USB device using rt3883-ehci and address 4
ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
usb 1-1.4: Detected FT232RL
usb 1-1.4: Number of endpoints 2
usb 1-1.4: Endpoint 1 MaxPacketSize 64
usb 1-1.4: Endpoint 2 MaxPacketSize 64
usb 1-1.4: Setting MaxPacketSize 64
usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
root@MiOS:/tmp/log/cmh# ls -ltr /dev/tty*
crw-rw-rw- 1 root root 5, 0 Jan 1 1970 /dev/tty
crw-rw-rw- 1 root root 4, 65 Jan 1 1970 /dev/ttyS1
crw-rw-rw- 1 root root 188, 0 Mar 1 23:27 /dev/ttyUSB0
crw-rw-rw- 1 root root 4, 64 Mar 1 23:29 /dev/ttyS0
root@MiOS:/tmp/log/cmh# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 1a40:0101
Bus 001 Device 003: ID 1a40:0101
Bus 001 Device 004: ID 0403:6001
root@MiOS:/tmp/log/cmh#[/font]

I have prepared the minimum lua code to start first tests, meaning initialization of the communication with the RFXtrx + trace of received messages from the RFXtrx.
Remains the XML files to do.
I should be able to make the first tests tomorrow evening.

[quote=“lolodomo, post:31, topic:170604”]I have prepared the minimum lua code to start first tests, meaning initialization of the communication with the RFXtrx + trace of received messages from the RFXtrx.
Remains the XML files to do.
I should be able to make the first tests tomorrow evening.[/quote]

You’re already one step ahead of me… Please keep us posted!

Good work.

If you are happy with the results then it would be good to post the files, I’ll hopefully have some time over the weekend - if you’re happy with your files I’ll work with them, if not I’ll start from scratch.

The question I am asking myself is: shall I create directly children device using usual temperature and humidity devices, meaning without the ability to add variables to store additional information (last update for example) ?
Or shall I first create a new child device specific to the plugin used for temperature/humidity that will store some data and then create the usual temperature and/or humidity devices as children of this new device ? We would have a tree with 3 levels instead of 2.

I will probably start with the first approach (because easiest), it is how it is done in the current RFXCOM plugin.

It’s working 8) Sending and receiving commands.
Until now I only log messages and partially decode temp/hum messages.
Next step is finishing at least the decoding of temperature and humidity messages received and clean my code.
Then I will publish my files (certainly during the weekend).

Finally, I took full of code from the original RFXCOM plugin to manage device children.
But it looks like there is a problem when creating several children with the same id. After syncing, some child are lost and mixed up.
Is it a know bug with UI5 (1.5.254) ?
Do we have to always use different ID (altid) ? In this case, I think the original RFXCOM can not work properly because temprature and humidity devices will have the same id for the same sensor.

Hello Lolodomo,

I’m debuging RFXCOM Plugin and I have the same issue with altid who have the same for Temp and Humidity.
I think we need to rewrite the creation of device look at Mochad X10 plugin who have a good implementation.

Here are my files. Of course, it is not finished and enhancements are possible, but it is now working with temperature and humidity sensors.

After uploading the 4 files (the lua file must not be compressed), you have to create a new device using the file D_RFXtrx.xml and setup the serial port for this new device. The serial port must be set to 38400 bauds (not yet verified by the plugin).
To enable the child creation (for creation of temperature and humidity devices), you have to set the variable AutoCreate to 1 in the device advanced settings.

Edit: a new version is available below in this topic

I haven’t forgetten about this… I downloaded the files, looked at them in an editor, but then I got distracted again by other stuff, so I haven’t actually given them a try. Have you progressed with them at all?

The only changes I made are relative to prefix. There were mismatches, sometimes I used “XX_” sometimes “XX/”. But the plugin is working well even with these “errors”.
Nevertheless I know my function findChild has to be corrected because it could fail in certain particular cases (depending on the ID of sensors).
I had no time to progress since the beginning of the week.

Here is my current TODO list:

  1. correct the function findChild (full matching from position 4 to the end of the string)
  2. check at startup the characteristics of the serial connection (bauds, parity, …)
  3. manage the result of “Get Status” command (and store in variables the protocols decoded by the RFXtrx))
  4. manage barometer data (new device to display pressure)
  5. manage the setup of the RFXtrx through the plugin (manage “Set Mode” command)