Guy Lavoie

The release notes advise against upgrading from below 5.9.1. I guess they make the upgrade process actually check that. You'll have to open a ticket for this.

Neat stuff! I actually have the previous TaHoma hub, the Beecon. I wonder if the software functionality is the same? I'll probably give it a try. I'm currently using a UTRSI-II with the Somfy plugin and it has been very reliable, so there is no urgency, but it's always interesting to try new things.

Did you just reboot the eisy or did you power it off and back on? If you didn't power cycle it, try that.

I have a keypadlinc that controls a ceiling fan (sends commands to a Fanlinc) that wasn't fully functional lately. But the funny thing, that prompted me to write this post, is that the backlight was blinking in sync with any Insteon signals being sent in the house! Literally, like a signal presence indicator. This afternoon I finally got around to fixing it, by doing a factory reset and then a device restore. That got it back to full functionality, and no more blinking. Anyone ever see this?

Wow, nice! First time I hear of a direct add. You're running IoX 6.0.5?

I also seemed to have more success when Matter support first came out in spring 2025. It's almost as if 6.0.5 somehow made it more capricious. Just a thought, not backed up by anything technical.

Yes, the Coffee Shop forum is where others list devices for sale.

I've also had mixed success with Matter (eisy is running 6.0.5). I've only been experimenting with Matter, not implementing anything for regular use. I bought a used Google home mini, and I first add the device to Google home, then share it to the eisy. I've currently set my experiments aside, waiting for the next IoX update before resuming tests. UDI is actively working on Matter implementation and it will take some time.

Ah there you go, if the creator is involved, then this should get figured out quickly enough.

Ah, I missed your mention that you had created a new, test program. I then thought I'd check out exactly what this plugin does and thought I'd test it, but it's the first time I see a plugin with no free trial period. In reading up on it, it seems to be doing several things that I've been doing myself as I learn plugin development, though mine is mostly about dates up until now. You might try contacting the developer directly.

Have you tried powering off the isy994i, taking out the SD card and cleaning the contacts, then try it again? There is a known issue with that which can sometimes help with reliability issues.

If you reinstalled the plugin from scratch (vs an upgrade) then nodes can get created with different references. Have you tried editing each program line by clicking on it and then re-selecting the same options from the select list? Do that for each program line referencing a value from the plugin, save it, and test it again.

If not, there is an alternate way of doing this using a couple of programs, without requiring a plugin.

Before deleting and adding back the modules (and redoing their references in programs), if you have spare modules of the same type, try this: add a spare device as a new temporary device. Then bring up your unresponsive device in admin console, and use the "replace with" function to replace it with the new spare device. This "holds" it's programming and references in the spare device. Now feel free to factory reset or whatever you want to do to the unresponsive device to get it working. If you succeed, then use the "replace with" function again to replace the spare device with the original, now working device.

A single bad device jamming an entire communication system is a rare, worst case scenario. It happens just once in every home automation enthusiast's lifetime to teach him that anything is possible and take nothing for granted. Hehe. Brings back some X10 memories.

Interesting. How did you determine that it was that one?

Rebooting the eisy will usually kill the linking process. You say you tried that, unsuccessfully. You'll likely have to wait for UDI support to respond.

No don't delete them. Doing that would require you to manually modify their references in programs after adding them back. Instead you should try to do a "restore device" on each one. If these are battery powered devices then this is normal after a PLM replacement. You need to momentarily activate the device by pressing the link button on it briefly, and then choose "Restore device" when you right click on the node in admin console.

So are you able to access it with the admin console? If so, you could try redoing the update from there.

There is a way on the android version. Press and hold the icon on your phone and a pop up will appear, letting you create a second shortcut that launches straight into favorites. I leave both shortcuts available.

The "official" solution is to open a ticket. Some of the more adventurous among us (including myself) will sometimes ssh into to it or use a screen and keyboard to redo the update using unix commands.

One thing that's a bit frustrating is that when you're used to neatly organizing code for readability and logical flow (nesting, indentation, etc) you find that there's no way to neatly organize IoX programs. Other than putting them in folders, you can only view one If/then/else script at a time, and they organize themselves in alphabetical (ascii) order. It would be nice if eisy-ui offered a more customizable way of listing programs or even better: more than one at a time. Hint hint...

I'm working on that Persian Gulf plugin as fast as I can!

Yes, it will trigger the first time that the variable becomes true to your test . Similarly, an ELSE statement will execute the first time that the variable test becomes false (so no, it won't trigger continuously). There is an exception when it comes to variables: a test with more than one possible true value will test true again if the value changes, even when it was already true. For example "IF Variable x is > 1" will test true if the variable gets set to 2, and will test true again if it goes from 2 to 3, even though the test was already true. Variables are the common currency between programs, because you can set and test them at will. They become triggers, flags, etc, whatever you want. Your question about Control vs Status: Control tests true if the control event tests true, which by nature happens only once (eg: when the switch is actually pressed). So if you turn on a switch that was off, it's status will change and a logic test for Status On will trigger, and you will also get a Control On event. Now if you now press the On button again, the Status won't have changed because it was already on, but a program looking for a Control On will trigger again, since you pressed the button. So Control events are useful for things like counting how many times a switch has been pressed within time period, for example, or to activate a secondary action.

Yes, that's how it works. A disabled program won't be run by the main IoX routine, but can be run on demand by another program. I use this in a garage door routine that updates the backlight of a keypadlinc button even if the garage door is operated manually. As you want to do, this is like a nested IF. There are two ways to do this: inefficiently, or ugly! The inefficient way is to use a Wait statement to pause the operation of your first program, to allow the second one time to run. Inefficient because you need to wait a bit more than usually required to be safe (that's it's actually finished) and for that to work, the triggering status of your first program has to remain true for the time the Wait finishes. So if your second program changes the status of one of your devices that triggered your first program, the Wait and the rest of the program just gets canceled. The ugly way is to use...a third program. You could put the commands you want to run after the second program is finished into a third program, which either the second program runs (set it up as a disabled program, which the second program runs when it's done) or by having the second program set a status variable, which triggers the third program when the value is set to the triggering value. I tend to prefer the ugly way, using status variables. It's akin to "state machine" programming and is easier to test and troubleshoot.