Multi-System Reactor

694 Topics 6.8k Posts
  • 0 Votes
    6 Posts
    288 Views

    @toggledbits yeah, accounting the different kind of styles is hard, but I think this is a specific use case for advanced scenarios, so I’ll trade it for a less advanced ui.

  • 0 Votes
    5 Posts
    139 Views

    @gwp1 said in MSR: run for two hours based on a condition, then wait 4 hours after the reset evaluating again:

    @toggledbits When using pulse does it do a re-eval of the triggers to see if the reaction should be run again or will it simply rerun the reaction again?

    Well, in a manner of speaking. You're thinking about it backwards, I think. It doesn't need to re-evaluate conditions at the pulse time because the condition state is always up to date, being updated when events within them occur. But I think it works as you would expect: as long as the underlying condition is true, the pulses continue; when the condition is no longer true, no more pulses.

    Whether the reactions run depends on the other logic involved, but if we take the simplest case with the only condition in the rule being a repeating pulsed condition, then the rule will set at the start of the pulse (and run the Set reaction), reset at the end of the pulse (and run the Reset reaction), and repeat those reactions for each pulse.

    Ref: https://reactor.toggledbits.com/docs/Condition-Options/#output-control-options

  • 0 Votes
    7 Posts
    242 Views

    @toggledbits Let me check in the plugin 😉

  • Question about triggers and rule state reset

    Locked
    4
    0 Votes
    4 Posts
    143 Views

    I didn't mean to offend you Patrick if I have, I was just trying to work out why Meshbot rules weren't working as I expected, I like to keep an eye on what they are doing and test some of their functionality. But if you don't want to answer the question that's fine, I won't ask again.

  • 4 Votes
    14 Posts
    466 Views

    Looks good, though I swear you might be missing a closing parenthesis at the end?

  • 0 Votes
    22 Posts
    358 Views

    Thanks for doing the footwork, being the hands and eyes! Sorry for the trouble. Onward!

  • 0 Votes
    4 Posts
    141 Views

    The translation might not be perfect but, your efficency is really out of this world...

    Thanks.

  • 0 Votes
    4 Posts
    129 Views

    That problem is likely the process's umask being applied, and that can't be controlled from within Reactor.

  • Multidimensional Array

    Locked
    28
    0 Votes
    28 Posts
    1k Views

    @toggledbits

    Well, you put me to think a lot, I'm reviewing all the logic and I think progressing. You could have a video lesson on Creating Automations > Expressions 🙂 I am looking to meet this with trial and error. I just tested this on Groups and it worked perfectly, it will help:

    "internal_move": name: Internal Move Devices select: - include_entity: - "vera>device_1679" - "vera>device_1683" - "vera>device_1797" - "hubitat>1" - "hubitat>14" filter_expression: > entity.attributes?.motion_sensor?.state == true

    Now from your last comment about the MSR visualizing the HSM, I really don't know what I have to do, the Safe Monitor you commented appears, but it is all Disarmed.

    c5e7919e-b0a8-4cda-ab8b-3732df49463c-image.png

    But in the HSM in the hub the rules are created, activated, and even with action alert activated.

    759e9d15-f591-4ec6-87dc-d5e40bbe5810-image.png

    Any recommendations on what I should do?

    Thanks,

  • 0 Votes
    3 Posts
    176 Views

    I ran the install script again and nodejs is now updated to the latest version.
    pi@raspberrypi:~ $ node -v
    v16.13.0
    I also copied the reactor.service file as advised and MSR is working fine.

    Thanks for your help

  • 0 Votes
    17 Posts
    443 Views

    @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.

  • Rule for devices battery level ?

    Locked
    43
    0 Votes
    43 Posts
    2k Views

    @crille

    In my opinion, everything you put in: more efficient, more dynamic, less complex. Below is a screenshot of how I do it today, and it would be replaced only by the format expression already directly inside a message as per telegram.

    77669a6a-5057-4bfc-9370-a32da5a597b3-image.png

    I will also use it to easily know all the devices that will be tripped in the house, see the other post for what I am adding after the battery. Besides this, unifying devices that for example are triggered by a contact or movement and have different expressions, will help unify and set up the alarm trigger management.

  • Recommendation for new hub

    Locked
    7
    0 Votes
    7 Posts
    346 Views

    I went for Homeseer, I liked you could run it local either on Windows or roll your own PC with 30 days to try it out.
    Horses for courses, what suits one doesn't suit the other.

  • Pick the middle of 3 values.

    Locked Solved
    5
    0 Votes
    5 Posts
    212 Views

    Thanks! That works.

  • 0 Votes
    5 Posts
    173 Views

    IMO, if you're going to use this for production/home use, you need a broker that implements QOS and retain properly (MQTT protocol specification section 3.3.1.3 mandatory normative statement 3.3.1-5 among others). Make things work the way they are supposed to work, don't layer up exceptions and special cases. Just install Mosquitto or another compliant broker and be done with it. It's free anyway.

  • MQTTController map different values from same topic?

    Locked Unsolved
    5
    0 Votes
    5 Posts
    202 Views

    The issue is that the sensors do not report at the same time, one publish contains one or two devices and when source id is not found it's setting null values.
    Lets say I use source LYWSD03aa6def

    17:19:25.359 MQT: tele/Växthuset/SENSOR = {"Time":"2021-11-24T17:19:25","LYWSD03aa6def":{"mac":"a4c138aa6def","Temperature":7.0,"Humidity":98.0,"DewPoint":6.7,"Battery":24,"RSSI":-71},"Flora6cabfa":{"mac":"c47c8d6cabfa","Temperature":7.8,"Illuminance":265,"Moisture":20,"Fertility":85,"RSSI":-86}} 17:19:26.372 MQT: tele/Växthuset/SENSOR = {"Time":"2021-11-24T17:19:26","Flora6cab88":{"mac":"c47c8d6cab88","Temperature":8.6,"Illuminance":167,"Moisture":0,"Fertility":0,"RSSI":-81}} 17:19:37.399 MQT: tele/Växthuset/SENSOR = {"Time":"2021-11-24T17:19:37","Switch1":"ON","Switch2":"ON","ENERGY":{"TotalStartTime":"2021-05-04T07:45:50","Total":0.000,"Yesterday":0.000,"Today":0.000,"Period":[ 0, 0],"Power":[ 0, 0],"ApparentPower":[ 0, 0],"ReactivePower":[ 0, 0],"Factor":[0.00,0.00],"Frequency": 0,"Voltage": 0,"Current":[0.000,0.000]},"ESP32":{"Temperature":40.0},"TempUnit":"C"}

    It maps the temperature and humidity on the first tele but applies null on the next ones.

    Also, what to put in init?

  • 0 Votes
    13 Posts
    414 Views

    Unfortunately, I can't correlate with any specific builds but, yes, I've noticed recently it's WAE.

  • 0 Votes
    2 Posts
    106 Views

    There is no SendData on eZLO. That's not an MSR limitation, it's completely absent from the Ezlo APIs/capabilities. This has been pointed out to them. They have made no reply.

  • 1 Votes
    2 Posts
    86 Views

    That is exactly the way it is built to be used, and I do that myself extensively.

  • 0 Votes
    5 Posts
    184 Views

    @toggledbits WWW

    waiting waiting waiting

    f636f1e3-11db-425f-b013-839f95ebfeb3-image.png

    Lord, inspiration and patience to Patrick, you are in my prayers 🙂

Recent Topics