larryllix

Start Top of Hour Clock - [ID 000A][Parent 000D][Run at Startup] <------------- If Then Send Notification to 'MY_GROUP' content 'ISY_REBOOTED.NTF' $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) <---- only ever calls program once upon power up. Else - No Actions - (To add one, press 'Action') Find First Top of Hour - [ID 000C][Parent 000D] If $Minutes_of_Hour is 0 Then $.Top_of_Hour += 1 <--- is this a State variable? Most here denote State with "s" prefix Else Wait 20 seconds $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) Note Top of Hour - [ID 000B][Parent 000D] If $.Top_of_Hour > 0 <---- must be State variable to trigger program, Self triggering loop? Then Wait 1 hour $.Top_of_Hour += 1 Else - No Actions - (To add one, press 'Action')Note Top of Hour - [ID 000B][Parent 000D] An alternate consideration -could use absolute real time hour above (Not +=1) also $.Top_of_Hour = [Current Hour] Note Top of Hour - [ID 000B][Parent 000D] If Then Wait 10 seconds <------ keep away from jitter point Repeat every 1 hour $.Top_of_Hour = [Current Hour] <-----create real time hour variable for usage elsewhere. Else ----- Very confusing method for me but looks like it should work if a State variable was the intent. You will always need to kickstart it manually after editing it. Proofing will be the final test.

Awesome concept! I like it! I am not sure UDI has gone that far for process control yet though. OTOH they did make some basic engine changes on or about v5.0.4 that apparently sped up processing. Who knows? M. told me there was no list, at one time.

My understanding is when the program is installed, each line is compiled into ISY isms, and triggers are installed into a table or list for the processor to check every X CPU clicks, or whatever time base ISY uses internally. This would avoid the ISY engine from having to "dig" through all the programs looking for what needs doing...for CPU speed and efficiency. Of course this is all conjecture on my part, from writing machine level code with less than 400 bytes of memory and a 1MHz CPU in 1971.

I have no special ISY inside information, but MY logic tells me, based on best resolution of each program element... - Wait lines would need an low-level ISY algorithm that checks for the end timeout every second. -Time trigger lines would have to have an low-level ISY algorithm that checks all time triggers every 60 seconds. Without knowing exact processing times one check every second vs. 24 checks every 60 seconds..... looks like you won!

Nice! With this technique it would be simple for newbie ISY programmers and result in a state variable containing the current system hour, usable elsewhere and never have to be used again. To keep the hour under 24 hours the second program could look like this. If $sHourlyIncrement >= 23 Then $sHourlyIncrement = -1 Run 'Program ThisOne (Else)' Else $sHourlyIncrement += 1 Run stuff The two programs could be combined into one with a more compound If section logic but I would likely separate it into two programs by logical function. One for e the clock setting the variable, and one for the slave function at each hour top. Just the way I tend to think.

For inefficiency and CPU cycle wasting...I doubt you would have to worry about it with ISY and when it comes time, you will have a Polisy running about 40 times the processor speed, with hardware clock and hardware buffered I/O etc.. The repeat every 20 seconds...Correct, runs forever. Init to is a variable assignment statement that programs a ROM copy of the variable for boot up, initial value. One of the first things ISY does is to copy all the "init to" ROM variable values over to the RAM copies of the same name.

I have to agree with that logic. I used a previous system which limited the number of timers available while ISY doesn't, and I suspect too many may bog some processes down. This is one reason to create a central time keeper and have all other programs use it. However, causing ISY to have to check each of 24 time triggers, every system minute change, in a program, may have more detriments to the CPU schedule, anyway. With down to one second resolution, ISY Wait timers may get checked every second? hmmmmmm…. I see the need for the Polisy CPU speed increase coming. Looks to be about 40 times the processing speed.

I would prefer to create a stable system clock, independent of any other hardware or systems, that could be used in many programs. Automatic startup is always a problem in ISY and it typically takes an extra program as kclenden demonstrated above. No flagging variable is needed, only one to keep the current system minute clock. This program needs to have "Run at startup" enabled. Reboot and Initialise - [ID 0040][Parent 0006][Run At Startup] If // Enabled to Run at Startup only Then Wait 2 seconds Run Program 'Set hh.mm' (Then Path) Wait 1 second Run Program 'Set MM.DD' (Then Path) ... Send Notification to 'Text Larry' content 'ISY Rebooted' Else - No Actions - (To add one, press 'Action') Then a program to keep system clock variables. I generate a combo variable $sISY.hh.mm also. Note the extra trigger times are for those times that you stall the process editing the program etc.. and no reboot is taking place. They can kickstart the program again. Note: The usage of State variables where triggers are needed ie: $sISY.minute and $sISY.hh.mm Set hh.mm - [ID 00FC][Parent 0006] If Time is 12:00:05AM Or Time is 8:00:05AM Or Time is 12:00:05PM Or Time is 8:00:05PM Then Repeat Every 20 seconds $sISY.minute = [Current Minute] $ISY.date.scratchpad = [Current Minute] $ISY.date.scratchpad /= 100 $ISY.date.scratchpad += [Current Hour] $sISY.hh.mm = $ISY.date.scratchpad $sISY.hh.mm Init To $ISY.date.scratchpad Else - No Actions - (To add one, press 'Action') Now all any program needs to trigger on the hour would be to watch the system clock based variable. No looping or self starting programs, keeping it simple. Run every hour on the hour - [] If $sISY.minute = 0 Then execute stuff Else ---

IIRC I read about heartbeats that only send On and previously some that alternated ON and then Off. I never saw any Off only heartbeats.

If this ISY cannot be recovered I would be getting a good electrician in to check your neutral and grounding. Your utility may offer some service also. Sent using Tapatalk

I waste a variable for a comment in the title for groups of common purpose variables. ------------------------------------------------- WEATHER STUFF ----------------------- another variable Sent using Tapatalk

Must have been in a state of flux. I am using v5.0.16c.

I keep reading people posting that advise but all I have ever get is the folder.. My Programs - [ID 0001][Parent 0000] Folder Conditions for 'My Programs' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. UPDATE: I see UDI has now split it into two options. "Copy to clipboard", and "Copy folder to clipboard" "Copy folder to clipboard" is what works if v4.xxx has it.

Try admin/admin. It may have been reset.

Not based on battery strength but on conservation technique. It may natively transmit a much lower power signal.

Lock/unlock is going the opposite direction of signal path to status coming back. The lock may have a much weaker signal due to battery life concerns. I wouldn't assume that.

The KPL LEDs are controlled by Scenes only. You have to create an Insteon scene for each LED and turn them on and off. LED brightness level is controlled across the board with a program command line. All LEDs will have the same brightness when on. It may be good to inject a Wait 1-2 seconds to allow Insteon traffic to settle down before hitting the LEDs with a change if it is based on a same KPL button press or reception of a wireless device via the same KPL. They act as one device and can cause problems with congestion into the same device (having so many Insteon elements in one address) I "borrow a smart bulb and flash it in the corner, while garage doors are open. If my ISY sees me turn off the lights and then motion in the bedroom, that lamp flashes 100% brightness. My Alexa speakers also announce which garage door is open and when both are closed again. It becomes "usual" and is missed if not heard.

Duplicate post from another thread.

ISY will not use any ports that it does not need. It doesn't wander through cyberspace.There is no need to block any ports from the LAN side of your router. There is no need to block any ports from the WAN side of your router. Your router already does that.

A bit confused here. You could break your functions into smaller programs. It makes it more modular and easy to understand. Sensing the same element you are controlling (jn the same program or system) is a bad idea in a trigger based language. You don't need the tests but it will set the Stat to Home each time the lock entry is used by these people. To avoid this variables or other flag methods to keep track of would be necessary and the feedback loop may be recreated again. If Keypad person is 1 or Keypad person is 2 Then Disarm system, Turn on light etc.. Else ---- If system Disarmed Then Set Thermostat Home On Else ---

ISY should not be blocked or email, SMS, ISY Portal, PolyGlot, NRs may not work. Your router does not allow any traffic from the Internet to your LAN unless you port forward and make holes in the router's natural firewall. Things inside your Lan, like your browser and ISY initiate requests to go outside and get answers and your router allows those answers to come back naturally. It's all about the direction of who asked the question and firewalls allow the answer back through.

Look what you have done to cause this. If Elk Area 'House' 'Armed State' is Armed Then Set Elk Area 'House' Disarm Why care if the system was armed before? Just disarm it, if a 2 is registered. No circular negative feedback. This may not be a good idea as it will compromise the security level of your system. This will allow any length of combination to be detected from a KPL

Nice! My Alexa Show gives temps every few hours on the screen. It's sound booms even more for voice and the temperatures never get up to 70 here so there must be something wrong with it. F/C

My S-I-L started out with GH units and got some Echoes later for some app reason? Her usage is not much for remote control,, but mostly for music. She also complains that her Echo 3s do not have the power. I think the GH speakers must produce about 5-10 Watts of sound while the Echoes, about 0.25 - 0.5 Watt. They get distorted and tinny at higher volumes while the GH units can really rock, not room shaking, but quite loud, and still stay clear. How are you finding your Echo, compared to your GH speakers?

That was the thread most features and updates were requested and UDI would respond fairly regularly. OTOH we never had the @XXXXXX attention getter back then either.