paulbates

I've had several as well. They straddle the line of having cloud support, like their mobile apps if you want to..... BUT, you don't have to -- they will operate 100% local with the UDI 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.

Have you tried factory resetting it? That's not uncommon for a new Insteon install

We have to keep in mind that us Home Automation controller types are not the main market for the products in question. It's the customer base of hundreds of millions of potential buyers who could use the product via the vendors' apps on their phones. The priority for those manufacturers is keeping their own product ecosystem whole. Or, the major ecosystems that Matter is being designed and built for: Apple, Google, Amazon, Samsung. Probably one of the best table scraps has been Apple's HomeKit Accessory Protocol (HAP) that a number of vendors have adopted as simpler, easier to support interface. It's typically lacking in complexity, but numerous vendors have adopted it. However, Apple announced a while back that it's done updating HAP and their integration direction is Matter. If you have something that uses HAP now, nothing should break it. If you're looking to future proof against this kind of problem, matter & thread is the kind of direction you have to think about now. It's still in its infancy IMO and other problems for things like lighting are lurking in there. So when we say "I'll stop buying product X and start buying Y because their changes broke my house", we're likely to be jumping from the frying pan into a different fire. We also don't help ourselves by demanding a subscription-less yet complex products and want them supported for years. That creates the "Sell once, support forever" business model for the manufacturer, they give up and there's a growing pile of stranded products in our homes as a result.