Trying to *send* X10_DS sensor TRIGGER/UNTRIGGER messages...

Plugins & Plugin Development USB RFXtrx Transceiver
#1

As per the title, in order to integrate my new zWave alarm items with my existing X10 Alarm while I am slowly replacing it, I am trying to “fake” the replaced sensors’ signals, to trigger the expected events on the existing alarm.

I can see the messages come in, but if I copy that message to the 'SendMessage" command, it sends a totally different message:

JobHandler_LuaUPnP::HandleActionRequest argument Message=08 20 00 00 3A 35 31 02 59 <0x307fe680>
luup_log:120: RFXtrx: debug: Action SendMessage: message to send: 08 20 00 00 3A 35 31 02 59 <0x307fe680>
luup_log:120: RFXtrx: debug: Sending command: 08 02 00 02 00 00 3A 03 05 <0x307fe680>

JobHandler_LuaUPnP::HandleActionRequest argument Message=08 20 00 01 3A 35 31 00 59 <0x2bf65680>
luup_log:120: RFXtrx: debug: Action SendMessage: message to send: 08 20 00 01 3A 35 31 00 59 <0x2bf65680>
luup_log:120: RFXtrx: debug: Sending command: 08 02 00 03 00 01 3A 03 05 <0x2bf65680>

I can’t find what is happening, and why!

Also been looking at SendCommand, but AFAICT from the code, that is limited to very specific commands…

If anyone can point me in the right direction, that’d be appreciated!

Sending "raw" data
#2

Ok, after studying the code, I realized: no spaces…

Still doesn’t seem to work though… :frowning:

08 07/15/18 0:03:13.002 JobHandler_LuaUPnP::HandleActionRequest argument Message=082000003A35310059 <0x2b785680>
50 07/15/18 0:03:13.003 luup_log:120: RFXtrx: debug: Action SendMessage: message to send: 082000003A35310059 <0x2b785680>
50 07/15/18 0:03:13.004 luup_log:120: RFXtrx: debug: Sending command: 08 20 00 03 3A 35 31 00 59 <0x2b785680>
50 07/15/18 0:03:13.753 luup_log:120: RFXtrx: debug: Received message: 04 02 01 03 00 <0x2f5dd680>
06 07/15/18 0:03:13.754 Device_Variable::m_szValue_set device: 120 service: urn:rfxcom-com:serviceId:rfxtrx1 variable: LastReceivedMsg was: 04 02 01 02 00 now: 04 02 01 03 00 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2f5dd680>

08 07/15/18 0:05:52.927 JobHandler_LuaUPnP::HandleActionRequest argument Message=082000003A35310259 <0x3021e680>
50 07/15/18 0:05:52.927 luup_log:120: RFXtrx: debug: Action SendMessage: message to send: 082000003A35310259 <0x3021e680>
50 07/15/18 0:05:52.928 luup_log:120: RFXtrx: debug: Sending command: 08 20 00 04 3A 35 31 02 59 <0x3021e680>
50 07/15/18 0:05:53.683 luup_log:120: RFXtrx: debug: Received message: 04 02 01 04 00 LEAK this:4096 start:946176 to 0x1705000 <0x2f5dd680>
06 07/15/18 0:05:53.684 Device_Variable::m_szValue_set device: 120 service: urn:rfxcom-com:serviceId:rfxtrx1 variable: LastReceivedMsg was: 04 02 01 03 00 now: 04 02 01 04 00 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2f5dd680>

#3

I might be able to help but I need more details about exactly what you are trying to do.
I think you are trying to use the RFXtrx to send X10 messages.

  1. What are you doing with Vera and/or the RFXtrx plugin to send these messages?
  2. Exactly what X10 device are you working with?
#4

I have an older X10-based Marmitek alarm, and we just replaced our windows and doors (and frames) with composite, and the original X10 door/window sensors were taken out together with the old frames…

So for the new composite doors/windows/frames I am using Sensative Security Strips (they work fine with Vera boxes, even on UI5, once you’ve tweaked the settings and installed 1.5.672) as they’re invisible.

Now I want to use the RFXTRX to send/emulate the DS10E/BNL ‘trigger’ and ‘untrigger’ signals to the X10-based Marmitek 9509 alarm system, until such time that I can completely replace the alarm with a Z-Wave based system, whenever the Sensative Security Strips trigger/untrigger…

(Does that help? Or do you need more information?)

#5

So I have found out that:
08 20 00 xx 3A 35 31 yy 59

08 20 00 ← X10sec message size and type
xx ← sequence#
3A 35 31 ← DS10E address
yy ← Action (00 - untrigger / 02 - trigger)
59 ← Battery level % (I think)

#6

Have you modified the plugin code to be able to send that message? If you have I’d suggest trying again but replacing the last byte (59) with 00. The transceiver sends that info based on the signal it receives but expects it to be 00 when sending.

#7

No plugin code modification (at least for this one!) yet… Would have to spend some time getting to understand the codebase before I could make changes w/o decreasing the WAF

#8

Hey @Tinman, any ideas?

#9

No, not yet. I’ve been experimenting with adding code to a scene to try to send the messages. No luck so far. My attempts so far either fail or cause the serial port to lose its connection to the transceiver.

#10

Ah, ok… Thanks for trying!!!

I have a temporary workaround, but it is an ugly kludge: I connected a KIKA potential-free switch to an X10 door/window-sensor, so I can trigger that, but it isn’t the most reliable solution!

#11

You might try this from the Vera Apps → Develop Apps → Test Luup code (Lua) dialog:
luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “082000003A3531xx00”}, yyyy)
where xx is either 00 or 02 and yyyy is your RFXtrx device number

If this works you should be able to use it as lua code in a scene triggered by your new sensors.

#12

I’m currently travelling, but will test this when I get home! Thanks a bunch!

#13

Tried:
luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “082000003A35310200”}, 120)

(120 being my RFXTRX device#)

Log shows:
08 08/13/18 9:15:44.019 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: RunLua <0x2ff0c680>
08 08/13/18 9:15:44.019 JobHandler_LuaUPnP::HandleActionRequest argument Code=luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “082000003A35310200”}, 120) <0x2ff0c680>
08 08/13/18 9:15:44.020 JobHandler_LuaUPnP::HandleActionRequest device: 120 service: urn:upnp-rfxcom-com:serviceId:rfxtrx1 action: SendMessage <0x2ff0c680>
08 08/13/18 9:15:44.020 JobHandler_LuaUPnP::HandleActionRequest argument Message=082000003A35310200 <0x2ff0c680>
50 08/13/18 9:15:44.020 luup_log:120: RFXtrx: debug: Action SendMessage: message to send: 082000003A35310200 <0x2ff0c680>
50 08/13/18 9:15:44.021 luup_log:120: RFXtrx: debug: Sending command: 08 20 00 0F 3A 35 31 02 00 <0x2ff0c680>
50 08/13/18 9:15:44.775 luup_log:120: RFXtrx: debug: Received message: 04 02 01 0F 00 <0x30964680>
06 08/13/18 9:15:44.776 Device_Variable::m_szValue_set device: 120 service: urn:rfxcom-com:serviceId:rfxtrx1 variable: LastReceivedMsg was: 04 02 01 0E 00 now: 04 02 01 0F 00 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x30964680>
06 08/13/18 9:15:44.777 Device_Variable::m_szValue_set device: 120 service: urn:micasaverde-com:serviceId:HaDevice1 variable: CommFailure was: 0 now: 0 #hooks: 0 upnp: 0 v:0x10f1d00/NONE duplicate:1 <0x30964680>
50 08/13/18 9:15:44.777 luup_log:120: RFXtrx: debug: cmds: <0x30964680>

But the alarm did not make the typical ‘door opened’ ping… :frowning:

Thanks for trying, but it looks like i’m stuck with the kludge until I replace the X10 based alarm unit!..

#14

When I send:
luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “08200207aabbcc0D00”}, 120)
(where aabbcc is the code of my SRsomething alarm remote)

I can successfully disarm the alarm, so the code itself is being transmitted, as per the log:

08 08/13/18 13:56:01.367 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: RunLua <0x2ffd2680>
08 08/13/18 13:56:01.367 JobHandler_LuaUPnP::HandleActionRequest argument Code=luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “082002071C136B0D00”}, 120) <0x2ffd2680>
08 08/13/18 13:56:01.368 JobHandler_LuaUPnP::HandleActionRequest device: 120 service: urn:upnp-rfxcom-com:serviceId:rfxtrx1 action: SendMessage <0x2ffd2680>
08 08/13/18 13:56:01.369 JobHandler_LuaUPnP::HandleActionRequest argument Message=08200207aabbcc0D00 <0x2ffd2680>
50 08/13/18 13:56:01.369 luup_log:120: RFXtrx: debug: Action SendMessage: message to send: 08200207aabbcc0D00 <0x2ffd2680>
50 08/13/18 13:56:01.370 luup_log:120: RFXtrx: debug: Sending command: 08 20 02 0B aa bb cc 0D 00 <0x2ffd2680>
50 08/13/18 13:56:02.136 luup_log:120: RFXtrx: debug: Received message: 04 02 01 0B 00 <0x30a2a680>
06 08/13/18 13:56:02.137 Device_Variable::m_szValue_set device: 120 service: urn:rfxcom-com:serviceId:rfxtrx1 variable: LastReceivedMsg was: 04 02 01 0A 00 now: 04 02 01 0B 00 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x30a2a680>

So I see no difference between the two, but the first doesn’t seem to work, whereas the second one does…
(Still researching!)

#15

I may have found something… The alarm keeps track of the sequence number, and the one the real sensor uses is different from the one the simulated one (with the same ID) uses…

I will try later to add a new virtual sensor (ie different hex ID) to the alarm…

#16

Using this code:

luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “082000003AEFE90279”}, 120)
luup.sleep(5000)
luup.call_action(“urn:upnp-rfxcom-com:serviceId:rfxtrx1”, “SendMessage”, {[“Message”] = “082000003AEFE90079”}, 120)

Successfully added a new sensor to the old alarm… So it was the sequencing that screwed it up…
After that (in normal alarm mode) it gave the “door open” ping…

SUCCESS!!!

Thanks a bunch for putting me on the right track!