Keeping flags state in AM server

[sergey]

Hi again!

I've got a problem  -if i change rules or the AM server reboots by different reasons all flags are turns to be cleared.   Due to quite "big diversity" of my AM system today - i wonder if there is a way to keep flags in original state or at least inform me about system reboot? 

[DougC]

Hi Serg. If you look at the flag device you will find it has an option 'persist' Check that box and the state of the flag will be restored after restarts.

[MikeP 4 MPP]

Right.  There's also an "OnStart" trigger to execute actions like sending you a notification of a restart.

[sergey]

Oh! Thanks Doug , i didn't know that. Unfortunately i can't check it because my server is in 200km away of me.... in next visit only.

[sergey]

Ok! Thanks Mike , it's useful!

[sergey]

Hmmm. It doesn't work for always. For instance if i change a rule it automatically restarts server and server send me proper  message. But there are some processes that somehow restarts the server and the server doesn't send me anything. I suspect the task killer or similar... I've using Samsung Alfa. I wonder if the  'persist'   flag option, that Doug has metioned for  is restoring after such processes..?

[MikeP 4 MPP]

OnStart is always called when the server (rule engine) is restarted, and right, the flags will only be restored when the engine restarts.  Flag states are persisted immediately whenever they change so it's not a caching problem.

So either the server isn't being restarted, or it's not really being stopped.  If the server device is sleeping, or it's wifi is off/sleeping AM can't send anything (there's a phone management device in AM you can use to force wifi on).  I think it depends on your email client whether it's retried - maybe it has a "draft" or "sent" folder?  AM won't retry.  There's of course no way to send a message when the task is killed so I can't help much there.  You could use AM Remote to see if AM is still responding - use an http connection to avoid confusion in case it's AoD that's been killed.  Another trick I use for debugging is to use one device state change to trigger a rule to change some other indicator (I usually use a "toggle" action on another bulb or switch) to confirm whether the engine is running.  

If AM has been stopped but not restarted when you open AM on your server device this should cause the email to be sent if AM really was killed and not restarted.

Forcing the Device Screen on in AM is pretty effective at keeping servers awake/active, though I do have trouble on some devices with crappy screen sleep functions (my S5 flickers like crazy when it's trying to turn the screen off when it shouldn't).

[sergey]

No, what i know exactly - the server wasn't stopped  and i checked there where no any issues with wifi shutting down or others accidents and i can connect to it using AM Remote. I check periodically the server and see that it resets flags from time to time (it's not so often -it might take days intact).It is quite disappointing because some flags are responsible for security system control.  Ok, tomorrow i'm going to visit my country home and check all versions. Thanks a lot! 

[MikeP 4 MPP]

Certainly possible it's a bug, but it sounds at least from this it's something else.

State is written to storage immediately when changed, and loaded from fresh on a restart - it's hard to image it's lost, more likely that a bug is causing it to change before being written or loaded.

But if AM Remote is working then AM is still running - if it stops the http server would not respond.  That would explain why OnStart isn't firing.

Try this - create a rule to trigger when the flag is in the wrong state, and use the "sendLog" action  to capture what's going on - we can see if something unexpected is changing the flag.  It'll be a bit trickier if it's on restart, but we can see why OnStart isn't firing too.