jang

a = 1 b = 24 print(a << 8 | b) > 280

Ok, I have seen those errors too, despite the protective code. Maybe protect the net.HTTPClient():request(...) call too? and maybe the QuickApp:onInit().... ...just thinking out loud.

What is your QA doing? HTTP calls?

Normally I would tend to agree with you. (actually to be more philosophical, the problem is when people by-pass functions and rewrite what they are doing (example). Here we just wrap an existing function and honour the existing contract - we still call the original HTTPClient etc. The only problem is if the function goes away - but that is the same problem for the rest of your code). However, these functions have been around since the beginning and are essential for most QAs out there. I would really doubt that they are going to deprecate them. In fact, I argue that the patched functions now works as they should have in the first place. This is such an easy fix that Fibaro should have done it themselves when the HC3 came out. Instead there are 100s of posts in the forum by users that complains about QAs crashes without any error message, and blame the HC3... and Fibaro puts up with it... I don't understand how that company is run.... The easiest and cheapest customer support is to have good error messages... I see that I used fibaro.* instead of hub.* - but today they both point to the same function table - also here I doubt thet they would remove fibaro.* as too many QAs would stop working.

The idea with protecting json.encode/decode was to get an error line pointing to where json.encode was called from in user code, and not an error pointing deep into the json library - which is seldom helpful. setTimeout and setInterval will not log an error if the function crashes. This prints out the error.

Instead of do : end do local debug = true if debug then : end and set it to false when you found the bug

Forgot a 'copy' function in original post - added.

Remove your pcalls and add this as a separate file in your QA do local function perror(...) fibaro.error(__TAG,...) end function copy(obj) if type(obj) == 'table' then local res = {} for k,v in pairs(obj) do res[k] = copy(v) end return res else return obj end end local httpClient = net.HTTPClient -- protect success/error with pcall and print error function net.HTTPClient(args) local http = httpClient() return { request = function(_,url,opts) opts = copy(opts) local success,err = opts.success,opts.error if opts then opts.timeout = opts.timeout or args and args.timeout end if success then opts.success=function(res) local stat,r=pcall(success,res) if not stat then perror(r) end end end if err then opts.error=function(res) local stat,r=pcall(err,res) if not stat then perror(r) end end end return http:request(url,opts) end } end local settimeout, setinterval, encode, decode = -- gives us a better error messages setTimeout, setInterval, json.encode, json.decode function setTimeout(fun,ms) return settimeout(function() local stat,res = pcall(fun) if not stat then perror(res) end end,ms) end fibaro.setTimeout = function(ms,fun) return setTimeout(fun,ms) end function setInterval(fun,ms) return setinterval(function() local stat,res = pcall(fun) if not stat then perror(res) end end,ms) end fibaro.setInterval = function(ms,fun) return setInterval(fun,ms) end function json.decode(...) local stat,res = pcall(decode,...) if not stat then error(res,2) else return res end end function json.encode(...) local stat,res = pcall(encode,...) if not stat then error(res,2) else return res end end end do local function perror(...) fibaro.error(__TAG,...) end local httpClient = net.HTTPClient -- protect success/error with pcall and print error function net.HTTPClient(args) local http = httpClient() return { request = function(_,url,opts) opts = copy(opts) local success,err = opts.success,opts.error if opts then opts.timeout = opts.timeout or args and args.timeout end if success then opts.success=function(res) local stat,r=pcall(success,res) if not stat then perror(r) end end end if err then opts.error=function(res) local stat,r=pcall(err,res) if not stat then perror(r) end end end return http:request(url,opts) end } end local settimeout, setinterval, encode, decode = -- gives us a better error messages setTimeout, setInterval, json.encode, json.decode function setTimeout(fun,ms) return settimeout(function() local stat,res = pcall(fun) if not stat then perror(res) end end,ms) end fibaro.setTimeout = function(ms,fun) return setTimeout(fun,ms) end function setInterval(fun,ms) return setinterval(function() local stat,res = pcall(fun) if not stat then perror(res) end end,ms) end fibaro.setInterval = function(ms,fun) return setInterval(fun,ms) end function json.decode(...) local stat,res = pcall(decode,...) if not stat then error(res,2) else return res end end function json.encode(...) local stat,res = pcall(encode,...) if not stat then error(res,2) else return res end end end

1. hub.call(175, "updateView","label", "text", "Good day")

Sorry for this long post in English in a French forum. However, I don't trust Google to translate my non-native English into French ;-) Anyway, it's the 'beginner's questions' and we are discussing how to structure our programs. Week-end reading for everyone interested in writing their own rule system – or just structure programs in a more “declarative” way. condition_1 => action_1 condition_2 => action_2 : condition_n => action_n If you have this way of programming, you typically need to test your conditions in a loop that runs every x second local function loop() if condition_1 then action_1 end if condition_2 then action_2 end : if condition_n then action_n end setTimeout(loop,100*30) -- check every 30s end loop() Ex. In this case checking every 30s. This is the way standard GEA rules behaves. However, GEA has another model with the -1 trigger, that reacts directly on external events, like devices changing states etc., and then run the loop checking the rules. That way rules can respond immediately to ex. sensors being breached. We can add that immediate check too local function loop() if fibaro.getValue(88,'value')==true then fibaro.call(99,'turnOff') end if condition_2 then action_2 end : if condition_n then action_n end setTimeout(loop,100*30) -- check every 30s end loop() local function check_sensor() if fibaro.getValue(88,'value')==true then loop() end setTimeout(check_sensor,1000*1) -- check every second end check_sensor() We have a loop that runs every 30s and checks all our "rules". We have another function, check_sensor, that runs every second and if the sensor is breached it calls the main loop that checks all rules. The ‘loop’ function still carries out the action when the light is on. This gives us the flexibility to check everything every 30s but also to react immediately when a sensor is breached. We can improve this. Now we check the sensor in both loops (fibaro.getValue). We have already detected that the sensor was breached so we can tell the main loop what has happened. local function loop(event) if event=='sensor_88_breached' then fibaro.call(99,'turnOff') end if condition_2 then action_2 end : if condition_n then action_n end setTimeout(loop,100*30) -- check every 30s end loop() local function check_sensor() if fibaro.getValue(88,'value')==true then loop('sensor_88_breached') end setTimeout(check_sensor,1000*1) -- check every second end check_sensor() Let's make the check_sensor code be more generic and check more devices local function rule_checker(event) if event.type=='device' and event.id==88 and event.value==true then fibaro.call(99,'turnOff') end if condition_2 then action_2 end : if condition_n then action_n end setTimeout(function() rule_checker({type='loop'}) end,100*30) -- check every 30s end rule_checker({type='loop') local myDevices = { 88, 99, 101, 120, 444, 55, 6 } -- ID of devices to check local myDeviceValues = { } -- Starts empty but will store last values of our devices local function check_devices() for _,id in ipairs(myDevices) do local value = fibaro.getValue(id,'value') -- Fetch device value if myDeviceValues[id]~=value then -- Has the value changed? myDeviceValues[id]=value -- Remember new value rule_checker({type='device', id=id, value=value}) -- Call our rule checker with new value end end end setInterval(check_devices,1000*1) -- check devices every second First our 'loop' function is renamed to 'rule_checker' and takes one argument 'event' 'event' is a Lua table with at least a key that is 'type'. When rule_checker calls itself every 30s it sends the argument {type='loop'} to itself. This is to make sure that there is always an argument 'event' that we can check against. Our check_sensor has become check_devices, and checks multiple devices if they have changed state and then calls our check rules with an argument (event) that is of type 'device' with information what deviceId it was and what new value it has: {type='device', id=<id of device>, value=<new device value>} Now our rule checks if the type of event was 'device' and the id was 88, and in that case turns off device 99. Note that the rule will not act every 30s as it now requires the event type is 'device' - not 'loop' We could keep both rules if that would make sense. if event.type=='device' and event.id==88 and event.value==true then fibaro.call(99,'turnOff') end if event.type=='loop' and fibaro.getValue(88,'value')==true then fibaro.call(99,'turnOff') end The observant reader will have discovered a bug. Every time check_devices calls 'rule_checker' it will start a new loop as rule_checker ends with a call to itself (the 'setTimeout'). Well,that will be fixed in the next example. Now let’s make one more abstraction of this code. Sending the event to our rule_checker should be a function - 'post' local post -- Forward declaration... local function rule_checker(event) if event.type=='device' and event.id==88 and event.value==true then fibaro.call(99,'turnOff') end if condition_2 then action_2 end : if condition_n then action_n end end local myDevices = { 88, 99, 101, 120, 444, 55, 6 } -- ID of devices to check local myDeviceValues = { } -- Starts empty but will store last values of our devices local function check_devices() for _,id in ipairs(myDevices) do local value = fibaro.getValue(id,'value') -- Fetch device value if myDeviceValues[id]~=value then -- Has the value changed? myDeviceValues[id]=value -- Remember new value post({type='device', id=id, value=value}) -- Post event end end end function post(event) rule_checker(event) end -- Posting an event means calling check rules with event setInterval(check_devices,1000*1) -- Check devices every second setInterval(function() post({type='loop'}) end,1000*30) -- Post 'loop' event every 30s Instead of the rule_checker calling itself with setTimeout, we have a separate setInterval, "posting" the 'loop' event every 30s to the rule_checker function. The abstraction is a bit better, and we integrate periodic and immediate rule checks. The next steps is to abstract the rule_checker function. it's just checking a number of rules in sequential order. Let’s break that apart in 2 steps. local rules = { device = function(even) if event.id==88 and event.value==true then fibaro.call(99,'turnOff') end end, <type_2> = function(event) action_2 end, <type_n> = function(event) action_n end, end We make it a Lua table with the event type as key, associated to a function carrying out the action. Our 'post' function then becomes function post(event) if rules[event.type] then -- Do we have a rule for this type ? local action = rules[event.type] -- Then get the action -- action(event) -- ..and call it setTimeout(function() action(event) end,0) -- Lets call the action with setTimeout instead of calling it directly... end end We can also add rules to the table like this local rules = {} local function addRule(eventType,action) rules[eventType]=action end addRule('device', function(even) if event.id==88 and event.value==true then fibaro.call(99,'turnOff') end end) addRule('loop',function(event) action_2 end) There is a big problem with the approach to store rules using the event type as key. We can only have one rule for each key, because keys are unique in a Lua table (or we overwrite the old value) Instead of using the type as key we can just store them in an array and let post search for matching keys local function addRule(eventType,action) table.insert(rules,{type=eventType,action=action}) end function post(event) for _,rule in ipairs(rules) do if event.type==rule.type then setTimeout(function() rule.action(event) end,0) end end end This means that we can define rules like this addRule('device', function(even) if event.id==88 and event.value==true then fibaro.call(99,'turnOff') end end) addRule('device', function(even) if event.id==101 and event.value==true then fibaro.call(99,'turnOff') end end) addRule('loop',function(event) action_2 end) addRule('loop',function(event) action_n end) If we have a 'device' event, both rules will run, checking if it was 88 or 101 that was breached. A drawback with this is that we run both device rules even though we know that if one match the other will not. And we have to do the if event.id == .. test in both. We can do better. Our post functions now only look at the 'type' key of the event. Instead it could look at all fields in the event. local function addRule(event,action) table.insert(rules,{event=event,action=action}) end local function match(event1,event2) for key,value in ipairs(event1) if event2[key]~=value then return false end -- If a key in event1 is not the same as in event2, no match - return false end return true -- All keys matched, return true end function post(event) for _,rule in ipairs(rules) do if match(rule.event,event.type) then setTimeout(function() rule.action(event) end,0) end end end Now when we call addRule to add a rule we provide the whole event it should match for the action to be called. addRule({type='device',id=88, value=true}, function(even) fibaro.call(99,'turnOff') end) addRule({type='device',id=101, value=true}, function(even) fibaro.call(99,'turnOff') end) addRule({type='loop'},function(event) action_2 end) addRule({type='loop'},function(event) action_n end) The 'post' function may not be the most efficient as it needs to look through all the rules and see if they match. Don't worry about that now (we can make it much more efficient). Instead enjoy the abstraction :-) Let’s improve the 'post' function with one more feature. local function postEvent(event) for _,rule in ipairs(rules) do if match(rule.event,event.type) then rule.action(event) end end end function post(event,delay) return setTimeout(function() postEvent(event) end,1000*(delay or 0)) end 'post' can now delay the invocation of the matching rules. (If we don't specify a delay it becomes zero and is invoked immediately) Why is that a nice feature? local rules = {} local function addRule(event,action) table.insert(rules,{event=event,action=action}) end local function match(event1,event2) for key,value in ipairs(event1) if event2[key]~=value then return false end -- If a key in event1 is not the same as in event2, no match - return false end return true -- All keys matched end local function postEvent(event) for _,rule in ipairs(rules) do if match(rule.event,event.type) then rule.action(event) end end end function post(event,delay) return setTimeout(function() postEvent(event) end,1000*(delay or 0)) end addRule({type='device',id=88, value=true}, function(even) fibaro.call(99,'turnOff') end) addRule({type='device',id=101, value=true}, function(even) fibaro.call(99,'turnOff') end) addRule({type='start'},function(event) post({type='check_devices', interval=event.check_interval}) -- Start checking devices every second post({type='loop', interval=event.loop_interval}) -- Start period 'loop' end) addRule({type='loop'},function(event) -- 'loop' event respost then'loop' event to get a periodic loop post(event,event.interval) -- and we delay it with the interval value specified in the event end) addRule({type='loop'},function(event) -- Do something every interval print("Periodic check") end) local myDevices = { 88, 99, 101, 120, 444, 55, 6 } -- ID of devices to check local myDeviceValues = { } -- Starts empty but will store last values of our devices addRule({type='check_devices'},function(event) for _,id in ipairs(myDevices) do local value = fibaro.getValue(id,'value') -- Fetch device value if myDeviceValues[id]~=value then -- Has the value changed? myDeviceValues[id]=value -- Remember new value post({type='device', id=id, value=value}) -- Post event end end post(event,event.interval) -- Loop and check devices end) post({type='start', check_interval=1, loop_interval=30}) - Post 'start' event to get things going... (This is the "whole" system) It's cool, because we have a 'start' rule that invokes another rules ('loop' and 'check_devices') by posting events. The 'loop' rule then just reposts the event after a delay to create a periodic loop. Then we can have other rules that trigger on the 'loop' event and carries out some actions. We have abstracted away all setInterval's as "looping" is done with rules that repost events they trigger on (check_devices and loop). We also see, that events can carry “arguments”, like the interval value that the loops use to decide how much to delay their posts to themselves. So, this becomes a powerful abstraction model where our logic is expressed in rules and events, and where posting events connects our rules into a logic flow. Another classic example. Assume that we want a rule that turns on a light (99) if a sensor (88) is breached and then turns it off if the sensor has been safe for 60s. For this case we need one more function, ‘cancel’, that allow us to cancel an event posted in the future - in case we change our mind… local function cancel(timer) if timer~=nil then clearTimeout(timer) end -- cancel event, e.g. the setTimeout that will post the event return nil end addRule({type='device', id=88, value=true},function(event) timer=cancel(timer) -- Cancel timer, if there were a timer running fibaro.call(99,'turnOn') -- Turn on light end) addRule({type='device', id=88, value=false},function(event) timer = post({type='turnOff', id=99},60) -- Post event in 60s that will tuen off light end) addRule({type='turnOff'},function(event) timer=nil fibaro.call(event.id,'turnOn') -- Turn off light end) This takes care of the resting of the interval if the sensor is breached while the timer is counting down. ...This is my all-time favourite model how to structure my programs.... especially when they becomes large and the logic complex and there are several parallell things going on. (and it integrates well with other asynchronous functions like net.HTTPClient requests.)

I guess the reason is that as you define more and more conditions and actions it will stabilise over time and you will only focus on the rules e.g. local rules = { {condition=condition1,action=action1}, {condition=condition2,action=action2}, {condition=condition3,action=action3} } combining existing conditions and actions to new rules. You could have conditions that combine other conditions (AND). You could have conditions that watch if another conditions is true for a certain time. You could improve the "rule engine" to stop evaluating rules if an action returns the "break. You could add automatic logging etc. Of course you will end up with something like GEA at the end.... The point is that the abstraction allow you to focus on the problem - home automation rules - like, ex. GEA does. When the number of rules/conditions/actions are as small as in the example above the overhead may not be justified, but when you sit there with 100+ rules, you would like an abstraction that allows reuse of logic and an easy way to add features... So, I don't write all my code in this style - but dealing with large complex test logic is tempting to write a rule engine - done it many times. My other favourite is "event style" coding. Defining event handlers and posting events to drive execution between the handlers. It's really suitable in asynchronous logic (like home automation tends to be) and it integrates well my app logic with both the asynchronous net.HTTPClient:request(...) we have as well as the triggers from /refreshStates etc. Your code becomes like a state-machine, but a bit more flexible. Here is an old post from the HC2 days https://forum.fibaro.com/topic/25214-event-based-programming/ ...and it has improved a lot since then.

Updated TriggerQA to v1.21 Supported triggers {type='alarm', property='armed', id=<id>, value=<value>} {type='alarm', property='breached', id=<id>, value=<value>} {type='alarm', property='homeArmed', value=<value>} {type='alarm', property='homeBreached', value=<value>} {type='alarm', property='activated', id=<id>, seconds=<seconds>} {type='weather', property=<prop>, value=<value>, old=<value>} {type='global-variable', property=<name>, value=<value>, old=<value>} {type='quickvar', id=<id>, name=<name>, value=<value>; old=<old>} {type='device', id=<id>, property=<property>, value=<value>, old=<value>} {type='device', id=<id>, property='centralSceneEvent', value={keyId=<value>, keyAttribute=<value>}} {type='device', id=<id>, property='accessControlEvent', value=<value>} {type='profile', property='activeProfile', value=<value>, old=<value>} {type='custom-event', name=<name>} {type='deviceEvent', id=<id>, value='removed'} {type='deviceEvent', id=<id>, value='changedRoom'} {type='deviceEvent', id=<id>, value='created'} {type='deviceEvent', id=<id>, value='modified'} {type='sceneEvent', id=<id>, value='started'} {type='sceneEvent', id=<id>, value='finished'} {type='sceneEvent', id=<id<, value='instance', instance=<number>} {type='sceneEvent', id=<id>, value='removed'} {type='sceneEvent', id=<id>, value='modified'} {type='sceneEvent', id=<id>, value='created'} {type='onlineEvent', value=<boolean>} {type='room', id=<id>, value='created'} {type='room', id=<id>, value='removed'} {type='room', id=<id>, value='modified'} {type='section', id=<id>, value='created'} {type='section', id=<id>, value='removede'} {type='section', id=<id>, value='modified'} {type='location',id=<userid>,property=<locationid>,value=<geofenceaction>,timestamp=<number>} {type='ClimateZone',...} {type='ClimateZoneSetpoint',...} It also supports time/cron events Time subscription: {type='cron', time=<cronString>, tag=<string>} cron string format: "<min> <hour> <day> <month> <wday> <year>" min: 0-59 hour: 0-23 day: 1-31 month: 1-12 wday: 1-7 1=sunday year: YYYY Ex. "0 * * * * *" Every hour "0/15 * * * * *" Every 15 minutes "0,20 * * * * *" At even hour and 20min past "0 * * 1-3 * *" Every hour, January to March "0 7 lastw-last * 1 *" 7:00, every sunday in the last week of the month "sunset -10 lastw-last * 1 *" 10min before sunset every sunday in the last week of the month Ex. self:subscribeTrigger({type='cron', time="0/15 * * * * *", tag="Quarter"}) will send back a source trigger ever 15min in the format {type='cron', time="0/15 * * * * *", tag="Quarter"} 'tag' can be useful to match timers to actions... This gives more or less the same or more functionality than what you get from Scene conditions.

Try to install this QA TriggerQA.fqa v1.21 and then create another QA: function QuickApp:subscribeTrigger(event) local s = self:getVariable('TRIGGER_SUB') if s == nil or s == "" then s = {} end s[#s+1]=event self:setVariable('TRIGGER_SUB',s) end function QuickApp:sourceTrigger(tr) self:debug(json.encode(tr)) end function QuickApp:onInit() self:debug("onInit") self:subscribeTrigger({type='device'}) end This will call QuickApp: sourceTrigger with the trigger as soon as it happens. You can be more specific and do self:subscribeTrigger({type='device', id=88}) self:subscribeTrigger({type='device', id=99}) to only get triggers from deviceId 88 and 99 etc. Inside QuickApp: sourceTrigger you need to look at the trigger to see what trigger it is if you subscribe to different triggers. If you don't need super optimized trigger handling (then you run your own / refreshStates loop) then the TriggerQA is a simple helper that makes it easy for other QAs to receive sourceTrigger with very little overhead - similar to how scenes gets them - and it scales very well.

It's not the setTimeout - it's what you do inside the setTimeouts... Here I start 1 million setTimeouts in parallell. local t = os.time() for i=1,1000000 do -- Start a million setTimeouts fibaro.setTimeout(1,function() end) end fibaro.setTimeout(30,function() print("OK2") print(os.time()-t) end) The last setTimeout with 30ms timer will not be allowed to run until all the 1 million have completed (that's how we time it). It takes 41s on the HC3 [27.05.2021] [12:07:13] [DEBUG] [SCENE24]: OK2 [27.05.2021] [12:07:13] [DEBUG] [SCENE24]: 41 That's actually quite ok. The trick with polling for state changes is not to do it with a setTimeout loop doing fibaro.getValue. It's to do http:requests to the /refreshStates api as the http request will hang if there are no events and not consume any cpu during that time. When an event is available the http request will return immediately. Granted is that you will get all kinds of events and need an efficient way to filter for events that you look for (devices changing state or globals changing value) - but that is easy to do with a table lookup. I have a ready made library 'fibaroExtra.lua' that implements an event/sourceTrigger callback function that is as efficient as it gets.

So the example becomes local function condition1(self) return true end local function condition2(self) return math.random(1,3) > 1 end local function condition3(self) return false end local function action1(self) fibaro.call(...) end local function action2(self) fibaro.call(...) end local rules = { {condition=condition1,action=action1}, {condition=condition2,action=action2}, {condition=condition3,action=action2} } function mainCode(self) for _,r in ipairs(rules) do -- Test conditions and run actions if true if r.condition(self) then r.action(self) end end end with the "passing around self' style.