Need help writing a plug-in

Plugins & Plugin Development openLuup
#1

Good evening all,
First off, I’m going to apologize for my litany of noob questions.

I’ve spent the better part of the evening reading through the openLuup topics and I’m left more confused. I’m not 100% sure it will do what I want it to do. It might not be the right tool, but I’m not sure what is.

I’ve got OpenLuup installed on a raspberry Pi 3 today, along with a python script that I want to call.

What the python script does, is acts as an API to a Kwickset Kevo deadbolt, since no official API exists, some individuals reverse engineered what was needed. Basically, there are a few scripts that reference the library, and combined with your user credentials and the lock’s UUID, get the device state (locked or unlocked), or direct the deadbolt to either lock or unlock. Those are the only commands it does.

The python script works. I can sit there at the cli and run the scripts all day, however, I need a way to translate that into Vera. People have already done it with SmartThings and
Home Assistant, but I’m a bit a noob as far as programming in Vera, and I’m not sure where to begin.
What I want is a toggle device in the main Vera console that can make calls out to my Pi, using the python scripts. I want to be able to set the interval that it checks the status (every minute, every 5, every 10, whatever), so it keeps it relatively up to date. I also want to be able to use Reactor or scences to lock the deadbolt if it goes into Night or Away mode.

It doesn’t sound like much, but again, not sure where to begin, I think SiteSensor would give me the state, were I to set up a Webserver to run the state function, but it can’t actually interact more than that.

Is openLuup the app for me? Is there something easier, something I’m missing? Am I overthinking this? Advice?

#2

It would be so simple if there was a HASS PI for Vera. nudge… nudge…
You could have a look at MQTT, IIRC there are some dev’s here that have used it to access HASS.

#3

I may not be that far off. I figured out how to turn the scripts I run into cgi, and I’m running a python -m webserver instance. I can make calls from Lua now.

http://192.168.1.138:8000/cgi-bin/lock-front.cgi

Code on my Pi:

Lock State:

#!/usr/bin/python3
print('Content-type: text/html\r\n\r')
from pykevoplus import KevoLock
lock = KevoLock.FromLockID("abcdef-ghij-klmn-opqr-stuvwxyz123456", "myemail@xyz.com", "supersecretpassword")
print(lock.GetBoltState())

Lock Door:

#!/usr/bin/python3
print('Content-type: text/html\r\n\r')
from pykevoplus import KevoLock
lock = KevoLock.FromLockID("abcdef-ghij-klmn-opqr-stuvwxyz123456", "myemail@xyz.com", "supersecretpassword")
lock.Lock()
print(lock.GetBoltState())

Unlock Door:

#!/usr/bin/python3
print('Content-type: text/html\r\n\r')
from pykevoplus import KevoLock
lock = KevoLock.FromLockID("abcdef-ghij-klmn-opqr-stuvwxyz123456", "myemail@xyz.com", "supersecretpassword")
lock.Unlock()
print(lock.GetBoltState())

Obviously, specifics changed, but if I run it from the Lua code developer, it works.

So, it works if I do this from Test Luup Code, so I just need to figure out how to turn that into a switch.

local http = require(“socket.http”)
http.TIMEOUT = 20
result, status = http.request(“http://192.168.1.138:8000/cgi-bin/lock-front.cgi”)

Once I do that, obviously I would want to be able to pass variables to it from Vera, so I don’t have to have a script for each door (I have two Kevo deadbolts). I’d also like to make it available on AltUI for other users eventually

#4

You could the Hass API directly without having to go through Python.
I am one of those who run OpenLuup and Home Assistant as a bridge. Granted there is no bridge plugin but… for sensors on HASS, I use SiteSensor by @rigpapa and poll the Home Assistant API.
For other devices, I manually bridged them by writing automation on HA to update devices on openLuup and created corresponding virtual devices which then update HA through scenes.

In my startup Lua I added this function to call updates to HA:

function POSTHA(path, payload, token)
    local async = require "http_async"
    local ltn12 = require("ltn12")
    local resp = {}
    local ok, err async.request(
    {
    url = path,
    method = "POST",
    headers = 
        {["Content-Type"] = "application/json",
        ["Content-Length"] = payload:len(),
        ["Authorization"] = token,
        },
    source = ltn12.source.string(payload),
    sink = ltn12.sink.table(resp)
    }, function() end)
end

Then you can build a lua code for example to lock door, example below is for a vent where I get the value and send it to HA and just set it up as a scene triggered by any target value change:

local path = "http://**HA-IP**:8123/api/services/light/turn_on"
local level = luup.variable_get("urn:upnp-org:serviceId:Dimming1","LoadLevelTarget",dev)
level = level*2.54
local payload = string.format ([[{"entity_id": "**yourtargetentity**","brightness": %s}]] , level)
POSTHA(path, payload, hass_token)

This is how I created a binding between openLuup and my entire zigbee network which resides on HA.

#5

The HAAS API uses the same python scripts on a Pi server to get its state, and to change the state of the lock. I’m afraid there isn’t a way around that.

#6

My point is to not to have to create a script at all. They are already in HA. You just call the API. Your code does not call the API at all. You are basically rewriting script and building a new quasi API on your own by turning them into cgi.

#7

FWIW, I’d just translate the Python to Lua.

I’ve done this for a significant amount of code (the whole Graphite API in openLuup and DataYours) and generally it’s very straight-forward. The syntax, and many library calls, are not dissimilar.

An HTML parser which generates a DOM is built into openLuup, so scraping HTML is easy too.

So if you were looking for a bit of a project…

#8

Another option may be to install (the upcoming, currently development/stable) Reactor 3.6, which contains an HTTP request action with response capture (i.e. a somewhat miniaturized version of SiteSensor)… then you can read and control from within the same logic unit. I think if you pair that with a virtual switch for the “slider” UI, you’re getting most of what you’ve asked if not all.

You could certainly build a plugin to do whatever. If you’re interested, I have a plugin framework (experimental) that I’ve been working on and a few people have used (myself included) for some recent plugins. Framework and documentation here: GitHub - toggledbits/PluginTools: Tools for creating Vera/Luup/openLuup plugins

#9

Patrick,
I was actually able to run a http request from reactor for lock/unlock actions, but of course I didn’t get any feedback. Still, I do have the rudimentary function of running the request when I go into a mode, based upon Reactor.

Reactor 3.6 may be what I need to get that feedback. What would I need to do use that?

I’ll take a look at the plugin framework. It would be nice not to have it dependent on an external server, and something that could be “native” to Vera.