RandyKnight said:
bfisher said:
After using it for a couple days, you hardly notice it anymore. However, for guests (and in-laws), it is a little confusing.
I have to disagree with this (though it's a preference thing). We've had our UPB stuff installed for over a month and it still bugs us.
Me too. We used some UPB switches for a few months and the local control delay is what made us rip them out. Even after a few months we still hadn't become used to this highly irritating "feature".
I could understand the switches taking the time to detect the difference between a single or double-tap on a device where they were programmed to do two different things. If they do the same action then the artificial delay is a pure nuisance.
If they solved that then I'd be seriously considering dumping our Insteon switches and replacing them with UPB ones. Well, except for the SA ones being too big for our J-boxes that is. The HAI ones I tried were smaller and fit ok, but I hated the feel of them. They felt "cheap" to touch.
What drives me crazy about Insteon is
- The PLCv2 is unbelievably dog slow and cripples PC interaction with the network
- Bugs, Bugs, Bugs!
- Things the designers forgot. (eg: you can't include an 'off' level in a scene. eg: you can't have 3 lights turn on and 1 turn off when you activate a scene - It appears you have to do things like having the scene turn it "on" to 3% dim instead of off. Not to mention the dual-linking hack to work around missing status reports, etc)
- Unfixed hardware problems that would have turned up in 3 seconds in a real world beta test before they started their mass production runs. (eg: appliancelincV2 fiasco, switchlincV2 microswitches wearing out under heavy use or in bathrooms, or the firmware turning "on" after power glitches that crash the onboard microcontroller)
- Don't get me started about the fake security system that achieves little apart from making life hard for programmers. (By fake, I mean the packets on the network are cleartext and unprotected. The PLCv2 censors the computer's view of the packets. You lose debugging ability and gain very very little, especially when there are old revisions of the PLCv2 with broken censorship handy. Or signalinc-RF's that don't implement pairing at all and will repeat with anything in range, regardless of the set button.)
I'm still waiting for switchlincv2-relay version 2.2 to ship so I can get accurate status reports from the kitchen. My wife presses both switches at the same time and causes a collision. The broken retransmit mechanism means both switches retransmit at exactly the same time and never succeed. The firmware in 2.2 switchlincV2-dimmers supposedly fixes it, but that hasn't made it to the -relay version after something like 6 months now.
The real crying shame is the extended message issue that KenM alluded to above. It's what turns link verification on a large network from an operation that should take a few minutes into an operation that takes hours. We should be able to read 14 bytes per packet instead of 1 byte per two packets and so on. Combined with the dog slow current revision of the PLCv2 and this is especially bad.
The most frustrating part is that they dont seem to test their fixes in the real world. eg: they made TWO revisions to the appliancelincV2 without testing in the environments that are known to kill them. So they committed to production runs of "fixed" products that didn't actually fix it. This is not the only case where this has happened, but it is the most graphic example.
X10 (unreliable), UPB (delays), Z-wave (closed system) and Insteon (bugs) all suck. I'm starting to like the idea of hard wired systems.
