Guy Lavoie

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.

The second program method is the way I do it. The second program is a disabled program that only gets run by the first program. I even name it starting with DNE (for Do Not Enable) to make it stand out.

People with isy994i controllers should take note.

If you do something that triggers a scene (whether it be a switch, from the controller, etc) you really need to wait a few seconds before sending anything else. The Insteon cleanup messages take time to get completed. Sending commands during this time also increases the risk of accidental "all on" events.

Does it still appear in the device list, after the reboot?

Sounds like a power blip that might have been worse than it looked. You could try a factory reset of the PLM. If it then shows as connected, then do a PLM restore. If you still have the ISY994i kickibg around, you could try connecting the PLM to it and see if it shows up as connected in admin console.

I've been messing with Matter (and it's been messing with me). I've had some success, and some frustrations. You need to keep in mind that this is still very much beta for UDI. I suspect that until now, support will mostly be for output devices like bulbs and plug in modules. I'm not sure if sensors are supported yet. I did try a Kajplats bulb in March, which worked well. You can read up on some of my experiments and discussions about Matter devices here:

So when you click on the Zigbee menu at the top, you get the various options (Add a Zigbee device, etc) right? That means that it's seeing the dongle. The next thing to try would be to try and factory reset the device you want to add, and then try adding it back. This usually involves something like holding down a button on it while powering it up, or some similar procedure. See the instructions that come with the device.

Have you tried a reboot that includes actuallypowering off your eisy?

If ELSE works by executing the command only the first time the statement becomes false, that might work too.

I think the keypadlinc really exists for this kind of thing. The ability to set a button's backlight on or off remotely (and set it's next sent command as on or off based on this, when set to toggle mode) provides the versatility you're looking for. I have one keypadlinc near my exit door with one button indicating whether any basement light is on. And that includes Hue bulbs in lamps, etc. That's the nice thing about using a program. So if anything;s status is On, the button gets lit by the program. That's a whole bunch of Or statements. Conversely, if everything is Off, the button backlight gets turned off. That's a whole bunch of And statements. These are two programs that are just left to run continuously, not triggered to run by any switch actions. There is always a short (about 2 second) delay between a status condition that warrants turning the key backlight on or off, but it's been very reliable.

Not that I know of. I'd look for control on and control off events (with Or statements).

Yes that's what I did, which includes then pressing and holding it in until it beeps continuously and then stops. That did clear it, but restoring the switch had brought back the beep. That's why I then deleted it from IoX, followed by another factory reset.

I tried writing that very setting to the switch (with a value of 0) but that wouldn't disable the beep.

I just came across an interesting twist with a used 2477D that I just acquired locally (as a spare). I hooked up power to it, and it worked normally, but it would do a short beep every time that I turned it on or off manually. Then I linked it to a test Polisy and that went fine, but still did the beep thing when operated manually. It wouldn't do that when controlled by the Polisy. So I though I'd factory reset it (airgap) and the beep thing stopped. But surprise: doing a "restore device" from the Polisy restored the beep. As if it was part of the configuration information that it obtained from the switch when I first linked it. Ok, so now I deleted it from the Polisy, and factory reset it again, and relinked it again as a new switch. Now the beep is gone, just like a 2477D usually works. There is no settable feature in IoX for beep on touch, but it looks like the switch can be set to do that. It had been used with an Insteon hub. Interesting.

When you use IoX finder, select loading the admin console from cloud. This will download and update the version on your eisy. Updating from eisy to eisy r2 would be a marginal improvement. The r2 is a bit faster and produces less heat.