This would remove the need to create huge switch / case / ifelse for every single device (and need to update it as I add / remove devices), and allow me to write one block, and if the device listed exists and supports the action, then I only need to worry about actions and not devices
Assume: Device Lists can be pretty dynamic, but potential actions a (relatively) finite set.
Personally, I would probably abstract the feature request a bit. The HTTP Request is a great example use case, but I suspect that the feature could be used in other scenarios as well.
It seems like the request would be to be able to get a device reference from a variable and then be able to execute a command on that device - regardless of if that’s from an HTTP Request or some other source. (eg. changing a variable value in a dashboard or another rule and then reacting to that change and doing something)
I noticed you mentioned the use of a device name… what happens if the input device name doesn’t exactly match or it matches multiple devices (potentially even devices with the same name across different platforms you could have connected to SharpTools)? I can see taking a device ID and using that to directly reference a particular thing, but a device name is a much looser concept.
And don’t forget to scroll to the top of the post and cast a vote on your own request. Vote counts are a key part of how we prioritize what we work on.
All valid. I was only thinking of my solution in the context of my problem, but it seems that an abstraction that would allow for the reference from a variable one place SHOULD be abstractable to solve other problems. That being said, I haven’t looked at your code base, so I I trust you to think about it in better context. I’m not sure of the other input cases (YET… I’ve only just started) but I assume I’ll run into them as I think about other automation, this is just the one that is the most immedaite for me to solve as I had a bunch of WebCore automations that utilized the URL input to the system from different devices (Stream Deck, Web Dashboard, etc) and I put off refactoring until it was too late, and now I’m forced.
Absolutely. I was thinking more about the Feature Request title and how it’s positioned in the first post content as that’s often what other community members consider when casting a vote.
While I am generally against super-broad feature requests since anyone can interpret it as a solution for their needs and thus the request gets upvoted fast without any real substance as to what the feature request actually is… in this case, it seems like broadening up the request a bit is reasonable and it could help this particular request get more interest from the community (which makes it more likely to get implemented quickly)
what happens if the input device name doesn’t exactly match or it matches multiple devices (potentially even devices with the same name across different platforms you could have connected to SharpTools)?
If SharpTools uses a unique device id locally to reference the external systems devices, you’re probably in better shape, but as soon as you are relying on the external systems for device id you’ve opened the door for collisions.
If I were writing the code, I would probably allow for a “Contains” or “Exists” on the Device/Automation collections as a first layer of protection and then give best practice around naming things the same.
The same would hold true in the external ID solution as you are not guaranteed a unique incoming id.
Ok something really nerdy but that has always enticed me is to have a speaker announce certain events. Like “welcome home” or “a package just arrived “.
One can easily set this up by creating an MP3 and setting up a rule.
Further enhancement would be to have different MP3 for different people so it’s customized “hey Matt, a package just arrived”. In the rules that’s easily enough selected by choosing the MP3 based on who is at home.
Even cooler, if you have multiple speakers, would be to only play it in the room you are in.
For example using motion sensors to detect the room motion was last seen in.
Now you can do that in a rule but it requires a lot of “if”
Statements.
If you could setup a variable representing a device (like a speaker).
Rule 1 sets that Device to a speaker based on motion.
Then rule 2 could be “stupid” and play the notification on the “closestSpeaker” variable without having knowledge of which speaker it actually was. The first rule would have already set it.
That way when you setup N rules for speaking, you only need the “if” logic tree in the first rule that sets the variable.
I went ahead and merged Matt’s prior feature request into this one as it seems like it’s generally the same concept… and even though the other thread hadn’t got much attention, his example use-cases seemed like a great explanation of the concept!
