GCAL3 - General Discussion

[Stuart]

If someone who uses AltUI can check the the file I posted recently (as 2.7a) and confirm that it works -- I will update Alternate App Store.  The version in the Alt App store (marked as 3.0) is a couple of revs back (likely 2.5 of GCal).

I initially posted above on 9/14 that your 2.7a .lua file was working for me on openLuup.

Mostly true.

My single all day event does trip,  but your control panel is now blank, ie can't arm or disarm, or perform a check. Also your icons are now the default zwave icons.

I'll pm you the log from past midnight when my single event tripped with my gc_debug at 3. (not sure if those token calls are revealing sensitive info)

Again, it is functional with my all day events, just missing the control panel & icons.

Thanks for interrupting "life happens" for us. Hope things are well.

Regards,

Chris

I took a look at the log file but did not see anything wrong. BUT I would not have expected to see anything .....  The GCal3.lua file does not define the UI or the icons other than selecting the files for UI5 or UI7 Those files are unaltered. So something else has happened - perhaps the UI files are incorrectly named or the mechanics of openluup are different.  Likely the later.

I do not use openluup (although now that I?ve rebuilt my basement server I should probably add it). As I said before I?m not sure if I made specific changes for openluup ( in the UI context) but thinking about it if the Alt App Store services both Vera and openluup (and openluup has different requirements) then it might get tricky. I go recall one accommodation had something to do with the OS version - I?ll have to look.

P.S.  The log files will show the calendar I?d and the access token (only good for an hour) and calendar entries. Most people?s entries are fairly cryptic.  So you are pretty safe :-)

[Stuart]

If someone who uses AltUI can check the the file I posted recently (as 2.7a) and confirm that it works -- I will update Alternate App Store.  The version in the Alt App store (marked as 3.0) is a couple of revs back (likely 2.5 of GCal).

I initially posted above on 9/14 that your 2.7a .lua file was working for me on openLuup.

Mostly true.

My single all day event does trip,  but your control panel is now blank, ie can't arm or disarm, or perform a check. Also your icons are now the default zwave icons.

I'll pm you the log from past midnight when my single event tripped with my gc_debug at 3. (not sure if those token calls are revealing sensitive info)

Again, it is functional with my all day events, just missing the control panel & icons.

Thanks for interrupting "life happens" for us. Hope things are well.

Regards,

Chris

I took a look at the log file but did not see anything wrong. BUT I would not have expected to see anything .....  The GCal3.lua file does not define the UI or the icons other than selecting the files for UI5 or UI7 Those files are unaltered. So something else has happened - perhaps the UI files are incorrectly named or the mechanics of openluup are different.  Likely the later.

I do not use openluup (although now that I?ve rebuilt my basement server I should probably add it). As I said before I?m not sure if I made specific changes for openluup ( in the UI context) but thinking about it if the Alt App Store services both Vera and openluup (and openluup has different requirements) then it might get tricky. I go recall one accommodation had something to do with the OS version - I?ll have to look.

P.S.  The log files will show the calendar I?d and the access token (only good for an hour) and calendar entries. Most people?s entries are fairly cryptic.  So you are pretty safe :-)

OK - may have found the issue.  Does the file D_GCal3_UI7.json exist on your openluup system ?  This defines the UI.

There is some code (in 2.7 and not in 3.0) that tests for vera UI7 vs UI5 that likely behaves differently (maybe meaningless) in openluup.  I'll check with the openluup forum ....  Although my suspicion is that this code does nothing in openluup, in which case the UI definition did not change on your system .....

      if ( luup.version_branch == 1 and luup.version_major == 7 and GCV.UI7Check == "false") then
        GCV.UI7Check = "true"
        luup.attr_set("device_json", "D_GCal3_UI7.json", lul_device)

[ChrisTheC]

OK - may have found the issue.  Does the file D_GCal3_UI7.json exist on your openluup system ?  This defines the UI.

There is some code (in 2.7 and not in 3.0) that tests for vera UI7 vs UI5 that likely behaves differently (maybe meaningless) in openluup.  I'll check with the openluup forum ....  Although my suspicion is that this code does nothing in openluup, in which case the UI definition did not change on your system .....

      if ( luup.version_branch == 1 and luup.version_major == 7 and GCV.UI7Check == "false") then
        GCV.UI7Check = "true"
        luup.attr_set("device_json", "D_GCal3_UI7.json", lul_device)

There is no D_GCal3_UI7.json on my system, only the D_GCal3.json.

I think that's the way it was meant to be, since the Alternate App Store downloaded directly from your github GCal3 which does not include the UI7.json version.

I don't believe the updated .lua file did anything, because I thought it worked briefly in my sequence of steps below:

1. downloaded your updated .lua file from your post.
2. Using WinSCP I made a backup file of the existing file (called GCal3Backup.lua) in the cmh-ludl/
3. Using WinSCP I uploaded your new GCal3.lua (overwriting the existing) to the cmh-ludl/ folder.
4. Reloaded the Luup engine.
5. Opened the control panel of GCal3 & clicked to ARM then clicked to CHECK. It worked here so the new .lua file was working at this moment.

I didn't notice until a day or so later that the GCal3 icon was gone, then I noticed the control panel was blank.

I will experiment further.

Thanks again,
Chris

[Stuart]

  @ChrisTheC
Ok - thanks, I can see what's happening.  I'll create an interim fix later today.

Basically - I was going down a path of an openluup only version (hence calling the release 3.0 and using default file names). I patched the (more recent) version that serves vera UI5 and UI7 (2.7a).  What that did was interpret openluup as UI7 and change the json file to one that does not exist in openluup.

BTW - I never formally released 3.0 as I had not finished testing it ....   good to know it was working well.  :-)

I'll rethink the strategy for a formal update - once we make sure it all works correctly.

[Stuart]

 @ChrisTheC

Can you test this please.  I ended up putting in more than a quick fix (although constrained to this one).  Moving forward - it should allow me to keep a single code base across UI5/6/openluup and make the common code available through Alt App Store and the mios app store.

NOTE: You will have to re-enter the Calendar ID when you update with this file.

[ChrisTheC]

. . . snip
NOTE: You will have to re-enter the Calendar ID when you update with this file.

Ok Stuart,

I uploaded the V2.7a1 lua file & reloaded the luup engine.

I still didn't have access to the control panel so I couldn't re-enter the Calender ID.

Instead, on the Variables tab, I changed the gc_Variables "Not Used" (and I was just guessing here, I didn't know the exact syntax) to:

Code: [Select]

[{"CalendarID":"https://www.google.com/calendar/embed?src=MYCalendarID%40group.calendar.google.com"
Again, I reloaded the Luup engine, refreshed the browser, and . . .

Everything seems to be back to normal! I have the calendar icon, the control panel is back.
The variable gc_Variables switched back to "Not Used", guessing that is the new norm?

Since I only use this calendar for 3 "all day" events per week (the days my wife works), I suppose it's a poor example calendar to test the GCal functions, but I'll start adding some middle of the day timed events this weekend to gauge the reactions of the plugin.

Again, thanks for the modifications.

Regards,
Chris

[Stuart]

. . . snip
NOTE: You will have to re-enter the Calendar ID when you update with this file.

Ok Stuart,

I uploaded the V2.7a1 lua file & reloaded the luup engine.

I still didn't have access to the control panel so I couldn't re-enter the Calender ID.

Instead, on the Variables tab, I changed the gc_Variables "Not Used" (and I was just guessing here, I didn't know the exact syntax) to:

Code: [Select]

[{"CalendarID":"https://www.google.com/calendar/embed?src=MYCalendarID%40group.calendar.google.com"
Again, I reloaded the Luup engine, refreshed the browser, and . . .

Everything seems to be back to normal! I have the calendar icon, the control panel is back.
The variable gc_Variables switched back to "Not Used", guessing that is the new norm?

Since I only use this calendar for 3 "all day" events per week (the days my wife works), I suppose it's a poor example calendar to test the GCal functions, but I'll start adding some middle of the day timed events this weekend to gauge the reactions of the plugin.

Again, thanks for the modifications.

Regards,
Chris

Great! and Thanks!  It really, really helps having someone like you that provides detailed feedback of what they did and what they saw.

The variable gc_Variables is in fact, Not Used.  I was a left-over from some prior iteration.  Unfortunately, without deleting and reinstalling a plugin, you cannot get rid of such variables - and what ever value it had could be misleading - so I just made it clear that it had no meaning.

What happened is that changing this value caused luup to restart and refresh variables that are stored in a file (helps keep the clutter down in the UI Advanced Variabled tab).  Not sure entirely why you did not see the UI change at first - it may have been a timing thing.

The trouble is that it's difficult to test without deinstalling the plugin, reinstalling the plugin, entering Calendar ID, credentials upgrading .....

Looks like we are out of the woods.  I'll see if there needs to be any further tidy-up and then push this out in the next few days.

If you want to do some further testing - why not create another calendar instance and use the test calendar and credentials I provide ?  Will make life a bit easier.  You may need to re-apply the patch file when you install it (depending on the openluup mechanics)  :-) 

[akbooer]

The variable gc_Variables is in fact, Not Used.  I was a left-over from some prior iteration.  Unfortunately, without deleting and reinstalling a plugin, you cannot get rid of such variables...

This is not strictly true.  AltUI does a good job of allowing you to delete variables on Vera or openLuup, also, on the latest versions of Vera firmware, writing a nil value to a variable will delete that variable.

[Stuart]

The variable gc_Variables is in fact, Not Used.  I was a left-over from some prior iteration.  Unfortunately, without deleting and reinstalling a plugin, you cannot get rid of such variables...

This is not strictly true.  AltUI does a good job of allowing you to delete variables on Vera or openLuup, also, on the latest versions of Vera firmware, writing a nil value to a variable will delete that variable.

Ah - I did not know that - Thank you.  I will make that change and leave those on UI5 to "suffer" :-)

[Stuart]

@ChrisTheC --

Would you like to try installing version 3.1 from the Alt App Store ?

It's the same as the 2.7a1 patch but I also included defaults of installing the CalendarID and Credential file for the test calendar - for those doing an initial install.

If you install from scratch - you first need to Arm the plugin and force a Check before the test calendar shows up.

[ChrisTheC]

Will do now

[Stuart]

Will do now

I made some changes in the last couple of days.  There were some start-up issues that I believe I have fixed.

What should happen now is when the plugin is first installed, it is in bypass mode.  When it is armed, it should automagically connect to the test calendar.  Thereafter you can change the credentials file and Calendar ID.  If you have a credentials file already installed from a prior version, it should find it.

I'm testing some minor cross platform (vera / openluup) differences to do with log files -- but other wise this is looking good on my openluup.  Have not tested these changes on an initial vera install yet.

[ChrisTheC]

Will do now

Sorry I didn't report back sooner.

On 9/25 I grabbed all the updated files from your github & manually uploaded to the rPi 3. (openLuup/ALTUI)

Everything to my eye is working well.

..snip

What should happen now is when the plugin is first installed, it is in bypass mode.  When it is armed, it should automagically connect to the test calendar.  Thereafter you can change the credentials file and Calendar ID.  If you have a credentials file already installed from a prior version, it should find it.

I'm testing some minor cross platform (vera / openluup) differences to do with log files -- but other wise this is looking good on my openluup.  Have not tested these changes on an initial vera install yet.

I'm afraid to test "installing from scratch" to see your automagically wizardry. The whole credentials, google cloud platform, IAM stuff is intimidating, and I fear I'll bork something, but . . .

This morning, I just created a new instance of your plugin and used the calendar ID of an old calendar that I had previously (a year or so ago) shared with the services account. After I input the calendar ID, my current "GCal3.json" credentials file, the new calendar is working too.

In summary, this is looking good on my openLuup too.

I won't test on my vera 3 still UI5 (and will remain so), thus I am not planning to add any modern plugins to it. (Unless you insist for testing purposes)

I will upload & install your recent modifications sometime today.

TA

Chris

[Stuart]

I won't test on my vera 3 still UI5 (and will remain so), thus I am not planning to add any modern plugins to it. (Unless you insist for testing purposes)

So I posted the official 3.1 version to the Alt App Store today and requested vera to approve the same code in the marketplace version.

Just so you know the code is exactly the same across UI5, UI7 and openluup -- other than some slight openluup / vera differences.  For UI5 the only difference is the file that displays the plugin in the UI.   I do not test on UI5 any more and have not changed the UI file since vera stopped updating UI5.  So you could be "brave" if you wanted to 

[jswim788]

I didn't do an update GCal3 on one of my systems, yet it appears that the 'missing access_token' problem has gone away and it is now updating properly.  I'm going to update it anyway, but I'm curious to learn if anyone else has noticed this.