Rules Engine Operation after Restart

[ChrisM]

Hi, I am looking for some help to understand what happens to rules that are in process when I edit other rules.

For example,  rule #1 is triggered at 8pm turning on a light with a restore timer of 4hrs.  i.e. it should restore (turn off) at midnight.

At 9pm I open AM > Manage rules > and edit rule#2, and save changes.

Should I still expect that rule#1 will complete the restore at midnight? 

Thanks

Chris

[Mike P 4 MPP]

The rule engine restarts if you edit a rule, meaning rules in progress (delay or restore) will be canceled - it won't fire at midnight.  If it's critical for the device to turn off it's better to use a SetMomentary if it's supported (and short enough for the device, generally 4hrs is ok) or a separate rule, e.g. triggered 4 hrs after noticing the light turns on (which will be delayed by the restart, use "not interruptible") or always off at midnight.  A SetMomentary on a persistent flag can work well too as the off time will be persisted so won't be delayed by the restart - use a "follow" rule to slave the bulb to the flag state.   The "Manage Rules" viewer shows a "*" beside any delayed trigger so you can double check if necessary.  If it's infrequent (which was my assumption in the design) you can use "sleep" or test the rule to restart it after editing.

[sergey]

Hmm, interesting , I miss that ...  Mike,  did you mean , that all momentary counters resets to zero when the rule engine restart?  I know that flags that only persistent keep their state intact. 

[Mike P 4 MPP]

Not certain I'm understanding the question since I was saying the opposite:  the difference between SetMomentary vs SetDevice+Resume is that "momentary" timers are meant to run on the target device so can be more reliable if the device itself doesn't restart - they're unaffected by an AM engine restart, loss of network/wifi, etc.  The exception is in AM Flags that have a "SetMomentary" that of course need to run locally to AM as they're local :).  The purpose of the "persist" flag is to let you decide whether it's worth writing to the phone's storage when the flag changes state (since phone storage life is somewhat limited).  If persist is used, "SetMomentary" on a flag writes the state and expiry time to storage so will survive if the AM rules engine is restarted.

But I would definitely suggest avoiding building rules that try to survive AM engine restarts - hopefully those are rare so doing so would be needlessly complex.  I would instead code for reliable behavior based on the type of device, it's importance, and the type of schedule you're trying to run. On the (hopefully) rare occasions that you update rules you could adjust any affected devices manually.

[ChrisM]

Thanks for the detail Mike.  Much appreciated.

[sergey]

Thanks Mike, that is clear, the confusion is in the terms - either you meant AM Momentary or device's. ) 

[Mike P 4 MPP]

Ok - though I'm not sure by what you mean about AM's Momentary?  AM's SetMomentary always uses the device's on board timer - devices that don't have a Momentary function won't be available in the target list.  The exception is AM Flags - though logically those timers are still running in the device (which is AM itself vs the AM Rules engine).  All other AM Rule timers like wait/delay, restore, periodic, schedules, etc run inside the AM Rules engine (an important distinction as many commercial devices offload schedules from their cloud service to the IoT device and make it keep track of the time).

[sergey]

Yep, Mike, as I told you , it's all in terminology . As for me , the "Momentary" term  never been usual .., so , now , I'm used to say Momentary for everything that using timer, doesn't matter where does it happen on a device or on the AM. I that case I thought about rule action SetDevice and Restore. The point is that I use cascade  switching for multiple devices. For instance:

Device one fires by the rule action "SetDevice to ON and restore after..." , the device one has their own "global flag switcher" that changes the flag device state on AM server , when some important things where done( but continue their job), when the rule finishes , the flag keep their state intact within whole day till the time ( before midnight) when all flag been  cleared by special rule. I thought that in you first reply , you meant that all timers  been cleared as the server  restarted .. In my case the such flags keeps their state itself.( as help me to code).

[Mike P 4 MPP]

Definitely there's a difference - there are purposefully separate actions for "SetDevice" (that has a restore) and "SetMomentary" (for which a restore is not necessary).  It's deliberately that way to distinguish between timers run on the device (momentary) vs timers run with the AM Rules engine (wait/delay and restore).  The main reason is for precision - the device timers are 10ths or even 1000ths of a second, while with AM the timers are 1000ths but there's an indeterminate network delay.  It's a secondary effect that SetDevice/restore is reset when the rule engine restarts (rarely I hope) vs SetMomentary which can be broken if the device crashes/restarts (again I hope rarely) and generally I would suggest rules aren't coded for that behavior.  I do my best to be consistent with that terminology though I might sometimes slip...

In your example, the "restore after" action could be interrupted by an AM Rule Engine restart.  So if you edit a (any) rule you'll need to do something manually to recover any restore or delay that was canceled.  Schedules (vs restore or wait/delay timers) are delegated to the android (or java) OS timers so are less likely to be affected - they're still kept even if the AM process is stopped.   They may not fire on schedule if something prevents AM from starting, but they will fire next time AM starts if they expired while AM was stopped.  The "persist" flag SetMomentary action is a way to convert a restore/delay to a scheduled action when it's critical.  But as I said, editing should be relatively infrequent and the AM Server itself shouldn't be crashing.

[sergey]

Thanks for explanation again. From what you said I would infer the question - Why you don't rely upon OS timer in all tasks , but in schedules only? As you mentioned the Android based timer seems to be more reliable ? What does prevent you from making  SetDevice based on Android schedule?   1000ths of a second ? where we could see them to be useful?
It just only for  general education- everything is fine. In my new custom AM-camera device I really need in accurate time between actions , just because  flow from 5M camera with 20fps refresh rate might generate quite frequent events (neural network in camera generating high state on one of camera's GPIO if interesting object is found). But that is only comes to my mind.

[Mike P 4 MPP]

Schedules are deterministic from the rules - every time AM restarts or a schedule fires it can compute the next timer and start a single android alarm for the next expiry.  No persistence is required which saves pathlength and storage writes.

Restore & wait/delay timers are started by events so would need to be persisted every time and on restart AM would need to look for anything persisted from the last time AM ran.  It's not worth the extra path length so they use java timers in memory and they're dropped by a restart.  AM restarts should be rare so the difference is marginal, it's not so much reliability but a question for the user - do they have problems with their AM Server, power, or with the target devices?  Do they edit the rules frequently when critical devices are running?

On android there can be many reasons for delays in how fast AM reacts - system load, network load, network errors, etc.  For some tasks short pulses are needed, e.g. some fan or auto light controllers use 1/2s on/off pulses to change states, set speeds, etc.  When restarting a wifi network you can't use AM to turn the wifi power back on if there's no wifi.  Or a sump pump or similar that needs to turn off after a few minutes - it might be bad to start it, have wifi go down and it not stop on time.  Heaters controlled from AM, turned off when a measured temperature is reached may loose wifi so a limit on the max run time can be safer.  I use SetMomentary cases like that, esp for wifi restarts.