Just making this change has not resolved it for me.
I guess I still have too many sensors, etc and the above change alone is not enough.
I think I remember reading about the rate limits changing again in the thread about the upcoming ST developer changes. I guess they are making changes and we are starting to see the affects.
Everything is failing for you today 
Fixed it for me
It’s an awesome day! LOL
I’ve been installing some LED strips as well and I don’t like how it looks so I have to redo them tomorrow 
.
Now it’s cocktail and wife time.
I’m confident this new error that was introduced {without any change on my side} was either:
The BitBar Output APP is really not overly complex (IMHO) & doing much heavy lifting but requesting device status. The MAC is performing the real crunching and formatting. I was thinking of pushing more of the processing to the ST cloud, but glad I had not started that path now that ST is being so strict on their run time limits.
I can create a new BitBar OutPut Version that executes in several separate parts, ie, get some devices, then get some other devices, then get events, etc? What a means to skin the same cat.
@jkp @kurtsanders @Nezmo @greg
The classic rate limits can be found here.
http://docs.smartthings.com/en/latest/ratelimits/index.html
The “New API” rate limits and what will become the future rate limits can be found here.
https://smartthings.developer.samsung.com/develop/guides/smartapps/rate-limits.html
There is a chance that a backend change could be enforcing some of the new lower execution limits. I will ask internally to see if that change was pushed.
Thanks @jody.albritton for the links to the classic & new limits. Quite a change in several areas. I will have to modify areas that are troublesome, which can be hard to determine when so much of the run time is dynamic with the selection of more and more devices, status, number of historical events, etc.
I {do} suspect that something on the ST backend was enforced/changed. Would have been nice to have a heads up for smartAPPs that were over the new limits, but for now, users can select fewer devices or history on devices to stay under the “rate limits”.
Right. Although history has shown this does not happen. Changes are made at ST; something breaks; we scramble to find a solution.
I have a feeling this is going to spill over in to other apps if it has not already.
ST is feeling particularly fragile to me right now. It feels like ST are slowly locking things down to where if you’re using stock code (which typically is very basic and often lacks the full functionality a device offers) you’re probably okay otherwise things are starting to break. A real shame given the huge effort devs put in to the custom apps and handlers.
@Nezmo I should have seen these restrictive controls coming!
I remember way back in the day when we had unlimited computer time on the Ohio State college mainframe. Then slowly each year the IT department started to limit program run time, print output, number of programs per day, functions, languages, etc… GroundDog Day returns!
added one normal fibaro switch:
favorite is empty:
at the moment, i cant use bitbar.
@NewHere17 I found the bug with selecting “No Favorite Devices”, and have uploaded a new version of ST_Python_Logic.py 3.02 to the V2 library. Download and install that new 3.02 release a try with selecting no favorite devices so you can get back up and running. Let me know that works. Then we can start to debug the fibaro switch error and the error line. It is weird that it shows up under a music player?
Thanks for the screen captures, it helps me locate the problem line.
The Device Monitor SmartApp is being affected now too according to my Live Logging.
Tagging @erocm1231 as an FYI. I’ll cross post too.
Dear @NewHere17,
This one is harder to detect where the problem is as the SmartThings API error seems to indicate that this music player device does not have a ‘status’ value which I am looking for to indicate whether the music player is ‘playing’, or paused/transitioning. It could be that you have selected a non-Sonos device in your list of musicplayers for BitBar to display. I think this SmartThings API ONLY WORKS WITH SONOS devices at this time. {Please let me know what type of music players you have}
If these are all SONOS devices, can you turn on all your SONOS system device and see if that will cause a ‘status’ value to be available via the SmartThings API. Otherwise you might have to de-select any Sonos devices as MusicPlayers in the BitBar Output App to avoid this sections error. 
Here are the 7 Sonos devices I have( Sonos 1, Sonos 5’s, Sonos Base) and they are both version 1 and version 2 systems. The green dot indicates playing and red, not playing/paused/transitioning, etc.
I have made some overnight performance enhancements in the latest release of the groovy App as well as lowered some system event history defaults to avoid the rate-limit. Everything is working as before and I have added back all the devices before the new limits as well as limited device event history.
Of course, if one turns on all the devices with extensive event log history, they will undoubtedly hit the rate-limits. 
Hi @kurtsanders
i use only sonos.
Play 5 in the “arbeitszimmer” and a stereo double in “bad”
before the update to 3.00 it works perfect.
@kurtsanders @Nezmo @NewHere17 @greg @jkp
We did in fact release some new rate limits early. They are being rolled back and there will be an update to the docs and a communication about the change before we start enforcing any new rate limits. Apologies for all of those who were inconvenienced by this.
Thanks @jody.albritton,
So are the new rate-limits rolled back as of now, or going to be rolled back. Just trying to determine if my version changes made the SmartApp work again or if the rate-limits were rolled back.
Just curious, how will a SmartApp know that it exceeded the runtine rate limit so that it can communicate to the user that they might need to select less devices or functions?
