Organizing/ structuring rule sets and rules

[therealdb]

Hey @toggledbits.
From the docs:

You cannot control the state of rules via MQTT. Rule state is driven exclusively by the result of its conditions.

And I'm OK when rules are triggered by something else, but I've built a couple of rules to be used by other rules, to streamline the logic, and it'll be useful to invoke a rule via MQTT. It's probably close to what rule/:id/restart is doing in the HTTP api.

Thanks!

[toggledbits]

There are other ways to accomplish this. Virtual switches are the traditional way, of course. You just add conditions to your rules to check the switch states, and that gives you additional external input you can use to control the rule state. The method I now prefer is to use a global variable, if for example, I don't need or want a UI for it. For example, I use virtual switches for "party mode" and "guest mode" in my house, which changes the behavior of my lighting rules, so my wife can turn these on and off from the dashboard or Alexa. But I use a global variable for "vacation mode", for which I want no Alexa visibility at all, and it's typically part of a bigger procedure to ready the house for long unoccupied times.

I've heard this "it would be useful" before, but nobody has yet explained why or how, so as of this moment, I'm open to hear it, but I'm unconvinced. I also think there' may be a framing problem. Rules are not "invoked." They are state, not action. Reactions can be invoked, either explicitly or driven by rule state. The Rule is the driver, not the driven thing; the Reaction is the driven element.

[therealdb]

@toggledbits yes, you’re right and I’ve used all you mentioned, but I’m not really satisfied.

But know I’ve started building a couple of new rule sets starting from previous code on luup, where I basically have to invoke a given set of actions (mainly setting roller shutters at a given positionm) based on other inputs (Alexa, a bot, another rule set). I’ve done it with global reactions, but since they’re not organizable it’s soon becoming too difficult to remember where it’s stored the logic and what is calling what.

You’re right that it’s not what I really need. I’d prefer a way to watch for a given mqtt message instead. This will probably solve all my problems, since it will be easier to organize and I’ll archive the same result.

In this particular case, I’d like to invoke it via Alexa and I’ll maybe just define a global variable and start messing with the corresponding api. Thanks!

[toggledbits]

@therealdb said in Invocable rules via MQTT:

You’re right that it’s not what I really need. I’d prefer a way to watch for a given mqtt message instead.

You know you can do that to an entity, right? And then conditions check the entity?

[therealdb]

@toggledbits yes, I’ll try to define a virtual entity that will just try to catch messages in a given topic and react to the payload. I don’t want to map every single actions to entities, because this is a lot of work for something that’s meant to be not exposed into ui.

[toggledbits]

@therealdb said in Invocable rules via MQTT:

catch messages in a given topic and react to the payload

This is where what you've asked so far is an incomplete thought, in my view. I can probably easily create a condition that responds to events from controllers such as an MQTT message, but those messages have payloads, and you haven't really mentioned that part before this post, although I anticipated that was where it was going to go. So as you have now said, you don't just need to respond to a message. You need to respond to a message, parse the payload it may or may not include, which may be a simple value or a more complex object in JSON form that you want to navigate, from which you may want to make a decision based on a single value taken from the payload or multiple values, which may possible need to be transformed or scaled prior to further processing (expressions), and then use any of the existing operations (and maybe some not yet conceived, so more expressions) to complete the conditional test, and/or store those values in local or global variables for additional uses elsewhere. This is all supposed to happen inside the context of a single condition.

Functionally, this is what MQTTController's method of reducing topics/events to entities does today, it just does not do it within the definition of a single condition (or condition type) in a rule. To make it a condition would require an extremely elaborate UI — you have to be able to specify what topic you are interested in (and since they are not defined/standardized, the user has to know and supply it correctly to the letter), parse the payload (which is in a form that the user again must know and supply) and use that output to extract data from the payload (the type and location of which within the payload again must be supplied by the user accurately — expressions? maybe too complex, so add an object navigator?), then store and/or build conditions from any number of those payload values (where currently conditions are one-value-one-test). MQTTController does all this now, but if you want it in a UI for a condition type, what you really are asking, in my view, is that I build Node-RED as a condition type, because this is also exactly how NR operates; this basically describes what NR fundamentally is and does.

I agree that configuring the custom entities for MQTTController is not for the timid, and I'd like it to be easier, but that's due in large part of what MQTT is, and what it is not. MQTT is, as you point out, not meant for UIs. It is fundamentally a transport interface, and nothing more. It doesn't define what the topics or payloads are, and it invites manufacturer/implementor interpretation/imagination/entropy in its use, and thus eschewing standardization/consistency/predictability, all of which defies the idea of creating a simple one-size-fits-all UI, and shifting a lot of the knowledge requirement onto the user. Even though NR has (is) a GUI, the user has to supply all of the knowledge about the topic and payload, and that is different for every topic/device/vendor. This is exactly why NR gets as complex as it gets, and why the learning curve is so steep and a lot of people can't use it all.

[therealdb]

I have to define something to parse the payload because I really don’t want to define too many rule set just to intercept messages. But it’s not too different than parsing a json after an http call, or transform entities values in expressions.

The choice is up to you, but this is not uncommon for power users to use mqtt to send/receive values from different systems and I’m not that interested in having a bus message representing an entity, so an an UI artifact.

As I didn’t wanted to invest too much time, I’ve accomplished the same by sending a numeric value to an an expression and I’m using it as a trigger. I already have a system that’s it’s able to intercept specific mqtt messages with a simple configuration and I’ll continue to use it. Thanks anyway for the pointers.

[therealdb]

For anyone trying to do the same in future, here's what I did, in detail:

• I defined a global variable named scenefrommqtt (leave it empty, so it's settable)
• I'm publishing an MQTT message under reactor/mqtt/Expr/scenefrommqtt/set, with value "mykey" (the quotes are important)
• On Reactor's side, I'm using the variable as a trigger, using the same name defined for the Rule Set

It's working very well for me, and it's easy to setup. Thanks @toggledbits for both MSR and for pushing me to think of current features, instead of asking for new complicated ones

Now I have just one single vera code running, and I'll migrate it later, leaving the Vera just as a glorified ZWave bridge until it'll work.