FYI fellow Tasmota fans I installed Tasmota 12 on one of my devices yesterday and had no issues with Tasmota Sync. Do not see any new features or commands in T12 to get me excited but we all have different interests.
It does add support for a number of additional devices that might be of interest.
1 Like
FYI the way the code is written the lowest log level is -1 which only reports gross errors so you could use that. If you entered a -2 you never see anything in the log unless it’s system generated.
Try that and let me know if that is sufficient.
2 Likes
Dude. I am so sorry I haven't responded. I have been so busy at work that I completely forgot about this altogether. I am actually still waiting on getting my Hubitat, so unfortunately I cannot test it. As soon as I get a Hubitat, I will throw Tasmota on the DS03 and test the driver out.
Thanks,
G
No worries. Mainly I just wanted to be sure it was working and you weren't having any issues.
@garyjmilne Thank you for the hard work on these drivers. Still finding my feet with them, hope my question wasn't covered already, but couldn't find anything.
Running and ESP32 with Tasmota 12.0.2, and installed the Switch with Sensor driver. No problem with the driver and the switch is working well.
I've got 3 x DS18B20s and they show up in Tasmota, but I can only get one to show up in Hubitat. My 'Status 8' feedback is: {"StatusSNS":{"Time":"2022-08-10T21:48:36","DS18B20-1":{"Id":"3C01B55682B1","Temperature":53.9},"DS18B20-2":{"Id":"3C01D6075955","Temperature":17.1},"DS18B20-3":{"Id":"3C01D607996B","Temperature":18.6},"ESP32":{"Temperature":53.3},"TempUnit":"C"}}
Have tried a few different iterations in the 'Tasmota Sensor Name' - spaces between, comma & space, comma only, semi-colon & space etc. - but only able to get one sensor to show up.
Any suggestions please?
Hi Ryan, the first release of the driver only handled a single type of sensor and you had to specify the sensor name in the settings as you have been doing.
I have been working on a second version which is not quite finished yet. In this version you do not need to specify the name of the sensor. I had been working with another user to get 2xDS18B20's working at the same time and here is the last piece of that thread with some instructions and comments.
You can find the interim code here but I expect this version will only find 2 of your DS18B20's plus the ESP32.
I can take a look and see if the code would be easy to modify for a third DS18B20. Finishing up another project but I hope to be able to take a look next week.
1 Like
Hi Gary. Thanks for all of your work on this. I spent this weekend updating a dozen devices that ran the old integration from Markus. All of them work flawlessly with Hubitat and the OTA upgrade went flawlessly on all of them from 8.3.1 to 11.1.0. That was much easier than the original programming of them including two that needed wires soldered to the chip the first time.
I did however notice a peculiarity with one of them that I use with Alexa. A number of them are Sonoff TH16's that have either a temp or temp/humidity sensor attached. They now use the Tasmota Sync Switch w/ Sensor Driver. One of them with a temperature sensor also controls a light bulb in the garage and is shared with Alexa through the standard integration. After upgrading it, I had to unshare the original child device with Alexa and then share the new device. Today when I asked Alexa to turn off the garage lights, I noticed this one stayed on. Looking in the Alexa app, I had it in the proper room, but when opening the device, it was only a temperature sensor and not a light or switch. You can usually edit the device in Alexa to switch between a switch or a light for proper voice control, but in this case, Alexa wouldn't allow any change since it only saw it as a sensor and not as a switch so no control was possible. (I didn't realize Alexa would see and share the temperature though. That was new to me.)
I'm not sure if there is anything you can do with the new driver to allow it to be both a switch and a sensor yet still allow Alexa to control it as a switch/light. I did come up with a workaround though, so I thought I'd share it here in case nothing can be done. First I unshared it through the Alexa integration app. Then I switched the driver from the Tasmota one to a Virtual Switch (no sensor). Then I shared it with Alexa again. I changed the device type in Alexa from Switch to Light and then set it up in the proper room and turned it (virtually) on and off in case it needed initializing. Then I closed the Alexa app (just in case). Back in Hubitat, I changed the device driver back to the one with the sensor. All the settings/states/attributes were still there. I clicked Refresh just in case. But most importantly, I didn't rerun the Alexa integration. So now Alexa sees it as a light, and Hubitat sees switch and sensor properly. If I ever rerun the Alexa integration for a new device, I'll probably have to redo these steps.
Thanks again for the updated Tasmota integration!
Chuck
Chuck, I'm glad you like the drivers and they are working for you. I like Tasmota, so it is nice to hear that others in the community are finding my drivers and are finally able to update their Tasmota devices to a more recent version.
FYI. I just updated all of mine from 11.X to 12.0.2 without problems. Don't know if you know this, but if you specify:
"OtaUrl http://ota.tasmota.com/tasmota/release/tasmota.bin.gz"
then all you need to do in order to upgrade to the most recent version each time is:
"Upgrade 1"
I am actively working on an upgrade to this so stay tuned. The new version no longer requires you to specify the name of the sensor and generally handles a larger number of sensors.
I have a few Alexa devices so I am familiar with what you describe. Back when I first got Hubitat I used to configure virtual switches that also had the contact property. It might be possible to do something similar but I'm glad you found a workaround in the meantime. I have a TH16 so I should be able to mock up your scenario but it could be a little while before I can get to it.
Cheers.
1 Like
No, I didn't know about the easy upgrade address. Thanks
I've got way more WiFi devices than Zigbee or ZWave as that is what I started with. Mostly TP-Link, Konnected NodeMCU's, and a variety of ESP8266 devices running Tasmota. I really like the Tasmota option as it allows things to run local and allows me to keep my info out of the Chinese cloud.
No need to worry about figuring out the TH16 and Alexa anytime soon as this is a simple workaround with no loss of functionality.
I don't have any other fancy sensors yet. I'll keep watching and see what you come up in case I want to try out something else nifty for the fun of it.
Thanks for your efforts.
I don't know about ZWave but I have found Zigbee to be problematic and prefer to use a WiFi device if I have power. All my Zigbee devices are sensors now, I got rid of the others. Such poor tools to diagnose Zigbee issues vs WiFi.
1 Like
Ive been playing with this for an hour or so and liking the improvements to the original, especially the fact that it allows use of a much more modern Tasmota version. Took me a while to find the InjectRule button as I had expected it to happen as part of the initialise command, however running smoothly now!
I understand that loads of child devices is annoying, but why not have child devices where the device has multiple switches? E.g. Tasmota Quad devices having child devices is much more convenient for syncing with Google Home....
Gary this is just great.
I was an early adopter during the Beta program of T4HE. I have just migrated a bunch of devices from Markus' FW 8.1.0 to 12.0 with no issues. Everything seems to work as expected. I agree with you that having a parent and child device for something as simple as a switch was a bit overkill, this implementation is much more optimized in every aspect.
Having said that, I think Markus did a good job by creating awareness of the Tasmota world in HE. It was a good first step that showed the potential this type of inexpensive devices have and the integration with HE allowed us to do so much more with them.
I have a mixed installation with about 40 ZWave devices and some 30 Wifi/Tasmota. I did a lot of research with Zwave, changed my topology, installed repeaters, I even bought a zwave network analyzer (yeah!) in order to debug the damned thing. I added a second Hub and build a second Zwave network on a different part of the house. Whatever I tried, after some time the Zwave network crawled. Phantom devices showed up from deleted ones. Malfunctioning devices turned the whole network to almost a stop. I even installed an app to automate a Zwave repair once a week. Not nice.
If you have a reasonable wifi infrastructure I can't find any reason to prefer Zwave devices which "optimize" their routing and you never know exactly what they do. Maybe low power battery operated sensors/devices would be the sole exception. Pricing is another subject, the Zwave devices are typically more expensive (2x) than their counterparts in the wifi world.
So, thanks again for taking the initiative and build this. My faith in HE has been restored 
There are times when you have to update the rule, after modifying the device for example or updating the driver. That is why I left it as a separate action, but your point is a good one. The documentation does cover it pretty well though.
There are 2 reasons for not having child devices. Firstly that is a completely different driver model and would pretty much be a rewrite and I don’t want to support two distinct versions. Secondly it is very easy to accomplish what you are asking for by 1) Create a basic virtual switch or contact and then 2) Create a rule that mirrors the state of Tasmota Sync Relay X to the state of the virtual switch.
I have thought about writing an app to simplify this process but nothing in the works at this point.
Gary, I´ve been playing with your drivers for a few days, and now I clearly understand how to install them fairly well.
Today I started a formal process of upgrading a few devices, and started configuring an old Smart Plug with Power monitoring, and noticed that it needed calibration, so I started the process, according to this document:
Which is very simple, starting with PowerSet, VoltageSet and CurrentSet, and now all values only show 0, except Voltage, which now is "adjusted" to the correct value.
It doesn´t matter if I turn on or off the device, the Tasmota UI and HE device screen just changes the Voltage value.
I´m using a Kill-a-Watt dongle, and I've done this process many times before.
Any ideas?
Disclaimer: I HAVE lightbulb ON plugged in, which turns off and on
Youre completely right of course, but sometimes people just skim over sections of the documentation thinking we know best... 
Maybe could add a flag that it has not been done in the device handler, or add a text note inside the driver itself (next to the IP) but your first post does have it pretty bold!
Indeed you can easily create a rule to mirror devices and make life very easy, though I would have a look at the minimal implementation in my Fibaro driver (for example), since it is genuinely just a few extra commands and everything funnels through the parent (and uses default Hubitat Child devices so no need for an extra Device Driver). Then you just need a button to create children and a button to remove them (again could copy from my code). Im happy to submit a MR but dont want to do it if you dont want the feature!
Either way @garyjmilne I just wanted to say thanks again as this is a great improvement and I have now finally setup a fan controller in Hubitat using the standard Tasmota driver!
EDIT: For ease of you testing or understanding, Ive pulled the key bits out and I think modified them to work but havent had time to test (so pasting here for prosperity).
def CreateChildren()
{
try {
for (i in 1..4) {
addChildDevice("hubitat", "Generic Component Switch", "${device.deviceNetworkId}-ep${i}",
[completedSetup: true, label: "${device.displayName} (S${i})",
isComponent: false, componentName: "ep$i", componentLabel: "Switch $i"])
}
} catch (e) {
log.debug "Didnt create children for some reason: ${e}"
}
}
def RemoveChildren()
{
// This will remove all child devices
log.debug "Removing Child Devices"
try
{
getChildDevices()?.each
{
try
{
log.debug "Removing ${it.deviceNetworkId} child device"
deleteChildDevice(it.deviceNetworkId)
}
catch (e)
{
log.debug "Error deleting ${it.deviceNetworkId}, probably locked into a SmartApp: ${e}"
}
}
}
catch (err)
{
log.debug "Either no child devices exist or there was an error finding child devices: ${err}"
}
}
def componentOn(child)
{
"${"Power"+child.deviceNetworkId.substring(child.deviceNetworkId.length()-1)+"On"}"()
}
def componentOff(child)
{
"${"Power"+child.deviceNetworkId.substring(child.deviceNetworkId.length()-1)+"Off"}"()
}
def componentRefresh(child)
{
refresh()
}
def updateChild(String ep, String status)
{
//First update the parent
sendEvent(name: "switch"+ep, value: status, displayed:false)
//Now find and update the child
def childName = device.deviceNetworkId+"-ep"+ep
def curdevice = null
try
{
// Got a zone status so first try to find the correct child device
curdevice = getChildDevices()?.find { it.deviceNetworkId == childName }
}
catch (e)
{
log.debug "Failed to find child " + childName + " - exception ${e}"
}
if (curdevice == null)
{
log.debug "Failed to find child called " + childName + " - exception ${e}"
}
else
{
curdevice?.sendEvent(name: "switch", value: status)
}
}
And also need to change the STATE section of HubitatResponse to something like updateChild(X, body.POWERX.toLowerCase()) instead of the sendEvent function.
Gary, additional to what I just mentioned on my last post, I just found what I suspect is a problem with your driver:
When you open the Device page in HE, the one using your driver, it does not show, at the bottom of the page, information for "In Use By", where you look at all Apps where you are using that particular device.
Very useful when switching from one device to another one.
Is there a solution for this?
Thanks for the great job you have done with this new approach to handling Tasmota devices.
This what I would do.
- tasmotaInjectRule
- Set teleperiod to something short, like 15 seconds.
- Look at the Tasmota console and you should see activity. Look for the part where it is doing a webquery command and the data it is sending beginning with TSYNC and in there should be the power data.
If it’s not present then it’s probably the rule and you can send me your status 8 output.
If the fields are present with data then the issue is the handling in the driver. To get mor3 info turn the log level up to 3 and wait for the next sync cycle. Should be some clues there.
I agree, very useful when switching devices. Unfortunately for you there is nothing in the driver that controls that, meaning when writing a driver you do not code for it. Those In Use By fields are populated by the platform when devices are associated with rules, apps, scenes etc.
Check whatever rule, scene or whatever you think should be using it and my guess is you will find a Broken designation and the device needs reselected.
Guilty as charged. But that is part of the fun of tinkering.
Thanks for sharing the parent\child code. I will try it out at some point for my own education if nothing else.
You are welcome. I’m happy to see interest in Tasmota picking up as a viable option for use with HE. My current position is that if it is main’s powered then Tasmota and WiFi are my first choice. My reliability has gone up since eliminating some Zigbee repeaters. I now use 2 hubs and no repeaters to get my Zigbee coverage which are mostly sensors but a few bulbs that I will replace with Tasmota as the Zigbee versions fail.
1 Like
If you took your message, replaced your name with mine and replaced Zwave with Zigbee it would pretty accurate for me.
I bought Zigbee repeaters, an Xbee network analyzer, got rid of all my Zigbee repeaters and got a second hub and split my Zigbee network in two. Thought about plugging my Zigbee repeaters into Tasmota devices so I could reset them when they stop working which was about once weekly.
Even after all that my Zigbee results are unpredictable. So if something is mains powered I use Tasmota. Much better tools to troubleshoot the issue and I can check the RSSI. I do find bulbs inside metal housings have a lower RSSI than I would like at times. I have two APs but might replace me that does not have any external antennas but over all the Tasmota stuff has been solid.
Glad you like the drivers. I think Tasmota is a great option and now sme manufacturers preload Tasmota making it accessible to everyone.
