RFXCOM for xPL

[Snedig]

Hi, and thank you for a very exciting piece of software:)

I recently got one of the new RFXCom LAN transceivers in the mail, and it's proving itself as a fantastic bit of kit:)

There are a few issues I've been having with the plugin though, which I thought I'd mention so someone a bit more competent in Python might have a look at them:)

Firstly I had a hard time getting it to respond to any xPL-commands issued from EG at all. I managed to sort this out in the end by changing the XPL-reporting name in the plugin. Also it wouldn't respond to any xPL-messages sent directly to the RFXCom. The latter issue I still haven't nailed down. I think the first issue may have been caused by the EG xPL-name being too long, as anything short seemed to work fine - am I right in this? I saw somewhere a reference to xPL wanting reporting names of 8 characters or less?

The second issue is a little less of a showstopper, but a bit tricky - I have through trial and error had to write my own parser that spits out events on incoming sensor messages from a bunch of Oregon Scientific sensors. There might be an easier way to do this, but I haven't figured out any useful way of defining wildcards in events, so when a sensor sends an xPL-command, it will look something like:

Code: Select all

xPL.xpl-trig:sensor.basic:rfxcom-lan.0004a31bb683:*:device=th1 0xcc01,type=humidity,current=51,description=comfort,

I've managed to make a small parser for this that spits out events on recieved sensor signals that look like this:

Code: Select all

Main.humidity.Temp/Hygro1 [b]'51'[/b]

The entire script looks like this:

Code: Select all

sensorcall_payload = eg.EventString
sensorcall_list = sensorcall_payload.split(":")
sensorcall_type = sensorcall_list[1]
def sensors():
    return collections.defaultdict(sensors)

#if sensorcall_type == "sensor.basic" :
sensorcall_data = sensorcall_list[-1].split(",")
if sensorcall_data[0] <> "" :
    sensor_name = sensorcall_data[0].split("=")
if sensorcall_data[1] <> "" :
    sensor_type = sensorcall_data[1].split("=")
if sensorcall_data[2] <> "" :
    sensor_data = sensorcall_data[2].split("=")
if sensorcall_data[3] <> "" :
    sensor_more = sensorcall_data[3].split("=")
    eg.sensors.setdefault(sensor_name[1], {}).setdefault(sensor_type[1], {})[sensor_data[1]] = sensor_more[1]
else :
    eg.sensors.setdefault(sensor_name[1],{})[sensor_type[1]] = sensor_data[1]
print sensorcall_data[0]
print sensorcall_data[1]
print sensorcall_data[2]
if sensorcall_data[3] <> "" :
    print sensorcall_data[3]
if sensor_name[1] == "th1 0xcc01" :
    if sensor_type[1] == "temp" :
        eg.TriggerEvent("temperature.Temp/Hygro1",sensor_data[1])
    if sensor_type[1] == "humidity" :
        eg.TriggerEvent("humidity.Temp/Hygro1",sensor_data[1])
    if sensor_type[1] == "battery" :
        eg.TriggerEvent("battery.Temp/Hygro1",sensor_data[1])
if sensor_name[1] == "th1 0xee02" :
    if sensor_type[1] == "temp" :
        eg.TriggerEvent("temperature.Temp/Hygro2",sensor_data[1])
    if sensor_type[1] == "humidity" :
        eg.TriggerEvent("humidity.Temp/Hygro2",sensor_data[1])
    if sensor_type[1] == "battery" :
        eg.TriggerEvent("battery.Temp/Hygro2",sensor_data[1])
if sensor_name[1] == "temp1 0x1" :
    if sensor_type[1] == "temp" :
        eg.TriggerEvent("temperature.Temp1",sensor_data[1])
    if sensor_type[1] == "battery" :
        eg.TriggerEvent("battery.Temp1",sensor_data[1])
if sensor_name[1] == "uv1 0x1400" :
    if sensor_type[1] == "uv" :
        eg.TriggerEvent("UV.UV1",sensor_data[1])
    if sensor_type[1] == "battery" :
        eg.TriggerEvent("battery.UV1",sensor_data[1])

The obvious issue, for me, is that I have to define all sensors in code and make a corresponding event.

I think this would be made easier, although it would probably still require some scripted parsing, if the plugin parsed sensor data and sent it as a payload, maybe something like (payload in bold):

Code: Select all

xPL.xpl-trig:sensor.basic:rfxcom-lan.0004a31bb683:* [b]'device=th1 0xcc01,type=humidity,current=51,description=comfort,'[/b]

Or maybe even more ideal would be something like the line underneath, although I realize that might take a bit more parsing script in the plugin:

Code: Select all

xPL.xpl-trig:sensor.basic:rfxcom-lan.0004a31bb683:*:'device=th1 0xcc01,type=humidity [b]',current=51,description=comfort,'[/b]

Lastly, there seems to be an issue with ac.basic commands to dimmers in particular, which seems to be a bit more of an RFXCom issue, as when I try to add a dim action, the corresponding command in the plugin, and also in the documentation for the RFXCom xPL-implementation, is "preset". The RFXCom also responds with "command=preset" on dim commands. However, for me, they didn't appear to work before I changed the plugin script to send a "command=dim" instead of preset. While this seems to work fine, the RFXCom still sends an xpl-trig with "command=preset" as a reply.

Hope this is helpful, and thank you again for your work:)

[krambriw]

Hi there, good to hear you are using the RFXCOM

Myself I have the old models but as you say, they have worked perfect during the years.

To answer your questions, I think some needs Bert's attention. I will try to answer the onces related to the plugin itself. Maybe we also need some more rounds of discussion before we change any formats since we might break working solutions if we do it in the wrong way.

xPL wanting reporting names of 8 characters or less?

Bert?

Also it wouldn't respond to any xPL-messages sent directly to the RFXCom. The latter issue I still haven't nailed down

Have you checked the box "Show all raw xPL messages"?

if the plugin parsed sensor data and sent it as a payload

I see the point. Typically you would like to keep the event string as fixed and unique as possible, holding data enough to identify the source, in this case the sensor id. If the sensor only changes between two states like on/off it is also normally fine if this is part of the event string, you can then drag & drop the two events to a corresponding macro respectivly. With the type of sensors that changes a value dynamically to one of many possible, it would be better to put that value in the payload. You could then drop the event to a macro where you have a simpler script doing the evaluation.

Two alternatives:
- payload has value data: you can have a simple script and need one macro for each sensor
- payload has sensor id and value data: you need a more enhanced script but only one macro

I tend to think the first is best, it will give you a better overview in the tree structure

It would not be difficult to change this in the plugin but I'm not sure if someone already uses the current format and has built a parser like you did...

there seems to be an issue with ac.basic commands to dimmers

Bert?


Best regards, Walter

[b_weijenberg]

xPL wanting reporting names of 8 characters or less?

I suppose you mean the length of the Vendor ID and the Device ID. This is 8 at maximum.
As the plug-in uses the system name be sure that the system name has a length of max 8 characters.
http://xplproject.org.uk/wiki/index.php ... t_Messages

Also it wouldn't respond to any xPL-messages sent directly to the RFXCom.

I will check this and update the RFXLAN firmware.

there seems to be an issue with ac.basic commands to dimmers in particular

I will also check this and update the RFXLAN firmware.

I will let you know that the updated RFXLAN firmware is available. (I hope today)

[b_weijenberg]

an updated RFXLAN xPL firmware is available at http://www.rfxcom.com/downloads.htm

Both problems have been solved: ac.basic and commands send from EG

[Snedig]

Fantastic, may I commend you on your hands-on support Bert and Walter:)

Updating to test now - I will also see if I can make a slight hack to the plugin and post on the board for anyone interested for the alternate payload method, although no guarantees at this point;)

Edit: Will take me a little while to test this out, as I've forgotten to bring the correct USB-cable to flash the transceiver to the summerhouse where this is being implemented... /facepalm

[krambriw]

I will also see if I can make a slight hack to the plugin

I have already started. It's better we change it synchronized, otherwise we will have a mess with different versions/variants.
In the version I have right now, I issue an additional event with the payload. Finally there might be need for a checkbox in the settings to select what type/format you want (to make it backward compatible)

Best regards, Walter

[krambriw]

Please try this version. It provides an additional event with the sensor data in the payload

Also added a control of xPL Vendor ID, Device ID and Instance ID (Vendor ID max 8, Device ID max 8, Instance ID max 16 characters)

Best regards, Walter

__init__.py

(44.22 KiB) Downloaded 283 times

[Snedig]

Fantastic Walter:)

I did manage to hack it to my needs, but my version has the definite downside that it may not work if you have anything but Oregon Scientific sensors - yours looks better, and might cover other peoples needs more efficiently:)

I did make a slight alteration to it in the new block:

Code: Select all

                            #print ml
                            for i in ml:
                                msgbody4 = msgbody4+i+','
                            msgbody4 = msgbody4[0:-1]    # Cull last item in list (empty)
                            self.TriggerEvent(
                                xpltype
                                +":"
                                +msgschema
                                +":"
                                +xplsource
                                +":"
                                +xpltarget
                                +":"
                                +msgbody3
                                , 
                                payload = msgbody4
                            )
                            messageOld = message
                            # End new test

Since the list items are seperated by trailing commas, I added a line to remove the last (empty) item that is generated.

This pretty much makes my hack obsolete, although if anyone wants it to look through or for use in an Oregon Scientific-only environment, drop me a private post and I'll send it over:)

Best regards,
Preben

[krambriw]

Hi, good to hear that it worked.

I think it would be ok to use your formatting for the payload, I'll leave the old one as is. In the version I'm preparing, there is a checkbox where you select if you want the old format or the new with the payload. It seems to work fine also for simpler events like rf devices with on/off events

I suppose you mean the length of the Vendor ID and the Device ID. This is 8 at maximum.
As the plug-in uses the system name be sure that the system name has a length of max 8 characters.
http://xplproject.org.uk/wiki/index.php ... t_Messages

I read about this and according to the xPL specification it is like this:
# (Vendor ID max 8, Device ID max 8, Instance ID max 16 characters)

I will control this from now and also convert names to lower case, so typically a name could have number of characters like this:
aaaaaaaa-bbbbbbbb.cccccccccccccccc

Best regards, Walter

[krambriw]

Hello,

I have uploaded the latest version with the changes discussed above. To allow for backward compatibilty, there is now a check box that allows you to select if you want to have sensor data & specifics in the payload or if you like to stick with the old format.
I also changed some other minor things as you can read below. I personaly noticed that my Vista PC seemed to disconnect itself from the xPL network. As soon as I sent something from it, it was connected again. I therefore changed so that heartbeats are sent from eg every minute instead of every fifth. After that, it seems to be working fine. I haven't seen any other negative effects due to this (so far).

The new version is in the first post of this thread.

First time you use it, if you have the previous version, you will get an error message in the eg log window. Then double click on the plugin to view the configuration, set the new check box according to your preference, click ok and you should be fine. Don't forget to save...

Best regards, Walter


Version 0.7 with the following enhancements:
- Sensor data in the payload (selectable in settings with a checkbox)
- Heartbeat is now sent every minute instead of every fifth
- Control of xPL Vendor ID, Device ID and Instance ID (Vendor ID max 8, Device ID max 8, Instance ID max 16 characters)

[b_weijenberg]

New RFXLAN firmware version RFXxPL_2_04 .
On request we have changed the unit numbering in the ac.basic schema from 0-15 to 1-16

This is done to make the code in line with other products and schemas like x10.basic

After installing this new firmware version in the RFXLAN you have to do this once;
- increment all unit numbers in configured ac.basic devices by 1,
- upload the web pages in the RFXLAN.

http://www.rfxcom.com/downloads.htm

[dadaniel]

Is it possible to control Intertechno ( http://www.intertechno.at ) or RSL ( http://www.conrad.at/ce/de/category/SHO ... system-RSL ) devices with RFXCOM_xPL?

[b_weijenberg]

Intertechno with address code wheels (A-P/1-16) and with learning mode are supported.
RSL is not supported by the RFXLAN

[piert]

Bert,

I am searching for a way to remotely reboot my router.
Could this be done with the RFXCom Lan? I.e. is it capable of:

1. receiving a command from Eventghost and, via a Klik-Aan-Klik-Uit socket, interrupt the power supply to the router (this will of course directly result in the inability to send another command between EG and RFXCom).
2. wait 10 seconds
3. send an ON command to the Klik-Aan-Klik-Uit socket autonomously, thus 'reviving the router'.

[b_weijenberg]

could this be used?
http://www.intertechno.at/produkte/empf ... -1001.html

and connect this relais to the output of the CMR-1001 to invert the contact (normal closed, open if CMR1001 powered)
http://www.conrad.com/ce/en/product/502 ... Detail=005