Guy Lavoie

Another trick could be to have the monitored circuit power a small electromagnet of some kind, and have that next to a Insteon open / close sensor, such that the contacts on the sensor reed switch would open when the magnetic field stops due to power failure. It has the advantage of being battery powered if a separate reliable power source isn't nearby.

Well, similarly for scenes, you can look at the old device's "membership" list on the right side of the screen, telling you what it is a responder and/or a controller for. For keypadlincs, each button has it's own list, for added fun... But it's still a manual process.

If you add the new switch as a temporary device, and you don't see it in the list when you select your old one and do "replace with", then you're out of luck. Eisy won't make it easy. You'll have to go over the scenes and programs involved and manually adjust everything. Interestingly, I had started a discussion about device replacement just 2 days ago:

I just did a bit of googling, and it appears that GE Cync is using Matter. This means that they should work with the eisy soon, as soon as the Matter update is released, which should be within weeks.

No. the Virtual plugin creates a virtual device (switch, etc) in the eisy, mainly for the purpose of acting as a flag in scenes, so that you can do things like trigger program actions on the status of the virtual switch being on or off, having been turned on or off by a scene command. IoX doesn't have an instruction to trigger on a scene command (eg: if Scene kitchen is turned on). Since individual switches can usually be turned on or off by themselves as well as through scene commands, the trick is to add a virtual switch to it, which cannot be turned on other than by the scene command. Monitoring the status of that switch can thus be your indication of a change due to a scene command. The plugin also has other virtual device types than switches (dimmer, generic, temperature) which might also be useful for other types of situations. I have not used those. If you know the protocol and communication type (wifi, zigbee, etc) then you could potentially control them directly with the eisy, or by using the network module.

Yup, I've done it that way. Link it to a spare lamplinc or other module not being used it your home, then link to the lamplinc, selecting "Add devices found in links and keep existing links". Then look at the lamplinc's link table. Works with battery powered devices like mini controllers, open / close sensors, motion detectors.

Ok, thanks for confirming that I'm not missing out on a trick or workaround. I guess the manual procedure would be to: 1- Start by going over every scene that involves the device to replace, and noting if it's a controller or responder, and remove the device from the scene(s). 2- Then going over the programs using the search feature for any programs using the device. What happens if you delete a device that is still referenced in a program? Possible corruption? If so, then delete the lines and note where they were in each program. Otherwise correct the programs once the replacement device is added. 3- Delete the old device and add the new one 4 - Add the device to the scenes and programs that were found in steps 1 and 2 Would that make sense? Anything else, or done differently?

That could actually probably be done. You could create generic raw serial strings (even with binary characters) with the network module, and they would be sent to the IP address and port of a device server by your programs. In the tests I mentioned in my previous post, I use a Lantronix EPS1 print server. I bought a bunch of these for $5 apiece about 20 years ago. Using the Lantronix configuration utility, I configured the serial port on it to send and receive raw bytes on port 3001 of it's IP address. Raw binary data, even with null characters, works reliably, and both ways.

Well, let's just see if these guys chime in, or if they have a workaround process, or a systematic procedure. Thanks.

There are generic rack mount shelves you can get. A simple 1U shelf would be good, plus you'd have room left for other devices.

Well the eisy can certainly communicate with a serial PLM for Insteon using a USB adapter. But now the question is: if you can add a second USB adapter, how could you talk to it? There are no programming options to access a USB or serial device. You would need to have a module like the networking module, but to talk to a serial port over USB. I did experiment with accessing a serial device server from a python program over IP. It works. But a plugin would need to be developed to do this. I'm experimenting with creating a plugin that communicates with that serial device server, but for another purpose.

Many of the handy features in IoX are those for maintaining and upgrading an installation. I'm talking about things like restore device, PLM replacement process, replace switch with... etc. I've just had the pleasure of using the replace feature to upgrade several switches to dual band models. One constraint is that it only allows replacing a switch with one of the same type (dimmer with dimmer, on/off with on/off). It would be handy if this feature also allowed replacing one with the other type. It could list the differing type switches at the bottom of the list, and selecting one could pop up a message warning that this is a different type, and that adjustments might be needed in programs and scenes. Sometimes you only want to replace a switch that is used as a 3 way slave, so it doesn't matter what type it is. Or simply don't need the dimming feature anymore in a location and want to reuse it elsewhere. Economics and availibility. Food for UDI thought.

The utility of the virtual switch is that it can serve as a flag for following the status of a scene. If all the lights in your scene are lights that can also be controlled individually, then you can't know for sure if any given light was turned on by itself or as part of a scene. If you want to keep track of if a scene was activated, the idea is to add a virtual switch as an additional responder to the scene. The virtual switch doesn't have a physical control, so the only way it can get turned on or off is with a scene command. So let's say that the eisy turns on the scene, and you'd like to update the backlight for that scene on your keypadlinc: First you create a new scene with one of the switches that can control the scene as a controller, and add the keypadlinc button as a responder. You might already have this if you have switches other than the keypadlinc that can turn the scene on or off. You might need to create a new, separate scene if it has the keypadlinc button as a controller, because you can't have the same button both as a controller and a responder in the same scene. I name these as "reverse" scenes. Now you create a new program that looks for the status of that virtual switch turning on or off, and have the program turn that new scene on or off, for the purpose of updating the button.

I also have keypadlincs and I like the button to reflect the status of the last scene command, wherever it originates from. This is especially true of keypadlinc buttons that are set up in toggle mode. So what I did was install a plugin called "Virtual" with which you can create virtual switches. It's a free plugin. Then I added a virtual switch to the scene as a responder, so that it get's turned on or off with the scene, no matter who/what turns the scene on or off. After that I added a program which monitors the status of that virtual switch, and sends the appropriate on or off command to the keypadlinc button. That keeps it in sync perfectly. If you have a light that is only ever turned on as part of a scene, then you can monitor the status of that individual light instead, and skip the virtual switch.

1- Please don't close the thread. I think there are still a few things worth discussing, and reliability testing over time. Wow, how long did it take you to write that post? You say that it would have been easier to just start from scratch, but I would argue that everything learned along the way was more valuable, and not just for you... About that quote I just made above: what type of keypads are these? If there is a way to turn off the light on the button by sending a off command to it, then I do have a workaround that is able to track scenes nicely. I have keypadlincs that I do that with.

Well the Hub 2 is an Insteon product, not UDI. So you won't learn much about it here. Not sure how much it can really do without a subscription, but if the bankruptcy of Insteon in 2022 is an indication, the hubs basically became useless. What exactly do you mean by "Alexa was updated" and no longer supported the isy994?

https://www.universal-devices.com/contact-us/#contact Or log into your account and open a ticket.

When I want multiple sources of triggers for actions, I have the triggers set a state variable, and the program controlling the device looks for that variable being set to the trigger value, turns the device on or off, and resets the variable for the next trigger. That way, you detach the trigger source from the activation of the device. Another benefit is that you can set the variable to different values for different actions of the same switch (ie: trigger two separate programs). For example you could have a slave switch or Alexa set the variable to 1 to just turn on the switch, and the motion sensor set the variable to 2 because you only want to turn on the switch for 30 seconds. - First your trigger programs: If slave switch Status is on and variable = 0 then variable = 1 If motion sensor control is on and variable = 0 then variable = 2 (For Alexa you would just directly set the variable to 1 in the portal) - Then your action programs: If variable = 1 then turn on switch then variable = 0 if variable = 2 then turn on switch then wait 20 seconds then turn off switch then variable = 0 Furthermore, you might want to override the motion sensor activation if the light is turned on by the switch or Alexa. so that the motion detection doesn't turn the light off on you when you actually want to be there for some time. So you might want to modify the action program to leave the variable set to 1 until the light is actually turned off by the switch or Alexa. This would be one or two additional programs looking for those triggers and setting the variable to 0. That way, the motion sensor trigger wouldn't happen because the condition to do so is by getting the motion sensor On command AND the variable being equal to 0. That's the difference between having just a hub vs a fully programmable controller.

The only difference between state and integer variables is that a state variable's value can be used as a trigger for a program (so the program "state" is true or false). Both variable types can contain the same values. In theory, they could have made all variables state variables. This was probably done to lighten the cpu load, to avoid needlessly testing the value of a variable that is only used for math, totals, etc. You would define variables for that purpose as integer.

Like with most software products, documentation is often behind in relation to the features. With the announcement that an entirely new admin console is in the works, I don't think much time will be spent updating the documentation of the current one.

Then you should contact UDI and inquire.

For the ISY994i, renewals are limited to single years only. That was announced here: https://www.universal-devices.com/994-portal/

Yes it will. The only thing we know at this point is that there is a new admin console planned, and that it will be web based (I guess/hope they mean browser based).

Choose the On level you want from the list, then click on the "On Level" button to the left of the list. It's not obvious but that is a button, not just a label for the field.

Is UDI or it's employees impacted by this terrible disaster?