Jump to content

"Init to" option for input device values


larryllix

Recommended Posts

Posted

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.

Posted

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.

Posted

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).

Posted

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.

Posted

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!

Posted

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

  • 7 months later...
Posted

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.

Posted

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.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...