From what you posted I gather you set your configuration manually rather than importing a template? Maybe check this out if you didn't know.
The included modules are a base to be built upon for new devices and the U3S is based on the included module 45 as per the base reference in the template.
Hi at9, yes, you are correct. I did them manually. I guess I haven't made my question clear. What I was asking on previous post is that, after I flashed my plug with the tasmota-habitat.bin, i could not find the U3S configuration from the drop down menu. So I would like to know if there's a way to add this U3S in there? which why I said that there might be some bin compiling works needed to be done for this?
I understood your question what I was getting at was is it is unnecessary to need to add obscure devices to the firmware itself when it takes a few seconds to copy and paste in a template. Not to mention the issues upgrading in the future if the number allocated to the module was then used in the mainstream of Tasmota.
FYI, I just upgraded 9 of my plugs from 6.5 to 7.1.2. Here were my steps - YMMV. No bricked devices. Again, if your stuff is working with 6.5, no need to upgrade
Tasmota Hubitat Upgrade from 6x -> 7
- Backup config
- Go to Console: Reset 6
- Restore 7.1.2 minimal from the web (https://github.com/arendst/Tasmota/releases/download/v7.1.2/tasmota-minimal.bin)
- Go to Console: Reset 6 (probably unnecessary, but won't hurt)
- Upload https://github.com/markus-li/Tasmota-Hubitat/releases/download/7.1.2/tasmota-hubitat.bin either from local OTA or via Web.
- Restore config (should get your name, wifi and templates back)
- Enable Hubitat support
- Configure Hubitat support.
- Optional: A few of my device's LED's blink when off. Turn off Blinking LED when Off; go to console and enter: SetOption31 1
I bricked no devices. 1 device I had to power cycle to get it to come back, 1 device I had to connect to the AP mode and reconfigure, then restore the config from backup.
I assume the same instructions would work to go up to 8.1. You may need to issue this option if you need to get from 7.2 to 7.1 Setoption78 1.
Edit: I also put together these tools I found on github to regularly backup config for all discovered devices on my LAN: GitHub - bdwilson/tasmota-tools: Things I use with Tasmota devices
2 Likes
as @at9 is saying, adding this to the firmware would NOT be recommended, it could easily be added to a new driver, but I'm looking at changing how this work, we're already drowning in drivers and I need to get it clear on how and when to to use which one. You can however add the template string to the Generic driver and the driver will configure the device for you, but that is a different thing.
Changing the firmware is not recommended, it is also a very complex thing to maintain.
Restructuring of the drivers
Now we have a bit too many drivers, it has been bothering/worrying me a bit. It makes it hard to choose and know which driver to use, at the same time a lot of the drivers do add something more than just a template and some automatic configuration of Tasmota.
As a medium to long term goal I want to improve this situation, exactly how is what this post is about.
I see a couple of different options:
- Instead of having a different driver for each device which just needs special settings set in Tasmota and no other changes in the driver, present a drop-down list where you can select a specific device inside the generic driver.
- Create an App that does the above and still leaves you the option to do it in the driver.
- Do 1 + 2 and still generate specific drivers but put them in a separate folder in the repo and NOT list and link to them directly from the main post.
- Not offer any device-specific drivers and let users just find their own Template/module settings and proper Tasmota configuration and enter that manually into the driver or Tasmota.
- Solve everything with better documentation and not change anything else. I really don't think this is the answer.
- Some other combination or scenario I've not listed above.
There's also the different Generic drivers as well as the TuyaMCU drivers, some of them might make sense to merge, but for that I'd like input regarding what would make it easier as a user. For me there really isn't a difference maintaining 10 or 50 drivers, that is automated once the specifics of a driver has been added. All drivers share all code that they can. What is important is user experience.
This is not for a change tomorrow, but for a change to be implemented over time.
So, any thoughts?
EDIT: I should probably explain a bit of the possible implementation scenarios I'm considering for 1 and 2. The base for all of it is a parent/child driver and device configuration. It can even be used to auto-configure the driver based on what is received from Tasmota, as suggested here. Auto-configuration will never be complete, but it could be made to work for the majority of devices used since most are just for "flicking a switch" anyway. Then there's all the other special things... For RF I already have the beginning of this structure, and it is appealing to continue down this road.
I personally think either of these options would be good but if the driver over the app is easier than go with that.
Agreed if we can consolidate where possible, at least from a user perspective it would be good. We basically need a super driver (or app) that can control it rather than you loading in a million different drivers.
I agree that it has become somewhat hard to understand with all of the specific drivers. I can only imagine how confusing this could be for some one just getting started.
I only use the generic drivers which perhaps makes me biased to option 4 but my view is if people can go to the effort of using tuya convert or serial flashing they can surely handle pasting a template into the Tasmota GUI rather than into a post in this thread.
My view is that this actually improves the user experience as all configuration in done during setup on the device and then it's just a case of add the device to HE and selected the driver based on the device type.
Ok , well noted, it really feels like this is where we'd be heading.
Yes, this is my concern as well, in my eagerness to develop stuff, this is what happened, but it is not too late to sort out.
In a way I agree, but for my own needs I do want the driver to configure stuff for me, TuyaMCU devices need commands issued in the console. With my driver it takes me, from the time of taking it out of the box new, via Tuya Convert and to having it in Hubitat fully configured, about 5 minutes, most of which is waiting for the firmware to be installed. Of my own time, basically none is needed. Granted, this is with a rPI sitting in standby and ONLY used for TuyaConvert and everything else, including power for my new wall switch, lined up and organized. But yes, without auto-configure in the driver it would take me another 5 minutes... See, I've spent hours to save several minutes, very efficient 
Joking aside, I do like and will keep it in one form or another, I do however appreciate the need for the other approach, which is what the generic drivers have been for.
There's also the device-specific settings, I prefer not to have to remember or write them all down, like which particular command makes the LED behave well on which particular device.
More opinions, please! I will let this take some time before I start rewriting the drivers, so before I do, opinions, thoughts and suggestions. 
2 Likes
I should have said i was mainly talking about non TuyaMCU devices.
Those with a TuyaMCU I agree using the driver to configure them would save a lot of time.
1 Like
so far i've tested 8.1.0 bin with 4 sonoff s31's, 2 teckin sp20's and a moes dimmer and a teckin sb50v3 rgbcct bulb but the driver still needs to be finnished for the bulbs to switch between white tempteures but rgb works great. i flashed most of them via ota method in tasmota. i only flashed 2 sonoff s31's via TTL and all seem to work fine. side note i was already on 8.1.0 tasmota i just needed to flash to minimal then to tasmoat.hubitat.bin
2 Likes
Hi @markus
Just a quick one from a neewbie. I am running your Sonoff Pow R2 driver. When I add the power attribute to the dashboard tile it does not show the units, same for the voltage. Yet in the driver page it has powerwithunit and voltagewithunit. The problem is this comes and goes sporadically. I am never able to choose these options under attributes when I go into the dashboard tile option. I can select voltage and power with no units.
- apparentPower : 210 VA
- current : 0.950 A
- energyToday : 3.622 kWh
- energyTotal : 131.876 kWh
- energyYesterday : 4.053 kWh
- ip : 192.168.0.XXX
- ipLink : 192.168.0.XXX
- module : [0:Sonoff Pow R2]
- needUpdate : NO
- power : 176
- powerFactor : 0.84
- reactivePower : 116 VAr
- switch : on
- templateData : {"NAME":"Sonoff Pow R2","GPIO":[17,145,0,146,0,0,0,0,21,56,0,0,0],"FLAG":0,"BASE":43}
- voltage : 221
- powerWithUnit : 176 W
- voltageWithUnit : 221 V
What am I doing wrong?
Fyi all, I just updated to HE Tasmota 8.1 across all my devices being Sonoff Mini's, Sonoff Basic R3, Brilliant bulbs, Brilliant plugs and Brilliant plug with BME280 sensor and it all worked perfectly fine. I just went to minimal first then to 8.1.
1 Like
You're not doing anything wrong. It was a bug in the driver, it has been fixed, it's in Github now.
1 Like
@markus
Thank you, I will give it a try. Thanks for all your effort and time you put into this, appreciate it.
Thanks
1 Like
White temperatures should work properly now Driver updated a few minutes ago
@markus the TuyaMCU dimmer driver works really well, I haven't had any issues or errors since loading it earlier today. Anyways just thought I'd pass on some feedback on that driver.
1 Like
Hey I think I found a bug in the power monitor driver.
If I enable/disable the ip override it resets the module on the plug to the sonoff pow 43.
I set this in Tasmota and don't have the Setting Module enabled.
