apostolakisl

That is true, but generally you want all controllers of a scene to do the same thing. They used to have a single button that would copy the primary scene attributes to each controller with a single click. They got rid of that. So now if you have a scene with lots of controllers and lots of devices, it is a PITA to go through and set each device's response for each controller.

@hart2hart If there is a reboot command that you can send via REST, then you could put that directly into the program I wrote above using a network resource. But I don't know that Nodelink does that via a REST command. If indeed there is a REST command for ISY reboot, it would be good to have it added to the REST wiki.

Perhaps the simplest approach is to do the following. There are already two time nodes for ISY (ioguys nodelink version and polyglot version) Both have a true/false for DST. When the True changes to False, or vice-versa, that will be a program trigger indicating you just switched to or from DST. Makes no difference whether you put true or false in the if since it is just the change you are looking for. By putting the exact same things into both then/else, these things happen when and only when the DST switches from True to False or vice-versa. At ISY startup, it will have a true or false status, but it shouldn't run provided you don't click "run at startup" . I haven't tested this, but I feel pretty good about it. interupt - [ID 017E][Parent 0093][Not Enabled] If 'ISY Data' Daylight Savings is False Then // Do the things you want to do when it switches Else // Do the things you want to do when it switches

I don't think it is really fair to call the PLM a "controller", it is a modem. As mentioned, everything has these modems, be it a z-wave board, PLM, or a built in wifi board. You could argue that a wifi board isn't a modem, but there are issues with that as well. Most wifi starts running into issues with more than 100 clients and putting in the kind of wifi that can deal with huge numbers exits the consumer market. The PLM's have had failure issues, though the most recent one (fingers crossed) seems to be holding up just fine (as are the ones people have re-capped). Z-wave has also had its issue in that I have been forced to replace my z-wave board, not as a result of failure but rather obsolescence. I don't really see that happening with the Insteon protocol. The death of Insteon has been a topic for quite a number of years. It hasn't happened and I suspect that the current discussion is just one more in this long line. We shall see. I also think Insteon is unlikely to ever dominate the market. The people running it don't seem to have the kind of marketing skills that are needed. I mean look at what Nest did . . . Insteon just didn't know how to jazz it up for the mass market. Seriously, how something as boring as a thermostat came to be such a vogue thing speaks volumes to the marketing people.

@Javi It appears you fixed it. Thanks.

@Javi Below is the rest/nodes for one of the missing scenes. It is not in a folder. I actually don't have any of my scenes in folders. <group flag="4" nodeDefId="InsteonDimmer"> <address>18871</address> <name>Patio Coach Lts S</name> <family>6</family> <deviceGroup>26</deviceGroup> <ELK_ID>E11</ELK_ID> <members> <link type="16">49 B7 B5 1</link> <link type="16">49 B6 D5 1</link> <link type="16">4C 77 2F 1</link> </members> EDIT: I just tried deleting the profile and re-adding. Still no scenes. The UD mobile app is the current release.

I have noticed that about half of my scenes are missing. There is nothing special about the missing scenes. For example, "party" and "patio lights" are two scene names that aren't there while "patio fans" is there. I have 48 scenes and only 23 are showing up in UD mobile. I tried syncing and they still aren't there.

Simply put, I would never do that. It would take all day and then some. As I said, it is no different than if your ISY crashed and your backup was corrupt. I don't think I am alone when I say that this creates a sense of great anxiety to even think about.

Well a painless migration procedure would be fine. If everything could be mapped over from one to the other then I would not complain . . . provided that it actually worked. As for Elk moving over to a node server, it is my understanding that I will have to manually manage that, and I have assumed that moving Insteon over would be the same.

I don't understand why native Insteon control needs to go away. The vast majority of people who have ISY have Insteon devices. The Insteon protocol is known by UD for all or nearly all of the devices sold. If SH chooses to go mum on future products, so be it, that would only affect future purchases, not the already present installation of dozens if not hundreds of Insteon devices so many of us have. We would all require a complete re-work if ISY goes to a node server for Insteon. I am already going to have to re-do my Elk which is going to stop being native as well. But at least with the Elk I am only looking at a handful of programs and no scenes. With Insteon, I have hundreds of scenes/programs. It would be like my ISY crashed and my backup was corrupt. And how would that even work? Would I have to factory reset every Insteon device and start from scratch? How would the NS learn all the scenes already programmed into the devices? And even if it could, you would still have to go through and figure out what was what and name them. It would be a huge headache that would keep on giving for months as you find the things that didn't go as expected or whatever.

But that would require a complete redo of programs and scenes containing an Insteon device. I think that would be VERY poorly received.

Anyone used this? I have a 0-10v led that sources the 10v and the dimming is done by applying variable resistance to the 10v . . .in other words a pot. I think the qubino device sources 0-10v but it also looks like it has a pot as well. I found one other post with a person using a different but similar qubino device and it appears the ISY zwave nteraction works fine. Just a matter of getting the 0-10v part. https://qubino.com/products/flush-dimmer0-10v/

No, doesn't matter if the console is open. The console runs on Java on your computer and just fills in the data from ISY.

No, only changing that program and saving will make it stop.

Correct, programs don't run with multiple instances. But see my other post just before this one.

I went back and looked at your screen shot below. Your program is not counting. You see the green is only a stripe on the left edge, not the full icon. This program can not stop running on its own. You have some other program or you did something manually to stop the counter. This program can not evaluate to "true" and be done on its own. On its own, it either runs true and keeps running true indefinitely (full solid green icon), or it runs false and is just a red stripe on the left edge (it will be solid red for a split second first). On its own, it can not run true and then quit. The only way to stop this program would be to have a "stop" command given to it either manually or by another program. Also if you make changes to it and save it that will also cause a "stop".

@IT Solutions The "if" triggers every time the variable changes (state variable that is). If your 1 minute counter is working properly, then after 1 minute (prior to completing the 2 minute wait listed in the "then"), the program will retrigger (start over), the wait clause will terminate prior to completion, and no notification will be sent. This will continue to happen as long as the counter keeps changing by 1 in a period of time that is less than 2 minutes. As soon as the counter stays constant for 2 minutes at a value greater than 0, it will complete the wait clause and send the notification. I think your programs will do the same thing, just with a lot more complexity. This will also send you a notification when it stops counting because the heater turned off, so you might want to put a "stop the program I wrote" clause in the program that stops the counter on purpose.

@IT Solutions You could write another program that sends you an email if the counter stops counting. Something like If $yourcountervariable is not 0 Then wait 2 minutes send notification that counter stopped counting repeat every 10 seconds turn on some light wait 2 seconds turn off some light This assumes you are using a state variable (not integer). What will happen is that once per minute, the "if" clause will restart the program, so the "wait 2 minutes" will never complete. But if the counter stops counting at any value above 0 for more than 2 minutes, you will get an email.

@IT Solutions If the program in the program tree shows a solid green icon, then it is currently executing a "then" (solid red for "else"), or in your case, counting once per minute. Please note, this is different than a green strip at the left side of the icon which means that the last time it ran, it ran "then", but is currently not running anything. In my example below, "Elk Temp" is running a "then" loop (this posts the current outdoor temp to my Elk keypads once every 5 minutes), while "Disarm" is not currently running, but last time it did run it ran "true". Anyway, if it is is solid green, and the counter is not moving, then this is basically impossible unless your system has hung. ISY isn't like windows, it pretty much never "hangs", but I suppose it is possible. I don't think folder conditions or anything else matters here. If the icon is solid green, the "then" clause is running. The only other, and unlikely possibility, is you have some other program that keeps putting the variable back to whatever it is "stuck" on every time the counter tries to increase it.

I'm quite sure you will just back up your ISY and then restore it to polisy. @Jimbo is writing the Elk node. You would have to ask him about Elk counters and custom values, at present that is not on his todo list. He pretty much has everything covered that is currently in the Elk ISY module plus he is going to add "last user". Access to tasks, custom values, and counters is not on the list. Jimbo seems to be pretty good at writing the node, however, and perhaps you can get him to add those things.

As mentioned by @DennisC, the end point is that everything will co-exist on the Polisy hardware platform. Based on the push to get the Elk NS finished, I suspect they are pretty close to releasing the all in one Polisy solution.

There is a partial list of node servers on this forum under "polyglot node servers". To see the full list you need to install polyglot (the node server host software) onto your raspberry pi (or similar) and browse the list. FYI, Elk is no longer going to be supported on ISY when it moves over to the new polisy hardware (polisy is the in-develpment isy next gen device). At that point you will need to use the Elk NS instead (which is currently in beta but working pretty well). Node Servers have the advantage of being able put all the nodes (for Elk a node would be any zone, output, armed status, or similar) into scenes. With the Elk node server (not the Elk module you currently have), you can put Elk zones/outputs/etc directly into scenes and skip the programs. So you might have an Elk zone that when violates turns a light on directly, no program needed. All of the nodes work that way. Like I could put an Elk armed status into a scene with Roomba. When I arm away, it would vacuum. Or I can directly link a light switch to an Elk output by putting them into the same scene (turn on light and output turns on). And so on with any of the nodes.

Your timer sticking at 3 is really not possible. If the program shows solid green colored icon (not half green) it is currently running the repeat and will be counting once per minute. My best guess is that your admin console lost its connection and that the actual value was still counting. NS stands for node server. With a raspberry pi, Polisy, or other linux device running the node server software, you can create nodes on your isy for a whole slew of things. There are like 50 or 60 NS's now including everything from your roomba, ip cameras, tesla, pool equipment, etc to isy. If you move the reset to 0 into the else clause, it will change the counter reset from happening when the heater turns on, to when the heater turns off. One or the other may be best for you, or it may make no difference. I don't fully understand what you are using that number for. But if the point is to trigger a different program if and only if the number hits 60, it won't matter. If the point is to email the finished value when the heater has turned off, you would want to leave it as is. In that case, I would put the email notification trigger in the else of the program.

This is the way I would do it. tes - [ID 008E][Parent 0093][Not Enabled] If Elk Zone 'zone' is Violated And Elk Zone 'zone' is not Normal Then $i.door.open.timer = 0 Repeat Every 1 minute $i.door.open.timer += 1 Else - No Actions - (To add one, press 'Action') If you want the resolution to be in 1 minute blocks. You could do seconds and divide by 60.

Didn't see your original post, was looking at the quote. I didn't see you enabling another program, I thought you were trying to make it all one program, which while possible, would require a lot of confusing stuff. You are correct about the second program. If he wants the first Thursday to still turn lights on, then he needs to add a line that says "and time is 11:59:59 pm" into my program. Then it will trigger at 11:59:59 and disable the 3rd program 1 second earlier than yours. As I mentioned, he may need a time trigger in there anyway since I am not positive that ISY time data node server values are triggers. Need to test that.