larryllix

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.

Look for programs, devices, and scenes with yellow icons for items the conversion knows it couldn't do perfectly. Sent using Tapatalk

I still prefer ISY's internal clock to dependence on another piece of hardware or software and network equipment. ISY v5 has it's own clock functions available as pulldown menu available system variables. Another source of real time may still screw up but should recover unlike some ISY wait based infinite loops. Once a wait loop stalls it will not restart again without some special triggers to kick the loop again. Sent using Tapatalk

'You will be charged with theft, possession of stolen goods and postal insurance fraud' ...and it must be correct because the computers, backed by the US government says so. Sent using Tapatalk

I hear GH uses facial recognition too. Sent using Tapatalk

We have gone through this every year at DST time. UDI stated they will get a fix for it but I don't think there is a fix, only a few workarounds may be possible. When the clocks move ahead there is an "empty" hour that nothing can happen during that hour because it just didn't exist. When the clocks jump back you have a duplicate hour with the same hour number so a computer hour clock would have 2 for an hour, possibly 3 for a split second and then 2 for another hour and then 3 for another hour? IMHO any possible solution in the low level ISY engine would likely mess up some ISY programs while others may work OK.