larryllix

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.

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.

Same call us, here is our phone number bait. Maybe the IP wall went up.

28 and 56 seconds? Your ISY must be wearing hip-waders. Have you checked your battery device pages to see if they are locked with green "1011" icons or programs constantly flickering colours?

I have run almost every v5 firmware UDI released so far and sitting back wondering why anybody would keep earliest versions just because the new device tables are in beta.

My bad. Yeah, I was answering your first post were you did use a browser before I read the second post enough. You appear to be measuring the http turn around time. ISY may do the job but not respond very quickly. I have also found the RPi o/s to take some time to switch tasks at times. If you can, try breaking the http function into a send and receive with time.sleep(0.001) between them to force RPi to allow I/o tasking. On second thought. Those times are way too long.

How are you inserting your credentials each time? With the first time access, your browser will usually ask you to enter your credentials, after ISY refuses, due to "not permitted". Every access time your browser will again get a refusal to respond due to security missing. Then your browser looks up every security it has ever been fed, and supplies them to ISY, without your knowledge. You would need to pre-encrypt your credentials and also use a browser that is capable of it.

As much as the screenshots are a PITA to post they really are worth a thousand words. So much easier than explanations.

DON'T play with creating an .env file. Some of those instructions in git-hub are out of date and may mess your system up badly.

I typically use Fast On Fast Off Wait 1 second or 0 second Fast On Fast Off. Wait 0/1 second The technique may make a good fast slice surrender though. Seems we need something to allow Insteon to be processed or the cache can clog up or you see erratic flashing. I like my flux net bulbs as I can send the built-in flash codes without any I/o bog down.

BTW:To get out of any repeat loop, only one "repeat 1 times" is needed to terminate all loops. "Repeat X times" is a syntax error but it is too late for UDI to correct it and be backward compatible. "Repeat 1 times" really means "Repeat 0 Times" or "Execute 1 Times" or "do not repeat at all".

What are the extra Repeat 1 Times lines for? A time slice surrender technique so the I/O can run?

I think with a little thought all Waits could be adjusted twice per year without too much problem but apostolakisls technique may be easier and more foolproof. Sent using Tapatalk

Using a mouse based O/S gives the option of cursor hover that shows what URL is in the link. You can examine the link before executing it. Touch screen users usually miss half the Internet browser features.

We can be our own worst enemies sometimes. Sent using Tapatalk

I shut my HRV down completely while on vacation. It cycles normally while just away (occupied= False). When my vacation mode terminates, my HRV runs for 40 minutes to ensure fresh air and less VOCs etc. Sent using Tapatalk

Make sure you get a newer version. There are lots of poor units out there as Insteon would never admit a problem. Just QA. Sent using Tapatalk

The link opens your email account with UDIs proper email address. Nothing evil here. Sent using Tapatalk

There were many threads and posts telling how to replace the power supply capacitors on PLMs. A soldier enabled tech guy may be able to get you up and running faster. Maybe take it to a radio repair shop and ask. Sent using Tapatalk

Yeah, I got thinking about your algorithm to convert all relative times into absolutes and then sort them into a stack that would always only need the next absolute time evaluated. That would present some complexities and each time change would require a specialised adjustment to be run. Could be done. Keeping waits as relative times and sorting into a stack, using the same technique, then absolute time would not matter at all. It would be based on a relative clock and no absolute clock would have any effect. Obviously that is not being done in ISY or DST should not be a problem. I guess there is always a solution. With so many absolute time based events in ISY code, it would seem maybe two timer stacks (one relative (for Waits) and one absolute time) would be the simplest. Just check both top of stack values every second against it's own clock. No DST special code adjustments should ever be needed. Reading your post again, I think you just said all that. Now there is the problem of 2:30 AM in the spring clock jump, could never trigger because it doesn't even exist......LOL. Oooops one more. How about 1:30 AM on the fall back which exists twice that night...LOL!!

Another fellow attempted this a few years ago with Insteon. Anything enclosed in a metal box that emits RF is asking for trouble. The X10 system he was using worked fine but when updated to Insteon it failed repeatedly. The old I/OModule, being powerline only may work OK. OTOH many newer Insteon modules have the option to disable the RF I/o. I wouldn't trust anything smartenit manufactured now after testing their X10/Insteon bridge unit. Others may have better success with their products.

NO. No Waits to be depended on. UDI has made an ISY system clock to be used for Internet synced and self backed up time.