Google Calendar Switch

[Stuart]

I have just installed the plugin (v1.7) and am also seeing http error code 400 has the fix been submitted to the app store for this?

The fix has not been submitted to the apps store - so please use  the version of I_GCal_II.xml about two posts above.  I am doing some general tidy up and will post a version 1.8 soon.

[Stuart]

Updated Version

Attached is the latest version which incorporates a couple of upgrades.  I will release this to the marketplace in a few days - but wanted to make sure there were no residual bugs (hence this beta).  I've tested it pretty heavily and also recently started to use ZeroBrane for Vera for development and testing.  ZB for Vera is highly recommended for anyone doing plugin work (or even just luup scenes) as it allows you to  interactively test on the vera device - and sometimes what works on one Lua interpreter does not work as you would hope in the vera environment :-(.  ZB for Vera really helps when that happens

This will probably be the last functional upgrade for a while.  Google will be deprecating the api version that is used to access the calendar and it will not be available come November.   So I have to come to grips with the new authentication scheme on google's V3 api.  This is non-trivial stuff .....

The enhancement to this version are basically two:
(1) gc-debug is no longer true / false but a number defaults to 1
0 = no debug messages
1 = minimal debug, basically checking calendar, device tripped, next check time
2= more detailed operating information
3 = unusual error conditions, probably only used when troubleshooting

(2) a new variable gc_retrip default to true and it's companion variable gc_TrippedID (just used for internal purposes)
This is used for back to back events with the same name e.g. repeating all day events i.e. any events with the same name where the end time of the previous event is the same as the start time of the next (same name) event.
if gc_retrip is true, then the plugin will treat the events as separate i.e. finish the first and trigger on the second.  In this way you can have the same trigger repeated using the calendar.  For example, if they were all day events - there would be a trigger each day at midnight.
if gc_retrip is false then the plugin will treat such events as one continuous event i.e. triggering on the start of the first one and finishing at the end of the last one.  For example, three all day events in a row with the same name would trigger at the start of day one and finish at the end of day three.

Hope someone finds this useful :-)

This version will show in the logs a V1.8.4

[duiffie]

Updated Version

Attached is the latest version which incorporates a couple of upgrades.  I will release this to the marketplace in a few days - but wanted to make sure there were no residual bugs (hence this beta).  I've tested it pretty heavily and also recently started to use ZeroBrane for Vera for development and testing.  ZB for Vera is highly recommended for anyone doing plugin work (or even just luup scenes) as it allows you to  interactively test on the vera device - and sometimes what works on one Lua interpreter does not work as you would hope in the vera environment :-(.  ZB for Vera really helps when that happens

This will probably be the last functional upgrade for a while.  Google will be deprecating the api version that is used to access the calendar and it will not be available come November.   So I have to come to grips with the new authentication scheme on google's V3 api.  This is non-trivial stuff .....

The enhancement to this version are basically two:
(1) gc-debug is no longer true / false but a number defaults to 1
0 = no debug messages
1 = minimal debug, basically checking calendar, device tripped, next check time
2= more detailed operating information
3 = unusual error conditions, probably only used when troubleshooting

(2) a new variable gc_retrip default to true and it's companion variable gc_TrippedID (just used for internal purposes)
This is used for back to back events with the same name e.g. repeating all day events i.e. any events with the same name where the end time of the previous event is the same as the start time of the next (same name) event.
if gc_retrip is true, then the plugin will treat the events as separate i.e. finish the first and trigger on the second.  In this way you can have the same trigger repeated using the calendar.  For example, if they were all day events - there would be a trigger each day at midnight.
if gc_retrip is false then the plugin will treat such events as one continuous event i.e. triggering on the start of the first one and finishing at the end of the last one.  For example, three all day events in a row with the same name would trigger at the start of day one and finish at the end of day three.

Hope someone finds this useful :-)

This version will show in the logs a V1.8.4

This version again hangs on 'Checking for json.lua'. Does this version contain the previous fix for that?

[Stuart]

@Duiffie
Could you please change gc_debug to 3
And send me the log? greg on gc_
It does have the changes and worked fine on my machine with multiple tests.  The additional debug should tell us pretty quickly what's happening.

[duiffie]

@Duiffie
Could you please change gc_debug to 3
And send me the log? greg on gc_
It does have the changes and worked fine on my machine with multiple tests.  The additional debug should tell us pretty quickly what's happening.

That did the trick... gc-debug was still set to false, it did not change to 1 after uploading the new xml. After changing it manually to 3 on your request (per device), all started to work. The error I got while the value was set to false was:

Code: [Select]

LuaInterface::CallFunction_Timer-5 function GCalMain failed [string "..."]:543: attempt to compare nil with number

[lammy]

can someone tell me how to upload the file to my vera lite?
sorry but im a newbie at this.

[Stuart]

can someone tell me how to upload the file to my vera lite?
sorry but im a newbie at this.

Apps--> Develop Apps --> Luup Files --> Browse
Select the file you want to upload (in this case I_GCAL_II.xml)
Check the box "Restart Luup after upload"
Press "Go"

I'll be posting the latest version (1.9.0) to the marketplace tomorrow if you want to do it that way.  Essentially the same as the post above but made the default setting more robust (i.e. overwrite incompatible defaults from prior plugin versions)

In the meantime - here it is V1.9.0

[CudaNet]

I seem to be having some problems getting a consistent trigger event (Plugin V1.9 from Apps/Install Apps). My use case is simple, I'm basically entering a calendar event in Calendar, Event = Key{ParmA; ParmB}.
In Vera, I have the following configured for the trigger :

[1] Type of event: A Calendar Event is Active.
[2] Status?: Device is Active
[3] [For testing purposes only] Send me a notification when the event occurs.

On the plug-in, the GCal is in an armed state (green). Now I'm watching the plug-in and it knows the event is going to occur (timestamp and event appear perfectly). As soon as the time is reached, I see the device icon change states (red), I receive an email notification but my LUUP code doesn't execute. On a trigger, I have LUUP evaluating the following containers:

gc_TrippedEvent
gc_Value

When I peek at Advanced, both of these fields appear to be empty until I restart LUUP,  then voila, my LUUP code executes and I now see values within those fields and they remain (I assume until the next event).  Any thoughts or am I just using this wrong ?

[Stuart]

I seem to be having some problems getting a consistent trigger event (Plugin V1.9 from Apps/Install Apps). My use case is simple, I'm basically entering a calendar event in Calendar, Event = Key{ParmA; ParmB}.
In Vera, I have the following configured for the trigger :

[1] Type of event: A Calendar Event is Active.
[2] Status?: Device is Active
[3] [For testing purposes only] Send me a notification when the event occurs.

On the plug-in, the GCal is in an armed state (green). Now I'm watching the plug-in and it knows the event is going to occur (timestamp and event appear perfectly). As soon as the time is reached, I see the device icon change states (red), I receive an email notification but my LUUP code doesn't execute. On a trigger, I have LUUP evaluating the following containers:

gc_TrippedEvent
gc_Value

When I peek at Advanced, both of these fields appear to be empty until I restart LUUP,  then voila, my LUUP code executes and I now see values within those fields and they remain (I assume until the next event).  Any thoughts or am I just using this wrong ?

I  don't think it's the plugin from what you describe ...

Some ideas to try: (also gc_debug = 3 will give us just about everything that is going on in the plugin - if you grep the log file for gc_)

(1) I have had issues with event notification that the MCV folks have not had time to look into (seems they are all working on UI7).  What happens if you remove the notification ?  Where have you set the notification ? - on the plugin, on your scene, in your LUUP code ?
(2)  Rather than restart LUUP - try refreshing the browser (F5) then looking at the advanced tab - that should show what the actual values are. - but I don't expect it to change any behavior
(3) In the code gc_Vale is set one line before the device Trigger is set and gc_ TrippedEvent, one line after (no reason) - but it's hard to imagine a race condition existing by the time it gets to your scene

The log file will tell  if the plugin is a suspect ....

[CudaNet]

Thanks Stuart,

[1] The notification is just the standard email notification that you check mark on the Scenes>'Name'>Triggers>Edit>Optional.
I only use the notification as a sanity check to verify that at least the scene>trigger is firing.

[2] Will try to refresh rather than restart LUUP and report back.
[3] Agreed but anything is possible.

Don't have the ability to eval the logs from where I'm at.. Can do later tonight if this (or me) can't be remedied.

I seem to be having some problems getting a consistent trigger event (Plugin V1.9 from Apps/Install Apps). My use case is simple, I'm basically entering a calendar event in Calendar, Event = Key{ParmA; ParmB}.
In Vera, I have the following configured for the trigger :

[1] Type of event: A Calendar Event is Active.
[2] Status?: Device is Active
[3] [For testing purposes only] Send me a notification when the event occurs.

On the plug-in, the GCal is in an armed state (green). Now I'm watching the plug-in and it knows the event is going to occur (timestamp and event appear perfectly). As soon as the time is reached, I see the device icon change states (red), I receive an email notification but my LUUP code doesn't execute. On a trigger, I have LUUP evaluating the following containers:

gc_TrippedEvent
gc_Value

When I peek at Advanced, both of these fields appear to be empty until I restart LUUP,  then voila, my LUUP code executes and I now see values within those fields and they remain (I assume until the next event).  Any thoughts or am I just using this wrong ?

I  don't think it's the plugin from what you describe ...

Some ideas to try: (also gc_debug = 3 will give us just about everything that is going on in the plugin - if you grep the log file for gc_)

(1) I have had issues with event notification that the MCV folks have not had time to look into (seems they are all working on UI7).  What happens if you remove the notification ?  Where have you set the notification ? - on the plugin, on your scene, in your LUUP code ?
(2)  Rather than restart LUUP - try refreshing the browser (F5) then looking at the advanced tab - that should show what the actual values are. - but I don't expect it to change any behavior
(3) In the code gc_Vale is set one line before the device Trigger is set and gc_ TrippedEvent, one line after (no reason) - but it's hard to imagine a race condition existing by the time it gets to your scene

The log file will tell  if the plugin is a suspect ....

[Stuart]

Don't have the ability to eval the logs from where I'm at.. Can do later tonight if this (or me) can't be remedied.

Take a look at the info viewer plugin - terrific!.  I actually use it more than directly connecting to the OS .....   It allows remote log viewing and log filtering (among other things).  You can get it here:

http://forum.micasaverde.com/index.php/topic,13477.0.html

[CudaNet]

Very nice ! I'll install that and see what's occuring. Did the refresh and sure enough, the data is there so perhaps there is a timing issue (one which is alleviated with a restart).... I figured if this was an issue that others surely would have reported it. Hmm... Think I'll reboot this thing (ya' never know) and start installing the log tool...

Don't have the ability to eval the logs from where I'm at.. Can do later tonight if this (or me) can't be remedied.

Take a look at the info viewer plugin - terrific!.  I actually use it more than directly connecting to the OS .....   It allows remote log viewing and log filtering (among other things).  You can get it here:

http://forum.micasaverde.com/index.php/topic,13477.0.html

[Stuart]

Very nice ! I'll install that and see what's occuring. Did the refresh and sure enough, the data is there so perhaps there is a timing issue (one which is alleviated with a restart).... I figured if this was an issue that others surely would have reported it. Hmm... Think I'll reboot this thing (ya' never know) and start installing the log tool...

Don't have the ability to eval the logs from where I'm at.. Can do later tonight if this (or me) can't be remedied.

Take a look at the info viewer plugin - terrific!.  I actually use it more than directly connecting to the OS .....   It allows remote log viewing and log filtering (among other things).  You can get it here:

http://forum.micasaverde.com/index.php/topic,13477.0.html

You are also welcome to try this.  It separates I_GCall_II.xml into two files (avoids me having to make some XLM changes when testing on PC vs Vera) but is otherwise identical to the version you have.   I just shifted the assignment for the plugin Tripped / Not Tripped to after the other variables - you never know ......  I'd be very surprised .....

Just download both files and reload.

Would be nice to get a log from the current version first though - just in case there is a difference in behavior .......

[lammy]

just wondering which side of the event a automation profile will trigger from

for example, i put into my google calendar when i work night shifts from 10pm until 7am, so that my lamp in my room will come on when i arrive home from work, air purifier turns on just as i leave work, ect.

will i need to set delays from the time that the calendar event starts (10pm meaning 9 hours before my automation profile does anything) or ends (7am meaning no delay before the first item triggers)

cheers

[CudaNet]

Sorry, work issue came up so I deviated... I'll get logs before loading these files (just downloaded the new Info Viewer plugin) and thanks for the quick responses.

Very nice ! I'll install that and see what's occuring. Did the refresh and sure enough, the data is there so perhaps there is a timing issue (one which is alleviated with a restart).... I figured if this was an issue that others surely would have reported it. Hmm... Think I'll reboot this thing (ya' never know) and start installing the log tool...

Don't have the ability to eval the logs from where I'm at.. Can do later tonight if this (or me) can't be remedied.

Take a look at the info viewer plugin - terrific!.  I actually use it more than directly connecting to the OS .....   It allows remote log viewing and log filtering (among other things).  You can get it here:

http://forum.micasaverde.com/index.php/topic,13477.0.html

You are also welcome to try this.  It separates I_GCall_II.xml into two files (avoids me having to make some XLM changes when testing on PC vs Vera) but is otherwise identical to the version you have.   I just shifted the assignment for the plugin Tripped / Not Tripped to after the other variables - you never know ......  I'd be very surprised .....

Just download both files and reload.

Would be nice to get a log from the current version first though - just in case there is a difference in behavior .......