I am using the Brilliant smart bulb. I find it will let me change the colorTemperature in app but it doesn't change the bulbs color to say cool white it seems to be always stuck on warm white. btw it does color selection fine though. Any ideas?
https://www.officeworks.com.au/shop/officeworks/p/brilliant-smart-rgb-and-white-globe-e27-bl20876
https://blakadder.github.io/templates/brilliant_20699.html
I noted the driver does not have the option to enable or disable debug logging or descriptionText logging. As such I am finding I have a lot of the below in my logs but no way to remove them. Can you add these options to a driver update please?
dev:11272019-12-08 07:25:06.791 pm debug[POWER:OFF]
dev:11272019-12-08 07:25:03.720 pm debug[POWER:OFF]
dev:11272019-12-08 05:00:00.856 pm debug[POWER:ON]
dev:11272019-12-07 09:00:01.304 pm debug[POWER:OFF]
dev:11272019-12-07 05:00:02.366 pm debug[POWER:ON]
dev:11272019-12-07 11:13:08.800 am debug[POWER:OFF]
dev:11272019-12-07 11:12:20.117 am debug[HSBColor:0,0,0, Dimmer:100, Color:000000FF, Channel:[0, 0, 0, 100], POWER:ON]
dev:11272019-12-07 11:12:18.687 am debug[HSBColor:0,0,0, Dimmer:100, Color:000000FF, Channel:[0, 0, 0, 100], POWER:ON]
dev:11272019-12-07 11:12:16.207 am debug[HSBColor:0,0,0, Dimmer:60, Color:00000099, Channel:[0, 0, 0, 60], POWER:ON]
dev:11272019-12-07 11:12:11.332 am debug[HSBColor:0,0,0, Dimmer:30, Color:0000004D, Channel:[0, 0, 0, 30], POWER:ON]
dev:11272019-12-07 11:12:08.378 am debug[HSBColor:0,0,0, Dimmer:20, Color:00000033, Channel:[0, 0, 0, 20], POWER:ON]
dev:11272019-12-07 11:11:54.940 am debug[HSBColor:0,0,0, Dimmer:100, Color:000000FF, Channel:[0, 0, 0, 100], POWER:ON]
dev:11272019-12-07 11:11:52.174 am debug[HSBColor:0,0,0, Dimmer:100, Color:000000FF, Channel:[0, 0, 0, 100], POWER:ON]
I don't think that bulb supports changing to any other color temperature. The store page only mentions "3000 K warm white". And the Tasmota template page has it as RGB & Warm White only.
Ah I totally missed that thanks mate. I just checked online and it seems that alot of similar RGBW bulbs advise "RGB and warm white dimmable bulb". It's all good I actually don't mind the warmer color but I just thought i'd ask to see if something was wrong.
Now if I can just stop it from dumping debug's into the logs I will be happy. I believe that @damon.dinsmore can simply write that into the device driver.
It's on my radar
First time poster, Just got my hubitat today and am already in love with it and the community here.
In less than 20 minutes I was able to learn all about bulb flashing, locate a user written driver, determine my Walmart special Merkury RGBW (2 for 15) bulbs should be easily flashed to Tasmota Firmware with tuya convert obtain everything i needed to begin.
Fired up a persistant live usb of linux, installed the flasher and had the first bulb of 12 flashed configured and working with your driver in less than 5 minutes. And I literally have done nothing else with hubitat yet.
I am impressed!
The template for the bulb is available here. There are several other variants already listed and I will be adding the 2 alternates i found within the 6 packs of bulbs i got around black Friday.
Hey you all
First off: thanks a lot for the work you put in all of this!
So I added the driver which supposedly supports google home and it does but what I notice is that when I start of on pure white in CT mode and change to a color e.g. red it can not activate the white LEDs anymore. So when I tell google "Turn xy warm white" it just loads endlessly. Also when color picking it does nothing. When I start in white mode I can adjust the white perfectly but as soon as I pick a color its gone - any ideas?
I am using the hubitat tasmota tree on 8.1 with a magic home controler and RGBW LEDs
Unfortunately I haven't had any time to work on the drivers but,
You need to add a few lines of code to the driver to get Google home to work,
capability "ColorMode"
capability "Refresh"
That should fix your issue.
These lines are in, it works except for that white issue.
I just realised it is the drivers from Obi2000 that didn't work. Yours, damon.dinsmore, do perfectly if you add those two capabilities. I'm sorry for the confusion!
2020-01-24 19:20:26.761 warnReceived data from 192.168.178.237, no matching device found for 192.168.178.237, C0A8B2ED:D844, C44F33A1066E or C0A8B2ED.
I get this log everytime I make a command in hubitat to the stripe. The led does what it's told so no big problem but this message clusters my logs and I believe this could be solved?
I have updated this driver v1.0.4 with an option to disable Logging.
BUT... The log that you have posted does not look like it is coming from my driver.
Please update and see if it does fix your issue.
Well the IP is the one of the LED stripes I drive with your driver 
so I believe it had to be that one, otherwise no device would send to hubitat... would it?
Have updated, logs are disabled now. Thanks for that feature!
I believe (99.5% sure) the issue is that you flashed your lights with the Hubitat specific tasmota firmware that is meant to be used with that specific tasmota driver. That firmware has a setting to report state changes back to hubitat which will result in that warning if not using the proper driver with the firmware as other drivers aren't expecting that data.
This driver is meant for devices using standard/generic firmware. It still works because the underlying command are the same, but your getting extra data back to the hub you cant use, which is wasting some of your resources.
You options are...
A. Re-flash your bulbs with tasmota-minimal.bin then tasmota.bin from either the maintenance release here http://thehackbox.org/tasmota/ or the main branch here http://thehackbox.org/tasmota/release/
B. Uninstall this driver and use the one your firmware was written for found here : [DEPRECATED] Tasmota 7.x/8.x firmware for Hubitat + Tuya, Sonoff and other drivers - #414 by anon62731458
C. Do nothing since everything "works" but if you experience hub slowdowns after a few days look into this as http stuff is suspected as a potential cause for the hub slowdowns some users experience after several days of uptime.
This is definitely my Tasmota firmware modified for Hubitat sending data. You have two more options:
D. Go to http://192.168.178.237/co and disable the Hubitat / SmartThings feature.
E. Change the "Device Network ID" of your device in HE to your device MAC "C44F33A1066E" or IP "C0A8B2ED". The parse function of this driver will then receive the data and should just discard it. Watch the logs for errors, but there shouldn't be any. The parse function "should" ignore anything unexpected.
Unless Teleperiod is set to anything other than default, that is one message every 5 minutes. And in terms of wasting resources, I seriously doubt that. Not from that. There's other things which are way worse.
Let me preface by saying I am a beginner here and am still learning, so please understand I am not trying to argue with you at all, I am explaining my understanding of things, in hopes of having misconceptions or understandings cleared up for myself and anyone else who comes across this.
When i was using your firmware, i have reverted until you get the new version out which hopefully uses 8.1.0.6 for the connectivity adjustments, (they really help with getting your devices to use and stay on the best signal AP) I was under the impression any commands sent to the light resulted in it sending back that data so hubitat could remain properly updated on the lights state.
I didn't realize they auto sent every 5 minutes.
It might not seem like much but when you have a high number of these lights like oh say 60, thats 720 extra data points being sent per hour, and if I understand the functioning could be another 60 per light change if someone has a scene or mode that changes every light to a setting without any checks on state first.
There are other things that are worse yes, but some extensive reading the past few days has led me to understand the developers recommendation is to eliminate as much excess data sending between devices and the hub as you can, and if hes not going to be using the data why have it being sent to begin with?
Also it seems that the slowdowns some end up encountering are suspected to be partially related to http traffic, and i personally noticed a 20-40ms increase in the time it took the lights to change from motion detect etc with that hubitat settings enabled. Disabling it from the web UI for the light removed the increase.
So yeah not much at all BUT if your pushing the edge of that 250ms window of perception that small amount of resources saved from processing that data can be the difference from the lights feeling instant or delayed and having a high or low WAF/HAF.
Let's start here, did you notice a difference? If so I'll release 8.1.0.6 in a few hours most likely, just that I'm very conservative in making new releases unless it is for stability or some required features. I have my 50+ wifi devices reporting 76% connectivity and up. The RSSI value in Tasmota is actually percent.
This is the "heartbeat" of Tasmota, it can be adjusted to be once every 3600 seconds by using the command "teleperiod". Some of my drivers do keep it at 300 seconds though. My new driver currently only in the development repo can adjust it in the driver settings for all device types. This is NOT released and only for testing.
There is no real reason as to why you'd want to receive it, but with the number of devices I have, I have no decernable issues. But then I don't run basically anything except my own drivers and app + built-in and drivers from one other developer.
It is possible, I'll be running some more benchmarking against timing once I have my new drivers out, they have a bit more code, but are better and more optimized so they do run faster than my old drivers. Disabling that might result in unsynched states when using my drivers, but usually that is more an issue with dimmers. And for sensors it is of course needed to have it active. Polling is the real problem, that is something my drivers NEVER do.
To each his own, my WAF is high, so I guess it's all good 
But yes, many things do come to play in this. I find I save more time in not using RM or other Apps and to use my own App tailor-made for my own use so that there is NO extra anything except the logic needed to get my home to work. That saves me more in response time than disabling callback from Tasmota.
With all of the above said, slowdowns are hard to diagnose on this platform, all I can say is that I do all that is possible for speed, but not at the expense of sacrificing having correct states.
Please confirm that you really have better connectivity with 8.1.0.6? But do so in my driver thread, please.
EDIT: To clarify, I have 52 Tasmota devices in my network as of yesterday, and 60+ Zigbee devices.
@markus I'd love to run on all my own code, but im no where near the point id feel capable of doing so. I'll get there eventually though, in the meantime we have awesome people like you sharing what youve done 
I currently have 28 zigbee devices connected with 5 more gen 2 iris outlets) on the way. I have a total of 60 tasmota bulbs going inside, and another 20 going outside. Currently only have 24 of the bulbs online, still putting in recessed cans in the rest of the rooms before adding the lights in.
I've been moving away from RM and towards apps with less overhead, in fact i only have one rule in RM and that is just a stupid on push play random message rule. I only have one user made app. and thats an alteration of simple motion lighting which i still need to figure out how to add fade in and out and lux control into, then i can do away with the inbuilt motion lighting app as well.
I love the platform but i am in the I wish we had some proper resource monitoring tools, and access to all the logs etc the devs have camp.
I'm not used to having the ability to run custom code without anyway to detect loads access to real logs etc...
I can partially understand the developers standpoint on it, we dont need a bunch of people on here making threads and opening support tickets because they think the load is too high even with a fully responsive and snappy system.
But since this platform is clearly intended for the enthusiast/hobbyist and not the consumer market that argument really doesn't make much sense as the community is the heart of the product and the first line of support. Be a lot easier to diagnose issues if we could see usage stats and be able to pinpoint for example that all systems encountering slowdown are having process x go into a loop cycle after x hours have passed, but what do I know lol
Ok enough derailing this thread, I apologize for that, I seem to be forming a bad habit of doing that... over to markus' thread to post about the 8.1.0.6 thing.
@markus I'm starting to move all of my drivers over to your firmware. I have all but my ifan02/ifan03 devices working with it at this point. I would be willing to work with you to convert them or if you want to take my driver and see what I'm doing and convert I'd be happy with that. I'd love to be able to shut down my drivers as your way has less overhead and I really don't have time to move to async http.
Download the Hubitat app
