Hi
Yes I have used the double relay/switch and the triple relay/switch, how do I add the second switch as a button on the dashboard?
As you can see with the old driver each light was "exposed" as a separate device. Now it is one device with 2 switches? How do I add a button on the dashboard for the second switch?
Thanks for help.
I have changed this 2 switch light fixture to your driver and I have not deleted the old ones below just to show you.
I don't use dashboards, partly because they are ugly and rather limited. If you want something prettier take a look at sharptools.io. They have an Hubitat approved app that shares all the devices and state with their platform and can produce prettier results but it costs $25/year.
But in answer to your question this is what you have to do.
Create a Virtual Device
Create a rule like this.
Basically, when the virtual switch is toggled it triggers the rule. The rule matches the state of the Switch2 on the physical device to the state of the switch on the virtual device. The key is that you have to use the custom command options for your actions.
and now you have what you were looking for.
I was hoping to create an app that would allow me to do all this leg work and make it easy to create these linked virtual devices but there is no API to create rules so they have to be done the manual way. It's a powerful platform but geared towards those that don't mind a little tinkering.
I CLAIM VICTORY!! @GraphicHealer Might be happy to someday come back to know that I have successfully frankensteined the "Fan with Dimmer" driver to work with this tuya monstrosity!
For the google machine wanderers that find this, I have managed to get the Treatlife DS03 fan and dimmer controller talking to hubitat perfectly.
It's literally going on 4am here, so I'll come back with updates another time, but just wanted to pop in to do my victory lap before bed. Managed to get my 3-way issue figured out too, but that one was much less polished. I may go in to rework it, just because, or I'll choose to not rip out the little hair I have left and just leave alone what is working.
Anyway, thank you so much for these drivers. Much of "my work" was copy/pasting code you already wrote and tweaking variables and such to make it work for me, but it never could have been possible without you blazing the trail. Thank you so much!
Dude! That's awesome! I still can't freakin get anyone to buy this samsung SmartThings hub off me. I wanted to sell it first so I can then effectively swap it out for a hubitat. I had one guy, but he ghosted me at the last minute. Still waiting. Errrg.
Im thinking about just getting a hubitat for family Christmas, along with a replacement smart remote for the harmony 900, cause no matter what Logitech says, there ain't no way their servers will continue to work forever.
Any one know of a good replacement remote like harmony? One that possibly works with hubitat?
Anyway, rabbit trails aside, that's pretty cool. I definitely know the feeling of a project FINALLY being successful. It's such a good feeling. Programming can be a pain in the rear when its not cooperating.
Well, when I actually get a hubitat, I'll let you know how it goes with my DS03.
Congratulations, quite satisfying when it finally works. I look forward to some details.
@GraphicHealer Forgot you mentioned that you haven't gotten the hubitat yet. When you get it and need help getting this stuff set up, feel free to reach out. 
Gary, where do I begin? The 3-way is easy, so I guess I'll start there. Keeping it simple, I made a copy of the single relay driver and made it so that the on/off commands are always sent to "Power2" (the A/B relay) via a "toggle" command, and that the syncTasmota stuff listens for changes in Power1 (the load-sensing relay). Hub UI updates with the actual load status, and tapping it or telling it to turn the thing on or off will always switch the relay via a toggle command. ... As I'm typing this, I realize that probably will become problematic if a light is already on and the hub sends another on command, it will then toggle Power2 and thus turn the light off.... hmm. Need to play with that more. I was just happy I got it to stop "rave party"-ing and the UI was updating appropriately.
As for the other device, I'll try to keep it simple, but it was a very lengthy process. I basically swapped out bits and pieces of your driver to accomodate the TuyaMCU stuff. "FANSPEED" commands going to tasmota became TUYAENUM4 (props to Obi2000's driver for that little discovery that TuyaSend4 wasn't necessary; it simplified things), changed power1 and power2 accordingly so dimmer commands would stop turning on the fan power toggle, learned what SetOption20 was so as to ALWAYS send the "power2 on" command along with a dimmer change (power2 is defaulted to the light, but changed to the fan so the driver on/off buttons change the light), etc. Also wrote a dedicated "rule1" that followed your "rule3" template so that any change in TuyaEnum4#State>0 DO Power1 1, state==0 DO Power1 0, etc. etc. AND, set up the driver so that the "tasmotainject" sends in rule1, rule3, turns on both rules, and enables SetOption20.
All of this was done over the course of hours and hours over multiple days, essentially reverse engineering your code and educating myself on how it works, what variables are getting sent where, tweaking the rule3 format to fit my specific needs, etc. Sidenote, I even tried to set up separate dimmer and fan devices, writing two versions of the code to focus the switch operations on the dimmer relay and the other on the fan, only to get greeted with the "a device already has this DNI, change it" message in the logs. Doh!
The end product is a single device that receives all power relays, dimmer state changes, and fan speed changes via integers and converts them to the necessary speed strings, including power2 "off" going to the fan control in the UI flawlessly. Local operation sync, remote operations do not race, everything is great.
... Enter the assistants. Alexa and Google ARE NOT down to clown with this combined driver capability. Alexa can't figure it out at all, Google turns on the light at 13% when told to "set the living room fan to low" and it's just a clunky mess. So, I created a virtual fan that will be exposed to the assistants. I used Ryan's fan sync app to translate assistant to virtual, which then pushes the virtual device changes to the actual switch. A rule machine rule that starts with any change in fan speed on the physical switch pushes the corresponding change to the virtual fan, that is then reflected in the assistants, thus 2-way syncing there as well (Turns out I can make a second instance of Ryans app with the slave fan as the master fan to create two 1-way bridges between them, saving me a rule machine entry for each room. * face palm *) (another side note, I wish that "fan speed" stuff in rule machine could play with variables. It's a bit of a pain to create 4 conditional actions to react to each POTENTIAL fan speed, when a single command with a variable would consolidate it much nicer). For the dimmer, I just used the built in groups command to add the Fan/Light controller to a "dimmer group" of one, then exposed the "group as a device" and included the group state, then shared THAT device with the assistant. Group updates with the local switch changes, sends that to assistants, which can 2-way speak that back to the actual switch via the group, so that was easy.
I'll squirrel this whole thing away for when somebody else might need it, but being that the DS03 stopped shipping with "Tasmota-able" chips a while ago, I don't foresee this needing much attention. But for those that do, I'll be happy to share my notes.
As always, thanks again for being the springboard to launch me off on this project. It's been a lot of fun (albeit frustrating at times) and I couldn't have moved "everything onto the hub" and thus pulling out the node-red / MQTT middleman without it.
It sounds like quite the journey. I would not be surprised if you go back and add some refinements\simplifications as you think it over for the next few weeks. Beating an inanimate object can be a lot of fun.
For anyone reading this you can buy a Sonoff iFan04 that will save you a lot of headaches and uses the off the shelf driver, but may be less satisfying and you won't learn as much!! 
I just came across this and It was an immediate switch from Tasmota Device Manager, looking at the concept of this, would it be possible to implement a driver for BLE? I have tasmota32 bluetooth on an esp32 chip which is detecting nearby BLE devices and beacons with their RSSI values. Would be really amazing to put this into work!
Rather depends on the functionality. If its Bluetooth gateway, that is a big undertaking. It it a Bluetooth client that just detects the presence or absence of a BLE signal that is much more doable. However, I do not have a BLE module to play with.
Is there a way I could help so this feature would be possible? Trying to know the RSSI value of a BLE so maybe I could do automations based on the RSSI value?
Hi all.
This sounds like exactly what I need.
I purchased some tasmota plugs from aliexpress and hoped for the best.
Installed the basic tasmota bits to add to my WiFi...
Note, if I boil the kettle, I can watch the screen above via 192.168.1.20 and it updates in real time.
I then tried installing marcus' drivers. Shows the info, but required a manual refresh.
Installed yours via HPM....
But I still can't seem to watch this device within hubitat unless I manually refresh.
I'm guessing I'm missing something simple. Can anyone please assist? Thanks!
I'm guessing that you have not done a tasmotaInjectRule(). That is what sends the notifications from Tasmota to Hubitat.
What you could do is figure out if you can create a rule within Tasmota to do whatever it is that you would like to monitor.
For example a rule that might identify when a BLE signal disappears or gets added. Or a rule that identifies when the RSSI exceeds one or more thresholds.
If the rules can be created to do what you want then it is possible to integrate with Hubitat.
Ah, this is all new to me.
I clicked the inject rule button, but that's all I thought was needed. Doesn't seem to help.
I kind of assumed that if I could see the live updates on the tasmota screen, this would automatically mirror in the hubitat device driver.
I'm not quite sure where to go from here I'm afraid. Sorry for the noob q's.
If you turn off the device at the Tasmota screen does that change get reflected in Hubitat within a few seconds? If it does, then the rules are working and what you are probably seeing is a delay in your electrical stats. If that is the case you need to set your TelePeriod to something like 60.
I'm off to bed but you can find the documentation here.
Success! Thank you.
Turns out I was being impatient.
Awesome.
Thanks for creating this app, seems to be the only viable option for using tasmota with HE.
I have my device setup as a sonoff 2ch touch module. The 2nd switch (user) function is controlled by an external sensor that toggles on/off when a doorway entrance is crossed. The primary switch functions as the normal wall touch switch.
I have run 'tasmota inject rule' in order to synchronize hubitat with tasmota. However, it consistently keeps missing switch reads from the 2nd (user) switch and I have to manually hit 'refresh' for the device (HE) to show the proper value of what tasmota SW2 is reading. tasmota is always showing the proper switch operation for the 2nd switch.
The primary switch does not have this problem, since it is output only, meaning it only goes on/off with command sent from HE (this driver). So, its seems as thought the sync for ingress from tasmota to HE is what is failing.
Are there any variables/settings in the driver to minimize the changes of missing the reading from tasmota? Even if the 2nd switch was sync'ed in late response to tasmota (up to 10 sec) that would still suffice for my application. I've tried increasing/decreasing both the timeout and debounce parameters, no change.
First, not sure why my comment went as a reply to @Vincent_The_Staat, it was meant as a general post.
I think I found the problem, well not "problem", just required use adjustment. In my use-case the 1st switch (light) is being triggered by motion detection, then within less than a second the doorway is crossed and the 2nd switch (user) is turned on by the external sensor. It seems that this is too close of an interval for HE and driver to sync CH1 switch and then CH2 switch. I think it being WIFI in general is the failure, hence why I used a zigbee motion sensor to kick things off, turn on the light.
As far as I know that is true. Plus it allows you to keep your Tasmota devices up to date.
Switches that are controlled by sensors report differently than a normal switch. My guess is that if you do a 'STATUS 8' you will get a response that includes a switch like this.
'{"StatusSNS":{"Time":"2022-05-25T10:23:58","Switch2":"ON"}}'
For these types of switches to be recognized you need to configure the sensor to use switch 3 or 4 and use the Tasmota Sync Universal Sensor Driver with Single Relay.
Once you have that configured the response time on the second switch will be the same as for the primary switch.
Yes, that could be a problem with debouncing if there are two events on the same device close to each other.
I doubt this is the case unless your WiFi is poor\saturated to begin with.
If I might suggest an alternative you could use a Tasmota rule that turns on SW1 when motion is detected without any need for involving HE or WiFi. You can also use a rule on one Tasmota device to trigger an event on another device without involving HE.
If you are not used to Rule have a look at my Tasmota Broadcaster app which is an optional component of the Tasmota Sync. Has quite a few rules that you can experiment with without having to know too much.
Download the Hubitat app
