SmartHome puts new PLM v2.5 on sale $29.95

LarrylLix

Senior Member
Requests for information from Insteon reveal  Insteon stating they have fixed the power supply caps problems the older PLMs with v2.5 now.
 
It looks like Smarthome has PLM's on sale until 10/11/2019 for $29.99.  Coupon code: PLM29.  One per customer.
 
Starting at V2.4 they also used a new Serial Port Daughter Board. With an improved serial port interface chip with better ESD properties and protection on the Serial I/O lines to the outside world.
 
Needs a faster processor so it can complete the cleanup commands for large scenes before other traffic terminates the process prematurely.
 
LarrylLix said:
How did you figure that one out? That is a pretty obscure event. Sent using Tapatalk
Not sure I understand the question. Abandoning unfinished group command cleanup to process new traffic is part of the Insteon protocol.
 
upstatemike said:
Not sure I understand the question. Abandoning unfinished group command cleanup to process new traffic is part of the Insteon protocol.
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 sales page was not to informative. I believe if you dug deeper. The code expired on 10/11/2019 and ran from earlier in the week.
The sale was not well advertised.
 
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.
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.
 
To be fair I could be mis-remembering what I read. I also wonder if controllers like the ISY pay any attention to acknowledgements anyway. It seems like things get out of sync a lot between reality and what state the ISY thinks things are in (especially keypad button indicators). I have been blaming lack of good cleanup for this but maybe the controller is just assuming success and not even monitoring acknowledgements at all. Eventually I will go through and add a bunch of query programs to my controller to try to get it to better reflect what is on or off as well as some programs to detect when group members are not all in the same state and force them to match a group member that I designate as the master (one of the controllers for that group). I could also go through and insert delays between group commands in programs that send more than one. Seems like a lot of work though if the problem could be resolved by improving the PLM so it could process cleanup acknowledgements  faster/better.
 
Yeah. I have been thinking of writing Insteon monitoring software for my spare PLM. Not sure I am up to this anymore...LOL
 
I did this with X10, years ago and discovered a lot of quirks, including a Insteon / X10 device that was reeating X10 commands twice but using a previous house code combined with the preset device code. This made a mess of my system and I finally returned it as defective design. Aatrech was good about it. Hopefully it didn't end up in somebody esle's system.
 
Anyway, moral of the story is, there is nothing like a third party monitor for any HA, instead of trusting the device you are trying to check, to report honestly.
 
I did order a new PLM last week when they were on sale and I also ordered a Polisys and November is coming which is usually when I can find time to play with stuff like this. My plan is to upgrade my ISY to 5.x, replace the PLM, clean up my programs and add the monitoring stuff, and add the Polisys to the system to control some Lifx bulbs. After that I'll see if the accuracy of device status in the ISY improves any.
 
Also my third party monitor is relays on most critical loads that I otherwise would not notice right away if they were incorrectly reported as off by ISY (outside lights, basement lights, attic lights, etc.) The relay contacts are monitored by a Stargate which never, ever, fails to tell me the truth.
 
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
 
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
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.
 
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.
No. I was just mentioning it because I had told you incorrectly before about PolISY. 
 
PolISY will only make a significant difference to people who want to operate other protocols for HA  or remote control, or people wanting to write their own custom drivers(nodes) for PolyGlot and don't want two boxes, or even to use the cloud based Polyglot system.
 
Things are getting more CPU intensive for some tasks and the CPU power and possibly the multitude of ports will make a difference in the future.
 
Back
Top