larryllix

I found I had more problems with routers that did not want to heal well with devices. I never found the ISY to be in that category. I found Venstar stats the worst and the router had to be rebooted followed by a complete power cycle of the stats almost every time. Later I discovered soft rebooting a lot of things didn't work mostly. A few routers and dozens of router upgrades, and a different brand of stats later, things have settled down a fair bit now. I discovered my UPS didn't like the power blinks we get here (rural with high winds) made some equipment reboot and some lasted through it. My router seemed to be especially bad with a 10 cycle grid switch over caused by a 1 second grid blink so I adjusted that to about 3 cycles for UPS switchover. Yeah I run a 6KW 48V 125Ah battery carry over system but only use it for my router, TV, select lights, and select receptacles but not my ISY. I fear the grid supplied PLM to UPS fed ISY would cause serial port burnouts and I would lose my ISY or PLM on a regular basis....maybe. Rebooting ISY is a b/tch as there is always something that isn't perfect and it takes a lot of logic sweating. There is always something more.

What would a running ISY control in a power failure and a dead PLM?

Yes. That was my point. It doesn't happen with ISY arithmetic. It appears the NS pulldown menu with the value groupings are not being substituted into ISY's arithmetic capabilities properly. This suggests that the NS substitution table is incorrect, not ISY arithmetic processing. I don't use this particular NS, but the ones I have tried (including NodeLink), and logical deduction, tells me the pulldown menus do not deal with actual displayed values, but rather only a numerical representation of each value or group of values. I have written ISY programs utilising this fact where say an ecobee climate style is represented by 0 - 5 but the human sees. 'Away' ,'Home', ''Sleep', etc.. eg. If stat mode > 0 would include 'Sleep', 'Home', 'Wee Hours', Extreme Cold' etc.. IMHO this is the case of this, and all, NS/device pulldown values also. The OP is dealing with 0.000-0.400, represented as value 0, 0.401 - 0.500 as value 1, 0.501 - 0.550 as value 2, and so on. Where the actual value substitution is made is unknown to us, but IMHO is where the bug is happening. Other NS users have not reported this.

@kclenden I have experimented with three decimal place variables against 1 decimal place variable and vice versa. The precision conversions always worked flawlessly. Since the OP program is showing three decimals of precision in the comparison, along with superfluous zeroes, I have to conclude this is a problem with the NS supplied values and not ISY arithmetic, or precision conversion. When a floating decimal value is used in any 'If' section comparison, the trailing zeros are always truncated and never displayed, as in the OP program. These must be predetermined pulldown menu values supplied by the NS. In the If line: 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall >= 0.400 Inches "0.400" is a predetermined selection made by the NS and I suspect the decimal arithmetic is is being done correctly by ISY's arithmetic engine but using incorrect values supplied by the NS software. Test decimals - [ID 00D0][Parent 0001] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $Test_terminate_value = 0.5 $Test_Ramp_var = 0 Repeat While $Test_Ramp_var < $Test_terminate_value $Test_Ramp_var += 0.001 Else - No Actions - (To add one, press 'Action')

10 seconds is probably a waste of bandwidth. Ecobee can only be polled every 3 minutes (180 seconds) or ecobee will cut you off. While I think 3 minutes is a little slow, I don't see faster than about every 30 tp 60 seconds, as necessary or useful. Thermostats are not that real time and temperatures and settings do not change that often anyway, to congest up any comm channel. With MSes and other devices that may be important. Even the 3 minutes update can live with some minor workarounds. I have a few to check updates are processed 100% and they always work, eventually.

? FreeBSD 12.1-RELEASE-p3 r359260 POLISY Welcome to Polisy! [admin@polisy ~]$ sysctl -a | grep temperature dev.cpu.3.temperature: 54.0C dev.cpu.2.temperature: 54.0C dev.cpu.1.temperature: 54.0C dev.cpu.0.temperature: 54.0C

FreeBSD 12.1-RELEASE-p3 r359260 POLISY Welcome to Polisy! [admin@polisy ~]$ uname -a FreeBSD polisy 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 r359260 POLISY amd64 [admin@polisy ~]$ FreeBSD polisy 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 r359260 POLISY amd64 -bash: FreeBSD: command not found [admin@polisy ~]$

A 9v or 12v power supply, as @Brian H pointed out above may have more noise resistance and better filter capacitor life.

sysctl dev.cpu.0.temperature returns command not found on my polisy also

Router DHCP failure? Sometimes my router previously would not reconnect with some equipment when they all reboot at the same time. At times a reboot wouldn't do it...I had to power cycle it. My ISY usually reconnected better than some pieces of equipment, especially thermostats. It is better now with dozens of firmware upgrades now, and switching to ecobee thermostats.

All good logic but in many years and so many users out there, I don't remember hearing of a program running by an incorrect trigger. Many times we thought we had trapped a bug of this nature but it always turns out to be some sneaky trigger or other source of the erroneous event. Of course anything is possible. We have had some variable roundoff errors before. Myself, I would be trying to eliminate more possibilities, by disabling the each of the programs affecting the same variable and eliminating all but the one in question. Then polyglot could also be inflicting variable changes. I have complained about the rest interface having no data security before and anything can be changed in ISY erroneously by a runaway box containing your ISY credentials. There are no boundaries. Then possibly trying a factory reset and reload everything before opening a ticket. OTOH, Michel may like to see this in action and do some digging of his own, before the possibility of it just disappearing into the unknown. This will definitely be interesting to find out what is happening here.

Because there are at least 6 programs that affect that variable due to unforeseen triggers. Many times we save a value and then another program changes it and destroys the evidence. As an experiment try changing all those lines from "=" to "+=", then clear the variable to 0, and test. This should show a cumulative result from every program that triggered. None of the other programs will show True (Green) as they will all trigger False when another program becomes True. This also hides history. I have many of these "selector switch" type banks of programs in usage and they can fool you. Also, "selector switch" type program banks cannot ever have Else program lines.

"Daddy! Thanks for the new skipping rope!"

Then I believe your verification using that variable as an outcome is invalid. Try disabling all your programs or removing the test variable line from all but the suspect program, disabling it, and then testing

Do all of your programs have the $RainTodayAmount = 'DarkSky / Forecast 0' Rain Today Inches line in them?

IRC this same issue was addressed about a year ago with the same outcome and a workaround was the only solution.

Best I can think of is to name your variables in a more meaningful way, so they sort for easy finding according to the app they are displayed in.

Have you tried with and without http://? Tried with https://192.168.4.xx:443 ? Just in case you use SSL in your ISY? Other ssl port number?

Is your browser and PC on the same subnet IP address range?

Did you format the SD card inside ISY using it's bios system?

Clean out and delete other scenes created for each KPL LED that you want to use for programs. Create a scene for each KPL LED that only controls that LED. Now control each scene with ISY programs because your can't directly control KPL LEDs with programs. See @dbwarner5's post above. He tells a different analogy that was good.

I am not sure I understood your requests completely but the removable lines are there to activate the KPL LED that you tapped. KPL LEDs, unfortunately can only be operated by scenes. It's s hame to have a scene with only one device in each but....The brightness level can be modified via ISY programs but all LEDs in the same KPL share the setting. I use a slight delay as Insteon signal flooding can be a problem in other places. With human operations a 1 second delay is not too bad. I also use another technique with a switchlinc dimmer to operate 6 different colours in my bathroom. If you tap the switch within 2-3 seconds of the last tap it rotates the colours. If you wait longer and tap it again it turns the lights off.

Try this 1st Floor Bath - Mirror - If Control '111st Flr Bath / 1st Floor Bath - Keypad - A' is switched On Then run (If) Program2 Else ------ Program2 (DISABLED) <-------------------------------------------------- If 1st Floor Bath Mirror status is Off Then Set '111st Flr Bath / 1st Floor Bath - Mirror' On Wait 1 second Set KPL LED scene to ON Wait 30 minutes Set '111st Flr Bath / 1st Floor Bath - Mirror' Off Wait 1 second Set KPL LED scene to OFF Else Set '111st Flr Bath / 1st Floor Bath - Mirror' Off - No Actions Wait 1 second Set KPL LED scene to OFF If you combine this in one program and the device you are controlling is a trigger in the same program's If section it will oscillate or undo your actions.

I don't think v4 can support the polisy or polyglot that is taking over ISY.

@Michel KohanimThose reserved battery device writes are dangerous. I had to learn the hard way also. Cached writes can tie up ISY and cripple it.