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

oh well. it was fun while I had it. I give up for today

Thank you for the ongoing updates.

I will install this fix when I get a minute and let you know how I get on.

1 Like

@jkp I have sent you a PM to see if we can get you back up & running!

Hi Kurt,

These latest updates also broke my existing functionality, unfortunatelyā€¦ Since Iā€™ve done a few previous updates since the beginning of this project, Iā€™m pretty darn confident that I properly installed the latest files (.sh and .py), and properly updated the app as well.

The app and saved files all reflect the latest version, but I mustā€™ve done something wrong since I now get this error:

01

I did notice an earlier post that mentioned an error similar to that first ā€œLine 622ā€ error, so I changed the ā€œRound temperature valuesā€¦ā€ option in the app to ā€œ0ā€ and selected the option to ā€œMatch all temp sensor valuesā€¦ā€, but that did not improve anything for me.

My BitBar setup was working great before - I would be very grateful for any thoughts/suggestions you may have to help get it back on the rails!

Thanks, Chris

@Hydro I have sent a PM to discuss this issue. ā€œList index out of Rangeā€.

This new error is being encountered because of the designation of Military Time format. Can you set your options to the following settings below in your ST BitBar Output App (in your mobile client interface) under Event History and Battery Display Options and re-test.

@Hydro Thanks again for patiently working with me to determine where these frustrating errors are in each new release. I will release a version that handles Military Time format this afternoon. Again, I apologize for the problems that come up with new releases given that this application has quite a few dependencies between all the display and device options, the ST Mobile SmartAPP quirks, Python and BitBar. But when it works, it is a piece of beauty!

1 Like

Just to update the community thread here, Kurt nailed it with a suggested settings tweak, and Iā€™m now back in action!

Thank you again to Kurt for his FANTASTIC support and work on this project!!

Cheers, Chris

3 Likes

I have the new ST.5m.sh file installed, have refreshed and all seems to be functioning.

1 Like

Dear @Nezmoā€¦ Glad to hear! Again sorry for the crash & burn install I caused for you!

2 Likes

Possibility for Humidty readings in the app?

1 Like

BitBar hates me it seems but I am making progress getting it partially working.:slight_smile:

Edit: back in business. I had to wipe out the entire thing and start with a fresh install. Things I discovered when setting back up.

  • You have to enter 0 in the Round Temperature values or else when you click Done, it gives you an Oops error.
  • You have to change the Events: DateTime Format as noted above or the bitbar app on Mac produces an error message.
  • If you choose a music player other than Sonos, the bitbar app on Mac generates an error while communicating with ST API
1 Like

Thanks for pointing these specific issues out @jkp. I have just updated the BitBar Output Application GitHub repository to V2.32 to address some of these issues:

  1. You have to enter 0 in the Round Temperature values or else when you click Done, it gives you an Oops error.
    • This is a SmartThings GUI issue that does not catch an invalid entry in a required numeric field until you save :rage:.
  2. You have to change the Events: DateTime Format as noted above or the Bitbar app on Mac produces an error message.
  3. If you choose a music player other than Sonos, the bitbar app on Mac generates an error while communicating with ST API.
    • This is unexpected since I thought that STā€™s APIā€™s for handling ā€œMusic Playersā€ would be identical for Sonos and Non Sonos music players. Since I do not have non Sonos music player systems, I might have to rig something else up to explore the bug.

Again apologies for the issues with 2.31, but the good news is that v2.32 now supports Relative Humidity Sensors as requested by @pmjoen

3 Likes

[Release 01/22/2018] BitBar V2 (2.32) - Humidity & Bug Fixes

Upgrade Components Requirements (GitHub Link):

  • BitBar Output ST APP 2.32
  • ST_Python_Logic.py v2.32
  • ST.5M.sh- v2.32
  • Launch ST Mobile Client. You must configure and save settings in your ST BitBar Output APP after the above steps are completed. If you wish to display Relative Humidity Sensors, you must select them in the devices section and enable specific display options and SAVE.

Changes

  1. Added the display and control of Relative Humidity Sensors. Must select your relative humidity sensors as a display device in the ST SmartApp GUI.
  2. Updated SmartApp GUI with various new display options to support humidity
  3. Fixed Military Time Format bug in event-log display

Notes

  1. For most users, it is recommended that one use their favorite text file editor (e.g. Textedit) to edit the old versions of the Python (.py) and bash (.sh) files on the Mac in the BitBar Plugin subdirectory that need to be updated. Delete all old text (select ALL), and paste in the new versions text from the GitHub RAW view of the same named file. Save the file.
  2. For the SmartThings SmartAPP, Use the SmartThings IDE to edit the BitBar Output App SmartApp, Follow #1 above and remember to Publish.
  3. Using the mobile ST client, navigate to Automation and the BitBar Output APP SmartThings and verify ALL entries. After review of all the entries in the mobile clientā€™s SmartApp GUI, please SAVE it so it can regenerate all values you have selected.
    • Verify the Header of Main Screen to insure that you are at the correct 2.32 versions
      image
2 Likes

Thanks for the humidity changes, using for my whole house humidifier and Cigar Humidorā€¦

1 Like

@kurtsanders, I have just noticed that my switches are now sorted by active status. That did not happen before. I know thereā€™s a menu option for sensors for sorting by status but there isnā€™t for switches. Regardless, I have sensor sorting by active status off anyway.

Also, I noticed issues with the Sonos info early on but waited to get more data before reporting. I have 12 Sonos players and the status for them is all over the place. Volume info seems correct as is grouping info but track names and status is over the map (BitBar says playing when Sonos player is actually stopped or it has no status at all like after Sonos system restart, etc.). I can provide more detail and assistance with troubleshooting if needed.

Hello @Nezmo,
Thanks for your feedback, itā€™s always appreciated. I hope I understand your questions, if not, PM me and we can discuss further.

BitBar Output App Display Sorting

In the current BitBar Output App version (Display Options), there are two True/False choices for sorting ALL Sensor Types either by Name and/or by {active} Value, which results in the following logic:

Sort by Name : Sort by Active Status

- 0 False : False: No Sorting, device list is presented in the menus as the SmartThings platform decides.-.
- 1 True  : False: Sort by Name, device status is not considered
- 2 False : True:  Sort by Active Status, name is not considered
- 3 True  : True:  Device list is sorted first by Name, then device value, eg. on/off, active/inactive, open/closed, etc.

I could expand this display logic in the next BitBar Output App version by device providing granularity for each device type category if that is what you are asking for switches, but not for motion, locks, temps, etc?

Musicplayer

As for the first version of BitBar Output App V2 displaying Music Player information for Sonos players, I agree with you, that SmartThings and Sonos have some work to do.

SmartThings has always stated that their Sonos API interface is Ī²eta and they expect Sonos will officially release a new API interface in the future and they will support that in future API updates.

In my testing, it appears that each Sonos Player, when paired in ā€œGroupā€ mode, has random and/or invalid extended information for Track, Status, Station/Title, Track Number.

The ā€œMasterā€ Sonos grouped extended device information appears to be valid as the other subordinate players are all over the board for their API information from SmartThings.

I was also disappointed to hear from other BitBar Output App testers that non-Sonos musicplayers do not work. The SmartThings musicplayer API is supposed to be manufacturer agnostic, but apparently not?

No problem Kurt, always glad to help.

As you state I see two options in the SmartApp:

Sort sensors in menu by name (I have this **on**)
Sort sensors in menu by active status (II have this **off**)

So ā€˜sensorsā€™ means all devices in this context? Regardless I do see now that not just my switches but my sensors too are sorted by active status yet I have the settings set to sort by name. This is new as in the prior release they were all sorted by name only which is what I want.

It would seem the logic is not quite working as intended.

Fair enough. I wondered if this was the same issues seen elsewhere but I do get correct info in ActionTiles.

[1/30/2018] Minor Version Upgrade: Corrected SORT SENSORS BY NAME Display Option

Thanks to @Nezmo who found a bug in the ā€˜Sort Sensors by Nameā€™ display option, I have provided a new minor version (2.33) of ST_Python_Logic.py to the Github Repository which will sort oneā€™s ST sensors in each category by Name Only (as expected) when that display choice is set ON and Sort Active is Set Off in the BitBar Output APP.

If you noticed an issue with display sensors by name, please upgrade your ST_Python_logic.py v2.33.

2 Likes

Nice work Kurt. Thanks for your continued work on this.

1 Like

Uh oh ā€¦

43%20PM

2 Likes

@Nezmo: Iā€™m getting this ERROR as wellā€¦nothing changed on my side AND WAS WORKING perfectly all week : Iā€™m guessing ST Cloud issueā€¦

RateLimitExceededException

{uā€™messageā€™: uā€™An unexpected error occurred.ā€™, uā€™typeā€™: uā€™physicalgraph.exception.RateLimitExceededExceptionā€™, uā€™errorā€™: True}
Error while communicating with ST API