larryllix

Results are always assigned to the variable register they originate from. Try not to use STATE variables for complex calculations as they may trigger your dependent programs repeatedly with premature results. For multiple operation calculations, it may be best to use an Integer variable and then transfer the resultant into the STATE variable. Use of a lower precision variable, during calculations, will result in truncated decimal places for the final variable precision regardless of the final variable set precision.

It only takes a few lines of code to create a variable timer that self starts and self runs. This one has been tested for years. https://forum.universal-devices.com/topic/45088-wait-variable-minutes/#findComment-394015

@Jimbo.Automates I don't know why this has reared it's ugly head now but my two ecobee remote sensors are reporting as F instead of C, as per settings and all other temperature readings. The values are correct but the nomenclature in the admin console show as 23F instead of 23C. IIRC, this has been scaled incorrectly for years but as just a scale typo I thought it would correct itself with an update sooner or later. However, it never has apparently. Now, trying to use a value in a calculation I find the value used for arithmetic is being converted to C, so that being shown as 23F calculates to -5C in the variable calculations. I have tried reinstalling NS into PG3 and restarting but no luck. How do I jerk this back to proper unit scales dictated by Admin Console settings?

Having a few spare FilterLincs can really help. My big problem was Chamberlain garage door openers. My first GDO gave me slight comm problems for about ten years. Once I got a second GDO with battery backup, my Insteon went to about 20% success. Unplugging both of them resolved the problem so I bought two FilterLincs and my system worked much better. The long delay was I though it was my whole home Outback Inverter system doing it and due to being minor, I just ignored it.

Most of my Insteon devices do that now. For the last few updates, I have had to right click on the device and select Write Updates or the 1011 stays there forever. I feel this is an old update logical bug that never got straightened out, especially on battery operated devices. This may also depend on what your battery writes options are set to but I have always just Write Updates for the last year or so.

I think the answer may be the speed difference is irrelevant to any home automation user if you use any remote devices via a communications protocol. If you want to listen to music while watching a 4K video and still have your HA operate at the same speed, there my be somewhat of a difference. IOW: in polISY and eISY the CPU will be 95% of it's speed wasted, waiting for the comm line to talk to, or hear back from, it's peripheral devices.

Any time lag perceived by a human is from the comm protocol being used. Insteon is a very slow protocol once you add in all the transmission security, echoing and retries of any bad device or noise picked up and translated to valid signals fr devices that don't exist. Of course it is fast enough in a clean system. I always needed to put in Wait 1-2 seconds between every group of 3 Insteon devices or buffers would overflow and lose commands and statuses. WiFi and some other protocols are much faster. ISY was only about 200 MHz CPU while polISY is aprox 1,000 MHz, and multi-processor core. It is not slow to a human.

This is how I did it with two programs. Any program wanting to start the time just sets the state variable, $sHouse.countdowner, to X minutes and the rest happens automatically. After the timeout the house is marked as unoccupied. Note usage of constant integers. Occupied.countdowner - [ID 0167][Parent 000B][Run At Startup] If $sHouse.occupied.timer > 0 And From 9:30:00AM To 11:00:00PM (same day) // [Run at Startup] enabled Then Wait 1 minute $sHouse.occupied.timer -= 1 Else - No Actions - (To add one, press 'Action') Self retriggering timer. -If startup occurs outside wake timeframe, will self start at beginning of timeframe. -If timeframe commences while .timer is 0, first new occupied.timer value will start again. Occupied.flagger - [ID 0168][Parent 000B] If $sHouse.occupied.timer > 0 Then $sHouse.occupied = $cTRUE Else $sHouse.occupied = $cFALSE Power up assumes home unoccupied! Shouldn't be long to correct that. Program cannot be combined into "Occupied countdowner" program as it's timeframe end would zero occupied.timer

Yes, Outback is one of the earlier era more top quality inverter systems for solar PV systems. I spent some time with Modbus, and more in DNP 3.0 before we went to Ethernet for electrical grid substation automation, just as I retired. When I started in 1974 I serviced tube and relay SCADA systems as well as some DTL systems. Left as Ethernet came into being. Would have loved to stay for that because it was right up my alley...but **sigh** time to go.

If you are dealing with Outback inverters they have another protocol laye on top of modbus, whereas the registers are dynamically assigned inside the modbus code. Fixed register numbers will not work with that higher level protocol.

I have a different brand and they have to be calibrated to the top and the bottom before usage. Has that been done before remote controlling them?

Very strange. I have used about 40 Insteon devices, and other than maybe 2 devices that came bad, I have only 2 devices that have gone bad since 2016. Some people have bad electrical noise that can get amplified via Insteon devices, or RF noise to interfere with wireless device comms. I would be looking to resolve those issues. Insteon is much more reliable than WiFi, most of the time in the homes I have owned. However, Chamberlain garage door openers gave me years of trouble until I found them and filtered their power plugs. I thought it was my 120/240v Outback inverters and just allowed it for years until my second Chamberlain GDO arrived and pushed my Insteon system over the edge.

I find it just stops working for no reason sometimes, Later it may start again but saving the URLs in a file helps expedite recovery times. My idea is that it sends out some "are you out there" signal and ISY, polISY, eISY and/or the new eISY responds with "Mommy. I am here" response. Sometimes they just don't hear each other and the child is MIA.

Look at the buttons on the bottom of the IoX Finder box.

I wouldn't jump to that conclusion. I use IoX Finder on two different laptops and after both finding my poISY for dozens of times successfully, either one may suddenly not find it at times. Then I have to reload my saved profile file and away it goes again. Either laptop can do this at random and I have never established a cause or reason for the random failure about once per two months.