REST API implementation
-
Hi,
@toggledbits do you have any plans to implement the missing endpoints of the REST API in near future? Especially the rule and ruleset functionality (list/enable/disable etc. as documented) would be really useful. I know there must tons of feature requests and the REST API isn't probably on the top of the backlog, so I'm not holding my breath. But if it's right around the corner on your roadmap, it would be nice to know.I'm asking this because I need a clean way to enable and disable certain rules from my custom home automation UI. I don't want to expose the MSR UI to the rest of my family to make sure they don't accidentally mess up with the rules and settings.
I could use a custom MQTT entity as a dynamic config object containing flags for different rules but it would be a lot cleaner to be toggle the rules thru the REST API.
br,
mgvraReactor (Multi-hub) latest-22310-a6da8097
MQTTController [0.1.22306] -
It's likely that the enable, disable and reset functions would not survive a review of that API prior to implementation. Enabling and disabling rules is not a way to add additional conditional logic to your automations, IMO, and I've stuck pretty firmly to that opinion (at least, I haven't been convinced otherwise to date).
See also this topic: https://smarthome.community/post/13111
-
It's likely that the enable, disable and reset functions would not survive a review of that API prior to implementation. Enabling and disabling rules is not a way to add additional conditional logic to your automations, IMO, and I've stuck pretty firmly to that opinion (at least, I haven't been convinced otherwise to date).
See also this topic: https://smarthome.community/post/13111
@toggledbits said in REST API implementation:
Enabling and disabling rules is not a way to add additional conditional logic to your automations, IMO, and I've stuck pretty firmly to that opinion (at least, I haven't been convinced otherwise to date).
Actually I don't see enabling / disabling rules as way to add additional conditional logic but merely as a user preference. For example I have a single rule that triggers lounge music playing through Sonos in my toilet whenever the PIR toggles the lights. But since I would like provide other users a possibility to switch off that feature, I would have to be able to disable that particular rule without the MSR UI for the reasons I've explained in my previous post.
And when I saw the REST API specs, that felt like a proper way to do it.See also this topic: https://smarthome.community/post/13111
I think this post is more about the additional logic or maybe I'm just seeing it in a different light. I kind of think toggling the rules as a core functionality since it's already on the UI. You could do it with additional rules or entity attributes but it just feels more of hack. But maybe it's just me.
-
@toggledbits said in REST API implementation:
Enabling and disabling rules is not a way to add additional conditional logic to your automations, IMO, and I've stuck pretty firmly to that opinion (at least, I haven't been convinced otherwise to date).
Actually I don't see enabling / disabling rules as way to add additional conditional logic but merely as a user preference. For example I have a single rule that triggers lounge music playing through Sonos in my toilet whenever the PIR toggles the lights. But since I would like provide other users a possibility to switch off that feature, I would have to be able to disable that particular rule without the MSR UI for the reasons I've explained in my previous post.
And when I saw the REST API specs, that felt like a proper way to do it.See also this topic: https://smarthome.community/post/13111
I think this post is more about the additional logic or maybe I'm just seeing it in a different light. I kind of think toggling the rules as a core functionality since it's already on the UI. You could do it with additional rules or entity attributes but it just feels more of hack. But maybe it's just me.
@mgvra said in REST API implementation:
I would have to be able to disable that particular rule without the MSR UI for the reasons I've explained in my previous post.
Your logic could include, for example, examination of a virtual switch that determines if the rule should be applied at all. This could be part of the triggers for that rule, or a constraint on that rule. This is a very common model. I myself use it for "Party Mode" in my house, to prevent the automatic locking of doors and the "Night mode" from dousing of all the lights that would cause an unwelcome interruption of the merriment.
-
@toggledbits said in REST API implementation:
Enabling and disabling rules is not a way to add additional conditional logic to your automations, IMO, and I've stuck pretty firmly to that opinion (at least, I haven't been convinced otherwise to date).
Actually I don't see enabling / disabling rules as way to add additional conditional logic but merely as a user preference. For example I have a single rule that triggers lounge music playing through Sonos in my toilet whenever the PIR toggles the lights. But since I would like provide other users a possibility to switch off that feature, I would have to be able to disable that particular rule without the MSR UI for the reasons I've explained in my previous post.
And when I saw the REST API specs, that felt like a proper way to do it.See also this topic: https://smarthome.community/post/13111
I think this post is more about the additional logic or maybe I'm just seeing it in a different light. I kind of think toggling the rules as a core functionality since it's already on the UI. You could do it with additional rules or entity attributes but it just feels more of hack. But maybe it's just me.
@mgvra said in REST API implementation:
I kind of think toggling the rules as a core functionality since it's already on the UI.
I see this opening up the proverbial can-o-worms wherein another obscure rule turns off the one you're using to drive something completely unrelated to the first.
I think of rules as true/false vs on/off (knowing I could be miles away from how Patrick intended lol) and do a very fair amount of "if rule set A is
truedo <this thing> but if it'sfalsedon't even think about it. TV on/off? That rule is true/false and the others just look for those two options. I don't really think it's that far off functionally from what you're hoping to achieve with on/off. -
@mgvra said in REST API implementation:
I kind of think toggling the rules as a core functionality since it's already on the UI.
I see this opening up the proverbial can-o-worms wherein another obscure rule turns off the one you're using to drive something completely unrelated to the first.
I think of rules as true/false vs on/off (knowing I could be miles away from how Patrick intended lol) and do a very fair amount of "if rule set A is
truedo <this thing> but if it'sfalsedon't even think about it. TV on/off? That rule is true/false and the others just look for those two options. I don't really think it's that far off functionally from what you're hoping to achieve with on/off.@gwp1 said in REST API implementation:
@mgvra said in REST API implementation:
I kind of think toggling the rules as a core functionality since it's already on the UI.
I see this opening up the proverbial can-o-worms wherein another obscure rule turns off the one you're using to drive something completely unrelated to the first.
Well I don't see it that way. You can already enable/disable the rules from the UI. Adding that same functionality to a different interface (REST API) woudn't open can-o-worms.
Please correct me if I'm wrong, but if you enable the rule I doesn't mean that it will trigger to true. It just evaluates the rule and if the conditions / constraints are met, it will trigger, otherwise not.
Of course if at the exact same moment you enable the rule and the conditions are, it will trigger, but that should happen anyway. So if you could do enabling / disabling via the REST API wouldn't it be just like hitting that red/green switch 'remotely'?
I think of rules as true/false vs on/off (knowing I could be miles away from how Patrick intended lol)
Well I think too. Maybe I was a bit unclear what I meant by toggling the rules. I didn't mean altering the rules evaluation outcome (true/false), just enabling/disabling the evaluation.
-
@mgvra said in REST API implementation:
I would have to be able to disable that particular rule without the MSR UI for the reasons I've explained in my previous post.
Your logic could include, for example, examination of a virtual switch that determines if the rule should be applied at all. This could be part of the triggers for that rule, or a constraint on that rule. This is a very common model. I myself use it for "Party Mode" in my house, to prevent the automatic locking of doors and the "Night mode" from dousing of all the lights that would cause an unwelcome interruption of the merriment.
@toggledbits said in REST API implementation:
@mgvra said in REST API implementation:
I would have to be able to disable that particular rule without the MSR UI for the reasons I've explained in my previous post.
Your logic could include, for example, examination of a virtual switch that determines if the rule should be applied at all. This could be part of the triggers for that rule, or a constraint on that rule. This is a very common model. I myself use it for "Party Mode" in my house, to prevent the automatic locking of doors and the "Night mode" from dousing of all the lights that would cause an unwelcome interruption of the merriment.
Thanks for your quick response. Well it seems that I have to forget the REST API approach if it's going the get scrapped anyway. I just wanted to know the 'proper' way to go before I have too many rules to refactor. But as you pointed out, it seems that I have to go with the virtual switch / config object while integrating MSR to my existing backend/UI.
-
@gwp1 said in REST API implementation:
@mgvra said in REST API implementation:
I kind of think toggling the rules as a core functionality since it's already on the UI.
I see this opening up the proverbial can-o-worms wherein another obscure rule turns off the one you're using to drive something completely unrelated to the first.
Well I don't see it that way. You can already enable/disable the rules from the UI. Adding that same functionality to a different interface (REST API) woudn't open can-o-worms.
Please correct me if I'm wrong, but if you enable the rule I doesn't mean that it will trigger to true. It just evaluates the rule and if the conditions / constraints are met, it will trigger, otherwise not.
Of course if at the exact same moment you enable the rule and the conditions are, it will trigger, but that should happen anyway. So if you could do enabling / disabling via the REST API wouldn't it be just like hitting that red/green switch 'remotely'?
I think of rules as true/false vs on/off (knowing I could be miles away from how Patrick intended lol)
Well I think too. Maybe I was a bit unclear what I meant by toggling the rules. I didn't mean altering the rules evaluation outcome (true/false), just enabling/disabling the evaluation.
-
T toggledbits locked this topic on
