#Url for bitbar mining code#

Well, that makes sense, and so glad you are back up and running! Well, don’t question a miracle I suppose - just glad to have good ol’ BitBar working smoothly again Thank you for all your work to make this great feature possible!! Well, don’t question a miracle I suppose - just glad to have good ol’ BitBar working smoothly again Thank you for all your work to make thsi great feature possible!! Well, heck, now that I think about it, I also added my ceiling fan state to BitBar last night – it connects via Bond, and it still has that default “placeholder” Device Type, and it’s showing up just fine in BitBar. The devices all still seem to otherwise work fine thru ST, but that “placeholder” DT makes me leery. Oddly enough, I’ve noticed that some of those new brand/device connections that are available for the new ST app bring devices over with “placeholder” as the Device Type – the new Honeywell TCC and Bond connections did it. I swear on all things holy I tried that very same Device Type switcheroo last night when I updated the TCC integration (and it didn’t work), but maybe I was half-asleep and was missing something! Or some overnight fix-it elves worked some magic - who knows! I just now updated the stat’s Device Type in IDE to “Honeywell TCC Thermostat” and that did the trick! BitBar back to rockin’ steady

#Url for bitbar mining code#

Can you identify the DTH that it is using so I can look at the source code (if available) and perhaps a screen grab of the My Device Data page with the values Since I don’t have a Nest thermostat I cannot test/fix what is causing this 500 error.

This works for Ecobee which is a cloud control thermo, but then again, I am running them with Ecobee Suite custom DTH, not ST’s OEM DTH. Thanks for pin pointing this, and I imagine you are right? Interesting, ST’s standard DTH’s are ‘supposed’ to return ‘standard’ metadata information from a Thermo capability device, like Nest, and that is all BitBar is requesting in this subroutine from above, nothing magical about those thermo metadata results which BitBar needs to display them for you. No big deal - maybe that new TCC connection has some kinks to get worked out. Since the timing is so coincidental, I suspect it was related to me switching my Honeywell Prestige 2.0 thermostat from the legacy Honeywell TCC connection to the new TCC (Total Comfort Connect) version that was just released for the new app.īitBar does not like that new TCC integration for some reason - when I removed that thermostat and refreshed, everything else in BitBar worked fine.

If interested, just start a PM to (just click on my name and select message) I prefer to do this extended debugging via a private message. If you are willing, I can try to debug your RGB device over the next week or so given my crazy schedule, but that will require some sharing of your ST API strings for BitBar and the device re-added when I start to debug what you are experiencing. I would recommend, for the short-term, that you remove the offending RGB color lightbulb from BitBar devices in the SmartApp Your remaining well-behaved devices will then function in BitBar… Log.debug “Trapped Error: colorRGBList = colorUtil.hexToRgb(RGBHex): RGBHex = $” I trap for unexpected results since their are so many manufacturers of RGB light bulbs, that SmartThings just passes something I cannot work with.ĬolorRGBList = colorUtil.hexToRgb(RGBHex) That particular trapped program error is related to a RGB type color bulb device that is not reporting an expected currentColor (See below code snippet).