Recent Posts

Pages: 1 ... 8 9 [10]
openLuup / Re: Porting Gcal3 to openluup
« Last post by reneboer on September 21, 2018, 12:39:23 pm »

akbooer sure added a quick reliable check to see if you are running on openLuup. I use this bit of code to determine what a plugin is running on (part of a library of utils i compiled):
Code: [Select]
local _UI5 = 5
local _UI6 = 6
local _UI7 = 7
local _UI8 = 8
local _OpenLuup = 99

-- See what system we are running on, some Vera or OpenLuup
local function _getui()
if (luup.attr_get("openLuup",0) ~= nil) then
return _OpenLuup
return luup.version_major
return _UI7

Cheers Rene
openLuup / Re: openLuup: Data Historian
« Last post by reneboer on September 21, 2018, 12:23:36 pm »
Could it be because my first Vera has device numbers going over 10000 and thus show with device IDs on the Verabrige from 10000 - 23500? the second bridged Vera has the 20000 range. I guess I need to up that? However, there goes my DataMine data and scenes  ???

I knew someone would manage this one day.  It just had to be you!

I would have to think hard about the effects of that, but at the very least, I think that devices in the wrong-numbered block will show the wrong node name.  What duplicate device numbers do, I hate to think...

...time to tidy up your Vera device numbering.

I wish I could sort of reset the Vera device numbering. At one point to Worldweather plugin went haywire and kept recreating its child devices. I did once change all the device numbers over 10000, but when you add a device the Vera just keeps numbering up. I guess I need to bit the bullet on the openLuup side.

For the historian view, maybe you can test with and without the on disk archiving and see if all bridged variables show an hyperlink.

Cheers Rene
General / Re: Vera issues and alternatives testing for zwave
« Last post by integlikewhoa on September 21, 2018, 11:49:32 am »
This is about automation, not walking around with a phone turning on and off lights.

This gets my vote for the most important concept for this budding industry to embrace.

Home Automation, Not Home remote control.
Program Logic Plugins / Re: only fire once per day
« Last post by mikoz on September 21, 2018, 10:34:42 am »
In case you're wondering the application for this, I have a device that I turn on via Zwave (from amazon echo)  but it still requires a remote control to actually operate and a few times my wife has said that she swore she set it via remote but it wasn't operating.    So I want to send a txt message when the device's energy usage exceeds a threshold but only do so once per day within 4 hours of turning it on. 

is this possible? 

The zwave system turns the device off automatically at night. 
General / Re: Vera issues and alternatives testing for zwave
« Last post by rigpapa on September 21, 2018, 09:25:30 am »
This is about automation, not walking around with a phone turning on and off lights.

This gets my vote for the most important concept for this budding industry to embrace.
Honeywell WiFi Thermostats / Re: PLUGIN: Honeywell Total Connect Comfort Thermostats
« Last post by cc4005 on September 21, 2018, 09:19:55 am »
Does the Vera hub have to be on the same LAN as the thermostats for the plugin to create the devices?

I don't think the plugin has anything to do with the actual unit.  It interfaces directly with the Honeywell website.
For some stupid reason, Honeywell has different formats for different countries.  I know that if you are in Australia it probably wont detect any thermostats as we are slightly different again for some reason.  Most other devices that interface with the TCC website don't work for Australia either.  Last I checked IFTTT didn't.  You can register your thermostat as if you lived in the US but then your times and weather are wrong.

Mine works in Australia but only because ages ago the interface was different and Vera could detect it.  If I do any searches now it doesn't get discovered.  I'm very grateful for backups otherwise I'd lose the functionality.

Thanks for the reply. I'm in the U.S. so no idea why it's not working. As I mentioned before, it says it connects successfully and "devices found", but nothing shows up in the plugin. Ugh.
General / Re: Vera issues and alternatives testing for zwave
« Last post by litby on September 21, 2018, 09:10:41 am »
Just start saving your coins for every Luup reload and you'll have enough saved up to buy HomeSeer by the time the next sale happens in November.  If you can keep your sanity that long.

Ha! Yeah I wish but my biggest energy barrier is migration and I have gotten the vera to now be up for days at a time. I think I know the source of that reload and remedied it. Let's see where this goes.

I will say that migrating to HS is surprisingly fast. The device enrollment process takes much less time and their dense gui uses cascading menus to build rules for events. It goes quite fast.

Quite. Function over form. I've been running HS in production for about a month now. I first tried to run it on Linux in a virtual machine but that was not a good idea. So I repurposed a Dell 3040 micro and it is solid as a rock with two Aeotec sticks.

I feel I'm using a real application rather than a toy. HS comes from a time before everyone started to think everything has to center around a phone app. That may well be its biggest strength.

This is about automation, not walking around with a phone turning on and off lights.
openLuup / Porting Gcal3 to openluup
« Last post by Stuart on September 21, 2018, 08:55:15 am »
A couple of years ago I was going to make an openluup specific port of GCal3 and then got distracted ....
GCal3, over the past year or so, has been not needed code changes.  Recently google made a change that needed an immediate fix  ....  Fortunately it was easy enough to identify so I issues a quick patch file.

A couple of folks using openluup picked up the patch file - functionally working but a UI problem - like no UI :-(

So I'm reinvigorated to take a look at openluup - but am traveling over the next few weeks and cannot get physically to my server to install etc. .

One question (for now) to maybe solve the UI problem.  In the patched file (nothing to do with the google issue) just from a more recent GCal version - I have this code:

    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)

(Yes - I know the if looks strange)

Several questiions:
1)  Do the luup.version and luup.version_major variables have meaning / return particular values in openluup ?
2)  If no - is there a simple way to tell if the code is running on openluup?
3) Does the line luup.attr_set("device_json" ....   do anything in openluup?
bump. Back to the drawing board. It all works welll... BUT

When I now turn on the light manually PLEG turns them off immediately:
((onL > 0) or (onR > 0)) and not timer (as expected).

I cannot seem to find to only turn off the lights upon "no motion" (and lightlevel below 150) detected anymore and timer passed.

Can you please help me in the logic syntax? Status report attached.

Thank you :-)
Google Calendar Switch / Re: GCAL3 - Version 2.7
« Last post by Stuart on September 21, 2018, 08:36:55 am »
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,  ;D 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.



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)

Pages: 1 ... 8 9 [10]