SJK

Thanks. Wasn't clearly thinking that one through. In general I rarely use else actions outside of "if this happens, then set variable to one/true, else set same variable to zero/false." It was an attempt to cut down on the number of programs to maintain. It works fine as separate programs, one count down, one count up. Given this is a large installation, and that I use small simple programs to set variables rather than directly manipulate devices, it gets complex fast. For those interested, the positive/negative state value is a new thing I'm trying in this house to decrease the number of state variables in play. In this case, what I'm doing is using a state variable for each room to track occupancy for lighting (there's a separate one for the HVAC delay). I have an integer variable to set the vacancy delay in seconds (minutes for the analogous HVAC variables). If the motion sensor is violated, I set the state timer to the integer declaration, a positive number. That's done in a separate simple program, one for each motion sensor. Then this timer program counts down to zero. Zero is my convention for a vacant room. So if there is continued motion, then the timer keeps resetting to the delay. Once the delay is able to reach zero, the room's been vacant for at least that length of time, and it's time to turn off the lights. A third program turns on the lights if the room occupied state variable is >0, if they're not already on. A fourth program is looking for the state variable to be zero, after which the lights are turned off (via the room scene). Yet another program determines if any lights are on in the room (as there may be multiple, and may be in a different scene) and sets a second state variable which tracks lighting on/off in the room. Sounds complex. But- there's an advantage. I can use another program to watch for manual lighting control. Turn on any of the lights in the room manually, set the lighting state as on, and set the delay timer (Same as motion, or a different value if desired). Turn the lights off manually, and set the lighting delay state variable to a negative number. That means the lights cannot turn back on until the state is zero again. Previously I had to set up a different state variable altogether to track that. That way you can turn off the lights, and take a bit to leave the room without the lights going back on as your exit motion re-triggers the lights. Here, I can even set a long off delay via a large negative assignment if a fast off is detected. That's essentially an override switch (I beep the keypad so you know you did it) that auto-expires rather than requiring you to remember to disable the override later when you wonder why the lights are not responding like you expect. So 2 state variables and two or three integer variables per room allows me to manipulate lights in a very flexible manner rather easily. As I add or adjust the system- adding switches or lights, convert more rooms to motion sensors, etc., all I have to maintain is the program which tracks lighting on/off state and the scenes themselves. If I want to adjust delays or the like, all I need to read is the integer variable page. And I can troubleshoot/visualize what is going on easily by doing something then watching the state variable page. I used to do this differently in the past with other locations. But I'm starting from scratch here, so I'm trying a new tactic with the negative numbers and force ons/offs. It's actually less state variables than the alternatives and a bit easier to parse. And I'm on polisy for this home, so I don't feel limited with processing power. Only a couple of timers are ever running at the same time- one for each occupied room per person not in the same room as others. That said, I've not had problems with using over 100 state variables on the ISY994is I've used either. Response times are good. The perceptible delay is and always has been motion sensor -> action which is because of the components involved: Elk response time/resolution, ISY notification over network via Elk M1EXP, then action. The new nodeserver-based interface is pretty good but seems to be slightly slower than the old ISY module (but that's just perception), probably due to adding another component to the chain- the nodeserver itself..

I'm not understanding why this works: If $State_X is not 0 Then Repeat While $State_X >0, Wait 1 second, $State_X -=1 as does $State_X is not 0 Then Repeat While $State_X <0, Wait 1 second, $State_X +=1 BUT $State_X is not 0 Then Repeat While $State_X >0, Wait 1 second, $State_X -=1 Else Repeat While $State_X <0, Wait 1 second, $State_X +=1 does not? The last example will count down, but not up. Thanks.

yup. Making the temp change in Polisy config doesn't work. A while (hour? went to put my kid to bed) after the change, my TZ was fixed, but my sunrise/sunset times are 3 hours off actual (Local sunset + 3 hrs) again. So any sunrise/sunset calculations in programs don't trigger correctly. My current workaround is to use the sun position nodeserver and key off the elevation parameter so set dusk, sunset, and sunrise as state variables to trigger programs. (fits anyway- most everything I am doing is llke a mini-state machine). Sent a support email.

Update/solved. Used the commandline to update instead of the UI. Reported 4 updates (even though I just did this via the UI a few hours previously) and rebooted. Restarted services and data is being saved properly, logs updating in real-time on the UI without reloading. Installed packages to be UPGRADED: isy: 5.1.1_5 -> 5.1.1_7 [udi] tcl86: 8.6.11_2 -> 8.6.12 [udi] tk86: 8.6.11_2 -> 8.6.12 [udi] udx: 2.5.1_2 -> 2.5.1_3 [udi] Number of packages to be upgraded: 4

I have my polyglot running on Polisy.. Version 2.2.13 Status: ConnectedFrontend Version: 2.2.9-5ISY Version: 5.1.1Uptime: 20 Hour(s) 45 Minute(s) 53 Second(s) (c) 2021 UDIRunning on Polisy I installed a few new nodeservers to play with and also tried to delve into config of ones I had previously installed but not configured. I can add parameters, hit save configuration, then restart the relevant nodeserver. I'd go to the log page, and nothing new would appear (not even shutdown/restart log messages). Clicking back to configuration, everything I just entered is there. If I go to the dashboard, then click on details to refresh the nodeserver page, the log would have refreshed (showing the data I wasn't seeing before doing that) and update, but when I reload the configuration tab, all my parameters are gone. At first I thought it was a problem with a particular nodeserver, but I can reproduce it with any nodeserver. Now nodeservers I didn't touch still have their config info. I think the config tab isn't saving writing the values. I have no idea where to go looking for them via SSH either. I did try a polisy update earlier just to see if there's anything new. I restarted polyglot. I shutdown polisy and power cycled it too. No effect. BTW: The uptime above is not correct- should only be a few minutes. By the time I got done writing this post- it's now saying uptime is 27 minutes (which is correct).

Thanks! Just to add a bit more information: here's a screenshot. This AM I find it still thinks it's in CA, but is reporting the correct EST time. And sunrise/sunset makes no sense at all. It's 9:11AM EST at the time of the screenshot and bright and beautifully sunny.

Update: time just flipped to Pacific (LA) while hitting submit on the last reply. I'll also note I'm running the TimeData node server. From it's logs, the time/date information on polisy is correct, including DST status and my manually-input lat/long: 2021-11-07 16:35:13,534 Controller polyinterface INFO polyinterface:reportDriver: Updating Driver timedata - GV1: 35, uom: 0 2021-11-07 16:35:13,537 Controller polyinterface INFO polyinterface:reportDriver: Updating Driver timedata - GV9: 447395, uom: 0 2021-11-07 16:35:13,539 Controller polyinterface DEBUG timedata:season: dd: 7 md: 1107 2021-11-07 16:35:13,540 Controller polyinterface DEBUG timedata:getNodeUpdates: UTC offset: -5.0 2021-11-07 16:35:13,543 Controller polyinterface DEBUG timedata:getNodeUpdates: Old epoch days: 18938.89945601852 2021-11-07 16:35:13,544 Controller polyinterface DEBUG timedata:getNodeUpdates: Stripped date string is 2021-11-7 16:35, weekday 6, days since epoch: 18938.89945601852, hours this year: 7456 2021-11-07 16:35:13,544 Controller polyinterface DEBUG timedata:getNodeUpdates: Day of week 6, Week number 46, Day of Year 311 2021-11-07 16:35:13,545 Controller polyinterface DEBUG timedata:getNodeUpdates: Minutes in year to now 447395, hemisphere north, season 2, leap year 0, isDST 0

I was having the same issue. I'm on ISY v5.1.1 Tried a polisy update via the UI. Last reboot it changed to match the Polyglot settings, then reverted back after a few minutes to pacific time. Tried comandline update options without effect. Manually called to update udx and polisy as above, and it worked despite the output not saying anything was updated. But again, simply restarting the system worked for a while- so I'll keep an eye on it. However, while the current date/time are correct, the sunrise/sunset are off by an our (stating today that sunset is at 15:51:53) when it should be 16:52 according to reality. Today was the switch to standard time. Wonder if it will fix itself tomorrow- Not sure when those values are updated. While there's a checkbox for Daylight Savings in the ISY UI, it's greyed out- and currently checked (incorrectly). Date and time is hard.

Thanks. This must be leftover from my first Elk - Insteon integration circa 2007. Thought I left that in the building. Date code is more recent though. ?‍♀️ Leaves me to wonder what will happen in the other two locations I have installed ISY and Insteon using the now discontinued? serial PLMs. (Smart home has it sold out, orchestrated home has marked it discontinued.) When they die, my ISY994s are now useless? Guess I’ll have to buy a few more Polisy units unless Michael lets us install the ISY software on a Pi (which makes poor business sense I’d imagine unless he decided to sell it like the ISY modules).

Anyone know a minimum revision level for the USB PLM to work with ISY on Polisy? I have a 2414U V2.1 lying around I thought I'd try. I'm not getting a connection despite the PLM appearing to be powered up. All my other PLMs are serial so I cannot do a hardware test by swapping it out. However I'm not seeing any UART entries in the domes log- just vendor/product codes corresponding to polisy devices. Most likely I need to get a new 2413U USB PLM? I have a few spare 2413S ones but that's not going to help me without a DP9-RJ45 cable. (Also I think one of them has bad caps and the the other is needed for an ISY going to another property)