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
@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?
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.
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.
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.
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.
you know @mjw-tan who started that private thread and has contributed code to the app has done that as have I. we can’t find any user scenario that slows down the hub.
Just to maybe add a little additional info. I use the custom app HousePanel pretty heavily. The other day while messing with it I started noticing slowdowns. Through the HP dashboard and through device pages.
To make a long story short. I had a custom driver authorized in HP. After many adds and deletes and resetting up the app. I realized JP just did not like this device. No errors showed. However deauthorizing this one device out of fifty restored hub function to normal.
So my question is could the uses experiencing issues possibly be authorizing devices that are themselves causing issues with RM?
yeah between the motion sensors and contact sensors you are good. removing the engaged with music. its only about 100 lines of code but with the hub every little bit seems to help.
ok. once there is a supported driver we can get this figured out. but any device any command that is already built in to rooms and will help with this. a lot of the window shade drivers also support levels so you should also be able to levels on rules to set this.
i will go ahead and remove this also. another 100 lines of code.
btw … this will also remove the music action from the rule not from rooms manager or announcement. guessing no one uses that … but if you do just switch to using the any device any command on those rules.
