Recent Posts

Pages: [1] 2 3 ... 10
HomeWave (iOS) / Re: Homewave project dead?
« Last post by Dude22573 on Today at 05:11:17 pm »
I have used VeraMate for many years on 2 iPhones.  Sad the developer has abandoned it. If Homewave has a free version to try out, I may make the move from VeraMate. Thus far, VeraMate does over 90% of what I need it to do but the AltHue support is weak.

I second this! I am also looking for a replacement to VM. I wish there was a free version of the Homewave app to try out.
openLuup / Re: openLuup: Data Historian
« Last post by ChrisTheC on Today at 05:10:49 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  ???

Cheers Rene

While wasting your time with my response, I'm also laughing at myself.
My devices are up to 93, but being an obsessive/compulsive type (read anal), I'm having heart palpitations because of the missing numbers in between.

I need to calm down now.


Karma for all you do here.

Weather Plugin / Re: No more free keys for Wunderground Plugin.
« Last post by fyford on Today at 04:33:04 pm »
My SAYTHEWEATHER app still pulls the local weather from Wunderground and broadcasts it over Sonos when I have my breakfast. I am guessing current API keys will stay valid?
Google Calendar Switch / Re: GCAL3 - Version 2.7
« Last post by ChrisTheC on Today at 04:27:47 pm »
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,
General / Re: No Vera email Alerts since 9/17/18
« Last post by vicw on Today at 04:13:13 pm »
I got Microsoft to disable Safe Links for my account, and that part seems to be gone now, but my Vera Alerts are still going to Junk Email. Microsoft now says that the sender needs to update their Microsoft Junk Mail Reporting program. Not sure about that, but I forwarded all of that data back to Vera Support.

I would really appreciate if any other Vera users who are using email for alerts are currently able to receive the Vera alerts to their Inbox, or if they are also going to the Junk Email folder as mine are. This problem started within the last 4 or 5 days. Note that the Android Outlook app doesn't display the Junk Email folder. You need to look on the browser version to see it.
General / Re: if you are fed up with vera....
« Last post by fyford on Today at 03:51:49 pm »
Does any of the solutions mentioned above work with LigthwareRF kit via  RFXCom?

I'm about ready to jump, just waiting to see what these new guys bring to the table with the MIOS Acquisition... sounds like they mean business... guess time will tell.
openLuup / Re: Porting Gcal3 to openluup
« Last post by akbooer on Today at 03:21:39 pm »
So I'm reinvigorated to take a look at openluup

That's great news!

1)  Do the luup.version and luup.version_major variables have meaning / return particular values in openluup ?

No, it's always 7.00.  It emulates UI7 luup calls.

2)  If no - is there a simple way to tell if the code is running on openluup?

Yes.  There's a variable luup.openLuup which is non-nil (actually, a table) in openLuup.  So you can write

Code: [Select]
if luup.openLuup then
  -- we're running under openLuup

3) Does the line luup.attr_set("device_json" ....   do anything in openluup?, yes, I hope.  It sets that device attribute.
When I now turn on the light manually PLEG turns them off immediately:

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

I would recommend starting the timer regardless of LightLevel.  As it is right now, it would be expected that if you manually turned on the lights at LightLevel>=150 the lights should turn off even if motion - you didn't start the timer due to the high LightLevel.  I would similarly recommend turning them off regardless of LightLevel (which you are doing already).  Just check LightLevel in the determination to turn them "on"...

As far as determining manual operation, that is a bit trickier.  If you look at my PLEG, I essentially would check if "onL" had happened within 30 seconds of "on".  So if the light turned on, was it due to the fact our on condition fired?  If not, assume manual operation and start a timer to decide when we can go back to automated functionality.  I would build "onL" as a trigger instead of a property, but it should work as a property.

openLuup / Re: Porting Gcal3 to openluup
« Last post by reneboer on Today at 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 Today at 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
Pages: [1] 2 3 ... 10