Not sure I understand the question. Abandoning unfinished group command cleanup to process new traffic is part of the Insteon protocol.LarrylLix said:How did you figure that one out? That is a pretty obscure event. Sent using Tapatalk
Is there some link to information describing that? Most of SmartHome papers are just whitepapers and not even what SH produced. This is why it couldn't be hacked by DefCon in their 2015 demonstration. None of the specs were accurate in the whitepapers.upstatemike said:Not sure I understand the question. Abandoning unfinished group command cleanup to process new traffic is part of the Insteon protocol.
I will have to look for it... read it years ago. The gist was that Insteon sends a group command which is not acknowledged and then follows with a direct command to each member of the group and retries those if there is no response. The idea is that the group should respond instantly to the first command but the cleanup process would take care of any device that missed the group command as well as use the acknowledgements to update the controller that the entire group responded. This takes a long time so there is a provision to terminate the cleanup process as soon as new commands are heard in order to reduce collisions. Problem is any large system will likely have a lot of traffic all the time so cleanup would rarely complete. Especially if you have a controller that set to send a group off command to giant scene 1 and a group off to giant scene 2 at a certain time each day. The cleanup process for giant scene 1 would probably never complete because the new traffic to giant scene 2 would always interrupt the cleanup process. In theory a faster processor coupled with some better command queuing in the PLM could resolve this.LarrylLix said:Is there some link to information describing that? Most of SmartHome papers are just whitepapers and not even what SH produced. This is why it couldn't be hacked by DefCon in their 2015 demonstration. None of the specs were accurate in the whitepapers.
As I understand it, the scene cleanup process shouldn't make any difference either way. The command has already operated the devices and a faster CPU shouldn't help handling a protocol snag in process. It's been a long time since I read any of that nitty gritty and I always figured I would build a monitor for Insteon with my spare PLM.
I grabbed a spare PLM years ago after hearing so many problems with them but I have never had any problem with my five year old unit,... yet. I think it takes two problems. Weak power supply capacitors and a bad power grid to push them over the edge. I know of some that claim over 5-6 bad PLMs so far.
The problems are all in the PLM so I don't see Polisys making any difference to anything to do with Insteon. Might eventually be good for Universal Devices to only develop on a single hardware platform but I don't see where it makes any difference to me as a consumer whether the functionality is in one box or a combination of two. I just want to get to where I can press a button on an Insteon Keypad and have my Lifx bulbs turn on to a specific color.LarrylLix said:I was wrong on the PolISY units in that will not come with ISY firmware, initially. They will only come with Polyglot installed. Apparently a lot of code needs to be converted due to things like little endian vs big endian, switching OSes or hardware. Sent using Tapatalk
No. I was just mentioning it because I had told you incorrectly before about PolISY.upstatemike said:The problems are all in the PLM so I don't see Polisys making any difference to anything to do with Insteon. Might eventually be good for Universal Devices to only develop on a single hardware platform but I don't see where it makes any difference to me as a consumer whether the functionality is in one box or a combination of two. I just want to get to where I can press a button on an Insteon Keypad and have my Lifx bulbs turn on to a specific color.