I certainly was a user who had issues with hub locking up. I removed Rooms manager and it's been fine since. I will go back through logs/private messages with support and try to find them for you.
thanks appreciate it.
Nope, we don't fix things ninja style. We're very open in noting platform, driver and app bugs, these are noted in the release notes, and quite frequently fessed up to here in the forums.
We don't do the,"o crap", we better fix that before some one notices...
1 Like
@mike.maxwell good to hear hubitat does not turn around fixes ninja style.
would you please shed some light on why requests both from users and me, multiple times, to share these errors is never responded to?
thanks.
1 Like
my Rooms are working well right now (rooms 0.95.0 and hubitat 1.1.7.120), and I don't want to mess things up by updating to 0.96 and hubitat 2.0 right away... Anybody have any new issues introduced after updating both rooms and hubitat to the latest?
from what little info i have gotten so far on hub slowdown … it seems to be a problem with an older version that worked well on ST but on HE. that code was deprecated couple of months back.
no current information on hub slowdowns from app code.
love to hear other users share their experience so we can get to the bottom of this as a community.
Because the things your are asking for would not be of help to users, or to developers for that matter, beyond knowing that an app has gone haywire. 1 million lines of trace is not going to help you. Stack Overflow doesn't point fingers at what caused it, pretty much by definition. There are no errors that we find in internal hub logs that would be of use to users or developers. Those that are, we have made show up in Logs. For many months, diligently, whenever any of our engineers encountered an error that did not appear in logs, but that should have, we made the adjustments to rectify that logging omission.
The single most effective tool for debugging code is already in your hands: put logging in your own code. When an app goes off the rails, don't blame it on what might be missing from the hub Logs. Instead, go track it down like any self-respecting software engineer would. You wrote this code, it's your responsibility to debug it, and it is fully within your capabilities to do so with the tools you have at your disposal.
1 Like
may be share the call stack or the actual error in the user log? that would likely help identify both the developer and help the developers on where to look.
without that … the slowness is generic in the sense that even if the hub is slow there is no clue on what app could be causing that slowness because users see nothing in the logs that they can share with the developers to check on.
Now this is funny. There are two apps known to cause slowness: webCoRE and Rooms Manager. So what do you think support asks? And what do you think the first test is? Aaron figured it out in about 10 seconds without logs or a test. And we didn't figure that out by looking at any logs. We did it the obvious simple way: Try removing Rooms Manager and see if the problem goes away. Yep, that fixed it.
The solution is to fix your app, not to be complaining about logs.
but we dont know from that if the issue is with the app or the hub. logging would help pinpoint this.
thanks.
Sure we do, it's with the app. Hub works fine until you install the app. What changed? Installing the app. Remove the app, hub works fine again. And you think you can draw some other conclusion from that? You would need to see logging proof to reach that conclusion? Seriously??
TO USERS: strongly recommend not running webcore and rooms on the same hub. if you need to use webcore please use webcore only. the hub seems to get stressed when both webcore and rooms are running on the same hub and i wouldnt want that to cause any issues for you.
i have benchmarked all frequently used functions in the rooms app and they are optimized to run within the sandboxed environment the hub provides. i dont use webcore or any other custom app on my hub so i am not seeing any slowness or any error in the logs that would indicate a potential problem in the rooms app.
if you do find any errors in the logs from rooms please share and i will be happy to fix.
thank you.
1 Like
First off I want to say I love your product, as do others, hence so many people are using it. Have you considered making a light, occupancy device only, driver? I only use the occupancy and rules, no vacation or holiday stuff. The rules page is redundant when we already have rule machine. The special sauce of rooms occupancy manager is the driver that creates the rooms device. If I could just use that in RM I would be perfectly happy. It would also reduce the code you maintain and shift the workload back to native RM. Just a thought as I await v1.0.
Mike
2 Likes
Cant you just add a virtual device and then select the occupancy driver? Then just set it with RM?
thank you. thats the only reason i keep working on this. 
funnily that is how this project started. i built a occupancy driver and released it. this was about a year ago on ST. users started using the driver with webcore and other native tools to set state and run various rules. through their subsequent requests what i found was that while they were finding it easy to do this:
when this state set these switches / lights
but driving the decision for when state should change or other complex conditions was not working for them as it should. it would typically be either too complex all in all or it took so many rules to try to replicate all the conditions that it became a maintenance nightmare. this was all on ST off course.
thats when the app came out to solve those issue. the rules are almost a small part of the app and in some way the easiest part of the app. in fact i would be happy to delegate the rules to any native app. see this request for example:
however the configuration settings does a lot more that may not be immediately apparent. for example how to decide between occupied, engaged and vacant states? the rules dont handle that. the app uses the configuration setting and drives those decisions transparently.
i have already moved out vacation to its own app. unfortunately it wont make the child app, which does majority of the processing, any smaller since it was handled by rooms manager.
next step is to move holiday lights out of the child app and in to its own app like vacation which will reduce a couple hundred lines from the child app and that should help with the size. i am still considering other alternatives for how the child app size could be reduced.
ok with that context … the occupancy device driver has always been built to run both independently and integrated with the rest of rooms.
you can use the occupancy driver to create a virtual driver outside of rooms manager and it is smart enough to know it was not installed by rooms manager and will handle calls to the other components accordingly as in not make those calls any more. so when state changes to occupied it will stay occupied and not process any switches and so on.
please give it a try. love to hear feedback on the independent driver only usage.
Oh for sure the app is a vital link between the driver and HE. Without the app the driver is just a fancy virtual button. As is, the app poles the other devices to set the status of the device, so its vital. I was just wondering if there was a way to offload more work to RM.
1 Like
right.
if that was possible i would do that in a heartbeat. like in the heartbeat it took to code it. 
did some app benchmarking yesterday and today. thought i would share representative sample with some annotations. read bottom up like logs.
| device or app | epoch | type | message | comment |
|---|---|---|---|---|
| dev:958 | 23:16:29.559 | info | dW BR LI 3 was turned on | |
| dev:955 | 23:16:29.528 | info | dW BR LI 1 was turned on | |
| dev:956 | 23:16:29.518 | info | dW BR LI 4 was turned on | |
| dev:957 | 23:16:29.457 | info | dW BR LI 2 was turned on | |
| app:55 | 23:16:28.892 | debug | motion exit: Mon Nov 19 23:16:28 PST 2018 | app exits |
| app:55 | 23:16:28.876 | debug | occupied | rooms occupancy device state update |
| app:55 | 23:16:28.817 | debug | perf turnSwitchesOn: 65 ms | switches are processed and all commands sent to devices |
| app:55 | 23:16:28.754 | debug | turnon: Mon Nov 19 23:16:28 PST 2018 | |
| app:55 | 23:16:28.752 | debug | switches: Mon Nov 19 23:16:28 PST 2018 | |
| app:55 | 23:16:28.750 | debug | execute: Mon Nov 19 23:16:28 PST 2018 | |
| app:55 | 23:16:28.732 | debug | process: Mon Nov 19 23:16:28 PST 2018 | |
| app:55 | 23:16:28.704 | debug | handle: Mon Nov 19 23:16:28 PST 2018 | |
| app:55 | 23:16:28.644 | debug | motion entry: Mon Nov 19 23:16:28 PST 2018 | app receives motion event |
| dev:1242 | 23:16:28.548 | info | dW BR MS is active | motion event that is passed to app handler |
total time from receiving event to exiting app ~250 ms this includes sending all device commands and setting rooms occupancy device state. this room has 6 rules and 4 lights.
2 Likes
Nice. Great how quick HE is. Have you done comparisons against ST? Would be interesting to know the speed difference
yeah. that is pretty good.
comparing it to a distributed system will be apples to oranges but i will run it tomorrow and share the numbers. on ST log timestamps dont have the same granularity so lets see how it comes out. 
1 Like
