jang

Running GEA 7.01 offline - easier to debug

plugin.restart()

sceneActivationEvent ? https://forum.fibaro.com/topic/49410-hc3-lua-sceneactivation/?do=findComment&comment=216519

Isn't that a sceneActivation device? - not a centralSceneEvent device...

...but from another QA you have a table... It's the marshalling of arguments that is broken - try this function QuickApp:test(arg) self:debug("Argument ",tostring(arg)," is a ",type(arg)) end function QuickApp:onInit() fibaro.call(self.id,"test","0042") fibaro.call(self.id,"test","true") fibaro.call(self.id,"test",'{"a":9}') end I complained in February about it...

self:deleteInterfaces({"light"}) or myQuickApp:deleteInterfaces({"light"})

self:createChildDevice always add "quickAppChild" for you. Some types of device will also add their specific interfaces.

self:createChildDevice({ name = <name>, type=<type>, initialProperties = .... initialInterfaces = ... }, <Class> )

I suspect a "bug" json.encode({42}) -> "[42]", an array with one item. json.encode({}) -> "{}", an empty key-value json table api.put /panels/sprinklers/ID expect days:<array>, an empty json array "[]" Somehow, a Lua array where you remove all items is still seen as an array by the "C" code that encode the Lua table. However, an empty table is default encoded as a key-value. The API type checks the argument against pre-defined schemas, and the 'days' value is found to be of the wrong type (not an array).

Yes, {<multiple value expression>} is a way to capture multiple return values in an array. string.byte returns 32 values in the example above. function foo() return 3,5,7 end local a = {foo()} print(a[2])

No, string.byte is not that efficient (compared to .sub) The difference I get is when I explode the string (with a single .byte call) and loop over the resulting byte array local s = {value: byte (1, n)} for i = 1, n do if s [i] == 49 then ...

Difficult. local function test2() for i=1,#value do if string.sub(value,i,i) == "1" then else end end end local function test5() local n = value:len() local s = {value:byte(1,n)} for i=1,n do if s[i] == 49 then else end end end test5 is 50% faster for me - but you have to deal with byte values. Is the data string you read always different? If not, cache seen data strings?

No problem. success() will be called immediately when the sensor event is available. It's just the the HTTP request is hanging until there are events available. If you have many event types a table like this can make sense - if you only have 2 it is not worth it. Events={ DevicePropertyUpdatedEvent = function(e) if e.data.property == 'quickAppVariables' then return end for _,id in ipairs({...}) do fibaro.call(id,"Function",e) end end, NotificationCreatedEvent = function(e) for _,id in ipairs({...}) do fibaro.call(id,"Function",e) end end, } if Events[e.type] then Events[e.type](e) end

Should be - setTimeout (Main, 50) - not setTimeout (Main(), 50) Anyway, it looks ok. My point was that sometimes the success() will not be called until there are events available. e.g. > 50ms. You could think about how to do the filtering effective with some kind of dispatch table....

api.get("/refreshState returns when there are events available - or times out after ~30s with empty events. So you will not always poll every 50ms. I always do http:request("http://127.0.0.1:11111/api/refreshStates?last=" .. lastRefresh... these days so I will not block other timers. (Ex. QA_Toolbox) You could have a master QA that push events to your other QAs. Pseudo code: QA.id=42 { subscribers = {43,44} while(true) events = get refreshState if events then for _,id in ipairs(subscribers) do fibaro.call(id,"NEW_EVENTS",events) end end end } QA.id=43 { function QuickApp:NEW_EVENTS(events) ... end } QA.is=44 { function QuickApp:NEW_EVENTS(events) ... end } You could add additional filtering to only send relevant events to each QA.