Programming enhancement: time periods

[bsobel]

Hi,

 

Since you are looking at programming enhancements this year, I'd like to add a request for one I think would help simplify the overall programming experience.

 

I'd like every item that has a 'state' (Insteon items, zwave items, variables, etc) in the ISY to keep track of the time (preferably in seconds) since that state last changed and then be able to use that length of time as an event available via a new 'runtime' command that would compliment 'status' and 'control'

 

E.g.

 

If status Insteon_BathroomFan is ON

and if runtime Insteon_BathroomFan > 300 # 5 minutes

then

set Insteon_BathroomFan OFF

 

if variable DSC_ZONE1_MOVEMENT is ON

and if runtime DSC_Alarm_Armed < 120

then

# Exit delay running...

 

etc.

 

This would, I believe, greatly simplify those scenarios where we keep track of the length that something happens in an attempt to later modify the same device. I very common usage case, IMHO

 

Thanks,

Bill

[Xathros]

Bill-

 

Interesting idea.

 

The ISY already tracks change time on variables I think so the time since change on those should be just a calculation. AFAIK, there is no time stamp on device state changes though they do get logged so does not seem like that big a jump to record those times as well.

 

While this seems useful, and the logic in your sample code seems a bit more natural, I haven't yet been able to come up with a use case that can't otherwise be accomplished currently with a wait. It just moves the delay from the Then/Else into the If.

 

Maybe I don't fully understand your idea.

 

-Xathros

[bsobel]

I may have oversimplified the examples, I have a few cases where I'm tracking how long an event occurs (occupancy and a few other cases). I agree the simplest case the wait can cover, but have enough programs that track something and then have built timers to update it later that I think this would be useful.

[Xathros]

Bill-

 

I've been thinking about how this would be useful to me. I have a few programs that track duration. How long the pellet stove or oil burner run each day. Occupied vs vacant hours per day etc. This would be useful and make these accumulators much more accurate than they are now but it would require the ability to grab or calculate the prevoius state duration at the point of a state change. Simply knowing when the state last changed wouldn't be of much use in this case.

 

I'd like to be able to say:

If 
  s.Oil_Burner_Running is 0 
Then  
  Burner_Runtime_Total_Today =+ s.Oil_Burner_Running(PreviousStateDuration)

 

Likely it would mean tracking 2 data points for each device/variable:

a) Most recent status change timestamp

Previous status change timestamp

 

The duration could be calculated on the fly by the ISY from the above data points.

 

Then, do we also need to know what the status changes were? From and To? For on/off devices we could work this out from the current state but for dimmers or thermostats, not so much.

 

Not sure how easy that would be for UDI to implement.

 

Your thoughts?

 

-Xathros

[bsobel]

I see what you want to do, I wonder if it simplifies things if we expose the ability to better control the timer, e.g.:

 

If

s.Oil_Burner_Running is 0

Then

Burner_Runtime_Total_Today =+ s.Oil_Burner_Running(PreviousStateDuration)

 

Becomes something like:

 

if

s.Oil_Burner_Running > 0

Then

TimeStart s.Oil_Burner_Running (Starts timer if not already running)

 

If

s.Oil_Burner_Running is 0

Then

TimerStop s.Oil_Burner_Running (stops the timer)

Burner_Runtime_Total_Today =+ Timer s.Oil_Burner_Running

TimerReset s.Oil_Burner_Running (reset timer to 0)

 

The timerstop above is probably not needed in this example, but would be useful when you want to keep an overall usage in the item itself (e.g. not reset it to 0 on state changes but rather timerstart when the item state > 0 and timerstop when it is not)

 

The change being each device counts up but we can control when we reset it to 0 instead of doing it on each state change automatically. This way for dimmer and other loads you could reset it when going from off to any on level but not from any on level to another one. And this way UDI only has to track one additional thing, not two (or one per state which could be 255 per item)

[Xathros]

Seems like a reasonable approach.

 

It would mean adding a new type of variable: Timer. Timer mvars would have both a value (in seconds) and a status (running/stopped). They would be simply set/reset like other mvars by setting current value and/or init value to 0 or other integer value. I wonder if a third paramater could be count Up/Down. Could act on countdown timer expiration but I guess it's just as easy to react when a timer reaches an upper limit as well so that might just be fluff and functionally no different than the current WAIT will be with access to a variable value.

 

Would require new program commands to start/stop.

 

Your example is pretty much what I'm doing right now like this:

 

If 
  s.Oil_Burner_Running is 1

Then 
    Repeat Every 1 minute
    i.BurnerRuntimeToday =+1

 

Not high on the accuracy scale but good enough for my needs. I could make the repeat every 10 seconds and divide down the result but don't need that level of accuracy and opted for reduced load instead. I massage the daily total down to hrs:mins for my daily log/report then reset to 0 at 11:58 pm (Midnight is a busy time for Izzy)

 

-Xathros

[Michel Kohanim]

Thank you!

 

#85.

 

With kind regards,

Michel

[arw01]

Similar along the lines of some timer functions suggested in another thread that died in the we have a work around lines.

 

Also useful is the time remaining on the timer itself. Ability to do calculations on that.

 

My previous insteon installation controller kept an array of 10 or so of the latest state changes and their time. I did not use them programmically, but it was enlightening to see patterns for other issues or when kids may or not have been active around the house (e.g. taking a nap when they were supposed to be doing chores)