larryllix

? 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.

Yes. Larger buttons are easier to label and tap. To many buttons on a wall plate makes it more intimidating for non-HA people to us. All my keypad, battery and power, except one got junk boxed, once Alexa and Google Home came out. With dozens or hundreds of vocal buttons I can push, why limit myself to 6 or 8 unlabelled, 'try and see what happens', type buttons.. Then there is the cloud aspect though.

This was one source somebody posted a years ago. Although he didn't succeed to hack into and control Insteon equipment while demonstrating he did discover many aspects of the documentation was false, mostly frequencies and some of the protocol, IIRC. AS I continue to maintain, whitepapers are not specifications. They are proposals for comment. Most companies protect their intelligent properties by publishing old version off-spec documents. THE USPO has become a poor system and checks nothing anymore except you signed the prior art docs.

They even release white papers with misleading specs to confuse copycats. Sent using Tapatalk

I wonder what the "Dial Switch" could be? Analogue looking dimmer with a rheostat style knob?

Where did you see the KPL description?

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.