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 fuzzy logic to display either a discrete known color name from a hue value of the current device or a color range using the following RGB values and comparisons:
if (r>=g & g>=b) {colorRGBName = "Red–yellow"}
else if (g>r & r>=b) {colorRGBName = "Yellow–green"}
else if (g>=b & b>r ) {colorRGBName = "Green–cyan"}
else if (b>g & g>r ) {colorRGBName = "Cyan–blue"}
else if (b>r & r>=g) {colorRGBName = "Blue–magenta"}
else if (r>=b & b>g ) {colorRGBName = "Magenta–red"}
Just updated. Seeing a bit of an issue. I manually updated the Python file and double checked the new version is in my local directory but the SmartApp is not seeing it as it still says 3.12 is loaded. I wonder if this is the same as an old problem some of us had and we had to run a terminal command. However, the last several updates have been fine for me.
That is definitely strange and it appears that somehow BitBar.app is only seeing the old version! I’m proposing that you could:
Reboot the Mac
Quit the BitBar application (⌘ Q located in the BitBar Preferences section of the displayed BitBar Menu & then Restart BitBar.app in your Mac’s Applications directory
and see if that reloads the current ST_Python_Logic.py 3.13 file.
I have also since tried deleting the py file and refreshing. The BitBar app could see the file was missing. I then recreated the py file and I am back to the error posted above.
And … while just watching the logs I also saw this … unrelated I am sure but just FYI:
10:03:18 AM: error java.lang.IllegalArgumentException: 234255255 is not a valid hex value. @line 456 (doCall)
I placed a updated 3.13a bitbar-output-app.groovy release in the Github repository and let’s try that version for the groovy code. If you are updating the groovy file from the “Update From Repo”, it should be an easy IDE upgrade, the 3.13 ST_Python_Logic.py file is the same version and does not need to be replaced as long as both versions are in sync.
Please run the live logging window when refreshing the BitBar menu on the Mac so I can verify that we are all running 3.13 and capture any error messages that you are seeing in the log.
Here is my log window for a LIFX bulb. I am sorry about the issues in this release, but I can only work with errors when I see them. Thanks for being patient while we sort out how our instances and devices are different.
@jkp. Please update the BitBar Output APP groovy file again (3.13c) in the ST IDE. I have updated this interim version with a check to see if the DTH for the colorCapable device supports the refresh() command. Ugh, I thought that all switch device DTH’s supported a refresh command…
As far as the error with uppercase??? I searched in the groovy file and did not see any line with that command?
Add back one of your color lights at a time into the BitBarOutput App and save, then refresh the menu bar on the Mac and see if you can get through the error.
I have half a mind to remove any non necessary functions in the groovy code in the ‘456’ section and process them on the Mac Python file. Hair is falling out!
I can see that you are running 3.13 code on cloud and Mac from the live logging. I am not sure why the ST BitBarOutput APP display showing a previous release in the top of the screen. I will hunt that down once I have this code stabilized for all the different RGB devices we have installed.
Me too. I am going to install a rear view mirror camera kit in the 08’ Civic. Perhaps I can make that work!
Note to Others: The errors are dealing with light devices that support color. If you encounter unrecoverable errors, return to v3.12 in both groovy and python files, or remove any color devices from the BitBar Output App device list.
Glad to hear @Nezmo, I always try to test as much as I can, but it seems that working with a variety of devices and manufacturers causes unforeseen errors.
Do you have all your color capable devices reporting and setting colors accurately from the macOS Bitbar menu?
Did the BitBar versions match what you are running in the ST Mobile BitBar GUI?
I think I still have some tweaks and bugs to work on, especially with adding checks to make sure that switch devices can accept set levels like, dimmer, hue, saturation, etc. I was going under the assumption that a color capable device had all those basic attributes, but apparently not.
BitBar V2 v3.13d Additional Checks for Color Capable Set Commands (3/4/2018)
** This minor version release is the ongoing effort to catch some of the nagging bugs that were introduced when BitBar V2 3.13 added support for color capable devices.
Added additional validation checks for set commands to color capable devices which will resolve some SmartThings DTH’s that do not support selected common set commands; eg. setColor() and setSaturation().
In this minor release, one can inadvertently try to change the color or saturation level from the macOS BitBar menu, but these settings will be ignored when sent to SmartThings if the DTH does not support these commands.
** In a future release, menu SET choices for color capable devices will only display valid commands. For example, if saturation or hue is not supported, the menu will not display these.