We have moved at community.getvera.com

Author Topic: Google Calendar Switch  (Read 140527 times)

Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #450 on: June 27, 2014, 01:36:45 am »

I'm on 1.5.622.

Results  in the log after setting gc_debug to true and while grepping on GCal:


Sorry - but can you grep for GCal_II   that will then catch the various debug messages.  I have an idea as to what might cause the issue, but it's strange that it does not happen on my and other vera's .....  looks like a number not being interpreted when used as a string parameter in a function call -- I may have to convert it.  But strange nonetheless ....

Can you try the updated file above (bottom of prior page) ?  I suspect the error you were getting was timezone related too .....  Are you in a timezone with a 1/2 hr offset ?
« Last Edit: June 27, 2014, 01:39:42 am by Stuart »

Offline duiffie

  • Full Member
  • ***
  • Posts: 126
  • Karma: +2/-0
Re: Google Calendar Switch
« Reply #451 on: June 27, 2014, 09:40:11 am »
Sorry - but can you grep for GCal_II   that will then catch the various debug messages.  I have an idea as to what might cause the issue, but it's strange that it does not happen on my and other vera's .....  looks like a number not being interpreted when used as a string parameter in a function call -- I may have to convert it.  But strange nonetheless ....

Can you try the updated file above (bottom of prior page) ?  I suspect the error you were getting was timezone related too .....  Are you in a timezone with a 1/2 hr offset ?
[/quote]

While grepping on GCal_II and having debug set to true, the only lines catched are (I have 2 GCal_II devices):

Code: [Select]
50 06/27/14 15:33:09.022 luup_log:68: GCal_II: Timezone is 2 hrs and 0.35 min <0x8021>
50 06/27/14 15:33:09.033 luup_log:67: GCal_II: Timezone is 2 hrs and 0.35 min <0x7c20>

I'm located in the Netherlands/Amsterdam (UTC+1 plus currently DST+1, so the current offset is UTC+2). Uploading the latest I_GCal_II.xml didn't help either,  same result as before.
Vera2 (1.5.622)

Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #452 on: June 27, 2014, 09:56:50 am »

I'm located in the Netherlands/Amsterdam (UTC+1 plus currently DST+1, so the current offset is UTC+2). Uploading the latest I_GCal_II.xml didn't help either,  same result as before.

So the timezone is showing up incorrectly -- that's a clue -- I will try to reproduce based on Amsterdam. Probably later today though.

Out of curiosity -- why two plugins ?   I'd like to understand your use case.


Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #453 on: June 28, 2014, 12:37:32 am »

I'm located in the Netherlands/Amsterdam (UTC+1 plus currently DST+1, so the current offset is UTC+2). Uploading the latest I_GCal_II.xml didn't help either,  same result as before.

So the timezone is showing up incorrectly -- that's a clue -- I will try to reproduce based on Amsterdam. Probably later today though.

Out of curiosity -- why two plugins ?   I'd like to understand your use case.

I tested with my vera and the calendar set to Amsterdam timezone.  Everything worked and the timezone showed correctly as 2hr 0 min.  So it's strange that there is a difference on your vera (especially as the difference shows as 0.35 min).   My original intention was to look for why the plugin would not start on your vera  - but I could not definitively find a problem (as it works on mine) .   I did find one suspicious error but ......  without being able to cause a failure, I cannot be sure.

Along the way I noticed a couple of possible edge conditions and fixed those - although none would have caused the error you reported.  I also tested with timezones for Amsterdam, Adelaide Australia and Mountain Time USA.  I added a few more debug messages that may help narrow the location of the issue.

Can you try with the attached version and just one plugin and grep for gc_ (will get us more log info) - I'd like to try and eliminate any possible interactions because of the two instances.

Thanks for your patience.

EDIT: I removed the attachments to several recent post so folks don't accidentally use them.
« Last Edit: June 30, 2014, 02:06:19 pm by Stuart »

Offline conchordian

  • Sr. Member
  • ****
  • Posts: 326
  • Karma: +4/-1
Re: Google Calendar Switch
« Reply #454 on: June 28, 2014, 01:34:21 am »
Can you try with the attached version and just one plugin and grep for gc_ (will get us more log info) - I'd like to try and eliminate any possible interactions because of the two instances.

Thanks for your patience.

That seems to fix it for me, thanks, and yes I am in a positive timezone: +10

Offline bubaleta

  • Full Member
  • ***
  • Posts: 111
  • Karma: +1/-0
Re: Google Calendar Switch
« Reply #455 on: June 28, 2014, 12:31:48 pm »
This file also fixed my http 400 error.
I live in Madrid, Spain.

Thanks a lot

Offline duiffie

  • Full Member
  • ***
  • Posts: 126
  • Karma: +2/-0
Re: Google Calendar Switch
« Reply #456 on: June 29, 2014, 03:54:18 pm »

I'm located in the Netherlands/Amsterdam (UTC+1 plus currently DST+1, so the current offset is UTC+2). Uploading the latest I_GCal_II.xml didn't help either,  same result as before.

So the timezone is showing up incorrectly -- that's a clue -- I will try to reproduce based on Amsterdam. Probably later today though.

Out of curiosity -- why two plugins ?   I'd like to understand your use case.

Two plugins because:

- I have a schedule for my housekeeper once every two weeks which disarms my alarm
- I have a wakeup light (dimmer) installed which runs every workday.

so these have to be seperate devices...
Vera2 (1.5.622)

Offline duiffie

  • Full Member
  • ***
  • Posts: 126
  • Karma: +2/-0
Re: Google Calendar Switch
« Reply #457 on: June 29, 2014, 03:59:10 pm »

I'm located in the Netherlands/Amsterdam (UTC+1 plus currently DST+1, so the current offset is UTC+2). Uploading the latest I_GCal_II.xml didn't help either,  same result as before.

So the timezone is showing up incorrectly -- that's a clue -- I will try to reproduce based on Amsterdam. Probably later today though.

Out of curiosity -- why two plugins ?   I'd like to understand your use case.

I tested with my vera and the calendar set to Amsterdam timezone.  Everything worked and the timezone showed correctly as 2hr 0 min.  So it's strange that there is a difference on your vera (especially as the difference shows as 0.35 min).   My original intention was to look for why the plugin would not start on your vera  - but I could not definitively find a problem (as it works on mine) .   I did find one suspicious error but ......  without being able to cause a failure, I cannot be sure.

Along the way I noticed a couple of possible edge conditions and fixed those - although none would have caused the error you reported.  I also tested with timezones for Amsterdam, Adelaide Australia and Mountain Time USA.  I added a few more debug messages that may help narrow the location of the issue.

Can you try with the attached version and just one plugin and grep for gc_ (will get us more log info) - I'd like to try and eliminate any possible interactions because of the two instances.

Thanks for your patience.

EDIT: I removed the attachments to several recent post so folks don't accidentally use them.

Output:
Code: [Select]
06 06/29/14 21:56:15.308 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_NextEvent was: Checking for json.lua now: Checking for json.lua #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x402>
06 06/29/14 21:56:15.310 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_NextEventTime was:  now:  #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x402>
06 06/29/14 21:56:15.382 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_NextEvent was: Checking for json.lua now: Checking for json.lua #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x402>
06 06/29/14 21:56:15.383 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_NextEventTime was:  now:  #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x402>
06 06/29/14 21:56:17.011 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_lastCheck was: 2014-06-29T21:50:24 now: 2014-06-29T21:56:48 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x7c20>
06 06/29/14 21:56:17.013 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_Keyword was: WakeUpLight now: WakeUpLight #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x7c20>
06 06/29/14 21:56:17.014 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_ignoreKeyword was: false now: false #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x7c20>
06 06/29/14 21:56:17.016 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_exactKeyword was: true now: true #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x7c20>
06 06/29/14 21:56:17.017 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_ignoreAllDayEvent was: false now: false #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x7c20>
06 06/29/14 21:56:17.018 Device_Variable::m_szValue_set device: 67 service: urn:srs-com:serviceId:GCal2 variable: gc_jsonEvents was: [] now: [] #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x7c20>
50 06/29/14 21:56:17.019 luup_log:67: GCAL_II:(gc_) timezone is 1 hrs and 59.45 min <0x7c20>
06 06/29/14 21:56:17.023 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_lastCheck was: 2014-06-29T21:50:24 now: 2014-06-29T21:56:48 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x8021>
06 06/29/14 21:56:17.025 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_Keyword was: Housekeeper now: Housekeeper #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x8021>
06 06/29/14 21:56:17.026 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_ignoreKeyword was: false now: false #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x8021>
06 06/29/14 21:56:17.027 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_exactKeyword was: true now: true #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x8021>
06 06/29/14 21:56:17.028 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_ignoreAllDayEvent was: false now: false #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x8021>
06 06/29/14 21:56:17.029 Device_Variable::m_szValue_set device: 68 service: urn:srs-com:serviceId:GCal2 variable: gc_jsonEvents was: [] now: [] #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x8021>
50 06/29/14 21:56:17.030 luup_log:68: GCAL_II:(gc_) timezone is 1 hrs and 59.45 min <0x8021>
Vera2 (1.5.622)

Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #458 on: June 30, 2014, 12:34:16 am »
@duiffie --

I momentarily  reproduce the error on my machine with 2 instances of the plugin.  One of the plugins 'stalled' at "Checking for json.lua"    Is this correct ?

I then pressed reload and the problem corrected itself.   I suspect a race condition at the os level when checking for the json.lua file.  This could take some time to identify the cause ...... you could try rebooting the vera .....

I have added some additional debug messages to try and narrow the problem but they will only show up during reboot (as opposed to reload)

Please try this version and send the error log (starting immediately after a reboot) until and including when the problem occurs.

« Last Edit: June 30, 2014, 02:05:51 pm by Stuart »

Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #459 on: June 30, 2014, 02:04:48 pm »
@duiffie --

I momentarily  reproduce the error on my machine with 2 instances of the plugin.  One of the plugins 'stalled' at "Checking for json.lua"    Is this correct ?

I then pressed reload and the problem corrected itself.   I suspect a race condition at the os level when checking for the json.lua file.  This could take some time to identify the cause ...... you could try rebooting the vera .....

I have added some additional debug messages to try and narrow the problem but they will only show up during reboot (as opposed to reload)

Please try this version and send the error log (starting immediately after a reboot) until and including when the problem occurs.

Better still - this version has better debugging.   I cannot get it to break my vera (with 2 plugin instances) but maybe you will have better luck :-(
I have tried it both with and without the json.lua files ... and with both plugins on the same calendar and with two different calendars at the same time ....

When you upload, do not check "Restart luup after reload" but instead Setup --> Net & Wi-Fi --> reboot.

Offline duiffie

  • Full Member
  • ***
  • Posts: 126
  • Karma: +2/-0
Re: Google Calendar Switch
« Reply #460 on: June 30, 2014, 04:01:49 pm »
@duiffie --

I momentarily  reproduce the error on my machine with 2 instances of the plugin.  One of the plugins 'stalled' at "Checking for json.lua"    Is this correct ?

I then pressed reload and the problem corrected itself.   I suspect a race condition at the os level when checking for the json.lua file.  This could take some time to identify the cause ...... you could try rebooting the vera .....

I have added some additional debug messages to try and narrow the problem but they will only show up during reboot (as opposed to reload)

Please try this version and send the error log (starting immediately after a reboot) until and including when the problem occurs.

Better still - this version has better debugging.   I cannot get it to break my vera (with 2 plugin instances) but maybe you will have better luck :-(
I have tried it both with and without the json.lua files ... and with both plugins on the same calendar and with two different calendars at the same time ....

When you upload, do not check "Restart luup after reload" but instead Setup --> Net & Wi-Fi --> reboot.

Done, I've sent you a PM
Vera2 (1.5.622)

Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #461 on: June 30, 2014, 11:48:36 pm »
@duiffie --

This does not seem to be anything to do with json.lua.  The logs show that it is recognized as being there.  The message stays visible because the plugin does not get to the next stage.  The error seems to be this:

01   06/30/14 21:41:50.023   LuaInterface::CallFunction_Timer-5 function GCalMain failed [string "..."]:113: bad argument #2 to 'format' (integer expected, got number) <0x7c20>

I've taken out the code immediately following the last successful debug message and coded it a different way.  The old code looked like this:

timezone = "&amp;2b" .. string.format("%02d:%02d",timezone,timezonemin)

for some reason, on your vera, timezonemin is 59.9333 but on mine (set for Amsterdam and other, even hour timezones) it's 00  so that could be the "integer expected, got number" issue.

Try this and let me know. V 1.8.2
« Last Edit: July 01, 2014, 12:27:34 am by Stuart »

Offline duiffie

  • Full Member
  • ***
  • Posts: 126
  • Karma: +2/-0
Re: Google Calendar Switch
« Reply #462 on: July 01, 2014, 01:15:42 am »
@duiffie --

This does not seem to be anything to do with json.lua.  The logs show that it is recognized as being there.  The message stays visible because the plugin does not get to the next stage.  The error seems to be this:

01   06/30/14 21:41:50.023   LuaInterface::CallFunction_Timer-5 function GCalMain failed [string "..."]:113: bad argument #2 to 'format' (integer expected, got number) <0x7c20>

I've taken out the code immediately following the last successful debug message and coded it a different way.  The old code looked like this:

timezone = "&amp;2b" .. string.format("%02d:%02d",timezone,timezonemin)

for some reason, on your vera, timezonemin is 59.9333 but on mine (set for Amsterdam and other, even hour timezones) it's 00  so that could be the "integer expected, got number" issue.

Try this and let me know. V 1.8.2

Great, that seems to fix it!

Could the timezonemin difference have something to do with my vera using ntp as a timesource instead of the builtin rdate?
Vera2 (1.5.622)

Offline Stuart

  • Moderator
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: Google Calendar Switch
« Reply #463 on: July 01, 2014, 10:13:12 am »

Great, that seems to fix it!

Could the timezonemin difference have something to do with my vera using ntp as a timesource instead of the builtin rdate?

I don't think different time references would be it.  The timezone offset is basically calculated by asking mios what time is it now (in local time) and what time is it now(in utc) and doing the subtraction. So the offset being reported should just be the equivalent of an indirect lookup in the timesone table.   i.e the same table  that gets used when you set the timezone for your vera.  All i do is then break it into hours and minutes

I think there is a rounding difference -- but I'd expect all vera to behave the same.  Mine is a vera lite - so maybe there is a slight difference among the vera models (but again - I'd expect at the same release level for them to behave the same).  There is always the possibility of a difference in hardwdare ......

Anyway - the main change I made as a result of this, and as a precaution, was forces the minutes offset to the nearest integer ....   


 
« Last Edit: July 01, 2014, 03:13:30 pm by Stuart »

Offline baxy_AU

  • Sr. Member
  • ****
  • Posts: 269
  • Karma: +5/-0
Re: Google Calendar Switch
« Reply #464 on: July 07, 2014, 05:10:24 am »
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?