HOME › Forums › Controllers › SmartLabsPLM › PLM and HOP Count
-
AuthorPosts
-
Anonymous
InactiveDecember 9, 2010 at 2:46 pmPost count: 6I’m posting this here because you folks seem to know more then the other sites including the manufacturers site. Sorry for the slightly off topic post.
Im writing my own interface to the PLM and I have recently introduced RF into the test bench. I’m now seeing that the PLM is passing up duplicate packets except for the hop count is lower. I was assuming the PLM would handle disposal of dup packets but its passing them along. It also seems that the first packet recieved has a lower hopcount then the second so I suspect the RF is getting to me faster then the powerline. Anyway to stop the PLM from passing dupes or am I doomed to write a complex packet handler. On the surface it sounds easy but the packets are out of order and if the software does a retry it needs to expect the same packet. Its gonna be a pain.
02 51 0E 93 20 14 83 0C 11 2F 00 01 01 0F F7 01 A2 01 14 83 0C FF 00 00 00
02 51 0E 93 20 14 83 0C 16 2F 00 01 01 0F F7 01 A2 01 14 83 0C FF 00 00 00If I am stuck writing the handler what would you folks recomend for a buffer timeout and what method of compare would you recomend, for example byte by byte compare or checksum compare? Any recomendations are appreciated.
Thanks
JimInactiveDecember 9, 2010 at 11:44 pmPost count: 1001What hop count did you use on the initial PLM serial call. The Controller will bump the initial hop count if it retries a command due to a lack of response. The hop count does not matter as far as determining the messages are logically duplicate. If nothing else the link record address is the same in both ALDB responses. I know of no way to prevent or suppress what you are seeing. Process the first and ignore the second as a duplicate. You may get some ideas from other users on the Smarthome forum. There are a number of users writing their own PLM interface code. As far as a check sum I don’t know what you would compare it against. There is no way to know what the source message looked like coming from the device the ALDB command was originally sent to.
InactiveDecember 10, 2010 at 12:30 amPost count: 6As you say process the first and ignore the rest. Its logically easy but technically difficult. It can be done I was just hoping I didn’t have to. The logic will have to be something like recieve the message. Store the message in a buffer ignoring the flag byte. Recieve the next message, compare current message to all messages stored in the buffer. Remove old messages from buffer after ?? ms. My traces show the dupes are arriving ~450 ms apart but Im not sure what the max could be. Maybe ~1000 ms at 3 hops? Each item in the buffer will need its own time stamp so it can be removed independantly.
Im also not sure how this will effect retries. If a command is lost I resend the command, if the buffer clears too slowly or too quicky then messages will probably be duped or dropped.
Im sending with 3 hops. The device is getting the command and responding cleanly. It appears that the RF reply is getting back to the PLM before the normal Powerline reply because the message with the lower remaining hop count gets recieved first.
Thanks for the help!
JimInactiveDecember 10, 2010 at 1:04 amPost count: 1001You may be making this more complex than it needs to be. The first message back is processed as valid. There may never be another message so waiting to see if a duplicate will arrive is waiting for something that may never occur. If another ALDB message is received it is analyzed against “is there is pending ALDB response expected”. If not then it is ignored as a duplicate. You will see multiple Group Broadcast messages from RF based devices such as Motion Sensors, TriggerLincs and RemoteLincs. Also the Controller has already retried a command if a response it not received or a NAK is received. There is no reason for the application to retry more than the Controller has already done before the application receives the final NAK.
The exception would be the ALDB request. Some devices indicate I2 engine support but do not send an ED ALDB 2F response. Some HA applications will reissue the ALDB request after waiting a few seconds just to be doubly sure the device will not respond with the ED ALDB message. The application must resort to the old Peek/Poke method under these conditions. The exception to going back to the Peek/Poke method is where a Motion Sensor or TriggerLinc is being accessed. These two device types did not implement Peek/Poke so should an ED ALDB response fail to come back it must be taken as a permanent error.
InactiveDecember 10, 2010 at 1:50 amPost count: 1001Jim
Something that may make PLM programming easier to approach. There will not be multiple commands stack up in the PLM or executed waiting for a response. Basically it is issue a command. get a response (which could be multiple messages in response), issue the next command, get the next response. Multiple Group commands cannot be initiated. Insteon will allow only one Group sequence to be active at a time. This is true even for device to device. If a paddle/button is pressed involving several responders and another paddle/button is pressed on another device which initiates another Group sequence, the current group sequence will be aborted in favor of the new one. Generally this has no visual effect since the initial Group Broadcast will cause all responders to react so the follow-up Group Cleanup messages that are cancelled would normally be redundant.
Lee
-
AuthorPosts
- You must be logged in to reply to this topic.