larryllix

It will be automatic everything. I leave it off and check the box when updates are announced and I am available for any trouble that could happen. It updates immediately then. Nodelink has not given me much trouble updating. There is also a checkbox to update the ISY portion of NodeLink. I think I got into trouble with this one enabled (only) last time when it updated and my RPi portion didn't causing some critical variables to change. I recommend you keep both checkbox options set the same. Sent from my SM-G930W8 using Tapatalk

Some other Insteon device settings only use the lower 5 bits so that value 33 is the same as 1 and 65 and 129 etc.. Sent from my SM-G930W8 using Tapatalk

You haven't seen how Apostolakisl managed to get all this in v3 while we were all still in diapers! Sent from my SM-G930W8 using Tapatalk

Repeat while looping Sent from my SM-G930W8 using Tapatalk

When triggered by a change in the back door status, the program then or else section runs only once. There is no 'continuous' in event driven software. Sent from my SM-G930W8 using Tapatalk

In v5 we have access to the current time of day, current date, month, and other real time items from the system. Many users did backflips programming to get these prior to v5. What are you hoping to accomplish?

Where are finding the import/export menu? I wrote up a thread about a year ago on using this. I was looking for it to help somebody in another thread question last week and spent more than a half an hour looking. I couldn't find it in the admin console v5.0.14. I just figured UDI must have taken it out again. Make sure you always Save after making any program or folder modifications. Sent from my SM-G930W8 using Tapatalk

Real time variable/system variables are available in v5. Sent from my SM-G930W8 using Tapatalk

Bash is the command line interpreter for some linux operating systems. Run the terminal screen on your RPi. Sent from my SM-G930W8 using Tapatalk

Query ISY? Sent from my SM-G930W8 using Tapatalk

That sounds like you do not have the Report "On Only"" checked..

Yes those all-else-fails timers are important with HA. People get to expect lights to turn themselves off and forget they turned them on manually. I use that with voice commands also. With the low powered LED bulbs these days it is not so critical though.

I think there is some confusion in key terminology here. If you remove the front cover from a 6 key KPL there are the same 8 switches underneath. Conversion (change of key count) kits are available.

Nope they won't but I don't use many scenes created directly between devices. I prefer the control I get when ISY handles them. Exceptions are between MSes and the Lamps they control (for speed of response), every unit in my home for security flashing, and a few Gathering room scenes (reading, TV watching, Movie Watching, Bright, Full On all affecting the same group of bulbs) I think If you want to break the path between the LED and the garage light you have to dump the scene connection and use programs. You just create scenes for each LED and monitor/slave programs to operate the scenes like this. If status garage Light is On Then Wait 2 seconds <--- avoids signal clashes in the same box set scene.LED.A On Else Wait 2 seconds set scene.LED.A Off Now whatever or whoever turns the light on or off, the LED will follow.

I believe the Max Hops are set by the system and used by every device. The retries are set by each device and many newer devices can be set from ISY options on each device. If the Max Hops bits are set to 3 and ISY shows Hops Left as 3, then no hops were used before reception by the PLM. = Direct between device and PLM If the Max Hops bits are set to 3 and ISY shows Hops Left as 0, then all the hop possibilities were used up. Devices stop repeating these messages so the system doesn't bog down. If the Max Hops bits are set to 3 and the PLM never received it shouldn't show up as an event in the logs. I believe it doesn't matter how many hops were used, the reception end has to wait until all three hops are bypassed (messages ignored) before it can respond with an ACK. If retries are involved the time it takes gets compounded. Now if the ACK has problems getting back also Insteon gets real slow. This is why a noise free power grid system is so important. Insteon usually gets there through a lot of garbage, but it can get real slow and ISY usually gets the blame. I just found two GDOs making noise (one since the beginning of time, one newer is noisier and gave the clue) and now my system is flying again!!!! My very first Insteon filterLincs ordered!

It works with 7-Zip to unzip it.

@arf1410 You can add an extra logic line in your programs like this offering two (or more) paths for any event trigger. If control KPL.Button.A is Switched On AND it's nighttimeThen do whateverElse ----- If control KPL.Button.A is Switched On AND it's NOT nightTimeThen do whateverElse -----

If I understand you correctly, you want to modify the scene used with each key? I don't think this is possible but you can dump the scene links and use programs to make the KPL key operate anything you want and change it with programming. The extra program usage time taken is not usually a problem for manually operated devices, but Motion Sensor to Lamp systems should not have the extra In/out of ISY delay. It is annoying. This extra time delay is not due to ISY CPU speed. It is due to the Insteon protocol taking time and waiting for all the Hops to finish, needed or not.

Hops are not reties! When an Insteon transmission is heard, all capable devices synchronously repeat that transmission. When another device hears this, one hop is completed. This allows Insteon signals to transmit to the Initiating device---->hop---->second device----->hop----->third device----->hop----->PLM or reverse orde,r PLM---->end device This is not counted as a Hop Initiating device ----->PLM On top of all that if an ACK is not heard back or a NAK is received Insteon devices will/may try again with repeats of the whole process. Zero hops left is not a failure. It means it took three intermediate devices to get there. If it failed, ISY wouldn't know about the attempt and you would not likely see any recording of an event.

The 1011 means there is binary code to be written to your device yet. If the device is battery operated it must be put into linking mode first. Then you can right click on it and select "Write Updates" As kclenden posted above, you need good comms first or things get messed up.

Sure. Write a program for each button and put whatever you want in each program. Configure your KPL to non-toggle On mode. If control KPL.Button.A is Switched On Then do whatever Else ----- KPL LEDs can have levels changed with programs in the admin console (all for one setting) but LED On/Off can only be done with scenes. Of course, then use programs to activate the scenes.

Post your program!

I don't think java ever made a 64 bit version. Install is made for a 64 bit O/S but java is 32 bit only. I may be wrong but years ago they announced they would never support 64 bit. Apparently java's install made the decision what to install.

I would use a State variable to control the pump. A simple final program to turn it on and off would be required and this may simplify the look of your programs making it easier to implement complex logic. Another advantage of a variable control is that it can only be turned on once and multiple programs can't keep hitting on it to cancel other timers. If $sPump = $cTRUE Then set pump On Else set pump Off Now using a vacation variable, things can be based on that logic flag If $sVacation is $cTRUE Then Repeat every 72 hours $sPump = $cTRUE Wait 10 minutes $sPump = $cFALSE Else $sPump = $cFALSE <----- vacation might be over while pump is on and then stays on Now you require programs to turn on your vacation mode flag. This flag will be used for many HVAC and other programs . This can be set off HVAC stats and other sources, even manually. I base mine on multiple logics. Mostly 12 MSes with different timeouts from each after seeing motion. If $sVacation is $cFALSE <----- add this to each existing program logic. AND your other time logic similar to what you have shown above etc.. Then $sPump = $cTRUE Else $sPump = $cFALSE To create a cycler after no action something like this could work. If $sVacation is $cFALSE AND $sPump = $cFALSE Then Wait 72 hours $sPump = $cTRUE Wait 10 minutes $sPump = $cFALSE Else $sPump = $cFALSE <--- another just-in-case recovery Now you can add all your shown logic, above, to operate the $sPump variable. This may make it easier for understanding and make program logic shorter, breaking it down into smaller logical blocks. I don't like basing program logic on other programs. I find that method obscure and can bite you down the road because it isn't visible inside programs being edited, that another depends on it's state.

@oberkc That's what I was eluding to, but I was trying not to complicate things just yet, by combining the logics, and I was hurrying to provide an answer. (excuse, excuse) Then the manual lock on / turn off and cancel comes in. The whole thing looks too complicated now and I don't like that, but comfort comes with familiarity. Being more familiar with the light placements would help understand the logic needed to provide better answers and logic. I have found simpler programs for more lights usually works better down the road when I come back and wonder WTF did I do?