Jump to content
FIBARO Home Center App 1.0.0 - release Read more... ×
FIBARO Home Center App 1.0.0 - wydanie Read more... ×

Search the Community

Showing results for tags 'debugging'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • FIBARO Community
    • FIBARO Portal and Forum policy
    • FIBARO
    • Say hello!
    • Off-topics
  • FIBARO Update
    • FIBARO System Update
    • FIBARO Mobile Update
  • FIBARO Community Support
    • Scenes and Interface
    • FIBARO Products
    • FIBARO Mobile
    • FIBARO HomeKit
    • FIBARO Assistant Integrations
    • Other Devices / Third-party devices
    • Tutorials and Guides
    • Home Automation
    • Suggestions
  • FIBARO Społeczność
    • FIBARO
    • Przywitaj się!
    • Off-topic
  • FIBARO Aktualizacja
    • FIBARO System Aktualizacja
    • FIBARO Mobile Aktualizacja
  • FIBARO Wsparcie Społeczności
    • Sceny i Interfejs
    • FIBARO Urządzenia
    • FIBARO Mobilnie
    • FIBARO HomeKit
    • Integracja z Amazon Alexa i Google Home
    • Urządzenia Firm Trzecich
    • Poradniki
    • Automatyka Domowa
    • Sugestie

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Website URL





Found 3 results

  1. Here is an example of how to code in a "single instance / event" style. A style I'm using today for all of my scenes. The idea is that instead of having to deal with a new instance being spawned with every scene trigger, all triggers are dealt with from within a single scene instance that is continuously running. It becomes something close to a traditional event loop model found in most modern GUI frameworks. The advantages with coding scenes in this style are: Scene can keep state in local lua variables between scene invocations/triggers Easy to keep different rules/logic in the same scene without causing conflicts, e.g. combining continuous running loops/schedules with immediate reaction on incoming triggers Easy to distribute different rules/logic between different scenes and allow them to communicate Easy to schedule actions to do in the future - that can be easily cancelled if new information is gained. Because the scene is continuously running it doesn't matter if there is a heavy initialisation when the scene starts up (parsing HomeTables etc.) as it is only done once... The framework has extensive support to run and debug the scene offline on a PC/Mac to get things right before deploying the scene on the HC2. Offline it is easy to simulate trigger/events to understand if the logic is correct, something that is not always easy to detect in a asynchronous environment. It has proven to be easy to integrate with external event/msg based systems like Node-red, where scenes can both send and receive events to node-red and thus extend functionality with Alexa, Google home, Hue etc etc. The framework is available in two version, a 'light' version and a full blow version with a lot of bells and whistles. The latter also supports writing rules in EventScript, a "simple", but very flexible and efficient approach to writing rules that need to trigger things at various times of the day, or trigger on sensors or switches changing states. The implementation of EventScript is built on-top of the single instance framework and the event model and would have been impossible to do in a traditional scene model. Ex of EventScript rules. --[[ %% properties 55 value 66 value 77 value 78 sceneActivation 88 ui.Slider1.value 88 ui.Label1.value %% events 100 CentralSceneEvent 120 AccessControlEvent %% globals Home %% autostart --]] myLightSensor = 55 -- do not declare local, script will not find them(!) myLight1 = 66 myLight2 = 67 myDoorSensor = 77 mySwitch = 78 myVD=88 myKeyFob = 100 myLock = 120 function main() -- Trigger rukes Rule.eval("myLightSensor:lux > 200 => myLight1:on") -- Turn on light1 if lux value goes above 200 Rule.eval("myLight1:isOn => myLight2:on") -- Turn on light2 if light1 is turned on Rule.eval("myDoorSensor:breached => myLight1:on") -- Turn on light1 if door sensor is breached Rule.eval("mySwitch:scene == S2.click => myLight1:on") -- Turn on light1 if S2 is clicked once Rule.eval("slider(myVD,'Slider1') == 50 => myLight1:on") -- Turn on light1 if slider is set to 50 Rule.eval("label(myVD,'Label1') == 'ON' => myLight1:on") -- Turn on light1 if label is set to 'ON' Rule.eval("myKeyFob:central.keyId==4 => myLight1:on") -- Turn on light1 if key 4 is pressed on keyFob Rule.eval("myLock:access.status=='Unlock' => log('Door unlocked by %s',myLock:access.name)") -- Door unlocked Rule.eval("$Home == 'AWAY' => myLight1:on") -- Turn on light1 if fibaro global variable 'Home' is set to 'AWAY' Rule.eval("#AccessControlEvent{data={name='$name',slotId='$slot',status='Unlock',id=myLock}} => log('Door unlocked by %s',name)") lamp = 55 lamp2 = 56 lux = 57 lux2 = 58 sensor = 66 switch = 77 -- S2 switch keyfob = 88 -- more rules -- Turn on lamp at 15min before sunset Rule.eval("@sunset-00:15 => lamp:on") -- Turn off 2 lamps 15min past sunrise on weekdays Rule.eval("@sunrise+00:15 & wday('mon-fri') => {lamp,lamp2}:on") -- Turn on lamp if sensor breached Rule.eval("sensor:breached => lamp:on") -- Turn off lamp if sensor safe for 5min Rule.eval("for(00:05,sensor:safe) => lamp:off") -- Turn on lamp if doubleclick on switch S2 Rule.eval("switch:scene==S2.double => lamp:on") -- Toggle lamp if key '1' pressed on keyfob Rule.eval("keyfob:central.keyId=='1' => lamp:toggle") -- Turn on lamp if average lux is less than 200 Rule.eval("sum({lux,lux2}:lux)/2<200 => lamp:on") end More on EventScript and the full blown version is available in the posts listed below: Here is a post on setting up the framework (works for EventRunnerLite too) Here is a post on the EventRunnerLite version - a bare bone version of the framework Here is a post on writing schedulers using EventScript. Here is a post on writing trigger rules using EventScript. Here is a post on EventScript syntax and rules Here is a post on writing Lua event handlers Here is a post on debugging the framework Here is a post on enabling Hue support - mapping of Hue devices to standards z-wave/fibaro:* calls Here is a post on integrating the event model with Node-red - sending/receiving events from node-red, with extendable, example flow. Gives support for Sonos TTS and Alexa input... Here is a post on running and debugging standard HC2 scenes - using the EventRunner framework (SceneRunner) There will also be some services based on the EventFramework posted iOSLocator - a service that checks with iClod for people at places and sends events to other EventFramework services Logger service - TBD Alarm service - TBD CronRunner - a UNIX like crontab service other scenes can register call-backs with Supervisor - A scene that pings EventRunner scenes and makes sure they stay alive. Best practices rules - TBD Implementation notes Notes on the basic EventRunner framework Notes on the EventScript implementation - TBD ChangeLog for the EventRunner framework. The lastest version of the code is kept in my GitHub. The background of this framework and a thread discussing it can be found here, however the code has evolved a bit from when originally posted there.
  2. As I anounced already, I want to explore a simple main control scene. The main goal is to have as few scenes as possible that run continously ('autostart') to improve overview and avoid contradictions and racing conditions. Because it is meant as an exploration I will keep it very simple. At some time I will probably join either the @Sankotronic stream or the @jgab event model. They are far beyond my experience on this platform for this moment. And too complex for me as a beginner also. I already presented my time calculation model, based on integers from 0 to 2359, with two very simple functions to work with decimal hours (7+1.5 -> 830) and timesteps 759+5 -> 804. One thing I learned from the last month or so was "zwave freeze". Causes can be multiple, but one of them certainly may be poor programming practices. Therefore I want to fire fibaro calls at low speed and log them when needed. local testmode=true function deviceCall(deviceID,value1,value2) if (value2 == nil) then fibaro:call(deviceID,value1); log(fibaro:getName(deviceID)..': '..value1) else fibaro:call(deviceID,value1,value2); log(fibaro:getName(deviceID)..': '..value1..'='..value2) end fibaro:sleep(1000) end function switchOff(deviceID) deviceCall(deviceID, "turnOff"); end function log(AMessage) if testmode then fibaro:debug(AMessage) end end The deviceCall function can handle most of the commands at a beginners level anyway, so fine for now. A built-in sleep certifies a low pace. It checks testmode on the log funtion. Without testmode no logging.
  3. Hi All, Hope someone can answer my question: Does the use of debugging in scenes make things slower ? (to respond, the system, negative impact on resources, etc.....) I like debugging in scenes cause it tels me what a scene is doing Greetz..