paulbates

Did you just migrate to eisy? If yes, there is a know quirk with the first run programs that use time of day... leaving it as is and letting it run for a day or 2 will permanently resolve it

Yes... You've documented several symptoms, especially the restore that works temporarily

The eisy in unique in that there are different functions associated with pressing the power button X times... I don't have the link right now My suggestion is for you to submit a ticket

You can try factory resetting it and restore device, assuming it's insteon and especially if it's been running for years

In addition to Guy's comments, can you say what the previous switch was and how the wires were connected to it? Is it a 3 way in concert with another switch?

What you're describing is normal: Swtich 1: controls light and it's red lead connects to the actual load line to the physical light Switch 2: Joined to Switch 1 with a scene. Both switches control the light properly at the switch Remotely controlling Switch 1 from iox works Remotely controlling Switch 2 changes it's status, but the light doesn't come on Remotely controlling the scene should work as you expect. This is Insteon working as designed. Once you crate an N-way relationship with multiple switches in a scene, you've created a virtual circuit. You control the scene from iox and not the individual switch. In your iox programs' set commands, Set scene on/off, not the switch.

Wait would probably be easier. I'd use a variable $chime_active in this example If motion sensed and $chime_active = 0 then $chime_active = 1 (allow the 10 minute wait to complete) Set chime on (or however you make one chime) wait 2 seconds Set chime on wait 2 seconds Set chime on wait 10 minutes $chime_active = 0

That is a strange one. I have 2 on/off that don't exhibit that problem, I would notice. But they are v.49 Probably a bit of a long shot, but I'd suggest firing up iox and starting the event viewer and set it to level 3, as close to the problem time as practical, e.g. when going to bed. Look at that in the morning

If you have the portal, you can log in, click tools > information > ISY Information. There's a a specific url to your ISY listed there.

Ok. Try taking to the appropriate echo and say "Alexa, discover devices"

You don't have to link each one if you added it through portal and your account is linked. Are you up to date with your portal subscription?

I did the same after Nodelink stopped being developed. Nodelink actually had that humidex feature/capability built in for Venstar years ago and it worked great.

1- This is typically done with smart thermostat, I've done that with the venstar colortouch and ecobee. 2- The alternative is to get a zwave on/off outlet or on/of plug-in module and plug 12 volt ac plug-in transformer (hardware store) to it, and wire that to the humidifier's water control actuator. Based on humidity levels from openweathermap, turn the zwave outlet/module on or off. I'd be careful with that as the sole source of data, I'd want a zwave humidity sensor (assuming that it exists) to confirm the actual building humidity.. have some iox watchdog programs to not let it humidity levels get "outside the box'

You want to be in linking mode first, so that the PLM/ISY catches the Insteon traffic from the device(s) being put into linking mode.

Try right clicking it and pick "restore device". Per @Guy Lavoie's comment, if it's a wireless device, put it in linking mode first

On Windows 10, it remembers for me. I don't have this issue I backup up based on material changes that I make to programs, configuration or notification settings. I would not backup unless a change has been made

It's discussed here: https://forum.universal-devices.com/topic/44142-nest-plugin-marked-inactive/

Since I've had eisy, this has behaved differently at different times and versions. Now, it sometimes can take 20 - 30 seconds to come up.... others right away.

It seems within the last couple of updates, one of the 2 advertisements was dropped, probably to eliminate the confusion of having 2

It's port 3000 for eisy / pg3 http://"eisy IP address":3000 You'll want to continue to access the pg2 on whatever you were running that on, on its ip address, not the eisy's.. rpi?

To add to @DennisC's great answer, UDI offers consulting help. It would be a good idea to buy that and let them remote in and evaluate and propose an higher level migration plan for you. Scroll to the bottom of this page. https://www.universal-devices.com/store/#top-row

Glad to hear you're working The capacitors can be repaired if you're good with a soldering iron and working on electronics. If not (I'm not), I would dispose of it

Can you post 10 - 20 log entries, especially ones that repeat?

Hard to say for sure, but relatively easy to eliminate as the culprit.

It's possible. I believe the admin console steps through the list of devices and won't avoid sensors unless that battery option is set. It's easy to try and see if it will complete.