right if you set that second toggle it wont. think i use the same in my downstairs garage entry hallway where the motion sensor is above the door and doesnt see you till you are a few steps in to the hallway.
updated to github with following changes:
Version: 0.99.3
DONE: 12/22/2018
1) standardized color notification routine
2) added asleep from and to times in asleep settings
3) various bug fixes and optimizations
- **REQUIRES SAVING ROOMS MANAGER AND ALL ROOMS CHILD APP SETTINGS AFTER UPDATING CODE. REMEMBER TO UPDATE DTH/DRIVER CODE ALSO.**
1 Like
Debug is set to false in my various child rooms, but I still get debug logging. Is there some other setting that controls this?
normal debug logging will get turned off with that flag in general settings.
theres some system logging thats enabled which cannot be turned off. while it should not be a significant amount of logs … i generally turn those off in subsequent releases after finding whatever issue i was working on. 
1 Like
Ok thanks.
It was this type of logging that I was getting:
[app:335](http://10.0.0.67/logs/past#app335)2018-12-29 09:45:02.490 am [debug](http://10.0.0.67/installedapp/configure/335)runTime: Sat Dec 29 09:50:00 GMT 2018 | opt: [process]
[app:333](http://10.0.0.67/logs/past#app333)2018-12-29 09:45:00.854 am [debug](http://10.0.0.67/installedapp/configure/333)runTime: Sat Dec 29 09:50:00 GMT 2018 | opt: [process]
[app:1](http://10.0.0.67/logs/past#app1)2018-12-29 09:45:00.200 am [debug](http://10.0.0.67/installedapp/configure/1)perf scheduleNext: 39 ms
[app:1](http://10.0.0.67/logs/past#app1)2018-12-29 09:45:00.186 am [debug](http://10.0.0.67/installedapp/configure/1)[[type:time, time:Sat Dec 29 10:00:00 GMT 2018, timeS:10:00], [type:next, time:Sat Dec 29 10:00:00 GMT 2018, timeS:10:00, options:[time]]]
[app:1](http://10.0.0.67/logs/past#app1)2018-12-29 09:45:00.168 am [debug](http://10.0.0.67/installedapp/configure/1){option=[time]}
[app:199](http://10.0.0.67/logs/past#app199)2018-12-29 09:45:00.130 am [debug](http://10.0.0.67/installedapp/configure/199)runTime: Sat Dec 29 09:50:00 GMT 2018 | opt: [process]
[app:289](http://10.0.0.67/logs/past#app289)2018-12-29 09:45:00.097 am [debug](http://10.0.0.67/installedapp/configure/289)runTime: Sat Dec 29 09:50:00 GMT 2018 | opt: [process]
But if it's normal then no problem, just thought I had configured something incorrectly.
Also I get the following error with the latest code:
[app:336](http://10.0.0.67/logs/past#app336)2018-12-29 08:18:00.581 am [error](http://10.0.0.67/installedapp/configure/336)groovy.lang.MissingPropertyException: No such property: option for class: com.hubitat.hub.domain.Event Possible solutions: location on line 4563 (scheduleFromToTimes)
sure. kind of semi-normal. they will go away in a while.
please update only the child app code and check if the error still happens.
1 Like
The error no longer shows up in the logs. Thanks & Happy New Year!
1 Like
How resource intensive is Rooms Manager? I don't have an overly complicated setup, and I can achieve the same result with a handful of Rule Machine rules. I'm wondering if Rooms Manager is overkill for my needs, especially if I'm risking slowdown for the platform as a whole.
i only use rule machine to set away mode so i have no empirical data but may be you could setup both and check?
I'd be happy to check, but I'm not sure how to see how much resources a specific app is using.
right. I don’t think any of us do directly. but you could:
- check how long it takes rooms to respond after a triggering event
— have logs open with device logging on then check delta between device trigger event and rooms occupancy device event - test 1 - do the same by setting up RM rules to do everything that the rooms setup did above - test 2
- do the same check for another app not rooms or RM … once while rooms is running and once while RM is running - test 3 and test 4 respectively
do each test above 5 times then average for each. now compare test 1 and 3 to test 2 and 4. that will give you some directional data to evaluate for both scenarios.
Thought it was time to update the community with my experience with Rooms Manager and HE, now that I have it working again.
TL;DR
Rooms Manager is working well
I'm one of the people that have experienced Hub freezing and crashing. I fought it for ~2 months, involving HE support. The first time the hub started crashing, I just began stripping back non-native apps until it stopped crashing. And then I built it back up again with only apps I consider essential (Rooms Manager included). It started crashing again, shortly after.
This second time it was bad. I could reboot and have about 1.5 min before the hub would lock up again and be 100% unresponsive. In contact with support, they advised that they'd been seeing this happen with users who'd installed Rooms Manager and asked me to remove it (a challenge for a locked up hub).
Of course they first ask about webCore, you can imagine, but I don't use it 
Ultimately, I was able to leverage that 1.5min to remove Rooms Manager. The crashing stopped.
I rewrote all my automation in the simpler native apps, as best I could, everything was fine for a while.
@bangali reached out to me letting me know how much work he'd done to tune Rooms Manager and asked if I would test it.
Over the course of a couple weeks, I've slowly moved my automation back to Rooms Manager for testing. I now have all the rooms automated again, using Rooms Manager and it has been working fine for sometime.
I don't know what the cause of the crashing was, I only know the correlations I depict above. I also don't know whether @bangali's changes solved the issue, or the many firmware updates that have occurred since.
None the less, I feel Rooms Manager received a bit of bad press and it's only fair to share all the information I have, because it is a really good app and seems to be working fine now.
4 Likes
On the " BATTERY LEVEL CHECK SETTINGS" screen what type of data should be filled in the "Annouce battery status when?" section.
And for the device connectivity check, does Rooms Manager try to refresh the device if there hasnt been any event in the set time period?
that should be time.
not yet. but if refreshing helps that’s a quick add.
EDIT: i should add one thing on this:
though the device check happens every hour … the battery check only happens once a day. this is the time when the battery check happens and any announcement of battery status is done.
1 Like
To be honest I'm not sure. I think it may help. I'm quite new to this, but my understanding was that Zigbee devices are supposed to check in with the hub periodically. But I seem to have devices which don't.
So I get "xyz have not checked in last 12 hours" announcements. But when I then go and try and use those devices via Hubitat they are all working fine.
change the threshold to 24 hours.
1 Like
When your code check a device for connectivity, does it check the "Last Activity At" time, or the datetime on the device events, or something else?
I have some devices which are marked as not having connected in the last x hours, but I can see in the Zigbee logs messages from those devices within that time period. So I'm a bit confused as to why Hubitat doesn't show them as having been active more recently.
it checks for the timestamp of the last event originating from the device.
please share a screenshot of what you are comparing and lets see if there is an issue with what the app is checking or something else.
Is that the same event that would show up at the top of the Hubitat /device/events/ page for the relevant device?
I'll capture some logs to show what I mean.
on mobile and don’t remember offhand which all events the device log displays. but note that it has to be the latest event where the origin is the device.
