Guy Lavoie

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.