GCal3 trigger in PLEG won't stay true during event

Plugins & Plugin Development Google Calendar Switch
#1

Hi,

I’m new to vera and zwave in general, but been messing around quite a lot with 433MHz and logics around that. So this might just be me not knowing what I’m doing.

Anyway, my issue is that the GCal trigger in PLEG only stays true for about 15 seconds and not during the whole event. Only deviation from the install guide I’ve done is that I moved the delta for both start and end to -150 minutes.

See screen shot for details https://goo.gl/photos/3anMJnTZt5pSYUDn7

What might I have done wrong?

GCal3 v1.6
PLEG 7.46
Vera Edge v1.7.1707

Best regards,
\ Andreas

#2

You are close … 8)

The long answer …

GCal has three ways to inform of an event:

Event Matches Keyword - this is for use when you specify a keyword in the plugin (Advanced → Variables tab) using gc_Keyword. Basically the plugin only ‘sees’ events that match that keyword(s) (you can supply a list). The plugin is "on’ for the duration of the event and ignores any overlapping events. There are some other control variables as well but this is the main description.

Event Has Specified Name - this is used when gc_keyword is blank. Basically the plugin sees all events and you indicate in your scene or PLEG what that event name must be. The plugin is "on’ for the duration of the event and ignores any overlapping events.

Event Start or End - this occurs at the start and end of each event based on the above and only lasts 15 sec (so it’s working ;D ). It was added for people that want to do things like sending a message to Sonos. It’s only 15 sec long so that it can ‘see’ overlapping events. To use this form you need to get additional variables to determine if it’s the start or end (gc_notifyType), the event name and and event parameter.

For most uses - either the first or the second form is used. The third is a bit more complex and definitely involves the use of additional code.

For PLEG - I tend to use the second form but this is mostly a preference of style and not anything technical.

Since you can install multiple instances GCal (each has it’s own separate control) you can mix and match your approach.

So - the short answer is … use one of the first two forms and you will see the behavior you expect.

#3

Hi Stuart,

Thank you so much for your very informative answer. It’s clearly my mistake all along. However I still cannot get it to do what I want.

Basically, I want GCal to be true for use in PLEG during any event in the calendar. No keywords and any event name. I did go for the “event has a specified name” option.

Right now, I have a condition where PLEG stay false and only updates Last False some 15-25 seconds after event start, regardless of event end. Last true is the same time as in the first post 05:25:12.104 and does not update despite many new events (during tests) since.

What I’ve tested is:
gc_triggerNoKeyword true and false
PLEG has event name with and Specified

No matter what what combinations I try, I only get last false to update in PLEG. (the color of GCal varies between green and grey when active in different scenarios)

I tried to reboot my Vera, to no avail.

I’m clearly still not doing it right and I’m sorry for beeing such a noob. But how can I get it right?

BR,
\ Andreas

#4

From the manual ::slight_smile:

gc_triggerNoKeyword Either ?true? or ?false? (no quotes)
Default is false Configuration. Set this to true if you want the plugin to trigger the plugin if no keywords are
set. This means the plugin will trigger on every event. It will usually be better to set to false and use the ?An event has specified name? option.

So what you need to do is have gc_Keyword blank, gc_triggerNoKeyword set to true – the wording above is not completely obvious but these two values work together.

In PLEG you need to trigger on Event Matches Keyword (this part is not obvious but the effect of gc_triggerNoKeyword is that all events have a “keyword” … provided no keyword was set)

See also this post
http://forum.micasaverde.com/index.php/topic,35582.msg263079.html#msg263079

#5

Hi Stuart,

I’m very thankful for your patience and your elaborate answers. Thank you!

Now I was very hopeful. This was a combination I haven’t tried before. Now I got a green GCal3 icon instead of a grey one. If I understand correctly, it’s the difference between I’m triggered and there is something in the calendar. But of cause, this still does not cause the GCal3-trigger in PLEG to go true.

I’m probably missing something obvious here. I’ve read the manual several times, but still cannot get it right. Please see my screenshots of the variables and GCal + PLEG status. Now PLEG do not trigger at all.

#6

Hi again,

Found the luaUPnP log and this was present at calendar event start:

01 02/26/16 21:20:06.103 LuaInterface::CallFunction_Timer-5 function setTrippedOn failed [string “local GCAL_VERSION = “V 1.6” …”]:1293: attempt to concatenate field ‘name’ (a nil value) <0x75401520>

Can’t really interpret it, so thought it might be of interest to help troubleshoot my issue. If not, please discard.

Best regards,

#7

Well – that error was a code error that I had not noticed (I’d miss-typed a variable name). Thanks !!

Here is a patch file that will fix it.

I will take a closer look at your last post later today. It might be necessary for you to IM a log file to me – but best to apply this patch first.

#8

I have taken a closer look and the problem remains a mystery. I have confirmed that it is working on my test system (it’s beyond V1.6 but that code has not been changed in a long time).

Please set up a simple scene that will activate when the plugin is tripped and do something simple like send you a notification. That will test whether the tripped status is being broadcast by the underlying versa code.

I suspect that there may be an issue in PLEG (likely in your setup) since the display turning green tells me that internally the plugin is ‘tripped’.

Can you send me a log file extract that covers the period from 1 minute before an event starts until 1 minute after ?
Be sure to make sure gc_debug is set to 3.

You can send it as an attachment to a Personal Message in this forum. I do not expect to find anything in particular as I think the plugin is working but I’d like to validate that.

Double check PLEG … have you exceeded the maximum number of inputs etc for the trial version ?

#9

A PDF of the PLEG Status report would be useful as well.

We can see what trigger you are using as well as the time when the trigger becomes true and when it becomes false.

#10

@ Andreas –

I left this running with a test calendar over-night with the same version of PLEG as you have …it all works as expected. I even added in some calendar events without any name (the plugin forces them to “No Name”).

Now, as I said earlier, I’m working on a new version of GCal and did not revert back to the 1.6 version. It’s unlikely that V1.6 has a problem since you described the ui going green at the start of the event. The simplest way to double check is to create a s scene as I described earlier.

Attached is the PLEG test setup that I’m using, As Richard said – you should send the one you are using so we can compare.

#11

I took a look at your log file and your PLEG report. You have a lot going on !!!

GCal looks to be running normally (see below comments on log file extract with my comments). Have you done test with a simple scene triggered by GCal ?? This will help determine if there is some underlying vera issue.

There are two error situations in the log file (multiple write_data_header errors and one ZWaveJobHandler::slight_smile: . Neither seem to be directly related to GCal or PLEG. The write_data_header errors look to be associated with http.request or wget and may be creating a problem.

This is the end of the GCal sequence that detected the event at 14:46:00
50	02/28/16 14:46:00.725	luup_log:121: GCal3 V 1.6:nextTimeCheck is: 180 seconds from now <0x75d75520>
............
This is the trigger for the event -- it is delayed by 5 seconds as GCal has a built in delay so other state changes can propogate.
This tells us that the plugin IS TRIGGERED
06	02/28/16 14:46:05.103	Device_Variable::m_szValue_set device: 121 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: ArmedTripped was: 0 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xfe4a30/DL_ARMEDTRIPPED duplicate:0 <0x75d75520>

Then there is a series of errors likely from "DCS-935L" -- IS THIS FROM ONE OF YOUR http.request calls ?.
............
02	02/28/16 14:46:26.758	write_data_header failed with 0/401 [ some hex characters] (HTTP/1.1 401 Unauthorized\r\n) <0x738f2520>
02	02/28/16 14:46:26.759	write_data_header wrote:0 bytes:27 <0x738f2520>
............
02	02/28/16 14:46:27.207	write_data_header failed with 0/401 [ some hex characters] (WWW-Authenticate: Digest realm="DCS-935L",nonce="3e7a92619c55c855776bbf95184526a3"\r\n) <0x74334520>
.............

I do not know what this error means
02	02/28/16 14:46:29.100	ZWaveJobHandler::AlarmCallback skipping check because of jobs <0x77975520>
............

Then we have an internal GCal 'cycle' that seems out of place but performs correctly -- it could have been scheduled from a prior test
50	02/28/16 14:46:31.100	luup_log:121: GCal3 V 1.6:local function: GCalMain <0x75d75520>
.....
50	02/28/16 14:46:31.716	luup_log:121: GCal3 V 1.6:Event-Start NO NAME 02/28 14:46 is already Tripped <0x75d75520>

@ Andreas –
Why don’t you try backing up the PLEG configuration, eliminating everything, adding in GCal and testing. If that works, add in the next part …
I’m suggesting this because there are errors being reported that may be ‘blocking’ vera responding to other plugins.

@Richard – do you know if the line
02 02/28/16 14:46:29.100 ZWaveJobHandler::AlarmCallback skipping check because of jobs <0x77975520>
could indicate the cause ? Any other thoughts ?

#12

From what I seen the event became true at:
2016-02-25 05:15:12.104
And went false at:
2016-02-25 22:50:25.103

It was on for over 15 hours.

What did you expect ?

#13

@ Richard –

From looking at his logs I can see that the ‘current’ event is

50 02/28/16 14:46:00.719 luup_log:121: GCal3 V 1.6:Next Event: NO NAME – 14:46 Feb 28 to 15:16 Feb 28 <0x75d75520>
So we would expect to see a false to true transition at ~ 14:46:05. The logs entries below indicate a correct transition of the plugin from untripped (0) to tripped (1) at 14:46:05.105.

So for some reason that transition does not seem to be getting to PLEG. In my test system it all works fine. Given PLEG’s stellar track record (and something simple like this) – my suspicion lies with the possibility of the other errors getting in the way (is that even possible ?)

@ Andreas – any progress on the suggestions I made i.e. a simple scene (not in PLEG) and then maybe simplifying PLEG then building back up (you can take a backup of your current config and use that to cut / paste as you reconstruct).

06	02/28/16 14:46:05.103	Device_Variable::m_szValue_set device: 121 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: ArmedTripped was: 0 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xfe4a30/DL_ARMEDTRIPPED duplicate:0 <0x75d75520>
06	02/28/16 14:46:05.104	Device_Variable::m_szValue_set device: 121 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1456610580 now: 1456667165 #hooks: 0 upnp: 0 skip: 0 v:0xfca490/NONE duplicate:0 <0x75d75520>
06	02/28/16 14:46:05.105	Device_Variable::m_szValue_set device: 121 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 0 upnp: 0 skip: 1 v:0xfca358/NONE duplicate:0 <0x75d75520>
#14

We did not see the previous UNTRIP event.
It was true since around 5+ AM
Since it was true and he did not flag “REPEATS” there was nothing to do.

#15

Help me out here … it’s been a while since I used PLEG so I could easily be misinterpreting the status / mechanics …

It looks like the trigger tGCal3SarasArbetstrider was last true on Feb25 at 05:15 and later went to false on Feb25 at 22:50. So it was false when, on Feb28 (3 days later) at 14:46 GCal3 was tripped ?

So should PLEG have seen the TRIP event ?

#16

I missed the dates … but the logs I have do not show the 28th.
So I can’t see what happened.

#17

Emailed them to you - thanks.

#18

Hi,

I’m so sorry for not being able to update you until now. It’s been a few hectic days at work.

First, I haven’t deleted pleg and started over. I have not looked into how the backup/restore work. And since I can’t get a file to save or upload to restore I’m feeling just a bit unconfident about it. But…

I have played around with a lot combinations of gc_keyword, gc_triggerNoKeyword, Event matches keyword, has a specific event and start or end. Most of the combinations trigger PLEGs Last False 4 times. First time is 10 seconds into the event, second time is 25 seconds into the event, third time 5 seconds after event ends and fourth and last time 20 seconds after event ends. Last True does not update at all. A week later, It’s still at Feb 25.

I’ve attached a screenshot of the PLEG status page just after a 3 minute test event.

I’m not sure if the above explanation can shed some light on the issue?

So for my application, starting a block heater in my partners car based on when she starts working that particular day and the outside temperature, I basically only need the start of the event to trigger my logics. And I found 2 ways to workaround the issue.

Workaround 1:
Used a repeating condition (as I only see the false part of the event) to trigger on !tGCal3SarasArbetstider with an action to start 3 timers. Then use the timers as triggers in my conditions to start the block heater based on temperature outside. To prevent the block heater to start when the event ends, I just added a schedule in the start block heater conditions. (I know I’ve seen smarter ways to calculate the start time based on outside temp, but I’m still learning how to use all the logics that can be used in the conditions. I’m still within my first month with the Vera, so I’m a noob :slight_smile: )

Workaround 2:
Created a Virtual Switch. Then used two Vera scenes to set the VS on or off at event start and end. Then the VS can be used in PLEG as the GCal plugin was intended to do (but not on my system, for some reason).

off topic
If someone are in my shoes and want a jump start, here’s my logics for the start conditions below. But please, do not comment on them in the thread.

cTempUteNorr_LTMinus15
!tGCal3SarasArbetstider and s0330_0800_m_f and pTemp_UteNorr <= -15

cTempUteNorr_Minus149_Minus5
!sTimer30min and s0330_0800_m_f and (pTemp_UteNorr >= -14.9) and (pTemp_UteNorr <= -5)

cTempUteNorr_Minus49_Plus5
!sTimer60min and s0330_0800_m_f and (pTemp_UteNorr >= -4.9) and (pTemp_UteNorr <= 5)

Best regards,
\ Andreas

#19

Something is wrong on your vera. These multiple triggers that you describe do not normally happen and there was no evidence of that sort of behavior in the log files you sent. There is no reason why you need to resort to virtual switches and combination logic. I’m afraid that you are just covering over a bigger problem and it will cause you more issues as you progress.

It’s up to you of course but why not try the simple scene I suggested ? gc_keyword = “”, gc_triggerNoKeyword = true, gc_debug = 3. Set up a scene to trigger on Event matches keyword and do nothing except send a notification email, create a calendar entry and reboot the vera, wait for the event to start… (Do not do anything else after the reboot except wait). I’m happy to take a look at the log file.

#20

Thank you for your patience!

I don’t know how many times I’ve tried this combination before, but maybe because of the Vera reboot, it worked as expected this time! :smiley:

I created a 3 minute test event.
I setup 2 vera scenes to trigger a Virtual Switch on and off. That’s GCal3 VS wo.
I setup 2 trigger in PLEG. One directly using GCal3 and the other using my Virtual Switch.
The old PLEG trigger tGCal3SarasArbetstider are left for reference.

Both the vera scenes with the Virtual Switch and the PLEG trigger works. Previously, only the vera scenes and the VS worked. But maybe the reboot did something to the PLEG trigger, I don’t know.

Since this now works the conclusion could be to try and reboot the Vera if this issue arises (or not do any stupid misstake I probably did without noticing :slight_smile: ).

Thank you Stuart for your excellent plugin!

\ Andreas