paulbates

👍 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.

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.

With plugins / integrations / whatever, its a cloud service vendor API change epidemic that has nothing to do with eisy/udi in particular. Here's the victims list of Home Automation controllers affected by unanticipated API changes across Govee, TP-Link and Kasa: Home Assistant, SmartThings, Hubitat, Homey, govee2mqtt / hacs-govee bridges, openHAB, AND... UDI eisy/Polisy Go ahead and jump to something else, discover the exact same problems and restart the discussion there.

Are these older Intel MACs? If yes, my understanding is that there's no go forward for these devices for Mac OS. Java is letting you know they can't support that dead end. There continues to be Java for newer Macs. So if you're staying where you are with your Intel Mac, you can carry on, knowing Apple and Java consider that HW arch to be end of life.

Yes. There are several integrations for ecobee. Two are official: 1- An intergraiton when you already have your own dev key. It provides access to everything the Ecobee API offers, is cloud based and no Homekit needed. similar experience to Jimbo's Plugin. 2- A homekit device integration. You log your ecobee in on the same L2 lan as your HA server (L2 Bonjour based), the integraton sees it and the thermostat offers a pin to authenticate with. It offers some important features yet is also feature hampered by Homekit Accessory Protocol's (HAP) more limited definition of a thermostat. It however is completely local, cloud free and no apple products are required.

There are AArch64 / Arm64 versions of Java for Macs.

If your router has logs I would look there. You might have to raise the log level to see each DHCP address assignment. Wait for it to happen again and go look there. The answer should be there. The factory MAC address for the EISY should be on it's case for reference.

No. The YoLink app is how you configure your devices. The app and the plugin point to the same YoLink cloud services You're certain that YoLink devices are active, updating and/or controllable from the polisy or UDM? What happens with the YoLink app? You can log in? Are there errors? What about the error log or event viewer, what do they say? Describe in more detail what's going on

Key pads are complex beasties. Mine would have odd behaviors sometimes and I'd have to reset every once in a long while. There was one 8 key that everything worked, other than sometimes the middle 4 buttons would blink in unison. Like 5 - 6 times. I don't think was it following traffic because it should have been doing it a lot more. It was rare and in a place hard to catch it doing it. Not even factory resettle totally made it stop.

If it's WiFi, is there a chance that the thermostat itself has WiFi/networking that locked up or has a problem? Can you reach it with an app if it uses that? (Or ping it or see it in your router) Can you restart it somehow (eg remove from its mount and reseat) to eliminate that as a possible cause?

The only time Insteon tried this was with the Smoke Bridge... many years ago. First Alert sold Smoke detectors under the Onelink logo that were proprietary RF and worked with the Smoke bridge, I had 3 of them. While there still are people using both products, neither is offered any longer. The Insteon Smoke Bridge was single band. I think First Alert sells under the onelink brand but for matter sensors and maybe zwave now. FWIW I moved my wireless sensors from Insteon to YoLink a few years ago. YoLink has Smoke & Smoke CO sensors. The YoLink hub can be connected to the Virtualarm service for central station monitoring.