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
another sample for a landing area with 4 rules and one light fixture. 166 ms from handler receiving event to exiting app.
| device or app | epoch | type | message | comment |
|---|---|---|---|---|
| dev:376 | 00:38:28.269 | info | dW LN LI was turned on | |
| app:216 | 00:38:27.991 | debug | motion exit: Tue Nov 20 00:38:27 PST 2018 | app exits |
| app:216 | 00:38:27.976 | debug | engaged | rooms occupancy device state updated |
| app:216 | 00:38:27.943 | debug | perf turnSwitchesOn: 29 ms | switches are processed and all commands sent to devices |
| app:216 | 00:38:27.916 | debug | turnon: Tue Nov 20 00:38:27 PST 2018 | |
| app:216 | 00:38:27.915 | debug | switches: Tue Nov 20 00:38:27 PST 2018 | |
| app:216 | 00:38:27.913 | debug | execute: Tue Nov 20 00:38:27 PST 2018 | |
| app:216 | 00:38:27.902 | debug | process: Tue Nov 20 00:38:27 PST 2018 | |
| app:216 | 00:38:27.884 | debug | handle: Tue Nov 20 00:38:27 PST 2018 | |
| app:216 | 00:38:27.825 | debug | motion entry: Tue Nov 20 00:38:27 PST 2018 | app receives motion event |
| dev:377 | 00:38:27.738 | info | dW LN MS is active | motion event that is passed to app handler |
2 Likes
here is the data from ST. this is a room with 4 rules and 2 switches. the log data does not have the same granularity. but from the device data … from the time the device registered and logged motion event to the switches getting set it was 486 ms.
| device or app | timestamp | type | message | comment |
|---|---|---|---|---|
| device | 1:26:30.377 PM | COMMAND | off | light off |
| device | 1:26:30.288 PM | COMMAND | on | fan on |
| app | 1:26:30 PM | debug | motion exit: Tue Nov 20 21:26:30 UTC 2018 | app exits |
| app | 1:26:30 PM | debug | occupied | rooms occupancy device state updated |
| app | 1:26:30 PM | debug | perf turnSwitchesOn: 18 ms | switches are processed and all commands sent to devices |
| app | 1:26:30 PM | debug | turnon: Tue Nov 20 21:26:30 UTC 2018 | |
| app | 1:26:30 PM | debug | switches: Tue Nov 20 21:26:30 UTC 2018 | |
| app | 1:26:30 PM | debug | execute: Tue Nov 20 21:26:30 UTC 2018 | |
| app | 1:26:30 PM | debug | process: Tue Nov 20 21:26:30 UTC 2018 | |
| app | 1:26:30 PM | debug | handle: Tue Nov 20 21:26:30 UTC 2018 | |
| app | 1:26:30 PM | debug | motion entry: Tue Nov 20 21:26:30 UTC 2018 | app receives motion event |
| device | 1:26:29.891 PM | DEVICE | motion active | motion event that is passed to app handler |
in rooms anyone using these 2 features:
- use music player playing to set room to engaged?
- set window shade position using rules?
if not … I am thinking of deprecating these.
thank you.
Nope i'm not using those.
@bangali
I don’t know how your apps works but, if you are seeing hub slowdowns, did you consider splitting it to make it more modular?
So people can chose which bits to install?
I don’t seem to have problems with Message Central (although it takes a while to save) and that’s up to about 5000 lines of code now.
Maybe above that is the issue?
Andy
2 Likes
unfortunately I am not seeing hub slowdowns. if i was it would be easier to at least triage though without visibility to logs it would be limited.
I have heard of hub slowdowns specially after updating/rebooting the hub. when the hub starts up there may be a flood of competing resource demands causing contention resulting in these slowdowns. but this is speculation based on observation not from data.
I have and have done some of it. Like over last weekend I was able to bring down the rooms child app from 6100 lines to 5500 lines by spinning of a helper app within rooms. however kind of limited in how much modularzation I can do since device objects are not serializable and are only stored in input settings of app the user entered them in and not in their parent, peer or child. which means at runtime every module every time it’s instantiated would need to call another app likely its parent to get the device objects thus limiting the benefits of modularity.
thinking about what else might be possible. open to other suggestions.
thanks.
1 Like
You’ve probably heard this before but I would add lots of additional logging
Maybe think about adding some try/catch routines around chunks of your code.
Sometimes this shows errors that don’t show up in normal logging.
If I have issues I’m having problems finding, I add additional logging to every method for a short while.
Not much help, I know. But as I didn’t write your code it’s difficult to know exactly how it works.
Andy
1 Like
thanks for the suggestion. to clarify a bit more:
- I have only seen one error that was shared with me from the platform log. it was because user had updated the code but not gone thru and saved the settings so subscriptions were still referring to functions that were deprecated. this error would have shown in the user logs think the user just didn’t realize they had to go to the app and save settings after updating the code as specified in forum notes with the code release.
- exactly the same code runs on ST. ST logs are pretty good about logging any app errors. there are no errors in the ST logs.
as someone else mentioned earlier think it’s more to do with size of the app and the app having to be loaded every time there is a triggering event subscribed to by the app.
I am off course thinking about how else I could modify the app to work within the constrains here for every user. there are off course other platform strategies that would also mitigate dealing with large apps.
thanks again. please keep the suggestions coming.
2 Likes
As we discussed in our private messages.. ST has unlimited resources for running apps in the cloud.
Not sure what you can do here
Does the app slowdown at a particular point?
when a specific routine is run?
For example.. "everything was ok until I walked into the room"
I would target a helpful informed user and get them to test each scenario individually to try and narrow your search parameters.
1 Like
