what’s about have an Item per trigger channel and then group those Items to monitor them with one group? Is it possible to define an Item for a trigger channel?
An Item can actually link to several channels. But Items are state based, and only link to state type channels.
So that doesn’t help you - you cannot link event type channels to any Item.
You could have rules to listen for trigger events and set Items to follow them. This may make no sense where the trigger event is “button press” or suchlike, and there is no “not pressed” event (because that is a state not an event).
thanks. We are looking for an efficient way to catch the health monitoring alarms for various Shelly devices (in fact all), without the need to have a rule per device and to have device names at multiple locations.
But you could set a dummyswitch to on/off by a rule when the eventchannel triggers.
A switch for evervy event -> rule for switch -> group the switches and declare group to ON if every switch is on.
You might consider why you are using transient event channel triggers, and not state driven Items.
It is more useful to know “x is broken” since you can trigger anything you like off of changes in that condition, as well as display it, and interrogate at any time.
Don’t really understand the gripe. You have six “health monitor” event channels for each device? For what purpose? State type channels are ruled out, because?
We are talking about the new Shelly binding, it provides a health monitoring , e.g. weak widi signal, overheating… = total of 6 indicators
Having them all in a state channel means 6 additional channels, for dual relay 12. So this is not an option.
As we understood there is now other way to have a rule listening to the triggers (one per component) and having the exact channel names there. The rule can than get the alarm type from the payload and the device/component from the triggeredItem.
Rule looks sound to me, if that was a question for me.
Okay.
Okay. This costs you nothing as binding designer. Users are not forced to use channels they are not interested in.
I would have thought that users might be interested in radio RSSI or box temperature as readable values that they can choose to monitor, graph, etc. but I’m sure you know the users of these devices better than me,
Maybe a compromise if you feel strongly about minimizing channels would be to provide one string type with various status as JSON or suchlike. Leave analysis to adventurous users.
I don’t see any problem with the “alarm event” proposal, just saying that implementing that does not stop you also having state channels. I have no horse in this race, just instinctive uneasiness about hiding information. Perhaps I’ve completely misunderstood and the data is not available from the device except as fault report.
I presume if you do stick to only generating alarm events, you’d provide some configurable threshold value e.g. alarm if temperature > 80C Or is this under the control of the remote device?
A further refinement you might consider for use with transient alarm events - a binding provided state channel of datetime type to represent “lastTriggered” of the alarm event, to be updated by the binding.
Monitoring that for changes via an Item opens up the possibility of using Groups, of course
Sounds like you are limited by some design choices at the device end, if that is providing per-relay info instead of per-box for common readings like temperature…
But again, providing 12 possibly unused state channels costs nothing.
I think we are the same page I had an alarm channel as String Item providing JSON formatting info. However, the Reviewers for the 2.5 PR convinced me that this is some kind of unprocessed information and should be mapped to channels (state/event). At the end those alarms are exceptional - usually they should never happen, but if so you need to take action.
I think the sample above full fills this requirement. One trigger channel providing the alarm type as payload, which means you get the information you need - the device/component which raised the alarm and the type of alarm. This is easy to monitor by a rule. Having to triggers in one group abstracts the channel ids from the rule, but at the end…
I think I’ll add a sample to the README and we have not the perfect, but a good solution.
Thanks for your feedback