OH 2.4 Rule: Group Channel-based Trigger

Setup, Configuration and Use Scripts & Rules
1

Hello,

is it possible to group Channel Events and use this group in a rule condition?

My rule is working with a single channel condition:
when
Channel “xyz” triggered
then
…
…

But in this way I have to define the condition for every Thing in a single line and join them with OR.
I’m note sure if this is a right solution.

Thanks.
Igor

2

There is no way to link channels to a Group Item.

1 Like
3

Thx

4

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?

5

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).

6

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.

7

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.

Group:Switch:AND groupname „label“ ...
8

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.

9

At the moment I have 6 x, so 6 channels per device is not an option
thx for the info

10

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?

11

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.

12

I think this one should work

rule "Catch Shelly events"
when
    Channel "shelly:shellydevice:25a73e:device#alarm"     triggered or
    Channel "shelly:shellydevice:559f55:device#alarm"     triggered or
    Channel "shelly:shelly25-roller:68fcfb:device#alarm"  triggered or
    Channel "shelly:shellyflood:76508f:device#alarm"      triggered or
    Channel "shelly:shellyht:e01ad9:device#alarm"         triggered
then
    logInfo("Shelly", "Alarm condition: " receivedEvent.getEvent() + " (channel: " + receivedEvent.getChannel().asString + ")" )
    
end

Note: alarm conditions of a sensor will only be checked when the device wakes up and reports an event

Would that work from your point of view?

13

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 :wink:

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.

14

I think we are the same page :slight_smile: 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 :+1:

1 Like