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.
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.
Added Sort Direction capabilities for temperature capability devices
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.
@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.
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.
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.
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?
The changes should be rolled back now and if you look at the docs.smartthings.com link I posted above about rate limits, there are some header values returned about the current rate usage and rate limit reset time.
@NewHere17
I think that your Mac OS system internet modules are not fully initialized for BitBar’s initial internet request, when it is starting up. The error that you are encountering is explained below:
URLError
Often, URLError is raised because there is no network connection (no route to the specified server), or the specified server doesn’t exist.
My Apple MacBook Pro 2017 macOS High Sierra 10.13.4, upon reboot/startup, does not encounter this URLError condition and displays the BitBar Menu as expected. But my Apple MacBook might be newer than your model and hence able to ready the internet connection before BitBar requests a HTTP connection with SmartThings.
I have uploaded a new release of ST_Python_Logic.Py 3.04 that provides an error handler to trap for this HTTP error rather than raise a system error. Since I cannot determine whether the HTTP error condition maybe due to many different factors, I simply have BitBar print am error message that alerts the user to check their internet connectivity and refresh BitBar again.
yes, it would be nice to change the color with bitbar.
2 new thinks
If i add the new fibaro door/window sensor 2 to the temperature section i get the error:
fibaro motion sensor zw5 works in the temperature section, since yesterday i get an error with my 4 motion sensors (the old fibaro motion sensor (without ZW5 in the description)
I added some ‘NoneType’ error checking in these minor releases to account for a ‘NoneType value’ being returned in certain devices. It might mitigate this issue you are experiencing with the fibaro motion sensor. If you are on this release, let me know.
As far as RGB devices that have a capability of color changes, I’m not sure how I could add a micro side control for the RGB device like BitBar displays for devices with a dimmer capability (10%-100% by 10). Perhaps showing a primary & secondary color list instead of a dimming level? Is this what you are requesting?
