Discussion Forum to share and further the development of home control and automation, independent of platforms.

    SmartHome Community

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Unsolved
    (Last Updated: 16 September 2022)
    • Home Assistant add-on

      M

      I've done a bit of repackaging of MSR to make it work as an add-on under Home Assistant mostly for my own purposes but hopefully it makes it a bit easier to install and get going.

      GitHub - mrw298/hassio-reactor-addon GitHub - mrw298/hassio-reactor-addon

      Contribute to mrw298/hassio-reactor-addon development by creating an account on GitHub.

      Multi-System Reactor
    • Include Entity by Name in Dynamic Group Controller

      Pabla

      Trying to figure out how I can include a list of entities that have "battery_level" in their ID without having to manually include them in a list. I have a group which selects all entities with the battery_power capability and filters them if they are dead. In HA there are quite a few entities that have the battery_power capability but don't actually report a battery percent (see screenshot below for an example), the entities I am interested in are the ones that contain battery_level in their ID.

      I tried the following in the config file but it hasn't worked:

      "dead_battery": select: - include_capability: battery_power - include_entity: "/^hass>battery_level/"

      What I think I am doing wrong here is that I am including entities with the batter_level capability which doesn't actually exist.

      b50a2bfe-1779-4467-8b91-c078ff9404ef-image.png

      Multi-System Reactor
    • [Solved] MSR actions aren't running anymore-- can't find what's broken

      E

      Suddenly my MSR actions aren't running anymore. I've had this before, but with an update to a new version it was fixed. see also

      https://smarthome.community/topic/987/msr-actions-aren-t-running-anymore-can-t-find-what-s-broken/3?_=1674661492589

      But an update from version 22240 to 22256 gave this time no result.

      The reactions aren't running correctly. Most of my MSR automations are use turn lights on/off, and time based automations nothing worked where MSR does his magic.

      I've also tested a bunch of things to see what's broken, here's what I've observed:
      -I can successfully flip lights on/off manually within Vera
      -I can successfully flip lights on/off manually within MSR's Entities section
      -the sensors are correctly reporting to Vera and MSR (I can see when they're switch on/off)
      -the rules within MSR are working correctly, I can see when they flip to 'true' of 'false' '
      '
      But I cannot successfully run the "Set Reaction" and "Reset Reaction" within MSR (by hitting the 'play' button)
      But the play buttons on the entitiy action in the "Set Reaction" and in "Reset Reaction" they work well.

      Can someone help me to get MSR working again

      MSR is running bare metal on Rpi4

      Multi-System Reactor
    • Reactor (Multi-System/Multi-Hub) Announcements

      toggledbits

      Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.

      Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed.
      Multi-System Reactor
    • My MQTTController templates contribution

      Crille

      I've made a few templates for MQTTController, mostly Zigbee2MQTT, and sharing them to the community if anyone else would find use for them.

      GitHub - calmen77/MSR-mqtt_templates: MQTT templates for Multi-hub Reactor GitHub - calmen77/MSR-mqtt_templates: MQTT templates for Multi-hub Reactor

      MQTT templates for Multi-hub Reactor. Contribute to calmen77/MSR-mqtt_templates development by creating an account on GitHub.

      These are the ones I'm using but I'm happy to add more Zigbee2MQTT templates if needed.

      Happy Holidays!

      Multi-System Reactor
    • Ezlo Controller - Error Incompatible serialization data - api cloud Timeout

      N

      Hi,
      Connection to Ezlo is going in timeout with api-cloud.ezlo. This happens in anonymous_access set to false or in true.
      A lot of Error Incompatible serialization data (in the log I cut many more).
      In MSR controller status, Ezlo is in green icon but after sometime devices start to not respond.
      Can I have some help?

      Synology Nas - INTEL - DSM 7.1.1-42962 Update 3
      Ezlo Hub Model: h2.1 - v.2.0.35.2156.5
      Docker Container
      Reactor latest-23010-7dd2c9e9

      Thanks in advance

      [latest-23010]2023-01-20T18:11:08.069Z <app:null> Reactor build latest-23010-7dd2c9e9 starting on v16.15.1 [latest-23010]2023-01-20T18:11:08.071Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/x64 #42962 SMP Tue Oct 18 15:07:03 CST 2022; locale (undefined) [latest-23010]2023-01-20T18:11:08.071Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage [latest-23010]2023-01-20T18:11:08.071Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules [latest-23010]2023-01-20T18:11:08.085Z <app:INFO> Configured locale (undefined); selected locale(s) en-US.UTF-8 [latest-23010]2023-01-20T18:11:08.122Z <app:INFO> Loaded locale en-US [latest-23010]2023-01-20T18:11:08.128Z <Structure:null> Module Structure v22323 [latest-23010]2023-01-20T18:11:08.131Z <Capabilities:null> Module Capabilities v22356 [latest-23010]2023-01-20T18:11:08.166Z <Capabilities:NOTICE> System capabilities loaded from core distribution, data version 22356 revision 1 [latest-23010]2023-01-20T18:11:08.211Z <Plugin:null> Module Plugin v22300 [latest-23010]2023-01-20T18:11:08.238Z <TimerBroker:null> Module TimerBroker v22283 [latest-23010]2023-01-20T18:11:08.241Z <Entity:null> Module Entity v22353 [latest-23010]2023-01-20T18:11:08.247Z <Controller:null> Module Controller v22323 [latest-23010]2023-01-20T18:11:08.261Z <default:null> Module Ruleset v22293 [latest-23010]2023-01-20T18:11:08.262Z <default:null> Module Rulesets v22146 [latest-23010]2023-01-20T18:11:08.271Z <GlobalExpression:null> Module GlobalExpression v22146 [latest-23010]2023-01-20T18:11:08.296Z <Predicate:null> Module Predicate v22345 [latest-23010]2023-01-20T18:11:08.317Z <AlertManager:null> Module AlertManager v22283 [latest-23010]2023-01-20T18:11:08.322Z <Rule:null> Module Rule v22345 [latest-23010]2023-01-20T18:11:08.327Z <GlobalReaction:null> Module GlobalReaction v22324 [latest-23010]2023-01-20T18:11:08.329Z <Engine:null> Module Engine v23001 [latest-23010]2023-01-20T18:11:08.335Z <httpapi:null> Module httpapi v22347 [latest-23010]2023-01-20T18:11:08.400Z <wsapi:null> Module wsapi v22320 [latest-23010]2023-01-20T18:11:08.400Z <app:NOTICE> Starting Structure... [latest-23010]2023-01-20T18:11:08.460Z <InfluxFeed:null> Module InfluxFeed v22286 [latest-23010]2023-01-20T18:11:08.462Z <Structure:INFO> Structure#1 starting plugin influx (InfluxFeed) [latest-23010]2023-01-20T18:11:08.463Z <Structure:INFO> Structure#1 loading controller interface vera (VeraController) [latest-23010]2023-01-20T18:11:08.517Z <TaskQueue:null> Module TaskQueue 21351 [latest-23010]2023-01-20T18:11:08.518Z <VeraController:null> Module VeraController v22325 [latest-23010]2023-01-20T18:11:08.548Z <Structure:INFO> Structure#1 loading controller interface ezlo (EzloController) [latest-23010]2023-01-20T18:11:08.635Z <EzloController:null> Module EzloController v22344 [latest-23010]2023-01-20T18:11:08.867Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_613c8f94129e291209006add: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.868Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.869Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_613c9094129e291209006ae4: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.869Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.902Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_61437a57129e29124dfcd791: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.902Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.925Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_61437a58129e29124dfcd7a0: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.925Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.942Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_6198168b129e2918c5ce97bc: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.943Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.945Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_61981760129e2918c5ce97cb: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.945Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.945Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_61981770129e2918c5ce97d0: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.945Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.946Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_6198177e129e2918c5ce97d5: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.946Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.947Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_6198178b129e2918c5ce97da: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.947Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.947Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_6198179b129e2918c5ce97df: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.947Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.948Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_619817a6129e2918c5ce97e4: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.948Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:08.948Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_619817b2129e2918c5ce97e9: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:08.949Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.012Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_626d5d16129e291244463492: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.012Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.013Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_626d5d16129e291244463494: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.013Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.013Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_626d64d4129e2912444634a8: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.014Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.014Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_626d64d5129e2912444634af: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.014Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.015Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_626d64d5129e2912444634b2: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.015Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.039Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_629e6ec1129e2912b034351f: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.040Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.040Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_629e6ec2129e2912b0343529: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.040Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.041Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_629e6ec3129e2912b034352b: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.041Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.042Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_629e6ec3129e2912b034352d: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.042Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.043Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_629e6ec3129e2912b034352f: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.043Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.043Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_62a6d99a129e29123e7b0a8f: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.043Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.044Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity device_62a6d99b129e29123e7b0a9d: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.044Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.060Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity room_629687b6129e2912430f2de2: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.060Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Group.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.061Z <Controller:WARN> EzloController#ezlo failed (1) to restore entity room_62a66189129e29124345f791: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.061Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Group.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at EzloController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new EzloController (/opt/reactor/server/lib/EzloController.js:707:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.128Z <Structure:INFO> Structure#1 loading controller interface groups (DynamicGroupController) [latest-23010]2023-01-20T18:11:09.146Z <DynamicGroupController:null> Module DynamicGroupController v22313 [latest-23010]2023-01-20T18:11:09.178Z <Controller:WARN> DynamicGroupController#groups failed (1) to restore entity earthquake_entities: [Error] Incompatible serialization data; can't unserialize [-] [latest-23010]2023-01-20T18:11:09.178Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Group.unserialize (/opt/reactor/server/lib/Entity.js:452:19) at /opt/reactor/server/lib/Controller.js:794:70 at Array.forEach (<anonymous>) at DynamicGroupController._restoreEntities (/opt/reactor/server/lib/Controller.js:782:36) at new Controller (/opt/reactor/server/lib/Controller.js:395:43) at new DynamicGroupController (/opt/reactor/server/lib/DynamicGroupController.js:207:9) at /opt/reactor/server/lib/Controller.js:451:37 [latest-23010]2023-01-20T18:11:09.186Z <Structure:INFO> Structure#1 loading controller interface weather (OWMWeatherController) [latest-23010]2023-01-20T18:11:09.219Z <OWMWeatherController:null> Module OWMWeatherController v22294 [latest-23010]2023-01-20T18:11:09.222Z <Structure:INFO> Structure#1 loading controller interface reactor_system (SystemController) [latest-23010]2023-01-20T18:11:09.227Z <SystemController:null> Module SystemController v22306 [latest-23010]2023-01-20T18:11:09.231Z <Structure:INFO> Structure#1 loading controller interface virtual (VirtualEntityController) [latest-23010]2023-01-20T18:11:09.238Z <VirtualEntityController:null> Module VirtualEntityController v22325 [latest-23010]2023-01-20T18:11:09.348Z <Structure:INFO> Starting controller VeraController#vera [latest-23010]2023-01-20T18:11:09.348Z <VeraController:NOTICE> VeraController#vera starting... [latest-23010]2023-01-20T18:11:09.357Z <Controller:INFO> VeraController#vera loaded vera capabilities ver 22253 rev 1 format 1 [latest-23010]2023-01-20T18:11:09.394Z <Controller:INFO> VeraController#vera loaded implementation data ver 22345 rev 1 format 1 [latest-23010]2023-01-20T18:11:09.394Z <Structure:INFO> Starting controller EzloController#ezlo [latest-23010]2023-01-20T18:11:09.397Z <Controller:INFO> EzloController#ezlo loaded ezlo capabilities ver 22266 rev 1 format 1 [latest-23010]2023-01-20T18:11:09.408Z <Controller:INFO> EzloController#ezlo loaded implementation data ver 22344 rev 1 format 1 [latest-23010]2023-01-20T18:11:09.408Z <Structure:INFO> Starting controller DynamicGroupController#groups [latest-23010]2023-01-20T18:11:09.413Z <Controller:NOTICE> Controller DynamicGroupController#groups is now online. [latest-23010]2023-01-20T18:11:09.413Z <Structure:INFO> Starting controller OWMWeatherController#weather [latest-23010]2023-01-20T18:11:09.503Z <Structure:INFO> Starting controller SystemController#reactor_system [latest-23010]2023-01-20T18:11:09.506Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. [latest-23010]2023-01-20T18:11:09.537Z <Structure:INFO> Starting controller VirtualEntityController#virtual [latest-23010]2023-01-20T18:11:09.549Z <Controller:INFO> VirtualEntityController#virtual loaded virtualentity capabilities ver 22263 rev 2 format 1 [latest-23010]2023-01-20T18:11:09.550Z <Controller:INFO> VirtualEntityController#virtual loaded implementation data ver 22280 rev 1 format 1 [latest-23010]2023-01-20T18:11:09.556Z <VeraController:INFO> VeraController: deviceclass room capability sys_group does not provide attribute members [latest-23010]2023-01-20T18:11:09.556Z <VeraController:INFO> VeraController: deviceclass room capability sys_group does not provide attribute empty [latest-23010]2023-01-20T18:11:09.557Z <EzloController:INFO> EzloController#ezlo device mapping data loaded; checking... [latest-23010]2023-01-20T18:11:09.566Z <EzloController:INFO> EzloController#ezlo: connecting to hub "90000464" [latest-23010]2023-01-20T18:11:09.570Z <VirtualEntityController:INFO> VirtualEntityController#virtual configuring virtual .DefaultMode (vec01) [latest-23010]2023-01-20T18:11:09.571Z <VirtualEntityController:INFO> VirtualEntityController#virtual configuring virtual .GuestMode (vec02) [latest-23010]2023-01-20T18:11:09.571Z <VirtualEntityController:INFO> VirtualEntityController#virtual configuring virtual .PartyMode (vec03)
      Multi-System Reactor
    • MQTT log levels & log rotation

      tunnus

      Trying to set log level for MQTT to the lowest possible, is it in practise level 4? Also, would like to set maximum size and log rotation, but the following setup in logging.yaml did not work:

      MQTTController: level: 4 streams: - type: file maxsize: 2 keep: 2

      Using the latest build (23010).

      Multi-System Reactor
    • Help. Installing Reactor on Home Assistant.

      A

      Good afternoon. I want to connect Reactor to HA. HA is installed on Proxmox. Proxmox is installed on a Beelink U59 PRO mini PC. Studied the installation instructions ( https://reactor.toggledbits.com/docs/Installation / ) but I didn't understand how to do it (I'm a weak linux user). Help, give detailed instructions on how to install MSR.
      Reactor is a cool plugin, I use it on VeraPlus, but gradually I want to switch to HA.
      Thanks.

      Multi-System Reactor
    • Neural TTS with Sonos & Hubitat

      tunnus

      My migration from Vera to Hubitat is almost ready, only Sonos & Visonic (alarm system) remain on Vera. Hubitat has a Sonos integration, but it lacks neural voices for TTS so I've been looking for an alternative solution.

      @a-lurker hinted that there's a mqtt version for Sonos so I went that route and installed Docker containers for both sonos2mqtt and sonos-tts-polly. It turned out that I won't need mqtt for this at all, and I can utilize Hubitat's integration and just use the latter container for Polly.

      Did create a separate user on AWS only for TTS usage (there's an access right called "AmazonPollyReadOnlyAccess") and configured key, secret & cache in the container. Then I made the following test rule / reaction in MSR:

      Screenshot 2023-01-20 at 15.32.23.png Screenshot 2023-01-20 at 15.32.38.png

      So if anyone else has the same (or similar) setup, here's one way to achieve neural TTS with Sonos.

      Multi-System Reactor
    • Cheapest platform on which to run MSR

      T

      Please can anyone give me advice on a cheap way to run MSR (both initial cost and ongoing electricity cost). I currently run it on my QNAP network drive (which works very well incidentally). However, this draws a constant 35Watts (£90/yr @ 30p/kWh) and given the recent rise in fuel costs I am evaluating the best way forwards. Note, I only really need to turn my QNAP on for an hour a week to back-up my computer data. I understand that MSR can run on a Raspberry PI, but I am not competent with Linux! Thanks.

      Multi-System Reactor
    • [Resolved] Determining if button is pushed

      3

      MSR latest-23010-7dd2c9e9 in a Docker image
      HE C7 hub on 2.3.4.130

      I'm trying to determine how to sense that a button has actually been pushed. I added a ThirdReality button to my hub and the current states don't release or reset after a function has been done. I/E: when I push the button, it sets the "pushed" state to 1. Same for all the other functions, double tap, hold, release. Nothing ever goes back to 0 or cleared out.

      If I write my trigger as when "button.pushed" == 1, the current value is already one and the rule stays true all the time. What I'm after is when the button is pushed, the action will toggle the light I want to control.

      I feel like I am missing something or maybe the States of the button are the issue. I can use Rule Machine in my HE and it sees the button as pushed, or held. But I would prefer to have all my logic in MSR.

      And for some reason, I cannot post images. The server keeps giving me a parsing error.

      Multi-System Reactor
    • MSR support for openHAB?

      tunnus

      Could MSR at some point support openHAB as a controller?

      Multi-System Reactor
    • Admin user required for Home Assistant Controller status and reactions

      S

      Hi,

      Took me a while to realise the issue here. Just want to share to save others the time of trying to figure out what's wrong.

      Reactor (Multi-hub) stable-22337-1a0a685f Home Assistant 2022.11.5

      Home Assistant integration with non-admin user (access token) will caused the Home Assistant status in Reactor to show as down. Entity info from Home Assistant, however, is being updated. But Reactor is unable to execute any reactions.

      If the user is changed to an admin user in Home Assistant, the status is changed to up and reactions work.

      Multi-System Reactor
    • [Solved] ZWaveJSUI not responding to ZWaveJSController

      G

      I'm using ZWaveJSUI 1.4.2 within Home Assistant 2023.1.3. ZWaveJSController has been quite happy with it until I upgraded ZWaveJSController to 23010. This morning my iblinds weren't responding at all.

      As I'd made some changes to the rules I figured it was my work and returned it to original rules. No change (iblinds not responding.)

      Restarted MSR.
      Restarted ZWaveJSUI.
      No change.

      Rolled back ZWaveJSController to prior version 22323 and all is well again, iblinds responding.

      Thinking on this as I'm writing it and I realized there was a light on this morning that shouldn't have been. I now realize it's on the ZWaveJSUI as well and didn't turn off last night as the house went to sleep.

      I have the reactor.log if @toggledbits would like it.

      Multi-System Reactor
    • warning icons missing

      tunnus

      I've noticed lately (at least with build 22328) that in some cases these yellow warning / alert icons in front of rules are missing, although errors are otherwise visible:

      Screenshot 2022-11-29 at 22.33.16.png

      Screenshot 2022-11-29 at 22.31.15.png

      Multi-System Reactor
    • [MSR] reactor-espresense to track ESPresense BTLE devices/beacons

      therealdb

      My main objective was to track cars/motorcycles in real time, as they are leaving/entering the property, and I've experimented with different solutions, including WiFi devices, but I was not satisfied.

      So, I have approached ESPresense to track BLE devices. I'm not yet 100% satisfied with my main use case (we'll see), but I learnt a couple of things about proximity along the way, so I've built a controller to natively track beacons/devices in MSR. The devices and beacons could be tracked inside Home Assistant, but I don't like the way it's doing it, and I wanted a very device-oriented solution, instead of a room one.

      Introducing reactor-espresense.

      You'll have a device containing various info, like the current room where the beacon/device is currently in, the distance, and so on, for each BTLE device you'll choose to map. Configuration is needed to map your devices, and a look at the doc to understand how devices/beacons are detected away is suggested.

      I've not invested into commands so much, but it's on my TODO list.

      Feel free to post your requests/comments. Thanks!

      Multi-System Reactor
    • Reactor Ex Machina

      G

      @toggledbits was looking thru rule sets and updating which (new) lights I wanted REMII to impact and saw that this...

      4711b0df-5e98-4992-bb25-d0e53203f0e8-image.png

      ...is showing as (missing) in the rule Deactivatedand looking in the dropdown of Variables it appears I cannot select that local expression (only Global) as I did when originally building this out back in 2021.

      27f7025c-057e-441a-88ea-dc4bdf39614d-image.png

      In looking at the rule Active Period I'm seeing:
      487074ef-3bfa-4a84-b03d-ed6d920c118c-image.png which appears to be pointing to setting a variable in a rule?

      It's admittedly been a couple years since this was built and it's def not fresh in my memory.

      Multi-System Reactor
    • Reactor Start - System Crash/Restart

      T

      Hello All -
      I upgraded my OS to Ubuntu 20.04 today and have been regretting it for several hours. I have most of my system up. However, I've found that, when I start Reactor, it panics / reboots my OS. I've included the syslog during startup below. There's a benign message about not finding a Vera device just before the reboot but that's it.

      Needless to say, I've learned my lesson regarding OS upgrades.

      Bare metal Linux / Ubuntu 20.04 (Running inside VirtualBox)
      Reactor Version: stable-22337-1a0a685f

      Dec 30 19:33:46 homeauto03 systemd[1]: Started Multi System Reactor. Dec 30 19:33:46 homeauto03 weewx[6592] INFO weewx.restx: Wunderground-RF: Published record 2022-12-30 19:33:46 EST (1672446826) Dec 30 19:33:46 homeauto03 node[7240]: Reactor stable-22337-1a0a685f app 22328 configuration from /home/tbully/reactor/config Dec 30 19:33:46 homeauto03 node[7240]: NODE_PATH /home/tbully/reactor Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.745Z <app:null> Reactor build stable-22337-1a0a685f starting on v17.9.0 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.746Z <app:null> Process ID 7240 user/group 1000/1000; bare-metal; platform linux/x64 #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022; locale en_CA.UTF-8 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.746Z <app:null> Basedir /home/tbully/reactor; data in /home/tbully/reactor/storage Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.747Z <app:null> NODE_PATH=/home/tbully/reactor Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.764Z <Structure:null> Module Structure v22323 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.765Z <Capabilities:null> Module Capabilities v22283 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.819Z <Plugin:null> Module Plugin v22300 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.827Z <TimerBroker:null> Module TimerBroker v22283 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.831Z <Entity:null> Module Entity v22314 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.835Z <Controller:null> Module Controller v22323 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.847Z <default:null> Module Ruleset v22293 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.848Z <default:null> Module Rulesets v21096 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.854Z <GlobalExpression:null> Module GlobalExpression v21333 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.864Z <Predicate:null> Module Predicate v22305 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.867Z <AlertManager:null> Module AlertManager v22283 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.869Z <Rule:null> Module Rule v22335 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.872Z <GlobalReaction:null> Module GlobalReaction v22320 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.873Z <Engine:null> Module Engine v22320 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.877Z <httpapi:null> Module httpapi v22337 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.886Z <wsapi:null> Module wsapi v22320 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.949Z <TaskQueue:null> Module TaskQueue 21351 Dec 30 19:33:46 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:46.950Z <VeraController:null> Module VeraController v22325 Dec 30 19:33:47 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:47.200Z <HassController:null> Module HassController v22334 Dec 30 19:33:48 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:48.294Z <SystemController:null> Module SystemController v22306 Dec 30 19:33:48 homeauto03 weewx[6592] INFO weewx.restx: Wunderground-RF: Published record 2022-12-30 19:33:48 EST (1672446828) Dec 30 19:33:49 homeauto03 node[7240]: [stable-22337]2022-12-31T00:33:49.110Z <Rule:CRIT> ReferenceError: Can't find entity "vera>device_368" [-] Dec 30 19:33:49 homeauto03 node[7240]: ReferenceError: Can't find entity "vera>device_368" Dec 30 19:33:49 homeauto03 node[7240]: at Predicate._evaluateCondition (/home/tbully/reactor/server/lib/Predicate.js:366:27) Dec 30 19:33:49 homeauto03 node[7240]: at Predicate._evaluateGroup (/home/tbully/reactor/server/lib/Predicate.js:748:106) Dec 30 19:33:49 homeauto03 node[7240]: at Predicate._evaluateCondition (/home/tbully/reactor/server/lib/Predicate.js:354:47) Dec 30 19:33:49 homeauto03 node[7240]: at Predicate.evaluate (/home/tbully/reactor/server/lib/Predicate.js:60:37) Dec 30 19:33:49 homeauto03 node[7240]: at Rule._evaluate (/home/tbully/reactor/server/lib/Rule.js:875:54) Dec 30 19:33:49 homeauto03 node[7240]: at async /home/tbully/reactor/server/lib/Rule.js:830:17 Dec 30 19:33:49 homeauto03 systemd[1]: Stopping Session 14 of User tbully...
      Multi-System Reactor
    • [MSR] reactor-mqtt-contrib package for additional MQTT templates

      therealdb

      I'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).

      Anyway, here's my reactor-mqtt-contrib package:

      GitHub - dbochicchio/reactor-mqtt-contrib: Contrib MQTT templates for Reactor GitHub - dbochicchio/reactor-mqtt-contrib: Contrib MQTT templates for Reactor

      Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.

      Simply download yaml files (everything or just the ones you need) and you're good to go.

      I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.

      The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.

      Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests 🙂

      Multi-System Reactor
    For those who registered but didn't received the confirmation email, please send an email to support@smarthome.community with the email you used

    Approach to Rulesets, a philosophic question

    Multi-System Reactor
    7
    14
    289
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gwp1 last edited by gwp1

      Having just embarrassed myself to @toggledbits by asserting that the latest release somehow had a bug when in reality it was surfacing underlying issues with my approach to building out my rulesets and automations I wanted to ask the collective for their feedback on how they've designed their rulesets.

      For me, I built out a list of Global Reactions that I commonly use. For instance, for mode changes I typically change the mode entity and write that mode to a variable for some future use. When building out a ruleset I just pull in that Global Reaction vs manually recreating the entity list as my ruleset Reaction. Example, for lighting:

      270bbe18-9680-491d-81d4-20308a9fe63c-image.png

      Each of these contains the appropriate group of lights to turn on/off, etc.

      I also have what I've dubbed my "Armed for..." rulesets. These are rulesets that can be referenced as true or false in other rulesets. Example, for my various lighting configurations in and out of the house I have these:

      0d9f55d4-5d5d-42e2-a83c-8afa95df08fb-image.png

      I think this is resulting in reactions stomping on other reactions creating race conditions that result in things looking like they're working when, in reality, they're one restart away from disaster.

      So how are you all designing your superstructure, if you will, at a high level?

      Hubitat C-7 2.3.4.130
      Home Assistant 2023.1.7 running ZST10-700 fw 7.17.2
      MSR on RPi4 bare metal Model B 2GBs
      MSR latest-23028-ddc3fb14
      MQTTController-23010
      ZWave Controller-22323

      1 Reply Last reply Reply Quote 0
      • toggledbits
        toggledbits last edited by toggledbits

        I'm pretty much doing the same thing you are. Where these "Armed For" rules and the global reactions are used, I try to keep things as simple as possible. One trap I think people (myself included) get into is this notion that all actions have to done in one place for a specific event. For me, I like to spread the logic out in a lot of small rules, particularly because Reactor lets me enable and disable rules, so when rules are small and well-defined, if something is acting up during my implementation of some logic, I can turn a rule off (particularly if its causing problems for a device, like turning it on and off rapidly). It's easy for me to have a clear picture of conditions for each circumstance, as well.

        Another thing that arose of the other discussion is that Reactor (MSR) is highly concurrent, meaning it can do a lot of things at once. This is unlike R4V, where things were pretty much single-threaded by the constraints of the OS and its plugin framework. That means a rule reaction that starts a global reaction will cause the two reactions to run concurrently. If one reaction has to wait for an action to complete (i.e. hub to tell it the command was received), the other action runs. And in fact, it's also possible that the action(s) completed thus far can cause a rule to be triggered -- rule evaluation is also eligible to be started in the "idle" time. That introduces the possibility that a rule could run during an interstitial state of another rule's actions -- work isn't done, but another rule kicks in. I think this was part of your problem -- rules need to be very tightly defined in these circumstances to prevent mis-firing in the interstitial states when another rule's actions haven't yet finished. One way to do this is to put conditions in a group, and use a stabilizing delay ("sustained for" on the enclosing group), to ensure that not only are the rule's conditions met, but they've stayed met and other pending changes didn't exclude the rule during the delay.

        Example: I have a set of rules that when any primary kitchen light is turned on, the undercabinet and in-cabinet LEDs on MiLight controllers (secondary lights) are also turned on at 100%. When all kitchen lights are turned off, the LEDs are then turned off as well, unless it's Evening (defined by time in another rule set), where the undercabinet LEDs are set to 50%, and the in-cabinet LEDs are turned off. When Night is activated (we're all asleep), the LEDs are turned off, unless the house is in Guest Mode (a guest is spending the night) in which case the undercabinet LEDs on one side of the kitchen (the most-used/most-useful strip) go to 25%, and everything else is turned off (making an illuminated pathway to snacks and water if our guest gets up during the night). And when Party Mode is active, all automatic off actions are disabled (no "Last Call" effect that kills the party). And during Day mode, motion turns on the undercabinet LEDs for ambience. And of course, lack of motion in the kitchen for 10 minutes turns off all main lights (but not LEDs, and never in Party Mode). This is all a fairly intertwined set of requirements, but broken down it relies on mutually-exclusive states that are easy to test (Day vs Evening vs Night), overriding tests (Guest and Party modes), and transitive states (the conditions of the primary lighting devices). The transitive tests have stabilizing delays, because, for example, the rule and reaction that turns off the primary lights for lack of motion, if it occurs in the Evening, will turn off the LEDs and also trigger the rule and reaction that turns them on to 50%, and those two reactions will try to execute concurrently -- not good. Without the delay, I would very reliably get a mix of the undercabinet lights being on or off, rather than all on at 50%. But it's simple: the "Undercab Evening" rule just makes sure that all primary lights, as a group, have been off for a few seconds before it triggers and starts turning the LEDs on.

        That may seem a bit complex, but the set of rules is actually pretty simple (I think). Here's how I've structured all that (typed-out since screen shots would be horribly large and long):

        • Rule Any Key Light On is an OR group that is true when any of the three primary lights is on: sink, island, and main. This is an "Armed For" rule in your parlance (i.e. it has no reactions/actions of its own; its state is used by other rules).
        • Rule Kitchen Recent Motion is true when (triggers) the motion sensor trips; delay reset for 300 seconds. This is another rule that is only used by other rules, it doesn't have any reactions.
        • There are "global" rules for Day, Night and Evening periods as mutually-exclusive modes, and Guest Mode and Party Mode (just virtual switches).
        • Rule Undercab Follower - On turns on the LEDs to 100% when Any Key Light On is true. Just that simple.
        • Rule Undercab Follower - Off turns off the LEDs when Any Key Light On is false for a sustained two seconds.
        • Rule Motionless Kitchen Off turns off all primary lights and LED strips when (triggers) there has been no motion for ten minutes (Kitchen Recent Motion is false sustained for 600 seconds) and Party Mode is false, and (constraints) when Any Key Light On is true on OR the always-used undercabinet LED strip is on.
        • Rule Undercab Day Default turns on the undercabinet LEDs (not in-cabinet) when (triggers) it's Day and Kitchen Recent Motion is true, and (constraints) Any Key Light On is false (no primary lights are on);
        • Rule Undercab Evening Default turns on the undercabinet and in-cabinet LEDs at 50% when (triggers) it's Evening and Any Key Light On has been false for at least 10 seconds (sustained for delay), and the always-used LED strip is not on.
        • Rule Undercab Normal Night turns off the LEDs when (triggers) Night is true and Party Mode is false and Guest Mode is false and Any Key Light On is false.
        • Rule Guest Mode Night (should be called Undercab Guest Night for consistency, I suppose) turns on the always-used LED strip at 25%, all others off, when (triggers) Night is true and Guest Mode is true and the always-used LED strip has been off for at least 10 seconds.

        Notice, for example, that I didn't make the effort to make a monolithic rule for Motionless Kitchen Off that figures out if it's Day, Evening, or Night, and if Party Mode or Guest Mode were in effect, and set the LEDs accordingly. Rather, MKO just turns the lights off, and the other rules turn things back on after a small delay. This serves two masters: it keeps the complexity low, and it allows recovery from a manual operation (i.e. all the lights are turned off manually rather than by the rule) without the need for an additional rule to detect and act on that manual change. Sure, it's a little "flashy" (LEDs turn off, then may come back on shortly after, rather than just going directly to the new terminal state), but it's also very easy to understand and maintain, and spouse-approved. I have no love or desire for any more complexity than is required by my own sensibilities and the WAF. Anyway, I think a lot of people get bogged down thinking they have to handle everything on one condition (i.e. when the lights are turned off, I need to implement every possible terminal state right there in the rule where that's detected), and that's not the case. I was also able to develop these rules incrementally and without the complexity going non-linear with every new requirement I added.

        In computing we would say Reactor's rules and reactions are not "atomic." Atomic, in the computing sense, generally means an indivisible part — an operation that will be done without interruption. Rules and reactions in MSR aren't atomic. A reaction does not take over the CPU and run until the reaction is done. The reaction may give up the CPU at any step to allow other things to happen, as I said. This can affect how you write conditions for rules, particularly when the conditions involve devices you are modifying in the rule's reactions. For example, if you have two devices A and B that are always in opposite states by your requirements (A-on/B-off or A-off/B-on), and you use two reactions to set them to one state or another, there is always a period where they are in an interstitial state, where one has been modified and the other is about to be, therefore both are on or both are off. It is in the space between those two actions that things can go wrong. If you think in your mind that A and B are always opposite and therefore it's safe in a rule to just test A's state alone before launching into some other action(s), that rule may trigger in that interstitial state and cause who-knows-what problem, perhaps even something disastrous. The key here is don't assume the computer works the way your brain wants to think about it. Even though you may think A and B are always in opposite states, make sure your rules enforce that expectation as well -- both devices tested for their expected state.

        Also, leave yourself a lot of comments in your rules and reactions, and if there are special conditions or actions, make sure to mention them. I think a lot of missteps occur when, for example, a reaction is written for a rule that only executes the reaction at night. Six months later, you have some need to do a similar thing during the day, so you decide to invoke that reaction to do your day work as well, but it does something else that you don't want, maybe something subtle that you don't notice right away, and a week or more later you start noticing and wondering why the landscape lights are on in the middle of the day. At that point, you've forgotten that you've re-used that reaction, and you've long-since forgotten that that reaction also turns on the landscape lights. Leave comments, and when reusing a rule or reaction, look at it and review what it does. Oh, and in this case, remember that the logs are your friend. Pretty much all device actions are logged at this point, so it's easy to spot the sequence of events leading up to a device being manipulated.

        One thing I can do to make things a little easier with regard to the concurrency is give you the option of making reactions started from other reactions wait for completion. That's already in the Engine, it's just not exposed in the UI. That would keep a single reaction from lighting off too many concurrent reactions; it would not, however, eliminate the possibility of other rules evaluating while those reactions are in mid-stride. That's a completely different problem (and for the moment, best handled with those "sustained for" delays). But I'll make sure the wait option is in the next release.

        Sorry for the firehose/text wall...

        Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

        G wmarcolin 2 Replies Last reply Reply Quote 4
        • G
          gwp1 @toggledbits last edited by

          @toggledbits This. This is exactly the response I was hoping to evoke from not just yourself but others who have been using the system for a while now.

          What works for you?
          What would you do differently?
          What was a horribly wrong path?

          Your lighting example makes me think of my living room curtain and the TV. I prefer the curtain to be open during the day because of the view, but once it's dark outside and the lights are on inside then I'm the view lol

          So, at sunset I want the curtain to close halfway. Once the TV goes on, close all the way down to the cat door (still allowing him access to his precious screened room.) But what if I was already watching TV before sunset. I still wanted the curtain open since it was daylight out but now I want it to close all the way down to the cat door at sunset. But once the TV goes off I don't want the curtain opening back up again.

          And what about that blind to the right of the TV - the one that allows the neighbors to look right in as you watch TV? Nice people but I still don't need them watching ME watching TV. So the blinds get tilted whilst the TV is on... but it's after sunset... I could go on but you get the idea.

          Hubitat C-7 2.3.4.130
          Home Assistant 2023.1.7 running ZST10-700 fw 7.17.2
          MSR on RPi4 bare metal Model B 2GBs
          MSR latest-23028-ddc3fb14
          MQTTController-23010
          ZWave Controller-22323

          1 Reply Last reply Reply Quote 0
          • therealdb
            therealdb last edited by

            I have a similar approach (smaller rules, global reactions with groups and lots of comments). But I used a very complex one (dozen of triggers and constraints) on a couple of other situations, that I regret now.

            I over complicated things because I was porting code, but when I have free time (an exceedingly rare event nowadays), I'll try to break them. I usually write simpler rulesets to get the state, and a reaction to execute the logic, that's invoked by other reactions (or even MQTT, as I documented previously). What attracted me to a single ruleset was the ability to write local variables (I use them a lot, being a programmer at heart), but you'll end up pretty soon with conflicting logic and problems in debugging the state.

            What convinced me to move my logic to MSR was the multi-threading capabilities, because I'm mixing lot of things together and I'm comfortable with multiple actions/rulesets being execute simultaneous, but I agree it's tricky if you're not used to concurrency. I agree virtual switches are the best help and I hope to see native virtual devices in MSR soon.

            --
            On a mission to automate everything.

            My MS Reactor contrib
            My Luup Plug-ins

            toggledbits 1 Reply Last reply Reply Quote 1
            • LibraSun
              LibraSun last edited by

              I wanna answer your question so badly, but fear my input at this juncture would be invalid since I no longer have a use-case for MSR. Oh, it's still running 24/7 in a Docker container over on my Synology NAS... but once I finalized the transition from Vera over to Hubitat (THANK YOU 1000x @toggledbits !), and ported all my my old logic into my new C7 hub, my "fiddling" days abruptly ended.

              Do I still have Rulesets in place (but disabled) on MSR Reactor (Multi-hub) latest-21307-1746e27? Yep. Are the Rules they contain worth mentioning, since 49% involved Vera and 49% were extremely/overly experimental in nature, with 2% marked for "Testing"? Nope.

              And did I ever try to Register another username on the old long-forgotten ezlo Forum after being excommunicated 4x? AW HELL NAW!

              But I will mention that MSR comes to mind periodically, such as earlier today, when I realized Hubitat lacks a native way to generate and send email messages to its users. And at other times when I delve into heavyweight plug-ins (the HE community calls them User Apps) like WebCore, I think to myself, "Hot damn, this would be waaaay easier to accomplish over in MSR."

              Mostly, I'm posting this reply just to SAY HI TO THE GANG, whom I miss, and to let you guys know that all of the time (Vera tweaking) and headaches (ezlo PTSD) I've spared myself over the past year was invested in buying and riding a new electric bike (the Priority Current with Enviolo CVT), so now I know what the outdoors looks like.

              PEACE and lemme know if my answer here raised more questions.

              • Libra
              G Pabla 2 Replies Last reply Reply Quote 4
              • G
                gwp1 @LibraSun last edited by

                @librasun Always a pleasure to see you!

                Hubitat C-7 2.3.4.130
                Home Assistant 2023.1.7 running ZST10-700 fw 7.17.2
                MSR on RPi4 bare metal Model B 2GBs
                MSR latest-23028-ddc3fb14
                MQTTController-23010
                ZWave Controller-22323

                1 Reply Last reply Reply Quote 1
                • toggledbits
                  toggledbits last edited by

                  Hear hear. Always good to "see" you, @LibraSun

                  Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                  1 Reply Last reply Reply Quote 1
                  • Pabla
                    Pabla @LibraSun last edited by

                    @librasun always nice seeing you here Libra!

                    1 Reply Last reply Reply Quote 0
                    • wmarcolin
                      wmarcolin @toggledbits last edited by

                      @toggledbits said in Approach to Rulesets, a philosophic question:

                      spouse-approved

                      It is the best comment 🙂

                      1 Reply Last reply Reply Quote 0
                      • wmarcolin
                        wmarcolin last edited by

                        I think there should be almost a unanimity to build small Reactions that are triggered by Rules, great practice for maintenance, and repetition of tasks.

                        What I've been doing is using delay in the calls when I want to have a sequencing of execution, i.e., in @toggledbits 's example of A and B being opposite, I know that there will be the interval of the two being equal, but managing the delay, I try to have greater control of the execution.

                        Another reason to use delay in the shots is as I have already reported in other posts, I see that shooting many simultaneous actions, generates failures, and some devices are not being triggered. Again @toggledbits intervened and improved a lot the communication between MSR and HE, but I ended up keeping the delay to a few seconds that I control in Rule.

                        What works for you? Use of delay to control the sequence;
                        What would you do differently? I think the path is very similar for everyone, I follow most of the simplification and many small rules;
                        What was a horribly wrong path? In my case, not having execution control on simultaneous executions.

                        1 Reply Last reply Reply Quote 1
                        • tunnus
                          tunnus last edited by

                          A short summary of my rulesets; first of all I'm using quite many rulesets (e.g. "lights outside", "lights inside", "sonos alerts", "statistics & alerts") that themselves contain a lot of rules ("statistics & alerts" contain 47 rules, that mainly send telegram messages when certain event happens). But one aspect of MSR that I haven't quite figured out yet is the use of global reactions. I have none of those.

                          Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Openhab, migrating from VeraPlus to Hubitat C-7

                          G 1 Reply Last reply Reply Quote 1
                          • G
                            gwp1 @tunnus last edited by

                            @tunnus I use global reactions in situations wherein, for instance, I'm triggering the color-changing smart lights I have for landscape lighting. I've created global reactions for each light and each color I typically use. The global reaction contains four different settings (which would be a pita to add to five lights) that make up each color. I then just call that global reaction when I need that color at a specific light.

                            Hubitat C-7 2.3.4.130
                            Home Assistant 2023.1.7 running ZST10-700 fw 7.17.2
                            MSR on RPi4 bare metal Model B 2GBs
                            MSR latest-23028-ddc3fb14
                            MQTTController-23010
                            ZWave Controller-22323

                            1 Reply Last reply Reply Quote 1
                            • toggledbits
                              toggledbits @therealdb last edited by

                              @therealdb said in Approach to Rulesets, a philosophic question:

                              I agree virtual switches are the best help and I hope to see native virtual devices in MSR soon.

                              You've now got your wish (22258)!

                              Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                              therealdb 1 Reply Last reply Reply Quote 2
                              • therealdb
                                therealdb @toggledbits last edited by

                                @toggledbits I’ll try them soon. I’m quite busy at work, but I hope to remove a couple of virtual devices from my Vera and move ha bridge and my dashboard to native MSR http commands. Thanks for the addition!

                                --
                                On a mission to automate everything.

                                My MS Reactor contrib
                                My Luup Plug-ins

                                1 Reply Last reply Reply Quote 2
                                • First post
                                  Last post

                                Welcome. If you’d like to participate in the discussion, rather than just read, then you can join the forum. As a member, you can interact with others here to share your experience and ask the questions you need answered.

                                Powered by NodeBB | Contributors
                                Hosted freely by PointPub Media Communications Inc. | Contact us