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: 29 November 2021)
    • 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

    [SOLVED] How do I: delay a notification to fire only if the ruleset actually fires

    Multi-System Reactor
    reactions delays
    4
    17
    229
    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

      Use case: Honeywell API gets easily flustered resulting in either one or both of my t-stats not receiving the change command/s. As such, I've written some "course correction" rulesets that basically look at the present situation and, if not matching what should be there, resends the command.

      Now... logic says if the first send didn't get thru then APIs generally aren't going to like another one right on it's heels. To combat this, I've added a Restriction to the correction ruleset that says the status must exist for 420 seconds before it will fire. This (hopefully) also prevents a race state when the real rule set AND the correction spring into action at the same time.

      I set a notification reaction to let me know a course correction had to be implemented but I've noticed that it fires even if the Restriction on the actual reaction never completes (is found unnecessary) and, as such, the correction ruleset never actually needs to fire.

      The ask: can a notification be tied to fire ONLY if/when the action actually fires?

      Hopefully that is clearer than mud.

      Solved here https://smarthome.community/post/10319.

      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
      • LibraSun
        LibraSun last edited by

        I guess the simplest reply would be, "Why not just place your Notification step inside the Set Reaction portion of your 'Correction' rule?" I can't think of a more succinct way to ensure that it runs if (and only when) the 'Correction' rule fires Or am I missing something?

        I do realize my simplistic response side-steps your underlying question of "Why isn't Restriction X stopping Rule Y from proceeding?"

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

          @librasun That's where it lives. It's also the second action under the action to reset the stats. Yet what happens is, whilst the seven minutes is in progress and the action to reset the stats is waiting for a go command, the notification fires.

          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

            @gwp1 I feel like a grade school teacher having to write this, but... show your work.

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

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

              @toggledbits "But Mr. Kedron, I did it in my head!"

              Screen Shot 2021-11-05 at 8.49.52 AM.png

              Screen Shot 2021-11-05 at 8.50.08 AM.png

              Screen Shot 2021-11-05 at 8.50.24 AM.png

              Screen Shot 2021-11-05 at 8.50.45 AM.png

              Screen Shot 2021-11-05 at 8.51.45 AM.png

              Concept is: other heating ruleset issues commands to Honeywell API to set heat at 68 upstairs, 65 downstairs. Sometimes this is ignored. As such, 'cause things happen, this ruleset essentially looks for the correct criteria to be UNMATCHED and, after waiting seven minutes, fires off the same command to Honeywell as well as notifying me.

              The seven minutes is to:

              • prevent a double hit on an API that already fumbled the first one

              • if, for some reason, the status change is just late and the original command was accepted then the Triggers here will go unmatched and this ruleset ultimately expires without needing to fire

              And yes, I do lie awake at night thinking up these convoluted scenarios because "food is a crutch, sleep is for wimps."

              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

                I'm not seeing a delay in your reaction. If there's no delay in your reaction, there won't be a delay between the actions. What am I missing?

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

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

                  @toggledbits I had a delay in it originally and all that did was delay the notification even if the ruleset ended up not ultimately firing because conditions changed and the Set Reaction didn't need to be fired - ie, I still got the notification (albeit delayed) even if the ruleset was aborted because the Triggers no longer applied.

                  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

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

                    @gwp1 said in How do I: delay a notification to fire only if the ruleset actually fires:

                    even if the ruleset was aborted because the Triggers no longer applied.

                    That is correct behavior. You can get the reaction to stop if the rule resets by supplying a Reset Reaction. If the Reset Reaction is not empty, Reactor will abort the running Set Reaction. It can even contain just a comment (so not actually do anything); as long as it's not empty, Reactor will abort the delay and everything that follows it.

                    Documentation: Reaction Delays

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

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

                      @toggledbits said in How do I: delay a notification to fire only if the ruleset actually fires:

                      You can get the reaction to stop if the rule resets by supplying a Reset Reaction. If the Reset Reaction is not empty, Reactor will abort the running Set Reaction. It can even contain just a comment (so not actually do anything); as long as it's not empty, Reactor will abort the delay and everything that follows it.

                      Wow, I never would have considered that, not in a million years. Thanks, Teach!

                      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

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

                        @gwp1 said in How do I: delay a notification to fire only if the ruleset actually fires:

                        Wow, I never would have considered that, not in a million years.

                        Well, there's a place you can go (and it's not here) that will tell you this and many similar secrets... 😉

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

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

                          @toggledbits I certainly hope you aren't pointing to the MANUAL! Next thing, you'll want me asking directions before embarking on an excursion from the house!

                          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
                          • G
                            gwp1 @toggledbits last edited by

                            @toggledbits said in [SOLVED] How do I: delay a notification to fire only if the ruleset actually fires:

                            You can get the reaction to stop if the rule resets by supplying a Reset Reaction. If the Reset Reaction is not empty, Reactor will abort the running Set Reaction. It can even contain just a comment (so not actually do anything); as long as it's not empty, Reactor will abort the delay and everything that follows it.

                            Documentation: Reaction Delays

                            This functionality has stopped working as of build 21331 (and the subsequent 21332) from my observations.

                            Screen Shot 2021-11-28 at 9.17.29 PM.png

                            Screen Shot 2021-11-28 at 9.17.50 PM.png

                            (Yes, I literally c/p'd your explanation into the Comment field so I'd know why I created that particular Reset Reaction.) The current behaviour is how one would expect it to respond if the Reset Reaction were empty. I don't have logs pulled yet, sleep for work tomorrow beckons but I wanted to put it on the proverbial radar. If this should be reported in Mantis I'm happy to do so, just may be a couple days what with Giving Tuesday this week.

                            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

                              I have a pretty short and definitive test for this, and it's working as expected. There have been no code changes in this area, so I'd be surprised to see a change in behavior.

                              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 0
                              • A
                                Alan_F last edited by

                                I've re-read this thread a few times and still am confused by the whole thing. If I understand the images of the rule set, the notification should not be sent because this entire rule set doesn't become true unless one of the conditions is sustained for 420 seconds. That notification should never fire earlier than 420 seconds after one of the Thermostat.Setpoint <> XX is first detected. There is no issue of stopping a running rule set. This rule set isn't supposed to run unless the error state is sustained for 420 seconds. I have several rule sets that work just like this, and they work as expected. Nothing happens if the mis-matched conditions are corrected before the 'sustained for' time expires.

                                Light bulb moment: I think I just figured why this may be firing the notification when you don't want it to.

                                Existing conditions:
                                Downstairs set point is 62. it has been set to 62 for more than 420 seconds.
                                Downstairs mode is set to heat.
                                Armed for heating master rule set is true
                                House mode switches from 'away' to 'home'.

                                This rule set will fire immediately.

                                This would also occur if the Armed for heating master rule set changed to true, or if the downstairs thermostat mode changed to heat. As long as the thermostat has been set to something other than 65 or 68 for 420 seconds prior to those other conditions coming true, the 'delay' (really 'sustained for') is already met.

                                This either needs to be wrapped in an outer group with a 'sustained for 420 seconds' on the whole thing, or the house mode, armed for heating master, and thermostat mode conditions also need to be set to only go true when they are sustained for 420 seconds.

                                I'm not sure I understand your use case, but if it's possible for the set point to be other than 65/68 and one of those other conditions to then change, this could definitely be double-running your HVAC - Heating Day reaction. If, for example, you have a reduced set point when you're in away mode (or at night), and the HVAC - Heating Day reaction is supposed to fire when you come home (or switch to day mode), then this rule will fire at the same time, assuming you've been away more than 420 seconds (or in night mode more than 420 seconds) with the set points turned down.

                                If this really does involve an already-running reaction that needs to be stopped by a reset reaction, then I'm completely misunderstanding how the rules in the images you posted work.

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

                                  @alan_f The goal here is, for those times when Honeywell flakes on accepting the API post to change temps, this will monitor that and, if the expected setpoints aren't met for the specified conditions (ie, Heating at Home, Heating Away, etc.) then it will resend the commands to Honeywell. The reason for the 420 second delay is to allow the Honeywell API to "compose itself" since it's easily overrun and sending the course correction immediately will presumably result in no correction happening.

                                  @toggledbits I'm at a bit of a loss, then. Nothing was touched with this ruleset since I added the Reset Reaction and it resolved this issue originally. What is the test you have for this and can I use it to spin up a temp rule and validate locally?

                                  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 think there's a misunderstanding here, and you need to review your logic and the state of devices in the detail panel for the rule, which shows the status of the condition targets and each condition as well as the running timers (when running).

                                    A Reset reaction can only stop a running Set reaction. There is no delay in your Set reaction, so your Set reaction will run instantly and completely when the trigger conditions are met. There is no opportunity here, based on what I see from what is posted earlier, for the Reset reaction to intervene. That whole issue is moot as it applies to the rule and reaction shown.

                                    The sustained for delay is self-cancelling. When the related condition is no longer met (i.e. result is false), the timer is cancelled. If this rule is setting, it is doing so because one of the two conditions is being met. A review of the detail panel and status will show this.

                                    I"m getting the idea that you are not looking at the detail panel. Go look at it. Post it if the results aren't what you expect.

                                    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 0
                                    • A
                                      Alan_F last edited by Alan_F

                                      @gwp1 I think I correctly understood the use case then. The issue is that your rule set doesn't start counting the 420 seconds when the initial command is sent to the Honeywell API. The 420 seconds starts counting as soon as the setpoint is <> 65 (or 68). If you ever have the thermostats set to another value (when away, or night, or when not in heat mode) then the 'sustained for' will start counting and as soon as 420 seconds have passed, that element of the rule will go to true. You'll see it is green in the detail panel if you expand the rule set.

                                      The thing I'm not clear on, but am making some assumptions about, is what triggers the initial call to the Honeywell API that this rule is designed to monitor/verify. Making the assumption that you turn down the thermostat at night with something like "HVAC - Heating NIGHT", and that heating is still armed and the thermostat mode is still set to heat at night, then 420 seconds after you go into night mode, every element of this rule set will be true except the Hubitat house mode rule. The rule set is primed to activate if that goes true.

                                      So at night:

                                      • Armed for heating is true
                                      • (7 minutes after you enter night mode) Set point has been at some other value for more than 420 seconds
                                      • Thermostat mode is set to heat
                                      • But the rule set is NOT activated because the "AND house mode not in (night, vacation, away)" is not true

                                      In the morning when the Hubitat mode switches from "night" to "day", this rule will go true immediately as all elements are now true.

                                      • Armed for heating is true
                                      • Set point has been at some other value for more than 420 seconds. It is still at the night value until the API reports the new daytime value
                                      • Thermostat mode is set to heat
                                      • House mode not in (night, vacation, away)" is true

                                      If you add the 420 second 'sustained' to the other elements, then in the morning when the Hubitat mode switches to "day", this rule will NOT go true immediately

                                      • Armed for heating has been true for at least 420 seconds
                                      • Set point has been at some other value for at least 420 seconds
                                      • Thermostat mode is set to heat for at least 420 seconds
                                      • House mode not in (night, vacation, away)" has NOT been true for 420 seconds until 7 minutes after you switch to day mode.

                                      As long as one of the other elements goes false within 7 minutes, the rule set will never activate. The expected behavior is that the "set point has been at some other value" will go false within 7 minutes. If that doesn't happen, the whole rule set will go true and the set actions will fire including re-running the other rule set and notifying you.

                                      I still think this could be improved as I'm pretty sure this will only fire once. If the second attempt at setting the thermostat fails, this rule will remain set and there is nothing to cause it to un-set and then re-activate. That could be your desired behavior if you want to manually fix it when it fails the first time and avoid calling the rule every 7 minutes on repeated failures.

                                      I dealt with a lot of the same issues setting up rules for my flaky Lennox thermostat. It's still in Node-Red and looks like this:

                                      55821e35-adfb-495c-b2b3-2a6ad7ea47bd-image.png <img src="blob:chrome-untrusted://media-app/55d4404c-a480-4453-ae24-0e6410279a3b" alt="Screenshot 2021-11-29 11.34.25.png"/>

                                      I'm not smart/experienced/brave enough to try to replicate that in MSR yet.

                                      1 Reply Last reply Reply Quote 0
                                      • Locked by  toggledbits toggledbits 
                                      • 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