Rgr. Easiest way, would be to use the Notification manager. It has the ability to limit the number of notifications within a given time period. Something like this.
Gary,
Thank you again for your advice with the fan stuff, both in this thread and the other. I have yet to take the time to implement your latest suggestion, I'll get to that one shortly.
In the meantime, I've moved along to another one of my node-red integrated switches to try and migrate them over to Hubitat / Tasmota Sync exclusively. This one is a Treatlife (Tuya) 3-way switch (Template can be found here). I have tried to set it up as both a single and a dual relay switch and can't seem to get it to play along well (once again).
Here's the rundown. Applying the listed template, it will show up as 2 relays on the UI. One reflects a "sensor" line that essentially reflects the actual status of the load, either on or off. The other is the actual physical relay, either on or off (or in a 3-way application, more like A or B). When set up with Tasmota Sync, power commands are sent to Relay 1, or the sensing line. That's fine, because I want on commands to tell the "off load" to turn on. Set up a tasmota rule that when Power1 changes, toggle Power2. Easy day.
BUT! When somebody comes along and toggles one of the "dumb" switches on the other end of the circuit, it flips the "A/B" relay in the switch, which toggles the "load sensing" relay to ON, which activates the rule to toggle power2, lights turn off, sensing relay flips, rule1 activates, and then we have a flickering rave party.
So I thought, maybe I can get Tasmota Sync to "listen" to Power1 for any changes and reflect that state in the UI, but then send on/off commands to Power2 (the physical relay). That would allow the UI to always reflect what the "sensing load" shows, but then only impact the actual relay toggle when commands are issued.
But then that essentially means sending commands to Power2, but then waiting for commands to return via Power1. As with the fan, I started picking through the driver to see if I could figure it out and figured I'd be better off just coming here to ask first.
Thank you in advance! I hope my antics aren't giving you too much of a headache and it's seen more as a test of creativity, flexibility, and perseverance! 
If I understand correctly it sounds like you are unable to get the 3 way switch configuration to work properly before adding Hubitat to the mix?
I don't have any 3 way switches but here is a thought that might work.
Configure them as two totally independent switches such as.
Switch1 @ 192.168.0.120
Switch2 @ 192.168.0.121
On Switch1
ON Power?#State=0 DO webquery http://192.168.0.121:80/cm?&cmnd=power off ENDON
ON Power?#State=1 DO webquery http://192.168.0.121:80/cm?&cmnd=power on ENDON
On Switch2
ON Power?#State=0 DO webquery http://192.168.0.120:80/cm?&cmnd=power off ENDON
ON Power?#State=1 DO webquery http://192.168.0.120:80/cm?&cmnd=power on ENDON
This should keep the two switches in sync.
Then connect them to Hubitat as a single relay switch.
Maybe better ideas but there is something to think about.
P.S. You can just paste these commands into your browser to test them out before putting them into a rule. http://192.168.0.120:80/cm?&cmnd=power off
I suppose I didn't describe it quite right. The "3-way" configuration is merely a description of how the internal workings of the switch works. It takes the incoming line power and directs it to a load A wire or a load B wire. The load is energized if the wires further down the line in the dumb switches are "in line" with the load. This is opposed to a single pole that is either toggled to "load connected" or "load not connected." I have only the one smart switch in the entire lineup, then a dumb 4-way switch at the top of the stairs, followed by a dumb 3-way switch at the end of the upstairs hallway, then the actual lighting load, then the neutral line goes back to the breaker panel. Essentially the 3-way switch serves as a standard on/off toggle (in reality it's an A feed / B feed), but Tasmota can use the smart switch's "sensing" line (GPIO14) to detect when one of the dumb switches upstairs has been flipped, completing the circuit and energizing the load, then marking the "sensing" relay as being "on" while the "relay toggle" (the A/B toggle) remains in its original position.
But here's where it gets (more) complicated. Tying that into Hubitat. If I use the "sensing line" as the signal to the hub so the UI shows "on" when the load is on, then sending commands to the load sensing relay would require flipping on the physical relay upon a change in the load sensing line. For example, load is energized, sensing line is "on," hubitat sees it as on. Send off command, tasmota receives it and flips the load sensing relay to off, a rule toggles the physical relay to toggle to whatever side it wasn't on, load is deenergized. Perfect.
But somebody comes along after that and flips a dumb switch, the load is energized. The load sensing relay goes from off to on, the rule triggers and flips the physical relay, which then turns the load off again. The sensing line sees this change and flips accordingly, sends another toggle to the physical relay, rinse and repeat.
Unfortunately, I'm traveling the rest of the week and won't be home to tinker, but figured I'd post an update to this little venture anyway. (As a separate aside, been working with the fan controller and have made progress. Far from perfect or consistent, but I'm getting there.)
Hi @garyjmilne
Thank you so much for the work you have done. I wanted to ask before I even tried to make changes. I have a custom device running Tasmota that measures (ultrasonic sensor) the distance from my garage roof to the floor. Using a Tasmota rule, if the distance is greater than say 150cm then the car is not in the garage. If less then there is a car in the garage. This rule either turns a switch on (car is present), or off (no car)
What could I use in the Tasmota sync drivers to replicate this and is the distance sensor supported?
This is how it is showing currently in Hubitat
Hi Greg, in theory that should be pretty easy. I have some SR04 so I know they work as long as you have the sensors version of Tasmota installed which you already do by the sound of it. I'll refer you over to the universal sensor thread which you can find [here.] ([Released] Tasmota Sync - Universal Sensor Driver - #15 by garyjmilne) for future discussions around this topic.
Here is what you need to do.
-
Change the IP on the DRIVER of your existing "Greg Car - Universal Parent". The field is called Device Network ID. This lets you keep your old config while you try out the new one.
-
Install my Tasmota Sync Universal Sensor Driver per the instructions and make sure you add the IP of the Tasmota device and the Hub. Looks like you have a switch on your Tasmota device so you would use the Universal Sensor driver with Single Relay.
-
Do a refresh and it should populate the attributes.
-
Once it has detected your ultrasonic sensor it should populate an attribute called distance if I remember correctly.
-
Once that is working you can now do the tasmotaInjectRule and the tasmotaTelePeriod and it will send updates from Tasmota back to Hubitat automatically.
-
When you are creating Hubitat rules around the sensor values you need to use the custom attribute value as your trigger.
I may have missed something so you can find the documentation here.
Sounds complicated but once you have been through it you will find it's quite easy to do.
P.S. You need to upgrade to Tasmota to version 11 or later. I'm using 12 on all my devices without any issue. Here is a guide if you need any help with that. https://github.com/GaryMilne/Hubitat-Tasmota/blob/main/How%20to%20Upgrade%20from%20Tasmota%20from%208.X%20to%2011.X.pdf
1 Like
It's a difficult one to think through without an actual device to tinker with. What I would do is figure out in english language terms what I want to happen in each of the scenarios.
Relay On, Sensing On - Receives Sensing Off
Relay Off, Sensing On - Receives Sensing On
etc.
My guess is you will need to use either a variable (%var%) or another relay to store "the truth". You might need to use the oneShot capability of rules to prevent the race condition that you are seeing. If you need more complex expressions in rules Tasmota has a version that allows that.
P.S. You can concatenate the values of the 2 relays into a single variable (like I do in my driver) and then use that single variable to decide what to do.
Sorry that I can't help more.
Did it all work out O.K.?
Hi @garyjmilne
I managed to change over the Tasmota device with the ultrasonic sensor and all is good. What I did want to ask you is, under the State Variables it has a LastSensorData and this does not update the time unless I click on refresh. Does this have anything to do with the device updating to HE. The values are changing in the Current States but the dashboards don't seem to be updating unless I re-load the dashboards? Any ideas?
Greg, glad it is working for you. I understand your confusion re:[quote="greglsh, post:157, topic:93651"]
under the State Variables it has a LastSensorData
[/quote]
Hubitat gets updated in two ways with this driver.
- After doing an injectTasmotaRule the Tasmota device sends the data (if changed) unsolicited based on the TelePeriod. When this happens it updates the lastTasmotaSync field.
- When doing a 'Refresh' via the Hubitat interface or when Polling is configured. When this happens it updates the lastSensorData.
Note that the state Variables area of Hubitat does not refresh automatically like the Current States does.
1 Like
Anyone interested in the Tasmota Sync drivers should also take a look at this companion app I wrote to distribute commands to multiple Tasmota devices at the same time. Makes a lot of things easier.
Hi @garyjmilne
Wanted to ask you I have Sonoff Tx light switches which have been flashed with tasmota. I have changed them to your sync driver. What I have is single, double and triple switches. I can operate the "primary" switch fine from the dashboard, but how would I "access" the second and third switches from the dashboard like I had before.
So I basically need to add a button so that I can switch2 and switch3 on and off?
If by dashboard you mean the driver interface screen then you would use the Triple relay/switch driver.
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.
- Place the virtual device on your dashboard.
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.
1 Like
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.
1 Like
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!! 
