Recent Posts

Pages: [1] 2 3 ... 10
1
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.

2
openLuup / Re: Porting Gcal3 to openluup
« Last post by reneboer on Today at 12:39:23 pm »
Hi,

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
else
return luup.version_major
end
return _UI7
end

Cheers Rene
3
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.
LOL.

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
4
General / Re: Vera issues and alternatives testing for zwave
« Last post by integlikewhoa on Today at 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.
5
Program Logic Plugins / Re: only fire once per day
« Last post by mikoz on Today at 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. 
6
General / Re: Vera issues and alternatives testing for zwave
« Last post by rigpapa on Today at 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.
7
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.
8
General / Re: Vera issues and alternatives testing for zwave
« Last post by litby on Today at 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.
9
openLuup / Porting Gcal3 to openluup
« Last post by Stuart on Today at 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?
 
10
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 :-)
Pages: [1] 2 3 ... 10