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.
Here is what I did and what I got;
Set Teleperiod to 15 secs
Couldn´t find any line beginning with TSYNC, but here is what I got in the console
And after Log level 3:
BTW, I´m on Tasmota 12.1.0
Looking at the bottom of your 2nd screenshot Tasmota is reporting:
SWITCH1 - 1
POWER - 0
VOLTAGE - 126
CURRENT - 0.000
So the driver is accurately reporting is the data that Tasmota is sending it which tells me that the issue is the Tasmota device. My guess is somewhere in your efforts to tune the WVA parameters something went awry. I'd recheck those and if you can't figure it out do a reset 5 and start over.
See commands - reset.
https://tasmota.github.io/docs/Commands/#management
Thanks for your help.
Will do so, and see how it comes.
Edit:
Solved!
Here is what was wrong on my side;
VoltageSet=126 (Ok)
PowerSet=45 (Ok) (I´m using a 50W bulb, and using what is shown on the Kill-a-Watt)
CurrentSet=0.36 (WRONG!)
I´ve should have used the value shown by my Kill-a-Watt, and then MULTIPLIED by 1000!
So the right value should have been;
CurrentSet=360 (MilliAmps, and NOT Amps)
Thank you very much Gary for your help and your great drivers!
1 Like
Regarding this other "error" reported by me (Missing "in Use By" information), I just want to express that I suspect that this was NOT an error by the code, but an error by me. Maybe I was referring to the wrong device! (the original one, and not the new one created according to Gary´s instructions)
Big thanks!!!
I have released a new version of the sensor driver, call the Universal Multi Sensor. You can read more about it here
It's a pretty big upgrade in terms of capabilities. Please read the docs referenced in the other thread before posting issues.
Try the new Universal Sensor Driver, it will handle all 3 of your temperature sensors. You can find more info here. As you have a switch\relay attached you would use the option with a single relay.
I have a similar configuration to your's and it's working perfectly.
@GraphicHealer and @garyjmilne I also have the dual fan/dimmer treatlife switch (DS03) that I've been using a node-red / MQTT / Virtual Switches to accommodate all this time. I upgraded the switch to Tasmota 11, which seemed to dump the wifi config and I lost connection. I did this while I was remote-desktop-ing my way into my house, so trying to connect to the switch to connect it to my wifi resulting in me shutting myself out of my connection. I'm home now and will tinker until I have to go to bed and will report back. (Thus far I seem to be struggling with setting the fan speed, but I'm sure my tasmota config is messed up at the moment)
Not sure of your Tasmota experience but if the device went into a complete reset it will be broadcasting an SSID like Tasmota-123456. If you connect to it and then point your browser to 192.168.4.1 you will get the config screen.
Out of curiosity what version did you upgrade from?
