larryllix

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.

Same call us, here is our phone number bait. Maybe the IP wall went up.

28 and 56 seconds? Your ISY must be wearing hip-waders. Have you checked your battery device pages to see if they are locked with green "1011" icons or programs constantly flickering colours?

I have run almost every v5 firmware UDI released so far and sitting back wondering why anybody would keep earliest versions just because the new device tables are in beta.

My bad. Yeah, I was answering your first post were you did use a browser before I read the second post enough. You appear to be measuring the http turn around time. ISY may do the job but not respond very quickly. I have also found the RPi o/s to take some time to switch tasks at times. If you can, try breaking the http function into a send and receive with time.sleep(0.001) between them to force RPi to allow I/o tasking. On second thought. Those times are way too long.

How are you inserting your credentials each time? With the first time access, your browser will usually ask you to enter your credentials, after ISY refuses, due to "not permitted". Every access time your browser will again get a refusal to respond due to security missing. Then your browser looks up every security it has ever been fed, and supplies them to ISY, without your knowledge. You would need to pre-encrypt your credentials and also use a browser that is capable of it.

As much as the screenshots are a PITA to post they really are worth a thousand words. So much easier than explanations.