[quote=“Selkirk, post:3, topic:198822”]The error message indicates that the fibaro library is not available. The docs say that the Fibaro Lua library is for the Home Center 2.
EDIT: I’ve tried using print(luup.variable_get… for some of them, but I don’t get anything printed. Also, nothing happens. If I use only luup.call_action it will dim up quickly and then instantly dim down. How do I know when to use luup.call_action and luup.variable_set?
[quote=“akbooer, post:6, topic:198822”]All your [tt]luup.variable_set()[/tt] calls should be [tt]luup.call_action()[/tt] calls.
You are already using (mostly) the correct argument list for action calls, except for some missing empty parameters.
You should never (well, hardly ever) directly set a device’s variables, unless it is your own plugin that you have written.[/quote]
Thanks! This is actually quite close to my starting point - except for your nifty way of shortening down the names and such. Also, I didn’t know I had to include the empty arguments. I think I learned a lot from this post (I say “think” because next time will prove if I learned anything or not ).
Seems the startRampUp function is too fast, so I might have to play with the delta value or do a while loop, but this was big help
local ID = 597
local SID = {
power = "urn:upnp-org:serviceId:SwitchPower1",
dimming = "urn:upnp-org:serviceId:Dimming1",
}
local function power (act, var) luup.call_action(SID.power, act, var or {}, ID) end
local function dimming (act, var) luup.call_action(SID.dimming, act, var or {}, ID) end
power ("SetTarget", {newTargetValue = "1"})
dimming ("SetLoadLevelTarget", {newLoadlevelTarget= "0"})
dimming ("SetRampRate", {newRampRate= 1000})
dimming "StartRampUp"
luup.sleep(4000)
dimming "StartRampDown"
power ("SetTarget", {newTargetValue = "0"})
However, as a matter of urgency, please do investigate the replacements I suggested for [tt]luup.sleep()[/tt].
[tt]luup.sleep()[/tt] actually stalls the thread which the code is running in. This may not be a problem since every device now has two threads, so some other actions can occur asynchronously. However, a LONG sleep time (~60 seconds or more?) can cause Vera to reload spontaneously…
…of course, many other things seem to do this too, but it’s good to minimise this type of behaviour in the hope of achieving greater system stability.
[quote=“akbooer, post:10, topic:198822”][tt]luup.sleep()[/tt] actually stalls the thread which the code is running in. This may not be a problem since every device now has two threads, so some other actions can occur asynchronously. However, a LONG sleep time (~60 seconds or more?) can cause Vera to reload spontaneously…
…of course, many other things seem to do this too, but it’s good to minimise this type of behaviour in the hope of achieving greater system stability.[/quote]
Thanks! Great answer
Could I pick your brain about something else, though?
I’m trying to read some parameters and they all come back as ‘-115’, but if I try to do something with them I get that hey’re nill values.
So you’re using the returns wrongly. You should see this if you try:
local err, msg, job, args = act (...)
and look at the content of the arg table.
However, it may also be that this particular device does not implement those actions (you could check with a [tt]/port_3480/data_request?id=lu_invoke&[/tt] call to Vera from a browser.)
In contrast to setting data, getting is far better (more efficiently) accomplished with a [tt]luup.variable_get()[/tt] call.
local ID = 597
local SID = {
power = “urn:upnp-org:serviceId:SwitchPower1”,
dimming = “urn:upnp-org:serviceId:Dimming1”,
}
local function power (act, var) luup.call_action(SID.power, act, var or {}, ID) end
local function dimming (act, var) luup.call_action(SID.dimming, act, var or {}, ID) end
).