The attributes array is an optional payload when setting the state of a binary_sensor via the API, but if I don’t declare attributes, they are removed from the binary_sensor. My feeling is that if you send an empty “attributes”:{} , THEN it’s appropriate to destroy the attributes. Otherwise, you should be able to alter state without affecting attributes.
You can do this with AppDaemon - AppDaemon’s code will merge any attributes you specify with the ones that were already there when you do a set_state() call.
1 Like
Does AppDaemon also expose itself to REST so that I can trigger from other sources?
I’ve been hesitating on AppDaemon - worried that it’s a sledgehammer when I need a wrench.
At the moment it integrates with HA, consumes events and responds, it does not have it’s own API - perhaps if you could describe your usecase a little better we could figure out a way to get what you need - or you could persuade me to add an API 
I have been thinking about doing that for other reasons.
I’m porting from a Vera. There are still a couple things that I’ve got attached to it because Vera’s currently handling them better. One is my Envisalink - the HA component doesn’t (yet) keep track of who last disarmed the alarm. I use that to keep track of when the kids get home.
So I wrote a helper function for the Vera that lets me pass info to HA. I really just want to update the state of a sensor. So there’s a (very little) bit of extra work to define those updates to keep the attributes{} intact. No big deal, but if I was touching a sensor that had more info that was evolving on the HA side, I’d need to do a check of the HA state first. So it’d be nice if I could touch just the state.
@ih8gates Hi Scott, I also still have a Vera running that handles most of my Zwave and some devices that are not supported by HASS. For a specific use case using a rest sensor in HASS to get info from the Vera is not enough. I have a use case where I need the Vera to push info to HASS when the event happens. Reading above it seems that you have figured out how. Could you share with me? Thanks
Put this in your startup Lua (replacing the URL and password)
-- talk to HA
function ha_api(endpoint,payload)
-- endpoint like services/automation/trigger
-- whatever comes after api
-- payload like {"entity_id":"automation.garage_doors_trigger_lights"}
local https = require 'ssl.https'
local ltn12 = require 'ltn12'
local request_body = payload
local response_body = {}
b, c, h = https.request {
url = 'https://YOUR-HA-URL/api/' .. endpoint .. '?api_password=YOUR-PASSWORD',
method = 'POST',
headers = {
["Content-Type"] = "application/json",
["Content-Length"] = string.len(request_body)
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body),
}
end
Then, in the Lua for any automation, etc, use something like:
ha_api(“services/light/turn_off”, {“entity_id”:“light.kitchen_ceiling”})
Yes!! Thanks!
Would you mind also posting a LUA example from Vera? Or is it as simple to put your example (ha_api(“services/light/turn_off”, {“entity_id”:“light.kitchen_ceiling”}), but with relevant info for my setup) in for instance a scene (where it says execute Luup code) ? Or is there some extra LUA needed before / after your code example?
I always avoided learning anything about LUA…
That’s all you need - the last line of my post, but with your info. The payload is whatever you’d use in the service data field of the services dev tool.
I just started using HA and wanted to make the same request. My use case is that I want to update the state of an object via HTTP requests using the REST API. For me to maintain the attributes I would have to do a GET, execute a regex and then a POST, which is way more overhead than I can easily do on my device.
Hi, setting this up now but after a few failed tests I see you actually use HTTPS in your LUA, I’m just a plain HTTP HASS user.
Just changing the HTTPS references in HTTP seems not enough. Could you help me out ones more with the startup LUA for a HTTP Hass?
I’m not sure. I think you can just remove the HTTP from the url and also from the request (so you have http.request)
-- talk to HA
function ha_api(endpoint,payload)
-- endpoint like services/automation/trigger
-- whatever comes after api
-- payload like {"entity_id":"automation.garage_doors_trigger_lights"}
local http = require "socket.http"
local ltn12 = require 'ltn12'
local request_body = payload
local response_body = {}
b, c, h = http.request {
url = 'http://YOUR-HA-URL/api/' .. endpoint .. '?api_password=YOUR-PASSWORD',
method = 'POST',
headers = {
["Content-Type"] = "application/json",
["Content-Length"] = string.len(request_body)
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body),
}
end
This looks like a good source for more info if needed:
http://forum.micasaverde.com/index.php?topic=32035.0
Thanks. Unfortunately no success yet. Just a check for the basics:
- I created an input_boolean called testvera in hass (and checked it worked etc.).
- Copied your code into the startup LUA screen of the Vera. Modified IP & password to match my config. Pressed GO (wait)
- Went to the ‘test LUUP’ screen and entered:
ha_api("services/input_boolean/turn_on", {"entity_id":"input_boolean.testvera"})and pressed GO.
Result: get a ‘code failed’ (also tried rebooting Vera etc. but same result)
Anything basic I’m missing here?
What’s the error in your Vera logs?
Also - have you tested the same payload with the services dev tool in HASS?
I had tested payload in HASS, that’s fine. Forgot about the (horrible) vera logs. If I execute the LUA and start monitoring the log I only find below references to ha_api:
08 01/06/17 7:37:54.415 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: RunLua <0x703d0520>
08 01/06/17 7:37:54.416 JobHandler_LuaUPnP::HandleActionRequest argument Code=ha_api("services/input_boolean/turn_on", {"entity_id":"input_boolean.testvera"}) <0x703d0520>
01 01/06/17 7:37:54.422 LuaInterface::LoadCode: [string "ha_api("services/input_boolean/turn_on", {"entity_id":"input_bo..."]:1: '}' expected near ':' <0x703d0520>
01 01/06/17 7:37:54.422 JobHandler_LuaUPnP::RunLua failed: ha_api("services/input_boolean/turn_on", {"entity_id":"input_boolean.testvera"}) <0x703d0520>Are you quoting that payload in the ha_api call? You’ll need to have single quotes around it.
ha_api(“services/input_boolean/turn_on”, ‘{“entity_id”:“input_boolean.testvera”}’)
Did not quote it. Changed and it works now!
Many thanks!
@ih8gates Hi Scott, do you know if I can use this same method for passing Vera variable values back to HASS? I have an RFID reader attached to Vera. With a restfull sensor in HASS I check that value. However as a resfull sensor is not real time (i think it checks every 60 seconds), the value it get from the Vera is the previous value.
I would rather just kill that sensor and have Vera ‘push’ the value as soon as it has a new value.
Yeah - sure. Anywhere you can run LUA on the Vera, you can run that code.
Thanks. Unfortunately I’m a bit of a noob when it comes to LUA.
As you cannot set a sensor (there is no service for it) I could create =an input select in Hass that holds the different possibilities (let’s say 3 options; A, B, C). How would I need to format the LUA?