larryllix

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.

You can increase the memory size but every update of Java will erase it again In today's world, we are pestered with updates on something every day or two. HTML5/CSS3/javaScript is coming soon, I hope.

SMS text messaging is not available to many people traveling. People do not want to pay exorbitant rates to get phone service for a week or two Usually most resorts (in Mexico) provide WiFi data, so emails are one of the only methods to receive notifications.

MS devices use many channels and each one establishes a link with your PLM. It is very common during disturbances and EPROM rewriting to MSes to lose or scramble one link. All the other functions may work, but one doesn't. Put the MS into linking mode and use IoX to Restore the device, by right clicking on the device in the device tree. If that doesn't do it, then try factory resetting the MS and then Restore it again. Sent from my SM-S711W using Tapatalk

I prefer not to add another dummy program just to run another a startup and try to use the function without another program. I have a few with Else sections that just jump back to the Then sections. Run at Startup would be much better as another program line that users could be aware that it exists without extra documentation, inside the program. A coding line for Run at Startup would also disclose the logic Run at Startup uses, and be controllable by the user usage of AND or OR logic. No extra confusing program or hidden checkbox would be necessary. Programs should be self-contained, not logic spread all over the webpages and jumps into the middle of other programs in spaghetti bowl style programming.

I also do that however it was never established what the logic is for [Run at Startup] is. I know it will fail with a time trigger because it appears to act like an AND function with the other IF logic making it nonfunctional. A few programs I have included a line Run ThisProgram[then] into the Else section to ensure it actually functions.

Key LEDs cannot be controlled directly, for some weird reason. The workaround is to create a Scene for each key, say KeyA, KeyB....KeyF, and drag and drop each key LED device into each scene. Now programs will be able to turn each scene on and off. Key LEDs can be dimmed as a group and turned on and off individually when they are part of a scene. They would then be the only device in each scene.

Also to be noted in ISY programming... Looping, of any kind, cannot be nested. Multiple programs must be used for nested looping. Sent from my SM-S711W using Tapatalk

I was big into energy monitoring years back, (spent a lifetime in the energy field) but now we have LED lighting and it is cheaper to leave a light on 24 x 7 than to purchase a smart home controller for the bulb. Make sure you are actually moving forward and let us know how it goes. If there is better out there, people will want to know about it.

Which brands are the perfect ones? Any lists?

I attempted this when I moved from ISY994 to polisy. I found most of it wasn't worth it but I think it may work with one CapU handling all Insteon comm devices while the other handled all WiFi and other protocols. The comm protocols are the bottleneck for the PLM and multiple PLMs will not help due to echoing them all over the house. It is easy to comm between ISY devices using Network resources talking to the other cpu device. Bidirectional gets a little trickier. Sent from my SM-S711W using Tapatalk

The 4000 lumen tends to line up up with the 50W actual. The size is pretty compact for that size though! Awesome light with selectable colour temperatures! Having had lots of RGBCW bulbs the 50 Watts may be the total LED draw but not all LEDs may ever be on at the same time. Perhaps only with one end of the colour spectrum.

Is that 300 Watts equivalent or 300 Watts actual? 300 Watts of LED lighting is a lot of light and not very likely. The LED companies love to exaggerate their luminescence values. Maybe the lumen ratings are visible on the fixtures?