Love this app. I was able to clean up a bunch of rules. Thank you.
I have a question about how the app tracks the state of devices. Does it check every device each time the app is called or do you keep track of the state for devices when they change? The reason I'm asking is that I have two child apps setup. One for my main house and the other for my house, the garage, and the in-law apartment. When I run the latter it updates the good/bad switches appropriately but the main house switches are out of sync. The main house child contains a subset of the house/garage/apt child. Will it cause problems if I sync the switches in this case?
I know you hate to add bloat to your apps but any thought of adding locking functionality to the app? I know it can easily be done with rules but to me it makes sense to have it built into the app. This way I wouldn't have to make a call to a rule and then call the app again to make sure they were locked. It would also be nice to have it announce 'Front door has been locked'
The app does create any device/event subscriptions for the "announced" devices (only the switch or presence devices if you have them configured to perform an announcement since the app needs to know when those change to "trigger" the announcement). So, what happens is that when the app is "triggered" to make the announcement, it evaluates the current states at that time. Whatever you see under "Current States" on the device page should be the same the app sees, so if that's wrong, that would explain any unexpected results you see. (If it just changed, then it could be that the app woke up and evaluated states before that actually "registered" as a change back into Hubitat's database.) I'm not sure if this is also part of your question, but having the same device in multiple child apps is not a problem.
I can see where locking would be a useful feature, though it's a bit out of scope for an "announcer" app. It wouldn't be too hard to add, though (as I did recently for a similar request in another app), I wonder if adding a "run these Rule actions when state is/isn't as expected" might be a more generally applicable approach, even if it requires using another app (rule) for the actual actions...
Maybe I didn't explain the 'issue' correctly. The app is reporting everything correctly. What is happening is I am running the child that checks everything and if any locks are unlocked it calls a rule to lock them, I then call the app again to report that everything is ok. In this case the called apps switches are in a good state but the other child app with a subset of devices is in a bad state even though I just locked all the doors. Since that child has to be in a good state if the other child app is good I was just going to sync the switches. From what you said above this shouldn't be a problem right?
The ability to call rules directly would be a nice feature. I think I would be able to get rid of the virtual switches then. I can't stand having a bunch of virtual tracking switches if I can avoid it.
I guess the real reason I asked for the lock function to be built in has more to do with the announcements themselves. I have a hell of a time keeping multiple announcements timed properly so they don't stack on top of each other and cancel each other out. I am using Alexa TTS Manager for announcements but was considering checking out Echo Speaks again. My understanding is that the latter can queue multiple announcements. I tried it about a year ago but it caused my hub to have slowness issues.
Ah, yeah, that shouldn't really be a problem, though if it all happens super-fast, it's possible the app won't have the correct device states (there is a way I can probably work around this in some cases by forcing a non-cached read of the state--I'm not right now and I don't think most apps do this in most cases---but it won't help if the new value simply hasn't been committed yet). If this child app is getting triggered by a virtual switch from a rule, then you could also work around it by issuing a slight pause in RM before the next app runs if this is a problem.
I'll think about the "lock" thing but do want to avoid scope creep. Were you thinking that the app would lock the lock before reading back the status? If so, the above could still be a problem--it may not complete in time for the new state to be read (could be worked around by adding either a reasonable delay or a subscription for the event plus some "timeout"). But you might also be able to do it with a rule if you're using a virtual "activator" switch to trigger this app if you use that to trigger a rule instead and then use something else (likely another switch, so...gets messy if you have a lot, I know) to trigger this app "for real," when any state that you may have wanted changed gets a chance to change beforehand. Just another idea that's do-able as-is!
That was my thought but only if the 'Lock the locks' field was checked in the app. I do this now in a rule by waiting for the locked event with a 15 sec timeout, it's been working fine for over a year. It then notifies me that the lock was locked opposed to it just being locked already. Another approach would be to announce which locks were unlocked and then say 'attempting to lock them' and then announce whether successful or not. I'm not sure of the best approach. I guess whatever is easer to code.
Hi, I installed the app yesterday, added 6 contact sensors. I did a test report & noticed that not all the devices that where open at the time where noted. I then did a Test announcement, again not all the open sensors where mentioned. The app is activated when the harmony remote turns my TV off. So prior to doing this I closed all but my front door, tirned off th TV & no announcement that the front door was open?? Can anyone help with trouble shooting this.
I was originaly thing that maybe there was a maximum open sensors that it could report on, which is why I only left 1 open when I turned the TV off.
Thanks in advance.
I'd start by checking the device page on Hubitat for any device you think is open: "Devices" on the left-side menu, then click/tap into the device page for each contact sensor, maybe opening each in its own tab for easy access. Check "Current States" towards the top, and make sure that you see "contact: open" or "contact: closed" there as expected. If you don't see it change, there's a problem with the device, and so this app (or any app) won't be able to see the correct state.
If that looks good, are these devices using built-in drivers? There's no theoretical maximum limit, but there could be something else going on (e.g., the driver using a non-standard attribute value).
Looks like I have a faulty sensor in the door. Just checked in 'Devices' & it's showing closed, & looked on the camera & the wife has the door open. Sorry for the false alarm.
Would it be possible to add a customizable small optional delay in the code, so that it would flow thru the HPM.. For example, I have set it up to run after HSM is armed ( and a virtual switch is turned on to reflect the armed status).
The code I have added is .. something like this
under section(styleSection("Notification Options")) {
input name: "notificationExecDelay", type: "number", title: "Delay execution by seconds (optional):"
and at the beginning of String getDeviceStatusReport() {
Long delayMilliseconds = settings["notificationExecDelay"]*1000
pauseExecution(delayMilliseconds)
The reason for the delay is .. that during the arming process , deadbolts are locked, but they need about 5 seconds to completely lock. but since the virtual switch (that is the trigger for this process) is turned on, this app runs before the locks are completely locked. So if there was a small 10-15 second delay, then it would not incorrectly say that the door is unlocked. and I wont have to go and check if it is really unlocked or if it was just timing mismatch ( which is what it mostly has been )
Thanks for a great app.. it saved a multi if-then else loop
Thanks
Shouldn't be too hard--I'll put that on my to-do list. In the meantime, I'm assuming you've thought of workarounds already, but one is: creating another virtual switch, turned on after the first by a short delay, that in turn "triggers" this app instead.
Yup.. I didnt want to create a another virtual switch ..
I temporarily added the suggested code in the child for now.. once you have ti updated, will refresh the code.
Thanks for your quick response
For my case, I found it useful to check if lights were also off for a general bedtime routine. I added a pull request in case it was useful for others also.
Is it possible to make this announcement dynamic? For example weather? Open contact sensor between 7-8am and play today’s weather
Thank you @bertabcd1234
This app does not have a way to retrieve weather information in the first place or to speak it, so you'd need some method to get that into Hubitat (and possibly into a speech-friendly format). I'm not sure it would really fit in the goals of this app, but if you want a weather announcement any time this app "runs," maybe you could use a rule that triggers at the same time or is triggered from the same switches that would wake this app to give the TTS or notification (depending on how you have this app configured)?
Not sure if this is too much to ask, but would it be possible to have a variable "it/them" that could be used in the "text to append to announcements" based on if there is or isn't more than one device?
Example: please close %variable% as soon as possible
I'd have to think about how that would work with multiple devices (comma-separated list with "and" before the last item?). But as-is, the device names are already part of the notification or TTS. For example, if I have two devices, Door 1 and Door 2, selected, and one of them is unlocked when the speech or notification is triggered and part of the configuration looks like this:
Then you'll get a notification of either nothing (actually, I cut that part off, but all the text fields above this are blank, too) if all is good, or something like this if Door 1 (or Door 2, just with different text) is unlocked:
Door 1 is unlocked, but you went away.
(This is an actual setup I have to let me know if any of my doors are unlocked and my presence sensor goes away--not that I've done that before. ) In your case, you could make it say something like:
Door 1 is unlocked; please close.
...if you put "; please close" (sans quotes) in that last box. I feel like this would be pretty close to what you want already, but perhaps I'm missing something that you want. Might be an interesting idea to get matching device name(s) usable elsewhere, too, though if there's really a need--mostly not sure how useful that would be since they're already there, and the ability to customize how they appear becomes a concern if there is more than one.
Any chance the ability to announce the status of a "switch" could be added to this awesome application? I have some virtual switches that I would like an announcement if they are "ON" when I trigger it.
It wouldn't be too hard to add, though (as I did recently for a similar request in another app), I wonder if adding a "run these Rule actions when state is/isn't as expected" might be a more generally applicable approach, even if it requires using another app (rule) for the actual actions... 
) In your case, you could make it say something like:
