Help me convert this piston with string manipulation to create a nice notification

One of the last things I've got left from ST days is a set of pistons to tell me about door or windows being opened I was able to get them to produce nice notifications, like this:

ALERT: Front Door Contact, and Mudroom Garage Door are open while Main Floor HVAC is heating on Thu, Apr 21 2022 @ 8:58:23 AM EDT

The key to this was the string manipulation done in line 35, where webCoRE did a great job of listifying the triggeredDevices list and I was able to insert "is" or "are" depending upon the length:

How can I reproduce equally nice messages in RM?

Here is the whole piston for reference:

FWIW: I've cobbled up something that sort of works the same, using RM and the custom app Device Status Announcer (to generate a nicer notification string). But the notification result is still pretty ugly - nothing as nice as the above. I'm hoping to be able to do it all in RM.

My current version has the list of devices repeated several times in different places (twice in the rule alone, once in DSA). It also looks much uglier than the above, as there are an additional 29 contact sensors for windows.

Also, I don't have webCoRE on my hub. This was a legacy piston running in the ST cloud, with device status mirrored there via HubConnect. I've since shut it down, but I'm just trying to reproduce the nice notification string.

This is the current rule, which just turns on a virtual switch (Announce HVAC Running with Something Open, which has an auto-off) that causes DSA to send the notification.

I'd basically like to remove the use of DSA and send the notification string straight from RM.

Is this not possible? Anyone with any suggestions or examples?

I think the rules is essentially correct, but like you mention, the notification is not ideal. The best I have is a simpler example. I'm expecting the idea will be to either write or find an app that can provide the notification you are after. I feel like there are some likely candidates for writing such an app, but am reluctant to pressure them to deliver :slight_smile:

Id have required condition for your heating on

Then drop it from the trigger

There should be a wait for condition
Wait for you contacts to be open for 1 min

Then %device% , %value% in your text string

Here are two rules using the different elements

1 Like

That's why I'm currently using Device Status Announcer (triggered by the virtual switch that the rule turns on). It produces a nicer notification message. I'm just looking to simplify things - and hopefully do it all in RM. I really dislike all these duplicate lists of selected devices (e.g., twice in the rule and one in DSA).

Would it be easier to just modify Device Status Announcer to do what you want? I originally had something like that app in a rule, but I wrote the app because that rule was getting too complicated to create as I added more devices and wanted a more complex notification:

With what it can do nowadays, the rule would be even worse. :smiley:

1 Like

That was my original plan - but then I hoped there was something I could just do in RM.
I very much like the app (thank you), but I found I needed a few things to work differently. For one, I wanted nicer strings like:

Front Door Contact, and Mudroom Garage Door are open
as opposed to
Front Door Contact is open, and Mudroom Garage Door is open

(I was hoping to feed this to TTS output, and the first is more desirable)

As you can see in my rules above, I want the announcement when the HVAC goes into heating/cooling -- and the app doesn't directly support this. This is what let me to using RM to trigger the app, and at that point the duplication of device selection was painful.

I earlier made a modification to my copy of DeviceStatusAnnouncer2Child.groovy to append the appropriate thermostat (we have dual HVAC systems) to the announcement:

>    // append thermostat name
>    thermostats?.each {
>       if (it.currentValue("thermostatOperatingState") == "cooling" ||
>           it.currentValue("thermostatOperatingState") == "heating")
>       {
>          statusReport += ", while ${it.displayName} is ${it.currentValue('thermostatOperatingState')}"
>       }
>    }

That only seems to report the last device in the trigger, not all the devices. E.g., when I have this:

only the last device to open gets into %device%.

I tried this today and it failed some use cases. The rule needs to fire off if either:

  1. there is a window already open when the HVAC starts running
  2. a window is opened after the HVAC is already running

This is why the original triggers were for changed, and the actions checked the proper states.

When I made a required expression that the HVAC was heating (since you can't make that changed), then the trigger of the contacts changed only cause the 2nd case. I tried making the trigger on the contact being open, but that never seemed to fire.

This is my test rule: (I have a whole collection of virtual devices for testing)

Did you mean something else?

What if you had everything in a restriction? So the heating, any windows and doors, etc? Perhaps with no trigger.... Or a periodic trigger to check and flick a switch that you also include in the restriction.... Then do something simple in the actions, say a delay and then a notification? I'm expecting there would either be more to this than just that, or some reason it would not work....

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.