Time Stamp for trigger changes everytime Vera restarts

I am running UI5 and V1.4 of the plugin and notice that the time stamp associated with the detection of a keyword in Google calendar changes every time that Vera restarts even though the event in the calendar has not changed during the interval. This behavior seems at odds with the behavior for other triggers that seem to maintain the same time stamp as long as the trigger value is unchanged on restart.

Since I live in an area that tends to experience power outages from time to time, this makes it difficult to use the time stamp in any calculations in PLEG with predictable results.

I have noticed that the time stamp associated with the “false” transition is maintained unless the plugin is updated in which case they are both changed.

Was this behavior intended?

By “time stamp” I assume you mean the time that PLEG last noticed a transition of a variable that it is using as a trigger ?

There are several possibilities, especially since you are talking about a restart situation.

Try setting gc_retrip to false. This will prevent the plugin from ‘tripping’ on the same event during a vera restart or reboot.

Let me know if that solves the problem. If not we can dig deeper.

Thanks for your quick response.

The time stamp is the time value that is displayed as part of the status report from the PLEG so I think the answer to your question is yes.

I also updated the plugin from 1.0 to V1.4 before I sent the note this morning and then noticed that now the trigger that the PLEG sees actually changes state everytime that Vera is restarted (in addition to the time stamp values changing - i.e, the trigger goes off and then goes back on again within a couple of seconds at most even though the calendar event spans the entire interval. This caused enough problems that I had to go back to an earlier version (1.0) that only exhibited the time stamp change.

I will try your suggestion when I have the patience to fight with it again. Without understanding any more about the details, I would wonder why the default behavior of the plugin seems at odds with the rest of Vera.

I cannot help you with V1.0. V1.5 will be out in a day or so.

The default behavior dates back to the original plugin (by another author). I preserved that behavior for the (then) existing users. gc_retrip was added so you can chose which behavior you want.

I reloaded V1.4 and set gc_retrip to false as you suggested. Doing this appears to have stopped the app from toggling the trigger value from TRUE to FALSE and then back to TRUE but it had no affect on the time stamp issue - i.e the time stamp is continuing to get reset to the time when Vera restarts. As such, it now appears that V1.4 with “gc_retrip = false” behaves in the same manner as V1.0 (with gc_retrip = true).

I will wait for the release of V1.5 and repeat the test at that time.

Can you send me a copy of your log file (with gc_debug = 3 and gc_retrip = false) and the timestamps for PLEG, during a restart. That will help me see if I have a logic problem (aka bug).

Also - what GCAL condition and / or variable are you using in PLEG, that can have a bearing too.

It’s been a while since I did any concerted testing with PLEG.

I ran the InfoViewer plugin and captured the Vera Log for a reload. I did this twice at different times so that you can see the behavior. The log files are rather large but I couldn’t see a way to reduce the data and be sure that you still got what you are looking for. I have also included a “pdf” file that captures the status information for the variable that is being time stamped incorrectly. I copied this from the status page of the PLEG plug-in - the only difference being that Excel swapped the order of the month-day-year - but the data is the same.

The GCAL3 plugin is set to detect a keyword called “AWAKE”. The PLEG plug-in has this configured as a trigger with the local name of “calAwake”. For the day in question, the calendar entry triggered at 7:00:00am and is due to turn off the next day at 2:00:00am. In the “pdf” file, you should notice that the time stamps for the “Last True” are different from the 1st to the 2nd run while the "Last False " time stamps are identical. The time stamps that you see for the “Last True” entry are the times when I reloaded Vera. If this plug-in was behaving in a manner similar to other plug-ins/devices, the “Last True” time stamp should read "1/4/2016 7:00:00 regardless of how many times Vera is restarted because that was the last time that the value transitioned to TRUE and on restart the Keyword is still the same and the calendar entry is still active so the state is still TRUE.

I don’t understand how Vera persists data through a restart but there is a mechanism that is doing this because I can see from the log files that other plug-ins know what the previous state was when the are initializing and I assume this is how they avoid changing the time stamp on a restart. If the plug-in does not make an explicit effort to compare the current state with the previous state but just updates the value - regardless of what it is, that would probably explain what is happening.

Thanks! - I will take a look at the log files.

I suspect this is the problem though:
GCAL started off live as a simple switch, either on or off. Tripped or Not Tripped based on the value of the keyword set in the plugin- a ‘Tripped Event’ accessible in a scene through “Event Matches Keyword”. That behavior remains and is the same as most plugins.

Along the way, the ability to leave the keyword blank and interrogate the event name (in a scene or code) was added but it did not make sense to ‘Trip’ the plugin on every event in the calendar. So GCAL has the notion of an ‘Active Event’ meaning that it is inside a calendar event and you specify if you want to do something based on providing the event name externally to the plugin (“Event has specified name”).

There is logic to prevent a ‘re-Trip’ on reboot. I’ll look to see if the same logic was applied to ‘re-Activate’. If it was not then it’s either an oversight or there is some ‘gotcha’ that I need to (re) think through.

In the meantime - note that there is a variable gc_triggerNoKeyword: Either ?true? or ?false? (no quotes) Default is false. You could set this to true. The plugin will then Trip on each event but not retrip (gc_retrip = false) on a reboot. Your PLEG logic would then be to react to the Trip status but filter on the desired event name i.e. logically ‘tripped and eventname = zyx’

I don’t think I understand your last paragraph or else I do not correctly understand your terminology:

In the meantime - note that there is a variable gc_triggerNoKeyword: Either ?true? or ?false? (no quotes) Default is false. You could set this to true. The plugin will then Trip on each event but not retrip (gc_retrip = false) on a reboot. Your PLEG logic would then be to react to the Trip status but filter on the desired event name i.e. logically ‘tripped and eventname = zyx’

I use the word “tripped” to mean that the value that the PLEG sees changes. So, for GCAL3, that means that a keyword has been recognized in Google calendar and the current time is within the specified calendar event (TRUE or tripped) or it just went outside the specified interval and is now FALSE or no longer tripped.

Are you using the word “tripped” to mean that the time stamp is changed even though the value remains the same? If so, then I still don’t understand how your suggestion resolves anything. I only have one event in the calendar so tripping on every event will not result in any more “trips” and the time stamp will still change when Vera restarts.

I initially had problems with V1.4 “tripping” every time that Vera was restarted - i.e. the value changed from ON (the previous state before the restart) to OFF and then back to ON all while the calendar event spanned the whole time. but after I followed your suggestion and set gc_retrip = false, that stopped the value from changing when Vera was restarted. The problem is that the time stamp is still being changed every time that Vera is restarted - even though the value is no longer changing. This is creating a problem because I am using the time stamp in calculations in PLEG and when it changes (and there was no trigger), it completely messes up the logic.

I realize that i can only look for gross patterns in the log rather than understanding everything that is there but I am using the iPhone locator app and I noticed that when Vera restarted, there were log entries that had keywords in them like “was” and “now” just like for GCAL3. However, in the iPhone locator entries, there were values next to the keyword “was” and for the GCAL3 entries, that keyword was blank.

I’m using the word Tripped in the Vera / UPnP sense to mean that is the state of the overall device (or plugin in this instance). For something simple like a light switch: Tripped = On and Not Tripped = Off. Think of this is a UPnP system variable.

It has nothing to do with timestamps as such. The timestamp is something that PLEG creates and tracks to do it’s magic. Basically it’s the last time PLEG saw that particular variable (system or customized plugin) change - the timestamp is not a value supplied by the plugin.

IF you set a keyword (gc_keyword = something) - then GCAL behaves like a light switch and turns on (Tripped) and Off (Not Tripped) the UPnP system variable.

If you do not set a keyword (i.e. gc_keyword is blank) then GCAL does not ‘turn on / off’ in the UPnP ’ variable (unless gc_triggerNoKeyword is set true) . Instead it toggles a custom state (to indicate that an even has occurred) and your code has to decide if the event name is of interest.

There are two separate and distinct behaviors in the plugin. What you are calling ‘tripped’ is a third :slight_smile: meaning a change in timestamp in PLEG on a single variable. What I’m suggesting as a workaround is that you can combine two GCAL conditions - Tripped (in the UPNP sense) and gc_EventName = your_desired_event and setting gc_triggerNoKeyword to true.

In PLEG this could be something like (from memory):

  1. create a trigger ‘t1’ for “Event matches Keyword” Device:Tripped (since we have gc_triggerNoKeyword to true)
  2. create a trigger ‘P1’ for gc_nextEvent

Then create a condition that is C1 → t1 AND p1== “YOUR_EVENT_NAME”. Notice all caps in the event name

The condition would be true when t1 first becomes true and would not be true on a restart as t1 would not have changed (gc_retrip is false).

I may be able to make this simpler with a change to the plugin but cannot look at it for a few days.

P.S. It mat even work without the p1 and having t2 be “Event has specified name” Trigger when event has name: “YOUR_EVENT_NAME”
and set C1 → t1 AND t2. I cannot be sure about this as some Vera execution semantics may get in the way - but worth a try.

OK - looks like this was an ‘oops’ on my part. A one-line fix (literally). I did not refreshing an internal variable on a reload. Probably overlooked when I did some related ‘clean up’ a while back.

Here’s what I’d like you to do … On V1.4, upload the two files here

http://forum.micasaverde.com/index.php/topic,26692.msg261969.html#msg261969

This will take you to V1.5. Then upload the attached file (V1.6a). Should fix the problem (although I have not tested). You will still need gc_retrip set to false. Given that you are using the UPnP ‘tripped’ status, you can ignore the discussion on gc_triggerNoKeyword.

As an aside - the log files are incomplete, some lines are missing (not sure why but …). They did contain the info needed to spot this problem though. Thanks!

EDIT: Moved attachment here -
http://forum.micasaverde.com/index.php/topic,26692.msg263178.html#msg263178

I followed your instructions and installed the new files. You have corrected the problem. The variable in PLEG now maintains the correct time stamp through a Vera restart.

I noticed that you labeled the “lua” file as V1.6. I assume therefore that this fix will be released sometime in the future. In the meantime, I should be able to use the files that you indicated so that the app will work correctly.

I assume that this is not your day job so I sure appreciate the timely response and the effort that you put into getting this corrected.

thanks very much.

No - not my day job at all :P. Just ended up with a couple of hours last night.

Yes - continue to use the files. If there are no new enhancements or fixes in the next month, I will push this out as a formal release.

EDIT: I’ll move the 1.6a (alpha) file over to the main thread so others can see that it’s out there (I try to tidy as I go). Since Vera have not published V1.5 to the marketplace, I pushed this patch into it and released as V1.6.

Thanks for your sleuthing. Enjoy.

OK. I have successfully installed your latest version V2.2 and now this behavior is back. i.e., everytime I reload Vera, the time stamp for the current event changes. Did your previous 1 line fix somehow get left out of the current version?

I’m traveling so will check this on Friday.

I had included the change. I suspect you may not have fully followed the instructions here for the move to 2.0+.

http://forum.micasaverde.com/index.php/topic,26692.msg276087.html#msg276087

Especially - deleting prior versions before the upgrade. That could have caused the issue as certain variables were restructured and relied on the prior version being completely removed.

Try uploading these 2 files - it should resolve the problem (I am forcing an update). If this does not work then I will need a log file from you with gc_debug set to 3.

Edit: Files removed