Conversely you could have one driver that only exposes the power monitoring capabilities if the device supports it. Just like the Generic Zigbee Switch driver. If your device supports power monitoring, you get those attributes. If it doesn't, then you don't. I would prefer to have less loaded into hubitat, personally. Makes it less confusing.
If that is what you want, then use the Generic one with PM features, no PM data will be shown unless sent by Tasmota (which a non-PM device will not send). The only exception would be PM-device specific settings.
I'm not using any of your drivers....I simply asked you why you had so many. Seems overly confusing to me, that's all. You only ever set the template on the Sonoff once. So, why bother having the driver do it when it takes about 2 seconds in Tasmota to do it? Are you going to make a driver for every Tasmota device?
Ok, to each his own, I would have to say that even though I've mentioned from the beginning in this thread, use the Generic driver and apply the correct Template, that is not always very easy and clear for everyone. In fact, you could paste the Template in the generic driver and the driver will take care of it for you. For me to create a driver which only need a Template/Module change and for the rest use base code from another driver it takes about 90 seconds, I happily make a driver which applies the right settings for whichever device someone requests. I also make one for every type of device I own.
There's also the special cases to handle, certain devices might have their LEDs behave better with different settings for example. These are things that I prefer to have in a driver.
How could this be improved to be less confusing for everyone? Probably by having even more clear instructions on how to choose a driver, instructions which don't require you to read this whole thread.
I understand your opinion, and partially I share it, at the same time, I happily help people out with a driver which will handle setting up the device for them. It doesn't take 2 seconds for everyone to set things up in Tasmota.
Then there are the very special cases, like TuyaMCU-based devices, Sonoff RF Bridge, IR gateways etc...
1 Like
Here is the information I believe you requested. Please let me know if you need more:
1) "Current States", as shown on the Device page does not update correctly when colorTemperature is set using the Tasmota web page (by browsing to the IP address of the bulb.)
This makes me think there may be a parsing error somewhere. For example, if I change the colorTemperature on the Tasmota web page, the "Console" page will report something like this:
20:34:09 RSL: stat/tasmota/RESULT = {"POWER":"ON","Dimmer":88,"Color":"0000009A46","HSBColor":"101,0,0","Channel":[0,0,0,60,27],"CT":262}
However, the "Current States" in the Hubitat device page reports:
Current States
- checkInterval : 1920
- colorTemperature : 3500
- driverVersion : v0.9.2 for Tasmota 7.x (Hubitat version)
- hue : 36
- ip : 192.168.1.99
- ipLink : 192.168.1.99
- level : 0
- module : [18:Generic]
- needUpdate : NO
- saturation : 0
- switch : on
- templateData : {"NAME":"Generic","GPIO":[255,255,255,255,255,255,255,255,255,255,255,255,255],"FLAG":1
The "Current States" do not change no matter what I set the colorTemperature to. However, if, instead of setting the colorTemperature, I set the Hue, then the "Current States" does update correctly:. For example, changing the Hue using the Tasmota interface, caused the "Console" page to report the following:
20:38:19 RSL: stat/tasmota/RESULT = {"POWER":"ON","Dimmer":88,"Color":"E0E0E00000","HSBColor":"115,0,88","Channel":[88,88,88,0,0],"CT":257}
Then the "Current States" in the Hubitat device page correctly reports:
Current States
- checkInterval : 1920
- colorTemperature : 3500
- driverVersion : v0.9.2 for Tasmota 7.x (Hubitat version)
- hue : 32
- ip : 192.168.1.99
- ipLink : 192.168.1.99
- level : 88
- module : [18:Generic]
- needUpdate : NO
- saturation : 0
- switch : on
- templateData : {"NAME":"Generic","GPIO":[255,255,255,255,255,255,255,255,255,255,255,255,255],"FLAG":15,"BASE
2) Setting the ColorTemperature in Hubitat does not properly change the ColorTemperature on the bulb.
For example, if I set Color Temperature to 4000 by pressing the "Set Color Temperature" button on the Hubitat Device Page, the message reported on the Tasmota Console page is:
20:42:00 RSL: stat/tasmota/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FFFFFFFF00","HSBColor":"0,0,100","Channel":[100,100,100,100,0],"CT":153}
If I then set Color Temperature to 2500 by pressing the "Set Color Temperature" button on the Hubitat Device Page, the message reported on the Tasmota Console page is:
20:45:30 RSL: stat/tasmota/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FFFFFFFF00","HSBColor":"0,0,100","Channel":[100,100,100,100,0],"CT":153}
So it seems that it is just turning all of the LEDs on full brightness, rather than setting the ColorTemperature parameter.
Note that the "Current States" in the Hubitat device page reports whatever value was set using Hubitat, however, this is not what the color temperature of the bulb is actually set to.
Current States
- checkInterval : 1920
- colorTemperature : 2500
- driverVersion : v0.9.2 for Tasmota 7.x (Hubitat version)
- hue : 0
- ip : 192.168.1.99
- ipLink : 192.168.1.99
- level : 100
- module : [18:Generic]
- needUpdate : NO
- saturation : 0
- switch : on
- templateData : {"NAME":"Generic","GPIO":[255,255,255,255,255,255,255,255,255,255,255,255,255],"FLAG":15,"BAS
My thought is there are potentially 2 bugs:
- The ColorTemperature value being retrieved from Tasmota is not being parsed correctly, leading to the incorrect display of "Current States"
- The ColorTemperature is being set incorrectly, and results in all 4 LEDs being turned on to 100% rather than the ColorTemperature being set.
Please let me know if there is any more information I can provide.
Thanks.
I fixed the retrieval of the ColorTemperature from Tasmota by adding the following code at line 266 to the expanded driver file.
if (result.containsKey("CT")) {
t = Math.round(1000000/result.CT)
if(colorTemperature != t ) sendEvent(name: "colorTemperature", value: t)
logging("CT: $result.CT",99)
}
I will now investigate the setting of it.
The fix for setting the color (at least for my bulb) was pretty simple. I just commented out the function
white()
at the end of the function
setColorTemperature(value)
It works fine now. Let me know if there are any side effects of the changes I made.
Thanks!
Ok, so I found one other oddity now. Tasmota sets B=0 (in HSB setting) when using ColorTemperature mode. Rather than using B for the "Level" value (as I understand you have set your code up to do) it uses the Dimmer parameter.
01:10:15 RSL: stat/tasmota/RESULT = {"POWER":"ON","Dimmer":28,"Color":"0000003413","HSBColor":"0,75,0","Channel":[0,0,0,20,7],"CT":244}
With the code the way it is set now, there is no way to set the brightness in Hubitat when using color temperate more.
However, setting the light color in Tasmota using HSB, B is always equal to Dimmer. Therefore, I think it would work better with Hubitat if your code always used "Dimmer" in place of the "B" parameter. This is required so the RGB light panel in the Hubitat dashboard works correctly.
If this is not clear, I can expand my answer. I'll probably try to change the code sometime this evening to see if it will work.
1 Like
This is mostly correct, should have been there to begin with, I don't have any RGBWW lights yet. Should have ordered them a long time ago, ordered them now.
The code should be:
if (result.containsKey("CT")) {
t = Math.round(1000000/result.CT)
if(colorTemperature != t ) events << createEvent(name: "colorTemperature", value: t)
logging("CT: $result.CT",99)
}
This is not a complete solution. I will fix it once my RGBWW light arrives.
It's clear, and I really should implement it that way, will see if I can get it right without having a proper light to test with, otherwise so in a few days.
Thanks. I should've looked a little more carefully.
Yes, I've realized since then that it doesn't handle the setting of state.colorMode correctly which causes some other problems. I assumed there may be some side effects I missed since I am not familiar with your code yet.
However, in thinking of how to fix thing, I played around with the light and Hubitat a bit more and have a few related questions that I have not yet found the answer to. Perhaps you will know, and that will influence how the driver is adjusted.
-
Is there a way from the Hubitat Dashboard to explicitly set the #RRGGBBCWWW values? It seems to me that Hubitat is always just setting HSB, and never the RGB values directly(i.e. I didn't see setRGB ever being called)
-
As I am sure you know, the type of light I am using actually has 2 white LEDs - one at about 2000K and one at 5000K. It blends them together to get different color temperatures. However, when setting the color temperature somewhere in the middle, Tasmota always decreases the PWM rate for those 2 lights to somewhere below 100%. It seems to just do a linear blend. However, I can make the bulb brighter by turning on both PWMs for the white LEDs to 100% by issuing a command like this:
Therefore, I think a possibly better way to set the color temperature is to have both of the LEDS at 100% in the middle color temperature (about 3500K) rather than have them both at 50%, which is how Tasmota seems to work. This will give a brighter light.
Did you ever consider adding code that allows directly setting the #RRGGBBCWWW values from Hubitat so the brightness of the bulb can be maximized? The control of Color Temperature could be directly in the driver, rather than Tasmota. Just an idea. Maybe not a good one 
Not sure about the Dashboard part, when I get my RGBWW light strips, I will check around... setRGB is used by the color functions, like Red, Blue and Green.
Yes, that sounds like a good way of doing it, let me see when I get my lights. Should also look more at how other drivers are doing it...
@hoi I found a good quality Tuya dimmer here in China (should be easy, but it wasn't, basically no dimmers available here, only switches). It will be shipped form the manufacturer on Thursday, so will have it here during the weekend. When I have time I'll look at these drivers again after that.
Created my first release of Sonoff RF Bridge and Tasmota + RFLink drivers. For these special drivers, please check out this thread.
Very sorry but i have a silly question. I have been flipping back & forth between many threads and tuya-convert youtube vids but i still can not find my answer.
I have been using the basic tasmota 6.5 FW on my Teckin SP10 for the last six months with the Sonoff-Tasmota ported to HE by dkkohler. Of course i used tuya-convert to do the FW upgrade on all 14 plugs that i have.
I am just getting around now to upgrading to your FW and drivers.
I understand that tasmota-hubitat.bin exceeds the 512kb size so i can not program this directly and that I need to load tasmota-minimal.bin first. If i understand correctly, this leaves enough ram in the device available so updating the flash with a larger bin file is supported.
So, my first mistake was going to the http page of my targeted plug and hitting FW upgrade and selecting the minimal FW and, well, i can't seem to get that plug back into program mode. My assumption, which i now understand was incorrect, was that the http page would still be available to do the next upgrade. (i know, i know). This device only has a single button/led on it. Right now i can turn the switch on & off, but holding the button for 4+ seconds no longer puts it into program mode.
Ok, so i had a new four pack of these things that i haven't touched yet. I updated my tuya-convert (to 2.0 i believe) and i can connect to the new one but i have not pulled the trigger yet to program it with anything because i am worried of a repeat.
Can some one please educate me on what i am missing or point me to a procedure somewhere?
The following do not address bin files larger than 512kb:
1 Like
I have not done many upgrades from 6.x using the web interface, but I can test doing so from the version you were using, send me a link to the bin and I will put it on one of my devices and then upgrade to 7.1.2.
I can say the following however, the Minimal build doesn't reset config variables, so using that for upgrading can be hit and miss from certain versions. For Tuya Convert I use the Basic version (my 7.1.2 binary), after that down to Minimal through the web interface and lastly from Minimal to tasmota-hubitat.bin.
So in short, if changing VERSIONS, best is to use Basic first, that has much higher success rate. I believe it is mentioned in the Tasmota docs as the ONLY supported upgrade path, or rather, that Minimal is NOT supported for version upgrades. I'll add that to the instructions here as well.
I has some issues originally with updating to to the 7.0 firmware and couldn't access the web interface and had to use the the fast power cycle reset the device.
This removes any setting but fixed the issue.
https://tasmota.github.io/docs/#/help/Device-Recovery?id=fast-power-cycle-device-recovery
Hi Markus, thanks for getting back to me.
Ok so v7 basic first, then minimal, then Hubitat bin files and I should be able to do this through the http interface and not have to screw around with TuYa-convert.
I am not sure I still have the 6.5 FW that I used. I have been screwing around with my pi over the last six months and started off fresh today with a clean install before upgrading to TuYa 2.0, so I may have lost the 6.5 file.
Nice. I will try this tomorrow as well. Thanks.
If you don't have Tasmota on the device at all, you'd need to use Tuya convert to begin with, or flash through serial. If you already have Tasmota on the device, Tuya Convert can't be used for flashing/recovery.
I just ordered 1 of these to have a play. Is this similar to what you are planning to try out?
