apostolakisl

I'm assuming you have the Elk node for ISY. It is an option in the Elk node server. It is also an option in Elk rules, but that wouldn't help you here.

I don't know. But ISY is still stuck in that mode and so far UD mobile hasn't erased my favorites again. Every time I open the admin console it shows that linking pop-up. This is not the first time for that. Last time I had to reboot eisy to get rid of it. And as I think of it, it is 2 for 2 on this problem. I have only put Eisy into linking mode twice since owning it and both times it has done this. I assume I need to reboot again.

Don't know what to tell you. But on the home page, I clicked on the "online" at the top and where I normally see both controllers drop down to choose from, only the one was there. And then I started going through the settings page and I don't remember what exactly I did, but it triggered a sync with the controller that was not listed in the drop down menu. But still, all the favorites were gone. I never re-entered credentials, so that part didn't delete.

Does the "display on keypad" function on ISY work on that keypad? I have my regular keypads display messages like the outside temp and wish my kids happy birthday and silly stuff like that. Do you have a PLM on the Elk or are using the xep via ISY? Might be that you need a PLM directly connected to Elk for it to see status changes. I'm just not sure, never used it that way.

I would suggest skipping the elk as a direct controller of Insteon devices. Use the Elk node in your ISY to bring all the Elk states into ISY and let ISY control the Insteon devices. Anything that happens in Elk will be known to ISY so there is no need to have Elk directly control anything. And vice versa, anything that happens in Insteon can control Elk via ISY programs. For example, I have Insteon KPL's arm the system. And going the other way, Elk zones will trigger lighting changes, all via ISY programs, not Elk rules. While ISY programs may not be perfect, it is certainly a better platform than Elk rules.

Folders I had created inside of the favorites tab were there, but they were empty. The actual nodes were all missing. Both in the main page and inside of folders. I had done nothing configuration wise. I was using UD mobile to turn on sprinkler zones an hour earlier, then I opened it to turn off the zone, and this is what I found.

I opened UD mobile a few minutes ago and everything pretty much was gone. It only listed one of my two sites and my favorites were pretty much all gone. Fortunately I had a backup from a couple months ago. But what the heck? Also, unrelated, Eisy seems to be stuck in Insteon discovery. Every time I open up the admin console it shows added device and UD mobile has a pop-up saying I am Insteon discovery. It shows this every time I open the admin console. I added this device a week ago.

Is there anything further on this? Every time there is any hiccup in my network Blue Iris disconnects (despite saying "connected"). It seems that people are saying using the "re-discover" button will fix it. Do I need to just have a program that runs every hour triggering a "re-discover"?

The heat sink on these things is the chassis. So I think it is a little deceiving compared to other devices with internal heat sinks. With these devices you actually touch the heat sink with normal handling of the unit. With internal devices, you are touching plastic that is well removed from the source of heat. I think if you opened your PC (or similar) and touched the heat sink, you might get the impression that it is also too hot even though it is working as expected.

@srjacob It is a language that is purpose built for HA. It has its own logic and it works for HA. The JAVA thing is roundly agreed upon to suck. UD is currently creating a local device-hosted web interface on Eisy that will integrate everything and ditch Java. You can install an alpha version of it if you like and see the first phases of it. Currently, it does no handle programming. But the endpoint is expected to be 100% of everything ISY including the plugins all on one coordinated interface. The method that is currently used to program ISY becomes tiresome when you are doing a lot of programming. The drop downs are slow. Aside from that, I see no reason to change it and I see lots of reasons to not change it. Some sort of "pro" interface that cuts out the drop downs would be the only change I would want to see. But without the drop downs, are you going to manually input device node addresses? I think the drop downs are going to stay, but could be made to work better. Starting to type in a name does not give you a very good list of close fits in any sort of logical order.

If there were enough people using this system, someone might be able to write a compiler to translate python or whatever language to "ISY".

You can add as many comments as you want. They show up as blocks in between each line of code.

Disabling a program only prevents it from self-triggering. Other programs (or manually) you can instruct it to run if and it will follow through to the then or else. Or you can directly run then then/else clause from another program. This effectively is an embedded "if" clause. You organize using folders and comments so that when you come back to it in a few years, you aren't trying to figure out what you did.

You can use wireless tags that have the lux feature on them for this too. If you already are set up to use wireless tags, this is super easy to add on. I use the USB version and plug it in to an outside outlet that is under a patio roof to keep the rain off of it. I like the USB plugin version since there is no battery to go dead.

You can do it one program if you like. interupt - [ID 017E][Parent 0093] If From Sunset To 10:00:00PM (same day) Or From 6:00:00PM To 10:00:00PM (same day) Then // what you want to happen at either sunset and 6pm Else // what you want to happen at 10pm. This program triggers at 3 different times. 6pm, sunset, and 10pm. At 6pm and at sunset it will run true, and at 10pm it will run false. If it is externally triggered it will be true when the time is between sunset and 10pm as well as 6pm and 10pm, so if only one of those is true, the whole thing will be true. The fact that the program runs true twice per day would typically not matter. If sunset is after 6pm, then the lights will be on already when it runs true the second time at sunset and nothing will change. The on command will be sent out, but presumably they will already be on, so nothing ends up happening. It will matter if whatever the program is doing in the then clause is an event that does not hold the same state until the second trigger. It would almost certainly not apply to lights, but perhaps if you want it to sound a horn once per day at either sunset or 6pm, whichever is first, then it will end up sounding a horn twice, once at each time.