EZServ response to EZSnsRF signal

[Anonymous]

#40080

I tried the manual linking method to link an RF input on the EZSnsRF to the EZServe so that I’d get an XML message on port 8002 for that event. The event I seem to be getting is an 0x27 LightSetStatus message rather than the group on I was expecting, here’s the dump output of my Java code with the hex:

LightSetStatus 2,50,d,fe,a4,7,0,aa,8b,27,1 from: (d:fe:a4) to address: (7:0:aa) flags: {0, 1, 3, 7}

Now when I linked the same EZServe to a button on a ControlLinc I got exactly what I was expecting:

LightOn 2,50,9,4c,df,0,0,2,c7,11,0 from: (9:4c:df) group: 0 flags: {0, 1, 2, 6, 7}

The address of the EZSnsRF is: 0D.FE.A4
The address of the EZServe is: 06.4D.EB
The address of the ControlLinc is: 09.4C.DF

Can anyone explain the reason for the different message? Can the EZServe be linked properly to the EZSnsRF via the button method?

[Anonymous]

#42353

Please refer to the paper on links and link records for the EZSnsRF available in our downloads section. If the code record is not linked, you get what you are seeing which is a status change broadcast message. Use our utility to set the “linked” bit so the broadcast message changes to a group message.

[Anonymous]

#42354

Thanks, I changed it and am now getting the group messages I expected. I think I’m finally on track to accomplish my project.

[Anonymous]

#42355

Just as an FYI, the breakdown of the ControlLinc message has a small error. The From: address 9.4C.DF is correct. The next three bytes are normally the To: address. In this case this is a Group Broadcast message so the first two bytes are always 0x00 0x00. The third byte of the To: address is the Group number, 2 in this case. The next byte is the flag byte. The On bit numbers are correct but normally presented in the opposite direction to match the charts in the Insteon docs (7, 6, 2, 1, 0). Bits 7&6 On, 5 Off (0xcx) indicate a Group Broadcast message. Next byte (0x11) is the Insteon command, ON in this case. The last byte of the Insteon message is the cmd2 value, 0x00 in this case.

LightOn 2,50,9,4c,df,0,0,2,c7,11,0 from: (9:4c:df) group: 0 flags: {0, 1, 2, 6, 7}

[Anonymous]

#42356

grif, thanks for the tip. I’ve changed my code so the output is now:

LightOn 2,50,9,4c,df,0,0,2,c7,11,0 from: (9:4c:df) group: 2 flags: {7, 6, 2, 1, 0}

Bit banging is a sick joke in Java – the language doesn’t even have an unsigned byte type.

There are some instructions for which cmd2 ends up being the group number, AssignToAllLinkGroup is one of them. Is there a way to determine from the flags whether CMD2 is a group, or does it have to be done on a case by case basic based on the value of CMD1?

Now I’ve just gotta figure out how to implement the Listener pattern once I’ve cracked all of these messages, but at least that’s a general comp sci instead of an Insteon problem…

[Anonymous]

#42357

You start with the Flag byte. A Group Broadcast message type has the Group number in the 3rd byte of the To: address. A Group Cleanup Direct message type has the Group number in the cmd2 field. A Direct message type content of cmd2 is command dependent. Generally not a Group number in Direct commands unless you are keeping track of Insteon commands that manage Insteon device links. For device control, such as turning on a device with a Direct command, cmd1 would contain a 0x11 and cmd2 would contain the Bright level, up to a 0xFF which is 100% Bright.

Over the years much of the basic Insteon message content has found its way into the public domain. On the SmartLabs site there is a public domain document, “Insteon Details”, which can be downloaded. Page 18 of that document has the best description of the Flag byte I have seen in a public document. Smartlabs does not publish a comprehensive list of commands and their content. You can purchase a Developer SDK membership from Smartlabs for about $200 but you have to sign a NDA.

[Author]

Posts