paulbates

Take this as something to try. I've been giving ChatGPT more of a chance on technical solutions. It took a couple of iterations, but I asked it specifically about LG TVs and ISY network resources. Here's what it said. Based on my use of network resources, it looks close to try easily: Name: Turn Off LG TV Protocol: HTTP URL: http://192.168.x.x:3000/ir/remote_control Method: POST Body: {"type":"KEY_POWER"} I'll be curious how close it got. I think LG TVs are toggle, meaning the "off" command will also be the "on" command. This was the whole answer where it was close:

Yes, that's discussed in the posts.

Take a look at these threads where the plugin author explains what's going on and is working on fixes that are available in the beta as things get resolved. Have you tried the beta version described there?

Try picking a device that's not working and perform a restore device, retest

It's hard to know as @Techman points out. When you launch iox from the launcher, do you pick the "Cloud" option from the finder? This would refresh iox itself if something happened to it due to adding dev packages. If that doesn't work, do the "generic" clear cache, reinstall java and iox.

Do you think the iox console was popping up on that second monitor all along. Not 100% sure from the posts if freezing means you could see it, but it wouldn't respond... or you never saw it.

How old is the plm? Insteon devices, especially the plm can be affected, damaged by power blips and age doesn't help. There's a sticker on the back with 4 digits, what are those digits?

6 nines? That's ~30 seconds of total downtime a YEAR on a product that costs $24. The reality is we don't experience that much downtime, most of it planned and announced. Let's let the team fix and they'll let us know.

Around 7am et my Alexa said she couldn't reach the hub, something like that. UDM said it couldn't connect. Rebooted eisy. I think that's a first for me, having to reboot my ISY to get it to respond. But everything else appeared to be working locally Everything works now

This sounds pretty specific yet unusual. I would open a ticket with a link to this post

I left mine in the house I sold in 2023. That was after a number of years of nothing new added or changed, it just worked.

When you're in iox, look at insteon devices that are out in the open where you can visibly see the LED and review them. Depending on which insteon product or revision of it you have, There could either be button on the buttons on the bottom of iox, or .. There's be an options button, look under there The label for what you're looking for can vary, it can say: LED on TX - which can mean only when the device transmitts Error Blink Blink on Traffic You might have to look around and experiment to see what results you get.

We're guessing a little based on what you said. If you log into the ISY Portal, and access Connectivity / Amazon Echo, you'll get a list of things to control with their spoken. Are the things in question listed as "device" or "scene"? If they are on the list as devices, it's one explanation for the results you're getting; delete and recreate with the scene that controls the lights

A couple of things The root cause it probably Insteon communications itself and its probably best to address that. There's a number of posts on Insteon Communications issues to search under the Insteon communications section of the forums Consider putting these devices in a single scene, and turn that scene on and off Set 'Outside / Malibu-Garage' On Set 'Outside / Malibu-NE Corner' On Set 'Outside / Outdoor Fountain Light' On Set '.Scenes / Malibu Lights' On For the queries and individual devices in the iox programs... put a 3 second wait between each command. Insteon device commands take time to receive and acknowledge and iox doesn't wait. Those sequence of set commands is banging into each other on the Insteon network Set 'Outside / Malibu-Garage' Query wait 3 seconds Set 'Outside / Malibu-NE Corner' Query wait 3 seconds Set 'Outside / Outdoor Fountain Light' Query Tweak the 'retries' on the problem devices. Right click on the device in iox, and pick advanced/PLM communication. Increase the retries. I makes the Wait after that device even longer. This approach is generally frowned upon, but I had a few at my last house where it ultimately worked ok. I would not recommend going beyond 3 retries

So a 2 part answer. How it's done: UDI created the polyglot pg3x environment for creating plugins that provide functionality and equally share access to the polisy / eisy controller. IMO you'll want to be a more advanced developer and plan on a learning curve and time to get there. Why it's done / how individual plugins are decided: UDI's success depends on community developers to create and sell their plugins. Typically developers are advanced and have the need to integrate the specific product(s) in question. They'll create it, usually, because they needed it and doing it as a plugin helps others. If you have a product like the Ultralogs, want a plugin and not a developer, you start by expressing interest - like you just did. Sometimes developers might take it on if a version of the product is shipped to them for development.

When you add a device to a scene, it presents the controller/responder choice there. If you look at devices in a scene in iox, the red ones are controllers. I'd delete the devices in the scene and add them back in one at a time to make sure they are correct. Another thing to kno for Alexa, (or any automation) you need to make sure it's the scene you've added, not the device. Turning the switch itself on and off will yield the results you're seeing

Two suggestions: When using the scenes and devices are not turning back off, either remove the load (unscrew bulb,etc) or pull the bottom tab out on the switch. Keep repeating until everything else functions. Either the load is the culprit or, see 2. Sometimes insteon devices that have run in place for many years need to have their data refreshed. If there are switches that are more likely the culprit to the problem, factory reset them and then right click in iox and restore device. In my experience it's been these devices in this order: keypadlincs, togglincs, any device that's the most remote from the eisy in terms of wire feet. Unrelated info, I grew up in Woodlawn, just south of you!

In addition to @tazman's suggestion, did you migrate your original PLM or buy a new one? If migrated, about how old is it. What are the 4 numbers on the white sticker on the back?

I think we're speculating on something we can't knowt yet. I can't imagine UDI designing a solution that cuts off functioning customers, too many still on 994i. They don't support it, but different than cutting it off at this time. Since they've mentioned creating a replacement for AC/Iox only, the core ISY product in eisy will probably not change much.. and the web interface will be a module running on polisy/eisy, web on one side and interface to v5 of ISY on the other to maintain its local only capability. But that's my speculation. At this point UDI wants us to know that they're actively working on it. And, for January, they're saying they've started laying the groundwork, not to expect web iox then. It was matter and other features to be released in January.

The notification plugin is recommended with 2 ways to go based on how complex your notification needs are: You can start with the free versions and have notifications come through UD Mobile. The UD Mobile template is the first on the list and handles simple messages... simply. If that doesn't fit your need, you can upgrade to the pay for version of the notification plugin and send notifications through notification plugins through the pushover app. You'll have to touch up all of your notification programs, shouldn't be too bad and you can likely use your existing notifications with variable substitution You'll want to read through the notification section of the forums to see some examples

I'd suggest opening a ticket with udi about options. This subject matter is their wheelhouse.

Another thing to consider, after reading between the lines, is that upgrading Freed BSD on our own will not bring eisy capabilities like HomeKit. UDI will release comprehensive updates of their software that requires the underlying OS to be upgraded. It will be an integrated package that only they can provide

As an appliance that info is not available on the surface of the eisy. I believe you'd need to use an SSH client to log in and use FreeBSD command line to see what it is. Pretty sure everyone but developers would be on the same version as eisy is an appliance, and in general it's not important for us to know unless wanting more capability that someone with developer skills would need. I think I read its 12.something but don't remember and never looked. I'm counting on the UDI team to come out with instructions or a link or something for us to follow sometime this month.

It's the version of OS that all of the UDI Eisy software runs on, and it doesn't get upgraded frequently. Its usually upgraded around new capabilities to be launched. IMO that's one of advantages of the Eisy vs other server based Home Automation systems is that it's not an owner responsibility to regularly keep it running and the system software upgraded. The eisy is more of an appliance and I came from server based home automation to UDI. I've not had to worry about random reboots or restarting it because it crashed. The reason you don't see instructions is that they haven't been provided yet. What you read was an announcement of what's to come. The other factor is UDI releases things when they deem them ready and not before.

Funny you mention that. I first noticed around 1:30ET when wanting to shut off downstairs lights after the guests left. I worked for IBM services at the time. What Y2K did was provide an incredible revenue stream for consulting. Ironically it was mostly IBM's fault for creating the system clock that they did in in the original PC... just 2 more bytes of rom and it wouldn't have happened.