MQTT - add rules support ?
-
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.
-
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.
-
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.
-
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?
-
@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.
-
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/...
-
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.
-
@alan_f You could create your own MQTT Entity that could be used for trigger.
Just define the topics inlocal_mqtt_devices.yaml
. You can change capability toSwitch
or any other that you prefer, this example is aBinary 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
orfalse
to the topics defined in your template. -
toggledbitswrote on Jan 29, 2022, 4:26 PM last edited by toggledbits Jan 29, 2022, 11:27 AM
@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). -
@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...
11/11