[DEPRECIATED] BitBar V2: Display & Control SmartThings from the macOS Menubar

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 :frowning:

1 Like

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 :weary:.

Now it’s cocktail and wife time.

I’m confident this new error that was introduced {without any change on my side} was either:

  1. A new lower execution time limit imposed on the ST cloud;
  2. The ST cloud platform is running slower for the devices and event history that the APP is requesting.
  3. ST Management is worried about the increasing number of SmartApps and their escalating hardware costs.

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.

1 Like

@jkp @kurtsanders @Nezmo @greg

The classic rate limits can be found here.

The “New API” rate limits and what will become the future rate limits can be found here.

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!

1 Like

Notice: BitBar Output App Alpha Testers

Announce: Version 3.0

  • Caution: There maybe new issues introduced in this alpha release. Please PM me with all details and screen captures if you experience an unintentional bug.

Files Updated:

  • Please refer to other version update posts above for procedures for updating the required files identified below.
  • After updating the required files below, you must launch the BitBar Output APP on the ST mobile client and view the new features introduced below if you desire the new functionality and possibly avoid display errors. Please SAVE or press DONE on each screen as applicable.
  1. ST_Python_Logic.py v3.02
  2. BitBar Output App.groovy v3.00

New Features:

  1. Added the ability to select “My Favorites Devices” from the BitBar Output Menu Display Options which displays your favorite mixed sensors before all other device sections.
  2. Added Sort Direction capabilities for temperature capability devices
  3. Added the ability to turn on/turn off EventLog Display on all devices to help avoid the new runtime rate limits imposed by SmartThings infrastructure. Should you experience this error, please turn off the display of the event log history and/or reduce the number of device sensors.
  4. Changed initial method for HTTP request to SmartThings REST API using urllib and urlib2 python 2.7 libraries. Previous method used CURL.
  5. Changed method for determining if display is in MacOS Dark Mode.

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.


now it works.
but a failure is still there

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. :frowning:

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. :rage:


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.

@NewHere17: I have PM you.

@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?