MrBill

There is no dispute that the ISY could make this available via programming, however as I said before there never has been a case that I can think of where the options under the "Options" button of a device have been available for use in programs. There are many things about Insteon that we all wish worked differently, for example I wish UDI had exposed the little known and barely documented option to uncouple the load from button A of a keypad, but that doesn't exist in the ISY world and I doubt that it will ever be added. As for whether UDI will ever incorporate the ability to control the LEDs on a fan controller in a program I also doubt that it will happen. Why? Because one user in 10+ years has wanted it. Further even if a few more users said "yes that would be useful to me" there still is not and never will be mass demand. Secondarily, UDI has stated they will not be developing anything new or supporting any new Insteon devices unless Smartlabs provides API documentation. Essentially short of bug fixes UDI has frozen the Insteon section of the code. If you want a definitive answer from UDI's engineers you'll likely need to open a ticket, support@universal-devices.com While UDI does participate in the forum, they seems to choose threads that affect many to participate in, and they don't participate in every thread (and I'd even go as far as saying they avoid participating in threads, like this one, with one off requests).

@Wes Westhaver As far as I know options settable from the "Options" button have never been able to be controlled via programs. Backlights are generally controllable via programs, however they aren't included under the options button. I have a few fanlincs but have never noticed the LEDs because they are buried in the ceiling canopy, and apparently I have a good seal because I've never noted light leakage.

In the late 90's at a customer's we had neighbor problems... they all claimed to have no X-10... like @larryllix I ended up writing a program to find out which neighbor it was and try to figure out which house codes they were using, everytime we changed house codes there seemed to be new interferences... it turned out they didn't know the switches and remotes were X10 (and it was off branded X-10) and they were actually using 5 house codes for next to nothing.

As noted as the thread progressed there's always multiple ways to do things. But your 100% correct... event based is a much different way of programing, and like all things there's more than one way to attack it. When I replied last night I was short on time, so I just started typing.... backed up and one point and just did something I knew would work. Now you have a number of examples!

I started with the enable/disable approach, as people who follow my example programs will know I use the technique frequently. If taking this approach I'd still recommend breaking Program 1 into two parts, allowing for hysteresis, or temp gap between mode changes-- imagine a cool partly cloudy fall day with the temp hovering around 40, as the sun comes and goes the temp can very by a degree or two, on the other hand I'm not sure how often openweathermap updates the temp, if it only updates hourly that's built in hysteresis by time. Another point is that if we switch temp ranges, enable/disable does not also run the program, in the case of program 3 being enabled there would be a delay until the next downward temp update before the pump turned on, and it may or may not get the off in the ELSE because there's no guarantee which would run first the "Else in program 3" or the "disable prog 3 in program 1" As mentioned above to fix this method i would suggest: Prog1 A IF temp >41 degrees THEN: disable prog 3 enable prog 2 run prog 2 (if) Prog1 B IF temp <=39 degrees THEN: Disable prog 2 Enable prog 3 Run prog 3 (if) ---------------------------------------------------------------------------------------------- This still leaves a problem tho... which can be solved by eliminating program 3: Prog1 A IF temp >41 degrees THEN: enable prog 2 run prog 2 (if) Prog1 B IF temp <=39 degrees THEN: Disable prog 2 Set coop pump on Prog 2 IF from 7am to 8pm THEN Repeat every hour, run pump, wait 5 minute, stop pump (your original coop pump THEN) ELSE Stop coop pump -------------------------------- Which gets it done in 3 programs and is actually probably the most efficient solution.

I'm not sure how to react to that, I could have done it in 4 but the logic is more confusing to follow, you took 3... it's definitely not a one or two program issue because there are essentially 3 possible states. The problem here is that every time the temp changes by .1 degree the If in the first program is re-evaluated, which will always interrupt the loop in the second program. Careful here... you're using two different temps.... "Temperature" and "Feels like", I'd recommend that you use Temperature for both. "Feels like" is only an expression of human comfort, not the temperature at which water freezes. Like I pointed out at the end of my original post, and was echo'd by @larryllix the temps should allow for hysteresis to prevent short cycling. In my program 1 changing the temp to 41 and in program 2 changing to 39 would give it a nice 2 degree spread.

The best way I see is to use a state variable lets call it "sPumpMode" It's init value should be zero for startup. It will be 1 when the temp is > 40 and 2 when the temp is <= 40 Program 1 If Temp > 40 AND $sPumpMode is not 1 then $sPumpMode = 1 -------------------------------------------------- Program 2 if Temp <=40 AND $sPumpMode is not 2 then $sPumpMode = 2 --------------------------------------------------- Program 3 If 7:00:00 am to 8:00:00 pm (same day) AND $sPumpMode = 1 then repeat every 60 minutes Set Pump to on Wait 5 Min set pump to off ------------------------------------------------------- Program 4 If 8:00:01 pm to 6:59:59 am (next Day) AND $sPumpMode = 1 then set pump to off --------------------------------------------------------------- Program 5 If $sPumpMode = 2 AND Pump is off then Wait 3 seconds Set Pump to on. ------------------------------------------------- Program 5 is written so that if something else turns the pump off it will get turned back on, the 3 second wait is there because without it and there's a program that (in error) keeps turning off the pump the admin console can become unresponsive, the 3 second wait will allow you a chance to stop. In an emergency you could also set the $sPumpMode variable to anything other than 1 or 2 to momentarily stop the program. The only other suggestion I have is set the temp a degree or two apart to prevent weirdness when the temp goes up and down between 39 and 41.

Since the z-wave board is unused you can upgrade to 5.3.4. When you back up your ISY just before the upagrade to V5.3.4 also create a text back up of your programs. To do that, open the admin console, click on the top folder (usually named "My Programs" but might be something else if you changed it or started originally with a much older ISY), Now right click that folder and choose "Copy Folder to Clipboard". Now open any old text editor that won't add formatting... windows notepad is perfect, click into that window and paste the clipboard. Save As the file with a .txt extension. Now if you want to see what your program looked like before the upgrade you have a reference. The first thing to do when you get back into the admin console after the upgrade is to check Help > About and compare your Firmware and UI versions. If they are not exactly the same, STOP, fix that problem... Likely clear your java cache including installed Applications and Applets and then install the ISY Launcher from https://isy.universal-devices.com/start.jnlp . The first time the launcher is run, it will install an Icon on your desktop that should always run the correct versions of the admin console going forward. The Launcher is a new tool to the arsenal invented in 2018 to solve the browser security warnings and launch the correct version of the admin console. Finally, the second thing to do after you're verified the firmware and UI versions is head to Programs > Summary tab... look for the color Yellow.. If you see any yellow it means one of two things... 1) the program needs manual attention or fixing and likely has an "Adjust Scene" in it or 2) you ignored the above paragraph and have mixed firmware and UI versions. ? Good luck.... version 4 to version 5 updates are not difficult anymore.

When I wanted to do this a year ago, I ended up with a zigbee shade, which directly interfaces to Home Assistant, I originally added a method for the ISY to be in control, but I ended up not using it that way. The Automation ended up 100% on the Home Assistant side-- it closes 30 minutes after Sunset, and opens between 5-9am when both (i.e. AND) mine and my wife's phone have been taken off charge, in other words when the second get's out of bed. (It actually has more logic tying in the ISY's $sAway variable, but its harder to describe that way.)

I can't answer the questions whether a 4.9 backup is directly restorable on Polisy, I would imagine you will need to upgrade to V5 first, (perhaps @Michel Kohanim can respond to that). That said. be careful, if you have version 4.9 your z-wave board is likely a 300 series (unless you specifically upgraded that). Open the Admin console and check the Z-wave version from the z-wave menu at the top. If the answer is 4.55.00 you have a 300 series z-wave board, if the answer is 6.81.00 then you do have a 500 series board. Why is that important??? you can only upgrade to 5.0.16C if you have a 300 series (version 4.55.00) z-wave board. If you have a 500 series (version 6.81.00) then you can upgrade to 5.3.4 (and not 5.3.0). Upgrade is fairly straight forward. However if any of your programs use the feature "Adjust Scene" then those programs require manual intervention.

You should update to version 5.0.16C, that's as far as you can go with a 300 series board. Yes you can restore your 994 backup on IoP (ISY on Polisy). Polisy does not have a built in z-wave board but the Zooz series 700 is what UDI recommends and also sells on the store page. Be sure to read up on the exact steps to take with z-wave, I've seen a few people end up having to start over with z-wave, I don't have any z-wave so I haven't been closely following the steps.

Get the connector.... it's easier and faster... here's the pin conversion:

You might want to open a ticket and get personalized help... support@universal-devices.com

So this program isn't running the first time? but it runs successive times? I assume that GarageOpen_1 is a state variable? If so, is it running one other program? or multiple other programs? The Wait 1 second may not protect the other program from finishing.... especially if that program has a wait in it. As soon as GarageOpen_1 drops back to zero the other program is probably going to end (since I can't see the other program that's a guess. why are you doing it this way? Why not just 'run program XXX' if or then?

Best thing to do is rename the light. I have some rather generic names for some like "lamp one" and then some more bizzare names like "animal crackers" that really don't describe the light at all, but Alexa knows what we mean and she never mishears it.

in addition to voice history in the app as suggested by @lilyoyo1 you might also log into https://alexa.amazon.com via a computer browser, I sometimes find it's easier to see name conflicts there.

Show us the intermittent programs...

You should be good to go, the ISY's REST API is identical... python is loaded but of course you don't have to rush to move those items from Pi or where ever they are located now.

yea good point. I was thinking of adding that but got sidetracked and hit send before i mentioned it....

5.0.16C is your stopping point. At this point in the game I don't recommend upgrading z-wave on a 994. Instead save your upgrade money for Polisy + 700 series z-wave. This replaces the 994 completely, and gives you lots of functionality in one box.

You can also open a ticket: support@universal-devices.com They are fast and amazing!

When you click the device in the device tree is the device type showing correctly in the right window? It's shown with the device address on the very second line of the right window just under the large type device name. I'd try holding the button for even longer, it does sound like the device needs a factory reset. Finally open the Tools > diagnostics > Event Viewer window and set the level dropdown to level 3, then turn the switch on and off using the admin console, and try the local button so see if it's trying to send anything even if the button doesn't work to toggle the load. If you need help reading event view output post it here and someone will help interpret..likely someone other than me, I'm not a good Event Viewer reader, but others here are.

Now that you have your system working again please upgrade from 5.0.16A. I'm assuming you don't have any z-wave, if that's the case go to 5.3.4 If you do have z-wave check the version.... 4.55.00 upgrade to 5.0.16c and don't upgrade to further firmware. 5.0.16c is a very stable release. If the z-wave version is 6.81 then once again 5.3.4. In any of the 3 cases, the update should take half hour or less of your time. Backup, load the revised firmware, wait for the reboot, you're done... there is no adjustments needed to upgrade from 5.0.16A to either of the above.

The important think to understand about link counting is that ANY Insteon traffic that occurs during the link count will destroy the link count. The resulting count can be way too low or way too high. In a system that's all switches it's easy to avoid other traffic... do the count will no one else is home and don't turn anything on or off. In system's with battery devices... it's a bit more difficult... motion and heartbeats in particular. To verify that the link count is valid run the link count repeatedly until you've obtained the same number more than once.

I'd bet on the left label being the actual address since it's obviously Hexadecimal, but that's confusing for sure. You can always try both. Also try factory reset. There's no difference in the Insteon devices different ISY models can control, it's compatible.