Plugin for the USB RFXtrx from RFXCOM

[lolodomo]

I received today my RFXtrx. Not yet connected to the Vera. I just used the RFXCOM test application on my PC and unfortunately only 1 of my 3 new Oregon THGR122NX sensors is detected by the RFXtrx I don't understand what could be wrong...

Edit: the RFXtrx firmware dated the 7th of March correct my problem My 3 THGR122NX are now detected.

[redeyedrob]

RFXCOM guys are pretty quick on tech support - hopefully they can look into it.  There's a msgcode for "undecoded packet" in the SDK, maybe you could catch them and forward.

Tellsticks now support Oregon and they've got big compatibility issues too.

Also - it's worth trying limiting the packets it's receiving i.e. limit the different kinds of hardware it's scanning for, however I'd suspect this would be a reliability issue rather than a recognition one.

[lolodomo]

RFXCOM guys are pretty quick on tech support - hopefully they can look into it.  There's a msgcode for "undecoded packet" in the SDK, maybe you could catch them and forward.

Tellsticks now support Oregon and they've got big compatibility issues too.

Also - it's worth trying limiting the packets it's receiving i.e. limit the different kinds of hardware it's scanning for, however I'd suspect this would be a reliability issue rather than a recognition one.

I tried to check "undecoded packet" but I got no additional information.
I have already setup the RFXtrx to receive obly Oregon and La Crosse.
I hope that a new RFXCOM firmware could solve the issue.

I hope these 2 new sensors are working well, I have nothing to test them exceopt the RFXtrx.

[lolodomo]

Eventually! 

Looks like it's recognised :

hub.c: new USB device 00:03.0-1.2, assigned address 3
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)

What is the version of your Vera ?

Here is what I get:

Code: [Select]

+usb 2-1: new full speed USB device using rt3883-ohci and address 2
+ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
+usb 2-1: Detected FT232RL
+usb 2-1: Number of endpoints 2
+usb 2-1: Endpoint 1 MaxPacketSize 64
+usb 2-1: Endpoint 2 MaxPacketSize 64
+usb 2-1: Setting MaxPacketSize 64
+usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0
And it is recognized even behind my new little Amazon USB hub:

Code: [Select]

+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.2: new full speed USB device using rt3883-ehci and address 3
+ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
+usb 1-1.2: Detected FT232RL
+usb 1-1.2: Number of endpoints 2
+usb 1-1.2: Endpoint 1 MaxPacketSize 64
+usb 1-1.2: Endpoint 2 MaxPacketSize 64
+usb 1-1.2: Setting MaxPacketSize 64
+usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

[lolodomo]

Ok, after reading few parts of the wiki and go through few existing plugins (RFXCOM, Onkyo, Denon, Panasonic, Pioneer, ...), I think I have now the minimum basics to understand how it works and what is the role of each file.

I would say that the existing plugin is too different to mod it to fit the usb variant. I would start new, maybe using some elements. If made generic it would give a lot of great options (for example the lightwaverf stuff)

What is exactly your idea when you think of making it generic ?
We have to define child devices, but it seems it is already what is done by the current RFXCOM plugin. Do you imagine a different architecture to make it even more generic than that ?

[lolodomo]

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_<kind of message>_<ID>, 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 ?

[Quinten]

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

[lolodomo]

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

As a user or as a developer for the plugin ?

[Quinten]

Both 

[lolodomo]

Both 

Finally, that makes a lot of people for one plugin

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.

[Quinten]

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.

[redeyedrob]

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   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

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.

[lolodomo]

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.

[Quinten]

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?

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:~#

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

[Quinten]

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


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#