I may be missing something here as I'm a new user, but I can't seem to find a way to trigger events or add conditions that are based on custom events (from what shows in the events log).
In particular, since the devices shows a log of events that get sent to HE, I want to add checks for certain values for any field of the events (or at the very least the "Description Text"). For example, I want to say If event field "Type" has value "==" to "physical" to check if a lock was physically opened (and other advanced scenarios that depend on device instance unique events).
Does this, or something similar, already exist? If not, how can an official feature request be made?
Where are you trying to do this? This is possible in Groovy, of course, but you have to write an app that does it. Otherwise, you have to use the built in apps that are available. There is no filtering based on the descriptive text as that is not consistent between different drivers.
In rule machine there are two triggers, switch and physical switch. Switch is any switch type and physical switch would be that change to switch with the type of physical.
Rather than ask in such general terms, why don you give a specific example of what you are trying to do? That might be a little easier than talking in the abstract.
I am referring to the events that show in the log when you click on the "Events" tab when looking at a device. In this case, I want to read that "Type" field in the below screenshot.
I was trying to do this in the rule machine. I know of course it won't be consistent, but as far as the rule is concerned, why do we care about it being consistent between different drivers? I can easily add multiple triggers for different drivers with different keywords.
It's for the example I gave in my original post. I want to check that a lock as been opened physically (not by code), without having to jump through too many hoops.
Then that would have to be a function of the driver.
I am trying to answer your question. But without sufficient information, I can't do that. Your question is 20 hours old. I don't see anyone else trying to help you. I thought you would have been more appreciative of someone trying. Well, best of luck.
@MMK - There are some Triggers in rule machine that are specific to "Physical" events of a device. If you look in the list or RM Triggers, you will see "Dimmer" and "Switch" as trigger options. These triggers will run the rule regardless of how the switch or dimmer level is changed (i.e. manually at the switch (physical) or via the Hub sending it a command (digital)). There are also two special Triggers named "Physical Switch" and "Physical Dimmer Level", which will only run the rule if the device was manually adjusted (physical).
I believe this is what you're trying to accomplish, however using a smart door lock, instead of a switch/dimmer. Correct? If so, then this is where my knowledge ends as I do not have any smart door locks. Therefore, I do not know all of the tricks and tips of using RM with those devices. I do know that @bravenel is the author of Rule Machine, and he can tell you whether or not it is possible to discern a lock being manually unlocked versus digitally unlocked in Rule Machine.
@bravenel, do you think being able to trigger on those "Description Text" fields in the events would make it possible to distinguish between them by listening to those events getting written?
Description Text is not a defined element of an event, and no consistency is to be expected. So it doesn't make for a good thing to use to trigger other actions. It is purely informational.
Of course it's not consistent across devices. But why is that a concern? The same device will be reporting the text all the time for any given user. If I do a keyword search in that field for my own door lock for whatever text it shows in the event I'm interested in, then I could deduce the specific case I'm looking for (and other complex scenarios). It doesn't need to be a fixed or built-in keyword that is part of the rule.
I don't know how powerful the HE itself is and whether string searches would slow it down though...
