larryllix

Tried to buy a RPi 4 complete system lately? I can buy a whole desktop system for that price and pick it up in the store today. I don't want to hear about old parts people have hanging around to feed a system that hangs on its wires and must be mounted vertically so it doesn't act strangely in the summer. Complete system to compare apples with apples. Don't forget a power switch. Sent from my SM-G781W using Tapatalk

Here is a one program trick I like to use to create an 'inline If-Then' construct inside programs that should work. You will get a notification every time the threshold bobbles from <=5.0000 to >5.0000 kW, if there is no time hysteresis used. I inserted 2 hours as a random amount of time. YMMV. MBR Aux Heat On If 'Emporia / Vue 2 L / L11 MBR Furnace' Killowatts > 5.0000 kW Then Repeat while $iUsageAlertSent = 0 Set 'Notification Controller / Service Pushover polyglot' Send Sys Short With Params To all Priority=Normal Format=Monospace Sound=Pushover (default) Retry=30 Expire=60 $iUsageAlertSent = 1 Repeat 1 times Else Wait 2 hours $iUsageAlertSent = 0

There is a problem with the single program in that it will send notifications every second value change. First time the threshold passes 5.0000 kW the variable $iUsageAlertSent will be set to 1. Second time the threshold variable changes over 5.0000 kW the $iUsageAlertSent variable will be equal to 1 and the If section will be evaluated as false, running Else. Now $iUsageAlert will be set back to 0. Third time the threshold changes over 5.0000 kW the notification will be sent again.

Use two programs. The first one senses the event and runs the second program. The second program disables the first program and sends the notification. After the desired time or event the second program re-enables the first program. Techniques like this sometime require a third program to enable the first program to avoid it being 'stuck' in disable mode due to user error or power failure while disabled. I find I prefer using a variable as they are more bulletproof. Sent from my SM-G781W using Tapatalk

Where did the installation put the file? Not where you put it.

I cannot remember the usages I had for it but the hh.mm and hh.5mm varies were used to trigger routines that could not not be event triggered from other sources. IOW polling certain variable or statuses. Been a while now but the hh.5mm one was used to dim lighting on a gradual basis for evening dimming where I didn't want ISY hitting on groups of lights so frequently. Sent from my SM-G781W using Tapatalk

Where was it found?

No idea. Have you checked your firewall settings to see if access is permitted of that file? I have to assume that is OK as writing files is usually more sacred than reading them. I think you should open a support ticket with UDI. I would be sure Michel would like to see this first hand. BTW: Saturday is not usually a good day for support from Michel. Sunday usually is though.

MY polisy system is smaller now but it previously was larger, about 300 Program ad 400 variables. It would take about 2-3 minute to backup and IIRC about the same to Restore it.

Here is one example. The one I posted in another thread. Note the usage of the variable $Scratch.NoFrac (precision=0) . One line of code using a fractional modulus would have done the job of several lines where I had to start over to recreate the same parameter and then use some Integer language math tricks to create a fractional modulus 5 minute variable. (or use the previous resultant, shift it left two places, do an integer modulus 5, and then shift it right two decimal places again to recreate the fractional resultant) I could have used $Clock.scratch %= 0.05 to accomplish this. All the math seems to be there but there is no decimal shift correction included for decimal factors giving arithmetically incorrect answers. I also ran into incorrect program responses creating an automatic evening light dimmer based on the system clocks but not wanting the bank of lights to be hit on every 1 minute. The $sSys.hh.5mm clock was the solution for that one also so the system could do it only once instead of so many programs with the same algorithm calcs. clock.sync - [ID 0003][Parent 0002][Run At Startup] If // Run at Startup enabled Time is 12:00:10AM Or Time is 6:00:10AM Or Time is 12:00:10PM Or Time is 6:00:10PM Then // update $sSys.MM.DD $Clock.scratch = [Current Day of Month] $Clock.scratch /= 100 $Clock.scratch += [Current Month (Jan=1, Feb=2, etc.)] $sSys.MM.DD = $Clock.scratch $sSys.MM.DD Init To $Clock.scratch // update $sSys.hh.mm Repeat Every 20 seconds $Clock.scratch = [Current Minute] $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.mm = $Clock.scratch // update $sSys.hh.5mm $Clock.scratch.noFrac = [Current Minute] $Clock.scratch.noFrac /= 5 $Clock.scratch.noFrac *= 5 $Clock.scratch = $Clock.scratch.noFrac $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.5mm = $Clock.scratch Repeat 1 times Else // Run at startup will evaluate False Run Program 'clock.sync' (Then Path)

I think @Brian H was keeping score years back. I would be sure a raspy sinewave voltage would make the caps work harder to smooth off those sharp edges. Some have had many PLMs burn out, while others have never had a problem with their first one. I still have my original PLM from 2016? but it was retired for a USB unit on my polisy. I suspected it at one point in time, and replaced it for a few months, but returned it to service after I tested the "spare".

I named my dog "ISY". He automatically comes home to crash.

Possibly it could but I have avoided NSs mostly as they were residing in another box at the end of a cable and via switches and routers. I prefer sources of data as reliable as possible. On power up how long would it take for a NS to have accurate data available? My guess would be about 30-60 seconds after other programs have already done things based on time 00:00.

Thanks. OP corrected to include "Not triggered" The truncating of superfluous decimal is a problem for appearances for sure. We want floating point...usually. $sSys.MM.DD init to $Clock.scratch? IIRC there were cases where the variables were not initialised before programs attempted to use them. It may have been a quirk in the system time parameters. Only more recently, did I discover you can [Run at startup] and redirect the action back into the Then section after the [Run at startup] typically evaluates to False and runs Else. Also, IIRC there may have been an intermediary version where the startup process did not evaluate in proper order? It may have become redundant now. Very observant!

This may be of interest to some involved with seasonal lighting, using programs that are year independent. In the past we had to change our date triggers due to the year portion being static. Here is how I accomplish this task using my favourite little engine that could....ISY The Date Variables First we use the system variables to create a variable indicating the month and date of the month. I shift the resultant two decimal points so it looks nice to the user and can be used to create filters that will respond for 1, 2,3, 10 days or the whole month by eliminating the comparison decimals and only using a whole number representing the month. This requires creation of several state variables containing two decimals of precision as well as several Integer variables for calculation usage. These are necessary so that programs triggered by state variables are not triggered erroneously every time an intermediary calculation result is obtained. Only the resultant is actually transferred into the State variable. State variables are prefixed with '$s' in my system $sSys.MM.DD contains the month and day, both using two decimal numbers 01.01 to 12.31 $sSys.hh.mm contains the hour and minute, both using two decimal numbers 00.00 to 23.59 $sSys.hh.5mm contains the hour and minute, both using two decimal numbers, except it only updates every 5 minutes 00.05 to 23.55 This variable can be used to trigger cyclic programs that you only want updated on a 5 minute basis in order to not flood ISY with unnecessary processing or excess traffic on your device protocol Eg: excess Insteon traffic when you slowly dim lighting in the evening. clock.sync - [ID 0003][Parent 0002][Run At Startup] If // Run at Startup enabled Time is 12:00:10AM Or Time is 6:00:10AM Or Time is 12:00:10PM Or Time is 6:00:10PM Then // update $sSys.MM.DD $Clock.scratch = [Current Day of Month] $Clock.scratch /= 100 $Clock.scratch += [Current Month (Jan=1, Feb=2, etc.)] $sSys.MM.DD = $Clock.scratch $sSys.MM.DD Init To $Clock.scratch // update $sSys.hh.mm Repeat Every 20 seconds $Clock.scratch = [Current Minute] $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.mm = $Clock.scratch // update $sSys.hh.5mm $Clock.scratch.noFrac = [Current Minute] $Clock.scratch.noFrac /= 5 $Clock.scratch.noFrac *= 5 $Clock.scratch = $Clock.scratch.noFrac $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.5mm = $Clock.scratch Repeat 1 times Else // Run at startup will evaluate False Run Program 'clock.sync' (Then Path) Program Usage Now we use these variables in programs like this Christmas lighting one. Note the multiple times and multiple date combinations in use. Also my lighting scenes are driven off State variables that trigger banks of lighting scenes. I find not directly operating lighting scenes offers much more control and simplicity of programming the end user logic. Making later changes becomes a snap. A special note should be given to date ranges that include the end of the year. The range dates need to use "OR" logic, not "AND". IOW: we are saying after Nov.15 or before Jan. 07 since contiguous numeric dates stop at 12.31 and start again at 01.01 without any break in the calendar dates. XmasTree.onOff.inititiate - [ID 00D8][Parent 00D7] If // Vocal input also ( Time is Sunset - 15 minutes And ( $sSys.MM.DD >= 11.15 Or $sSys.MM.DD <= 1.07 ) ) Or ( Time is 5:00:00AM And $sSys.MM.DD >= 12.24 And $sSys.MM.DD <= 12.26 ) Then Set 'Dining Room / Christmas Tree' On Wait 7 hours Run Program 'XmasTree.onOff.inititiate' (Else Path) Else Set 'Dining Room / Christmas Tree' Off Simpler Usage Eaxmple Here is another example of using this system. This is a theme setter for Independence day. Note the usage of the ISY native time trigger ANDed with the $sSys.MM.DD variable to achieve this. Festive.set.USA - [ID 0083][Parent 007D] If Time is 12:10:00AM And $sSys.MM.DD is 7.04 Then $Festive.theme = $cMODE.USA $Festive.theme Init To $Festive.theme Else - No Actions - (To add one, press 'Action') Canada Day Date Range Program Example Festive.set.CanadaDay - [ID 007B][Parent 007D] If Time is 12:10:00AM And ( $sSys.MM.DD >= 6.25 And $sSys.MM.DD <= 7.02 ) Then $Festive.theme = $cMODE.CANADA $Festive.theme Init To $Festive.theme Else - No Actions - (To add one, press 'Action') Christmas Date Range Except New Years Day Example Note the combination of IS native time trigger ANDed with a date range and the New Years Day exclusion logic. Festive.set.Xmas - [ID 0081][Parent 007D] If Time is 12:10:00AM And ( $sSys.MM.DD >= 12.01 Or $sSys.MM.DD <= 1.15 ) And $sSys.MM.DD is not 1.01 Then $Festive.theme = $cMODE.XMAS $Festive.theme Init To $Festive.theme Else - No Actions - (To add one, press 'Action') Hope this inspires other programmers to be more creative with their ISYs. They are as powerful as your imagination. The cloud is the limit!!

The system has several system date and time variables that can be used but only on the right side of condition equations. I have created a few cyclic programs that update state variables so that I can create year independent programs that will operate seasonal lighting events. Time only triggers can be created in the "If" section native conditional logic.

@Michel Kohanim@bpwwer Has anymore thought been given to upgrading the modulus function to floating point? I didn't see it in IoP v5.4.5 upgrade

aartech.ca has this alternative on sale right now for only $1149 CAD. Sale ends tomorrow and it goes back up to $1378.62 CAD. It should perform as well as a polisy pro. You may need to add some I/O to it to make it work with your HA system. HomeSeer Pro

Yup. My routines started working again overnight now.

Same problem with routines again. Triggers from ISY go all the way through to display the change of state in the alexa app but the routines are not triggering like they did a week ago. Something set the alexa routines into misbehaving again. Last time amazon had to correct something but it seems the disconnection broke the Routine triggering again. Routines have been checked as still all enabled, tested for voice output from the manual trigger, and trigger point tested from ISY. Must be something that breaks the Routine internal logic. UPDATE: Routines began working many hours later. Rebuilding them, and dis/enabling them, did nothing but sometime in the middle of the night they repaired themselves.

Mine came back by itself except that I disabled the skill and it had to be re-enabled again. Routines will likely have to be re-enabled after pseudo devices went MIA. Thanks @bmercier

Mine came back up and reconnected by itself. However I had to reconnect my ISY Portal and amazon account skill again after the bad advice amazon app gave. hmmmm...routines likely need rebuilding and enabling again.

@bmercier Same here. ISY Portal server must have crashed.

@Michel Kohanim Nothing. ISY Portal has crashed.

No. The box contained about 40 Insteon devices. When I first grabbed the device to unplug it from the chain of OnOff modules it seemed totally intact. When I attempted to pull it out of the receptacle less than about 1/8" it shattered between every plug pin. As I began to wiggle it, in order to reduce further damage the device let go inside on all mounts and the electronics began to expose themselves as the device split apart. At that point I realised it was going to be garbage and pulled harder. I have been storing spare devices like this for years. Never happened before but maybe I need to examine the rest (and maybe lube the pins before putting any back into storage). I need to reduce my spare parts storage and this seems like it would serve that need well. *SIGH* If this was due to shock of some kind, then somebody hit it directly with a hammer. It shattered like glass when I pulled on it.