Posible to update a timer period in Edge Action?

Octave
1

I have a use case that requires the ability to set a timer duration (period) dynamically.
Using a virtual resource would be ideal.

I need to be able to update the timer duration (period) in an edge action.

The particular test is to set a value for ULPM “up time” duration – i.e. how long
the device should stay “awake” between ULPM sessions.

I have a test working with a timer duration (period) specified in the timer resource, but
I need to be able to read this value from a VR and update the ulpm_up_timer period with the new value in an EA.

I cant see how to accomplish this. Two timers are currently in use:
bootup_timer
ulpm_up_timer

So the timer config looks like:

timer
   config <output> = {"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}} (ts: 1684700154.699300)
         data type = JSON (e.g., '{"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}}')
         default = JSON: {"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}}

Is it possible to update ulpm_up_timer “period” to new value in edge action?

Many Thanks!

2

Hi @dpinc
You can achieve this by writing the timer configuration with an edge action.
Something like this should do the trick:

var my_new_period = 100
var timer_config = {bootup_timer:{period:1,repeat:1,autostart:true},ulpm_up_timer:{period: my_new_period, repeat:1,autostart:false}}
return {
		  "dh://timer/config": [timer_config]
	  }

HTH,
Nicolas

3

Thanks! This works, but for some reason the module reboots when the timer config is updated. I took care to verify that the correct element in the correct timer is updated. For testing I backed up the original timer config to a VR. You can see that ulpm_up_timer period was updated from 302 to 401 – see below:

Original timer config (save as BU to VR):

root@swi-mdm9x28-wp:~# dhub list /app/virtual/timer_config_BU
timer_config_BU
   value <input> = {"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":302,"repeat":1,"autostart":false}} (ts: 1684808396.425500)
         data type = JSON (e.g., '{"value":{"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}},"timestamp":1684800859.49399}')
         default = JSON: {"value":{"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}},"timestamp":1684800859.49399}
root@swi-mdm9x28-wp:~#

Updated timer config (as applied)

root@swi-mdm9x28-wp:~# dhub list /app/timer/config
config <output> = {"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":401,"repeat":1,"autostart":false}} (ts: 1684808396.407007)
      data type = JSON (e.g., '{"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}}')
      default = JSON: {"bootup_timer":{"period":1,"repeat":1,"autostart":true},"ulpm_up_timer":{"period":300,"repeat":1,"autostart":false}}
root@swi-mdm9x28-wp:~#

I think I would be in good shape if I can keep it from rebooting upon timer config update. Thanks for your support!

4

It seems updating timer config causes many undesirable behaviors with any other timers, observations, and actions. The timer config update suggested was successful, but the device state appears to be reset with unpredictable results.

For anyone with a similar need to set / vary a timer duration dynamically, (which does not appear to be supported by the platform) a solution that worked for my case was to set the timer duration (period) at some small duration, i.e. one minute. A Virtual Resource was used to specify a duration “multiplier”. This value was read at each timer expire. The desired timer expiry action is only executed when the timer count (i.e. the number of times the timer expires) reaches or exceeds the Virtual Resource duration multiplier value. While not as efficient as updating the duration directly, this is the next best solution found.