Wow ! There are a lot of changes in the development branch (e.g. update from Github for plugins)
luup.set_failure is now implemented… but I think there’s a bug.
luup.set_failure(1,id) => for communication failure => device status = 2
luup.set_failure(2,id) => for authentification failure => device status = 2
Device status seems to be always set to ‘2’ when there is an error (in Vera).
But openLuup takes the parameter of set_failure as the device status.
Anyway, my goal was to show a communication problem in the UI, but as set_failure blocks the device actions, the user can not do something to fix the problem (like new user/password) without reloading the luup engine.
Red warning in UI7 is bound to an hidden flag, set with set_failure.
Set variable “CommFailure” or device status attribute is not enough.
I have to use a special icon in case of communication problem.
And use the device status to highlight the problem, at least in ALTUI.
Yes, it’s not up to the speed of development of AltUI, but I try my best. This will shortly become release 8.0
luup.set_failure is now implemented... but I think there's a bug.
luup.set_failure(1,id) => for communication failure => device status = 2
luup.set_failure(2,id) => for authentification failure => device status = 2
Device status seems to be always set to ‘2’ when there is an error (in Vera).
But openLuup takes the parameter of set_failure as the device status.
Hmm. Seems like there’s more experimenting to do here.
Anyway, my goal was to show a communication problem in the UI, but as set_failure blocks the device actions, the user can not do something to fix the problem (like new user/password) without reloading the luup engine.
Red warning in UI7 is bound to an hidden flag, set with set_failure.
Set variable “CommFailure” or device status attribute is not enough.
I don’t touch the CommFailure flag, and there’s clearly nothing I can do about a hidden flag. But in previous experiments, I was able to turn the device panel banner green / blue / and red with various status values.
I have to use a special icon in case of communication problem.
And use the device status to highlight the problem, at least in ALTUI.
Yes, I ran into the same problem wanting to implement a flag to show that an openLuup version update was available. (The development version can now update from itself from GitHub, as well as AltUI, but don’t try it because you will revert to a version which doesn’t have that functionality!)
Hi, this is related to the device status in the development branch. I modified this code in VeraBrigde to copy the status, so now ALTUI shows the openLuup device banner blue, green or red when remote vera device does.
-- updates existing device variables with new values
-- this devices table is from the "status" request
local function UpdateVariables(devices)
for _, dev in pairs (devices) do
dev.id = tonumber (dev.id)
local i = local_by_remote_id(dev.id)
if i and luup.devices[i] then
local d = luup.devices[i]
d:status_set(dev.status) -- copy device status
-- TODO set d.tooltip from dev.tooltip ?
if (type (dev.states) == "table") then
for _, v in ipairs (dev.states) do
local value = luup.variable_get (v.service, v.variable, i)
if v.value ~= value then
-- print ("update", dev.id, i, v.variable) -- TODO: TEST ONLY
luup.variable_set (v.service, v.variable, v.value, i)
end
end
end
end
end
end
I just ran a quick test to confirm that calling luup.set_failure for vera devices with 0, 1, or 2 sets the device status to 2 (turns the banner red). Parameter values 1 and 2 also set the CommFailure variable to 1. The parameter does not appear to be the same as device status.
It seems that the only way to reset the status back is to post user data modification for that device. That’s how ALTUI does it:
http://vera_ip/port_49451/upnp/control/hag
SOAPACTION:"urn:schemas-micasaverde-org:service:HomeAutomationGateway:1#ModifyUserData"
... device user data here ...
I also did not find any info on how to retrieve what was specified in set_failure parameter…
Just to expand on my previous comment on your last posts…
I’m very grateful for your experimentation and insights here, confirming the behaviour of set_failure. I need to adjust my code accordingly. Now @amg0 has resolved the upnp/control/hag user_data modification requests for openLuup, we are filling in some of the user interface functionality. Editing Startup Lua will be, I hope, a useful start. The WSAPI CGI framework is there for anyone to extend it further.
My assumption is that functionality resumes if the plugin itself changes the failure status once again. In which case, an HTTP handler could be used to respond to a request and reset things appropriately. Just a thought.
Yes it could be done like that. For the moment I use HTTP handler just for retrieving computed informations.
It could be used instead of upnp actions (but there can be only one handler for instances of a plugin)
