apostolakisl

I am trying to add another account. It shows up as an account requesting to be added. I click on "accept" and get the response "bad request". I tried restarting the admin console to no avail.

Twilight duration by latitude and date. Further from the equator, the more it varies by date.

Another trick if you have varying amounts of twilight at different times of year is to use the "sun position" node server. When the elevation hits a certain number of degrees below the horizon, that could be your trigger to turn on lights.

The weather nodes you can install using polyglot include "solar irradiation". This might be better for you than sunrise/sunset. I assume you are very far North and have very long twilight? I'm looking at the weatherbit node and it has that measurement, but I am pretty sure it isn't the only one. This is also affected by cloud cover. Obviously, patchy clouds will be very inconsistent from your location as compared to the measuring location, but on days with horizon to horizon cloud cover you will get an accurate reading.

centering on the current value is another option, currently it starts at the current value and goes up. I still think centering on 72 with a range of maybe 62 to 82 (or more) would be the best.

When you click to change the set temp, I would suggest having it default to 72 degrees as the center point of the shown range to increase the likelihood that scrolling isn't necessary. Also, I suggest a bit smaller font so more can be displayed at once on the screen, again, to keep the need for scrolling down.

I have this issue randomly many times over the last couple years. I have to unlink and relink ISY from Google Home on my Android phone Google "Home" app. Like others, I find it very frustrating.

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.