[RELEASE] Device Status Announcer (TTS or notification if lock unlocked, door/window open, etc.)

Apps and Drivers Community Apps
#1

I just wrote a small app for myself to replace a hard-to-edit (if devices change) rule I was previously using and figured I'd share in case anyone else has a use. The basic idea is that you can choose locks, contact sensors, and motion sensors of concern, then choose to get an announcement (TTS) and/or notification either at a specific time or when a switch turns on if any of those devices are in an "undesired" state (lock unlocked, contact open, or motion active).

(Placing link to code near top of post so it's easy to find ... read on for more information on the app)

App code can be found below (install parent and child code):

or direct raw link to:

It is also available in Hubitat Package Manager.

My particular use case for this is that I turn on a virtual "momentary" switch in Hubitat as part of a "good night" rule I run via other means. That switch then "triggers" this app, which announces if any of my locks are unlocked or any of my contact sensors are open so I can fix them before going to bed. I made the app a bit more general than this specific case in the hopes others may find it more broadly useful.

Here's a screenshot of (most of) the app:

Hubitat-SpeakLockApp
Hubitat-SpeakLockApp834×1091 23.5 KB

...and for comparison, here's the rule it replaced:

Hubitat-SpeakLockRule
Hubitat-SpeakLockRule817×688 23.3 KB

As I was moving my locks between different hubs, I got tired of editing this rule and figured an app would be easier to edit (it is). Hopefully others find it useful, too! If not, I at least have a place the "documentation" link the app can point to now if anyone stumbles upon it: here. :laughing:

18 Likes
Check contact and temperature sensors by voice
Notify which is open help
Summary type notification?
Rule Machine - need help to send list of devices (e.g., contacts that are open) to string variable
#2

Will have a play with this. I have left the loft windows open many many times and it's rained

#3

Thank you. I have been putting off setting something like this up in RM for a while now.

#4

I hear you: the thought of moving my Z-Wave locks to or from a C-7 hub is what finally put me over the edge, and I decided just writing an app would be easier. There are a couple more things I might consider (notifications if one is unlocked when I go away*) that aren't too bad to do in a rule right now, but we'll see what else I get tired of clicking.

*EDIT: I guess I can already do that with this app! Just turn on the virtual switch when presence goes away. (Might be nice to customize the notification text a bit, though...I'll think of what I can do.) In my case, I'd create a second instance of the app since I only need a notification and not TTS, while in my "good night" case I want TTS and no notification. I wonder if there'd be value to a parent/child structure here for organization if people see the need for multiple instances... :thinking:

4 Likes
#5

This is the result when I tried to access this app in HPM:

image
image915×126 5.33 KB

#6

Hmm, just tried it on a friend's hub (who has never installed this app before), and HPM downloaded and installed it fine. Are on the latest version of HPM? There were breaking changes a while back that required a manual code update, otherwise I'm not sure.

#7

Well, this time I searched for "device anounce", and I found it.
Thanks.

#8

Update: I released version 2.0 and did a parent/child app structure as I foretold. :slight_smile:

New in version 2.0:

  • Parent/child app structure (create multiple child apps for different notifications/announcements as needed)
  • Additional option for notification/announcement "trigger" (presence sensor)
  • More options to customize notification/announcement text
  • Text now comma-separated list of devices/statues instead of separate sentence for each (makes notifications with multiple devices more natural to read)

IMPORTANT for 1.x users upgrading: My recommendation would be to just uninstall and start over or keep using 1.x indefinitely if it meets your needs. However, you can upgrade to 2.0 if you comment out line 33 (the "parent" line--this may move around slightly in future versions) in the 2.x child app code as suggested in the app code. You would then not need the parent app and would directly install 2.x child apps. If you upgrade via HPM, I would comment out the "parent" line in the child app code or consider starting over with a removal and reinstall as suggested.

2 Likes
#9

Looks like your package manager integration is broken. I get this error when trying to install:

Error Occurred During Installation

An error occurred while installing the package: Failed to install app https://raw.githubusercontent.com/RMoRobert/Hubitat/master/apps/DeviceStatusAnnouncer/DeviceStatusAnnouncer2Child.groovy. Please notify the package developer..

#10

Hmm, I made a change to the package manager JSON that might fix this (assuming it installs in order, this would install the parent app first, which the child app will complain about if installed first and it's not there). I'd give it a few minutes for the raw file to update in GitHub, then try again. Thanks for the report!

1 Like
#11

That solved it! Thanks for the fix!

#12

@bertabcd1234...wondering if you've ever considered adding a trigger related to thermostats. My family likes to run the AC and heat w/windows and doors wide open (just a very generous lot), so I end up paying to aircondition or heat the entire neighborhood.

Something like "If thermostat A turns on cooling or heating" as a trigger option for an announcement of open windows and doors. That would be very helpful for me. I can send you a 25% annual cut of my HVAC savings. :wink:

Future wish-list?

Loving this app...I have it set up for our nightly windows and door check before we go to bed, and to run ad hoc when I just want to know what's open, both via GH automations I start via voice command. Also have a third instance that runs automatically when our bedroom lights are turned on in the evening, in case we forget to run the good night check via GH. We have left so many windows and doors wide-open/unlocked all night that I wanted a belt and suspenders approach. :slight_smile:

#13

That's possible. I might even get some use out of it, too...I'm really stingy with AC and would hate to go to bed while leaving it on or at least (gasp!) set too low in the summer. However, since this app doesn't get "triggered" by contact sensors directly, you'd need something else to make that notification happen--say, a virtual switch that gets turned on when one of your door sensors opens, like via a rule. If that works, I'll put it on my list. :slight_smile: ("Combining"/associating devices is also there so I can get an announcement like "Back door is open and unlocked" instead of "Back door contact sensor is open and back door lock is unlocked.")

1 Like
#14

Cool! My request is somewhere on the endless list of potential possible maybe if-there-is-time-after-we-do-a-bunch-of-other-stuff future enhancements!! (Can you tell I worked with SW dev teams? :slight_smile: )

Seriously, thanks for considering it. And yes, I would die if I woke up and found I had been airconditioning the house to 65 degrees all night. <eek!>

It should be simple to set up a rule that turns on a switch (which gets turned off immediately after) any time a window or door is opened. I think even my RM rookie self could do that.

It would be two use cases?

  1. Some doors/windows open & thermostat starts a heating or cool cycle. DSA kicked off by HVAC starting and checks and reports the open windows and doors.
  2. All doors/windows closed & thermostat starts a heating or cool cycle. DSA has nothing to report. Then a door or window is opened later. Rule that flips a switch any time a door or window is opened fires. DSA is triggerd again by that switch and warns about the open door or window.

That make sense?

1 Like
#15

Yes. I think it would be appropriate to set off a siren to keep you from dying.

#16

LOL...at least someone feels that I'm that important.

:smiley:

My parents were early reduce, reuse, recyle proponents. Leaving a light on in a room when you weren't using the room was just not done. Seems like I've carried forward that childhood imprinting.

#17

I've just released an update, version 2.5, with the following new features I hinted at above:

  • Contact/lock "grouping": If you have a contact sensor and lock on the same door, for example, you can now group these devices to get an announcement or notification like "Font door is open and unlocked" instead of "Front door contact sensor is open and front door lock is unlocked."
  • Thermostat setpoints: You can now add messages like "Thermostat XYZ setpoint is 65 degrees" to announcements/notifications if the mode is heating, cooling, or auto and the heating or cooling setpoint is above or below the specified value(s).

I realize the latter is not exactly what was requested above (e.g., notification of contacts if the thermostat operating state turns to heating or cooling). However, after thinking about that more, this can already be done via the "switch" trigger available in the app: create a Rule or other automation that turns on a switch when that happens, then use that to trigger this app. I'm not opposed to including this functionality directly if the demand is there but am trying to keep the app as focused as possible otherwise (with options like this switch available for whatever notification-inducing customization you may want that I haven't thought of).

1 Like
#18

Hi,
This is super great and useful! 1 feature request, and if I can figure out how to do it, I'll submit it.

Feature request: Allow an "all good" status to turn on another switch or push a button.

Use case: I would like to turn on another switch or push a button so that I am able to trigger another rule to do other things such as changing my mode, arming my security system, shutting off the switch that initiated the check, etc.

#19

Hmm, seems reasonable. To make it applicable to any case (and somewhat Dashboard-friendly), I suppose I should just add all four combinations of these options: turning on or off a specific switch (or switches) if there is or isn't something undesired to report.

2 Likes
#20

I've just released Device Status Announcer 2.6 with new features requested above:

  • Ability to turn on switch(es) when all device statues are OK
  • Ability to turn on switch(es) when any device status are not OK
  • Selected switches will also be turned off if devices are in the opposite status (I think this is intuitive behavior, and if you self-implemented some "auto off" behavior for the switches, as I'd guess some people may, this should have no additional effect)

It's not quite as adventurous as my suggestion above, but I think this should cover any real-world use case. :slight_smile:

As usual, updated code is available on GitHub for manual installation as well as Hubitat Package Manager.

1 Like