Gradually turn on lights.

[toggledbits]

I like the idea of publishing telemetry for rules. Unfortunately, the trigger state of a rule is (currently) not settable by anything other than the condition state that drives the triggers, and I think this is a vital consistency in the system, so I don't see that changing.

[Alan_F]

Would it be an acceptable workaround to add the capability to set an expression to the value of an incoming MQTT payload? That way one could set up a rule set that goes true if:

Group 1: AND   
   My condition 1
   My condition 2
OR
Group 2
   My expression changes from A to B

So for a slightly more detailed example:

My expression is named MQTT_Action_Switch1. It is set to the value of the payload of MQTT Topic "MSR/Action/Switch1"

I make this rule:

Group 1: AND
   Time is after 0800
   Motion sensor changes to true
OR
Group 2
   Expression MQTT_Action_Switch1 == true
Set Action:
   Turn on switch1
   Set expression MQTT_Action_Switch1 == false

So this rule goes true after 0800 when motion is sensed OR when the MQTT topic is received with a payload of True. It is self-resetting when set by MQTT, because the rule's set action resets the expression to false. Alternately if I leave off the last action, this rule would remain true until reset by something else setting MQTT_Action_Switch1 to false.

[therealdb]

I already expressed the desire to have mqtt messages as triggers. This is more flexible imho and gives us the ability to capture a message and parse in one or more expressions.

[toggledbits]

Question: what should the topics for rules and global variables look like:

reactor/mqtt/expr-somevariablename/value
reactor/mqtt/expressions/somevariablename/value
other?

reactor/mqtt/rules/rule-948j23rj29/state
reactor/mqtt/rule-398429223uf2/state
other?

[therealdb]

@toggledbits I prefer these:

reactor/mqtt/expressions
reactor/mqtt/rules

because it's easier to subscribe with filters. The beauty of MQTT message structure is that it's hierarchical.

[Alan_F]

My original thought was that there would be a syntax in the expression definition that would allow an expression to be set to any MQTT topic. So "my_expression" = "^{{MQTT/topic/subtopic/etc/etc}}" where ^{{...}} is the syntax for an MQTT topic just like ${{...}} is the syntax for an expression anywhere in MSR... picking the ^ symbol at random just as an example.

This would allow the capturing of topics that may already be defined. For example I use Teslamate to pull data from the Tesla API related to my cars. It stores the data in a psql database and also publishes everything to MQTT, with topics like "teslamate/cars/1/plugged_in" and a payload of true or false. If I could set an expression to ^{{teslamate/cars/1/plugged_in}} (meaning the payload value of that topic) then I would be able to create rules that would react when this changed to true or false.

If I have to format the topics in a certain way to get MSR to recognize them, then I can't use it for anything in MQTT where I don't control the topics.

I get that this wouldn't work for directly calling rule actions. For that one would have to format the topic to what MSR is looking for, like reactor/mqtt/rules/...

[therealdb]

I’m ok to use an entity as trigger via mqtt. Something like we’re doing now for entities, but to intercept messages using wildcard.
Then, pushing the value to an expression is an easy task.

Right now I’m mostly using my own bridge to accomplish this via virtual devices, but I’ll be more than happy to further streamline this thing.

[Crille]

@alan_f You could create your own MQTT Entity that could be used for trigger.
Just define the topics in local_mqtt_devices.yaml. You can change capability to Switch or any other that you prefer, this example is a Binary Sensor.

teslamate_sensor:
  type: BinarySensor
  capabilities: ['binary_sensor']
  primary_attribute: binary_sensor.state
  events:
    "teslamate/cars/%topic%/plugged_in":
      "binary_sensor.state":
        expr: 'bool(payload)'

and use that template for your MQTT entity in reactor.yaml.

"teslamate":
  name: "Teslamate"
  topic: "1"
  uses_template: teslamate_sensor

Your entity will now change state when something publishes true or false to the topics defined in your template.

[toggledbits]

@Alan_F The response by @Crille is correct... I was in mid-authoring of a similar post. You don't even need to make a template for it. Templates just make it easy to re-use topic/handling cross many entities, but if your topic is a one-off, you can do it all in line without a template as well:

    entities:
      teslamate_sensor:
        type: BinarySensor
        capabilities: ['binary_sensor']
        primary_attribute: binary_sensor.state
        events:
          "teslamate/cars/1/plugged_in":
            "binary_sensor.state":
              expr: 'bool(payload)'

And here's the silly example I was writing, showing how you can capture a JSON payload (or any part of it):

      entities:
        my_received_data:
          name: "Some Topic I Watch"
          capabilities: 
            - "value_sensor"
          events:
            "foo/bar/what/ever":
              "value_sensor.value":
                json_payload: true
                expr: payload

In this case, the expression at the end just captures the entire payload, but you could also write payload.somemember.deepermember to pick just one value from within the passed object (if it is an object).

[Alan_F]

@Crille Thanks! I was a bit confused when I first read that section of the MQTT documentation but your example using the topics from my own system helped clear it up for me.

I made a slight change to the template to make it "teslamate/cars/%topic%" which allows me to re-use it for multiple binary entities for both cars by using for example "topic: "1/locked" and "topic: 2/locked" for two entities in reactor.yaml.

I also hit a snag where trying to directly copy:

    entities:
      teslamate_sensor:
        type: BinarySensor
        capabilities: ['binary_sensor']
        primary_attribute: binary_sensor.state

caused Reactor not to start with a yaml formatting error, but referring to the documentation I changed it to:

    entities:
      teslamate_sensor:
        type: BinarySensor
        capabilities: 
          - binary_sensor
        primary_attribute: binary_sensor.state

moving the capability down one line with a leading "-" and it works.

Now I just have to find the time to write all the rules that are possible with the car information available in MSR...