paulbates

I've had a few of these. Do you occasionally have the dreaded Insteon "All on" events"? Iolincs are vulnerable to "All On" events. I've used them to sense things, but hold short of using them for major house infrastructure control like turning water on/off. If closing the contacts means the water is on, you'll probably be ok as a random "all on" will simply turn on something already on. If it's the other way, it might unintentionally shut your water off. If you don't get "All Ons" then it likely won't be a problem. I've followed the endless forum thread of what to do about "all ons", did everything prescribed including removing all Insteon rf sensor devices, and I still get a couple a year. I you use it, i would add some "dead man" programs to detect an unintentional triggering of the iolinc.

👍 and I was not inferring the Canada or Celsius are wonky🤪. (I watched America try and fail at metric conversion in the 1970s and really wish we had finished the job). It's wonky to have to convert and convert back again.

Looks like you are in Canada? What the HomeKit Accessory Protocol (HAP) gives in a fast and local connection, it takes back in a reduced feature set and, well, 'wonkyness'. The ecobee is likely set in degrees F, but HAP ships the data in C. So the tstat values are converted from F in ecobee, converted to C for HAP and converted back to F in plugin/HA. So in the US in degrees F, the double conversion hurts. However, You can get the tenths on HA>Ecobee>Homekit device. There are sensor entities not exposed by the main controls presented in the default dashboard. Go to Developer Tools > States and paste in sensor.*_current_temperature. That will give you the ecobee entity to use to get degrees F in tenths, see below. Oddly, in another "wonkyness" moment, my remote ecobee sensor does report in tenths via the default entity. I'm not trying to steer this convo to HA; I'm guessing something like this is possible for the Ecobee HomeKit plugin.

@Guy Lavoie is correct. If it's a bathroom exhaust fan, it's an inductive load which can damage the switch, especially when initially starting it, as the inrush current is higher than when in running state. You'll have to look, but I'm fairly certain Insteon docs mention this. Since this is for the isy994 you'll need to get an Insteon on/off... the i3 paddle that can do both dimmer and on/off jobs isn't fully compatible with 994.

As @Guy Lavoie pointed out, iot manufacturers commonly adopt a "sell once, support forever" business model.. AND.. insist on a cloud API <- I'm not clear why on this part, probably to collect data on us. And then they realize they sold their product once, have no more revenue stream and yet have real costs to operate the infrastructure for their api and fix bugs and security problems. Or, sometimes plugin developers reverse engineer an iot manufacturers API and get it to work, eg there's no official API. Then one day the manufacturer changes or locks it. I've found UDI plugin developers to be clear about it when they are reverse engineering something. When the developer has to create the new API to solve the vendor breaking it, they spend real time doing real work to address the problem. And candidly, plugins are a "sell once, support forever" model. It's a risk of having a home automation system... any of them, not just a UDI product.

Green is that the conditions for the program are true. It may be running, the Then, or it may have completed the program steps for the Then. Either way, a solid green means the conditions of the program are true ... and remaining true. So it's going to be hard to give a straight answer without seeing the program and a short description of how it's expected to work. Another possibility tied with the eisy locking up report is that the program's "Then" has an infinite loop tied with a condition that is always true. Shutting it off, per @Guy Lavoie 's suggestion, will make that apparent. If you disable it, it can't loop and the eisy won't crash.

If your current mac is older and has an intel based processor, no that will not work. Apple is sunsetting development of the intel processor/silicone based software platform, MacOS. No more updates coming. What you can do: Do you have a Mac with Mac silicone = does it have an M1 - M5 chip? If yes, install the appropriate Java software for an Apple Silicone Machine... . then install the iox launcher. The Java installer typically picks the right version automatically. You're going to keep your older Intel silicon based mac (not M1 - M5 chip). Do nothing, as you are frozen at both MacOS and Java versions. Apple is not providing more updates to you. You keep using what you have the way you have it with no new improvements or security upgrades on the horizon. Think of the Intel Mac like the ISY994. UDI created the ISY994 many years ago and has moved on to new and improved products like the polisy and eisy. There's no changes or feature enhancements coming for the ISY994, yet many users still use them.

Crafting a state machine for each key function with its own state variables, and using "Init to" to constantly save current state in variables works very well. For your basement deodorizer, you could track start and end of a cycle with a single state variable by init-ing it to say 1 at the start and 0 when it exits. On the chance it happened to be turned on and the eisy rebooted (for whatever reason), you could have a run on start program... if the variable is 1 you'd know the deodorize has been running and needs to be shut off. You don't want this kind of thing happening when you're not home to catch it. IMO the ISY was designed with this in mind and extremely dependable and easily survives reboots when it's done right.

My guess you'll need to pull the stat off of its mounting plate and it will be there somewhere.

I think the idea we have in our heads about what Catch Up should do vs what it really does can be different things. I got unexpected results with it in my first ISY and since then I've always kept it off. An alternative is to use "init to" variable statements to save running states coupled with setting "run on start" for programs designed to insure things are in the right state after a reboot.

The network router / switch decides that. Devices get their vlan assignment during authentication: Wireless devices are assigned and routed when they have successfully authenticated ET ports assignments and routes are set by the router or managed switch they are plugged in to, and the device gets what it gets from that network side assignment

I'd try that simple, isolated example. Based on it working, or not, you can go from there.

One possibility is that the old PLM was dying over time.. this has happened to me. The way the polisy works is that it copies link info from the PLM to its master link table when it sees changes. As the PLM functions fail, the links get scrambled or polluted, and the polisy copies that in. When you set up the new PLM and used restore modem, possibly bad link data was copied from iox into the new PLM. Since your Insteon devices are all working good stand alone, it's plausible that a restore device could force the new PLM back to reality. Start with single switch that only has a few links (eg not a keypad or wireless devices) and right click in iox and pick "Restore device" If that works, slowly go uphill to switches with more scenes or keypads, stopping to test after each. However it's possible that some devices will not respond to this. If that's the case, start by cleaning out and redefining the scene. If that's doesn't work its possible that the device needs to be deleted and re-added

If commands are reaching the gate, but not the other way around, I would try right clicking on the device and pick restore device in iox

In the "Ecobee not communicating..." thread last week, Jimbo mentioned that there would be a new eisy/iox release to enable things needed for the HomeKit plugin, which will support an alternative interface for the ecobee plugin to go around the ecobee paywalled developer API.