larryllix Posted March 10, 2016 Posted March 10, 2016 BACKGROUND Many attempts have been made to extract values from input devices into ISY variables. V5 is making this much easier to do with direct program functions. One popular usage of these variable copies of these input data copies is to eliminate the unknown and blank value after ISY powers up, or other interruptions in status are incurred between ISY and remote devices. ISY remembers the latest known status and analogue inputs/output of devices during normal operations. PROBLEM The problem happens often when ISY first powers up it is a blank slate. Querying devices can get the latest value of most Insteon devices but not battery powered devices. This is usually analogue devices used for temperature and other level based logic decisions. Thermal input devices can take hours or even days before a change and thus any reported update is had by ISY. Thus ISY sits with a blank value causing notifications and bad decisions to be made for heaters and humidifiers, to offer just a few of the common ones. REQUEST Can an option checkbox be added to devices, similar to the variable "Init to" variable option? This option, when enabled, would always keep a "init to" copy of the latest know value of it's affected input, and replace the working copy used by ISY upon ISY power up? EXAMPLE ISY powers up and instead of the main house thermostat seeing a blank input it would contain he last known thermostat temperature reading. This temperature may be obsolete but decisions could be made to operate a heater based on the old temperature instead of a 0 or blank. A soon as the temperature changes by the smallest resolution the ISY value would retrigger any program affected as per normal ISY logic. ADVANTAGE This could eliminate the need for many program lines attempting to validate input readings in decisions being made. Newbies would not complain about blank input boxes and missing data values. IMPLEMENTATION This would need to be an option checkbox for each device node, affected, as some uses may not want this function, and the unchecked default would maintain backward compatibility. This should function in a very similar manner as currently implemented for variables. No "init to" value would need to be visible to the user as it would always match the current working value. Status inputs could be included for door and window sensors as well as IOLinks. Usage would be a user selection. A disclaimer could be popped-up when turning on regarding temporarily false information.
Teken Posted March 10, 2016 Posted March 10, 2016 Love the idea but don't see that coming down the pipe anytime soon. This would be similar to my request that the last time stamp be remembered in the variable list. I really can't understand why those time stamps can't remain upon reboot.
Chris Jahn Posted March 11, 2016 Posted March 11, 2016 We'll add it the list, but I'm not sure if we can come up with a workable solution. The basic problem is if we have to write to the SD card every time a variable or device status changes it could impact performance (and may not be great for the SD card itself).
MWareman Posted March 11, 2016 Posted March 11, 2016 I have one doing this already. The device updates a state variable, and I have a program triggering on the state variable changing to set the 'Init To' on the variable to the new value. If the ISY resets, this variable comes up at the last known value.
larryllix Posted March 11, 2016 Author Posted March 11, 2016 I have one doing this already. The device updates a state variable, and I have a program triggering on the state variable changing to set the 'Init To' on the variable to the new value. If the ISY resets, this variable comes up at the last known value. This is the way I do most of mine also but I thought this could eliminate a step. Are we not writing to the SD card when constantly stuffing "init to" parameters? Should we be cloning our SD cards and taping the clone to the bottom of ISY? Uh oh! Send in the cloud!
larryllix Posted March 11, 2016 Author Posted March 11, 2016 We'll add it the list, but I'm not sure if we can come up with a workable solution. The basic problem is if we have to write to the SD card every time a variable or device status changes it could impact performance (and may not be great for the SD card itself). Perhaps some way to shove this low priority task to the background would be needed and a way to insure it was NOT easy for users to just check all the boxes. Possibly implement in a program command line to eliminate abuse of feature? Set Stat.temp init to Stat.temp
MPG Posted November 11, 2016 Posted November 11, 2016 MWareman, what is your if logic to trigger the program any time the state var changes? "$var is $var" seems to be working for me, but I'm not sure if there is a more proper way to do it.
MWareman Posted November 11, 2016 Posted November 11, 2016 MWareman, what is your if logic to trigger the program any time the state var changes? "$var is $var" seems to be working for me, but I'm not sure if there is a more proper way to do it.I do "$var is not 9999" where 9999 is some impossible value. Adjust for your application.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.