[RELEASE] Tasmota for HE - Auto-detecting Tasmota drivers + Tasmota firmware 7.x/8.x for HE (for use with Tuya, Sonoff and other ESP devices)

This should be fixed now, only the Parent driver needs updating.

Awesome:
dev:5202020-07-19 11:54:17.096 am info'illuminance' set to '55.25'

dev:5192020-07-19 11:54:17.080 am infoparseResult: [StatusSTS:[Time:2020-07-19T11:54:15, Uptime:0T00:00:57, UptimeSec:57, Heap:22, SleepMode:Dynamic, Sleep:50, LoadAvg:63, MqttCount:0, Wifi:[AP:1, SSId:FBI_Surveilance_Van, BSSId:18:E8:29:64:28:57, Channel:1, RSSI:76, Signal:-62, LinkCount:1, Downtime:0T00:00:03]]]

dev:5212020-07-19 11:54:17.037 am info'gas' set to '570.13'

app:1312020-07-19 11:54:17.004 am infoAverage humidity = 68.4%

dev:1982020-07-19 11:54:16.982 am infoAverage Humidity was set to 68.4%

dev:5212020-07-19 11:54:16.978 am info'pressure' set to '986.7'

dev:5212020-07-19 11:54:16.930 am info'dewPoint' set to '17.6'

dev:5212020-07-19 11:54:16.898 am info'temperature' set to '29.2'

dev:5212020-07-19 11:54:16.871 am info'humidity' set to '49.8'

dev:5192020-07-19 11:54:16.845 am infoparseResult: [StatusSNS:[Time:2020-07-19T11:54:15, BME680:[Temperature:29.2, Humidity:49.8, DewPoint:17.6, Pressure:986.7, Gas:570.13], TSL2561:[Illuminance:55.250], PressureUnit:hPa, TempUnit:C]]

Yes, it's pretty dark with all the rain today :slight_smile:

Thank you very much for the quick fix.

Great it's working! I wrote the first change in 5 minutes and missed one row, that's what happens when you code in the middle of the night.

What I'm not certain about is if the number of decimals are right for these values, or if that should be changed? For Dashboard use, is there a need for a combined attribute which shows both number and unit as a string? Which of these new ones would need that?
For lux I don't see a need, but maybe Dew Point?

Well.. I don't use the dashboard much, since I prefer to have everything covered by rules. It has to just work based on external inputs like the lux in my living room, which will dim the lights automatically when I'm home.
For the dashboard I had to add °C to the temperature reading manually
So I don't need the units, but I could see some use for others.
Same goes with the decimals, lux could be rounded to one or zero, the rest is fine with me to be one decimal.

Lux now has one decimal. I think I will just leave everything else as is then and this will have to do :slight_smile: At least everything works well enough.

Sorry, but the lux has to be rounded to 0 decimals., else it will break built-in apps, like Simple Automation Rules:
2020-07-19 08:48:39.269 pm [error] java.lang.NumberFormatException: For input string: "5.46" on line 471 (luxHandler)

I already changed line 1851, which fixed it, and sorry for not checking it right from the get-go. :confused:

Ok, updated the code, also in the Release version.

@markus Thanks for the update fixing my log errors. It's working flawlessly since the upgrade. All my devices are now back in the app, and the devices are less chatty in the logs. Appreciate your fast response.

Also, I hope you can sort out your zigbee mesh issue. Having PAN id's change is problematic. A year ago, I had some zigbee device network ID's changing every 5 minutes, causing havok in my mesh. I had to remove the problematic device from my zigbee mesh.

1 Like

Yes, thank you :slight_smile: I'm getting closer, I might have solved it, need a few more days to be certain. Once I know the exact reasons I will check all my Wireshark logs (I have logs from every day and night from almost the beginning of this) again. It does look like some information that hopefully can help others come from all of this. The issue in my case is a changing PAN id (due to, in my opinion, how HE incorrectly changes PAN without having enough of a reason.). Having the 16 bit address of a device constantly changing is also a very annoying problem and can cause it's own brand of issues in the mesh, but when the PAN id changes this often, many devices become unresponsive for HOURS before they find their way back, if at all, in the case of some not so compliant devices. Even compliant devices can become unresponsive for some time after such an event.

1 Like

@Obi2000
I have a Sonoff TH16, which measures Temp and Humidity.

Not sure when this started but I am now getting this in my logs

dev:4272020-07-22 20:18:21.676 warnGot 'dewPoint' attribute data, but doesn't know what to do with it! Did you choose the right device type?

dev:4272020-07-22 20:18:21.069 warnGot 'dewPoint' attribute data, but doesn't know what to do with it! Did you choose the right device type?

The child device is using the Universal multi sensor.

This does not have or need a dewpoint as far as I know??

P.S. I checked and there was a new driver ending in 720 so I updated and this seems to have gone away?

Yes, this is a newly added supported attribute. For you to see this you must have updated just the Parent driver. As you found out, updating the child device driver fixed it. :slight_smile:

Hi,

I'm currently moving all my IoT devices in their own Wifi network, so I deleted all my tasmota device before, moved them into the new network and it works for all but one, which will always throws errors:
2020-07-25 01:44:02.335 pm [error] java.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI on line 2871 (parse)
But it reports fine and I don't have a 2nd Device with the same ID and I also can't change the parent device.
I there a fix or do I have to redo that one device, since refresh or configure doesn't solve it, nor a reboot of the hub :slight_smile:

It is probably trying to change to use the MAC address as the ID, but some other device is using that MAC address. Are your devices on a different subnet than HE? If you want to keep using IP as the ID there is a setting for that in the Parent device.

Hi,
Currently the tasmotas are in a different network (10.10.10.0/24) than the hub, but that will also change. Setting the IP as the ID fixed it and they are fixed from DHCP.
Same MAC, unless you change them manually, shouldn't happen. I had it with all devices later on.

This would in most cases mean that as far as HE is concerned they all use the same MAC address. Routing MAC addresses between subnets is usually not done.

That would be how you need to do it when on different subnets.

@peterbrown77.pb In case you missed it, there's a specific child driver which convert a Tasmota child switch to a contact sensor in HE. Just install that child driver and change the driver of the child devices you want to have as a Contact sensor instead of as a Switch.

1 Like

Thanks @markus . I looked at using a virtual garage door control device that was changed by the tasmota switch through rules.. But I decided to stick with a switch for now. But good to know about being able to change it to a contact sensor through just a driver. May come in handy.

Finally got around to moving the remainder of my Teckin SP10s (total 17) over to my server hub running your latest driver and using hubconnect to take care of the rest.

No issue and works flawlessly.

Tomorrow I hope to start the update from Tasmota 8 to 8.3.1. Always something to do. Lol.

Thank you again @markus for the work done.

2 Likes

Thanks for writing this integration because it's exactly what I need to use my Sonoff 4CHR2(latest stock firmware version) relay for outdoor flood/safety lights.

I'm new to Hubitat and Tasmota and have never flashed any of these devices before.

I do currently have the relay connected to the ewelink app and controllable.

If I have this right, the next steps I need to follow to use in HE are:

  1. Flash 4CHR2 with Tasmota... And then reflash with Markus' firmware
  2. In HE, install the drivers and app from Markus HERE
  3. Enjoy

Does that sound correct?

So my question and where I'm at now is can I flash Over-The-Air(OTA)? I do not have a USB dongle with a header that I have seen in some videos. Can I just go from stock to Tasmota OTA?

Thanks all!

I did something stupid and flashed straight from OEM to tasmota-minimal, expecting it to work as I have previously used it to convert from normal Tasmota to the Hubitat builds.

Now I can see the device and connect to its wifi (which is oddly named ESP-BC368C, rather than Tasmota-xxx) and even get an IP number (192.168.4.2) from the device. Problem is that there are no open ports at all! Web interface is not there.

Have I killed the device (short of fitting a serial interface to it)?