[Release] Tasmota Comprehensive RGBCCT Device Handler w/MQTT for SmartThings Classic - V1.1

I’m a fan of Tasmota but found the existing device handlers for color Tasmotized bulbs to be very simplistic given the reach feature set of Tasmota. This screen shot shows most of the capabilities of the device handler. What is not obvious is that you can toggle between “Device” and “MQTT” for controlling multiple devices simultaneously.

If this gets your interest you can find a video walkthrough demonstrating the capabilities of the device handler here: https://youtu.be/hC1wcNZveCo

You can find the documentation here: https://github.com/GaryMilne/Tasmota-RGBCCT-DH-for-SmartThings-Classic-with-MQTT/blob/master/Smartthings%20Classic%20Device%20Handler%20for%20Tasmota%20RGBCCT.pdf

You can find the code here: https://github.com/GaryMilne/Tasmota-RGBCCT-DH-for-SmartThings-Classic-with-MQTT/blob/master/Tasmota%20RGBCCT%20Driver%20for%20SmartThings%20wMQTT%20V1.1.1.groovy

3 Likes

Hi!

First thank you for this amazing DHT!

If i flash one Arilux RGBW LED Controller with Tasmota and connect it with an LED Strip, will it work?

Thank you,
Vlad

That is a good question. The DH simply uses web requests to execute the commands as if they were typed in at the console. So if you can execute the following commands at the console without any errors then it should work for you.
Power on & Power off - Power
CT 153 & CT 500 - Color Temperature (these are the valid Tasmota limits)
Color 1845FF0000 - Change color to blue for example
Dimmer 20 & Dimmer 100 - Changes the brightness
Fade On & Fade Off - Turn fade off and on
Speed 7 - Change dimmer speed to 7
State - Return the current status (used by the sync process).
BACKLOG Rule3 on power1#boot DO color FF14BB0000 ENDON ; rule3 1 - Sets power on color
BACKLOG Rule3 “” - Removes the boot color by deleting rule3.

If you can do all of the above things at the console you should be good. If not then it probably means that Tasmota does not see your device as RBGCCT.

Hi,
Thank you work the good work. I have been trying to use your code to create a new device handler in smartthings IDE. But when I click create after pasting the code, I get the following error:

Org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update

Can you please help with this?
Regards,

Hi Manoj, another user with the same issue has made some progress on this. See this post on github.

Gary,

I just flashed my first MagicHome module. All went well, and I can easily control the device using the tasmota webpage. All of the functions work just fine.

However, I cannot get your DTH to control the light. I’m not sure where I went wrong, or what I’m doing wrong. Any help would be appreciated.

I’ve tried another DTH, and have same problem / result.

Thanks.

EDIT: note that I am NOT using MQTT for control

First click on the DNI button to make sure it gets assigned properly.
Then take a look at the “Live Logging” tab for clues on what is happening.

I saw your post on the Hubitat forum. The answer is a lot simpler than you are making it. There is no need to capture the command sent to the device is a variable. The easiest way to confirm that the correct state is returned to to not generate the events for any of the attributes until the device responds back with its new status. So, if you want to turn the device on, in the on() method, you issue the command to the device to turn on. Then in the parse method you send the event that the switch has turned on. This means that if it didn’t turn on, the switch attribute will still be off. If you wait for confirmation, that’s already too late. The event has already gone out to the system.

Ryan, I understand what you are saying and I like that approach but I don’t see how it solves the underlying problem.
If you issue the command: color 000000461B
Tasmota responds: {“POWER”:“ON”,“Dimmer”:27,“Color”:“000000461B”,“HSBColor”:“0,0,0”,“Channel”:[0,0,0,27,11],“CT”:250}

I can parse the above response but if I don’t know the nature of the original request I can’t tell if I should be sending an event to Power, Dimmer, Color, ColorTemp etc? Am I missing something in your explanation?

You don’t have to know.
If you send an event and the value is the same as it was, then no event will be generated. For example, if you issue the follow:

sendEvent(name:“switch”, value: “on”)

when the switch is already on, the event will not be posted.

But if you want to generate events for any value that changed, just compare to the new value that the device is set to.

Your question seems to be that you want to set the device to the values that you ordered rather than the values the device reports. In my mind, it doesn’t matter what you ordered…only what the device currently is. You don’t want to base the display of the attributes on what you ordered but on what the device actually is.

1 Like

I understand what you are saying vis-a-vis only changing the state in parse(), which makes perfect sense.

There are two things my driver does that may have to give up with that model. A) Blocks secondary requests until the first request is either fulfilled or times out. B) Measures responsiveness and detects timeouts.

But I’m hopeful that I may be able to get the best of both worlds.

Thanks a lot.
P.S. I did not know that a send event would be ignored if the device was already in the desired state. I over-complicated my code in places ny checking the state before sending a second request.

The only thing better than writing code, is writing better code in less lines.

Why would you need to do this? If the light hasn’t changed, are you going to try and re-issue the command to the device? There are so many different ways that this could be handled.

This is already done if you are using an HTTP call. You will get a response code or no response at all.

The fact remains, if you make the attribute changes when the request is issued to the device, it won’t matter if the request times out or the device doesn’t update. Your device in ST is already changed. What if the you have lost connection to the device? You can issue the command all day. The reality will be that your ST device will not match what is true on the device. As a general practice, that is unacceptable. This is not just true for Wifi devices but is the standard practice for Z-wave and Zigbee devices as well.

It is not that the send event is ignored, it’s that the event is not posted to the system unless there is a change in the attribute or the parameter isStateChange is set to true manually. There’s nothing wrong with double checking in your driver.

[quote=“Ryan780, post:12, topic:179937”]
Why would you need to do this? If the light hasn’t changed, are you going to try and re-issue the command to the device? There are so many different ways that this could be handled.
[/quote] By having a timeout on a transaction I was able to identify a non-responsive device and have the code branch accordingly.

But I realise now that there was a better way thanks to your earlier comments. But I did it this way so that I could correlate the command and the response when it came back to parse. The DH did not make the change to Smartthings until I got the confirmation back in parse() , which I then parsed and compared to the command that was issued. So it kept things in sync, but not so elegantly.

As I mentioned above I correlated the response to the command and only updated the device when the transaction was confirmed. But I created a lot of extra work for myself in doing so.

Bad phrasing on my part. I understood what you meant.

Thanks for all of your advice Ryan. It really has been very instructive and I look forward to trying out the changes you suggested.

Hi Gary,

Very impressed with your work. I have an LED strip controller, Arilux LC01(RGB) flashed with Tasmota that I cannot get to work in ST. Is there a chance this can be used ??

Thanks
Mike

Yes, some or all of it should work. It sends Tasmota command lines to the device so in the end it’s a question of compatibility. By that I mean does the Arilux support the same Tasmota command set as a standard RBGCCT device.

If not feel free to modify the code. I moved over to Hubitat as I didn’t like the direction SmartThings was going in. Hubitat allows me to have everything locally and has good (third party) Tasmota support.

Hi Gary,

Your device handler is one of the most comprehensive I have ever seen. Amazing work. Unfortunately, in the last two weeks I have been “forced” to move to the new Smarthing app and I can’t get it to work. It says “Can’t connect to device”. It still works in the classic app so there should be some piece of code the new app just doesn’t like. I see you have moved to Hubitat but any tips to get it to work?

Unfortunately the new Smartthings severely limits the UI display for the developer and prevents any real customization. Because my driver had many custom features that would no longer work I decided to abandon Smartthings. My driver will not work in the new Smartthings in any recognizable form.

Sorry.