Is it still recommended to run the Hue Emulation ?
Edit: I've set the Hubitat IP in Tasmota.
That is for automatic device discovery in the App, it is not used beyond that
1 Like
I have a pi zero w that is running pi-hole. Would I be able to use it to do the Tuya Convert part to flash some TreatLife DS01 wifi switches? Thanks
if it would work you would need a screen and keyboard hooked up to it as it will use the wifi chip to connect to the swtiches.
The Kali llinux live boot has been used by others to flash devices so might be an easier option if you can use that.
Oh yea this is wifi only. Could the Kali linux be run in a vm? Vmware Workstation 15 is what I have on my desktop.
Kali can be run in VMWare Workstation, you have to give it access to your wifi network card, apart form that it is rather straight forward.
As for your pi zero w with pihole, Tuya Convert would mess with your pihole since it needs to run some of the same services as your pihole, so they are not two things you can easily run on the same pi. If you connected a second network card to your pi 0 you would not need a screen and keyboard connected, but it still would be a bit complicated to get it working together with pihole.
Thanks, I'll try Kali as a vm. I've got a dell wifi adapter in the desktop that I'm not using, I'll let Kali have it.
Is it also possible to solder to the pins inside the TreatLife DS01 on the chip and do this the same way I did the Sonoff's?
Yes, it should be, I don't have that particular device, but in general the answer is yes, it is just more or less difficult depending on your skill with soldering. Show photos of the inside and I can answer more definitely. For me personally it very quickly becomes a risky operation since I'm not good at soldering, so I use pogo pins. If you have a 3D printer and pogo pins there's good alternatives to soldering available. @jchurch recently used an alternative approach using PCB pins held in place while flashing.
1 Like
This is from a youtube video, but it looks exactly like this - 3.3v, gnd, io, tx, rx, etc.
Yes, that is the TYWE3S, and since others have done the flash there is no secondary chip causing issues, so should be straight forward to flash.
I promise I read a lot of this - But I'm still a little confused which bin file should I use for this? Does it require an initial then a second flash? Thanks again.
For serial flashing you can go for the target bin file (NOT the .gz file) from the start, no need to flash twice. Don't forget to run "reset 5" in the Tasmota Console once you have booted the device though. For Tuya Convert, use the included firmware first to be safe, the full instructions for Tuya Convert are in the wiki.
Also, make sure you run the latest version of T4HE, there was a fix for some installation issues added a few days ago.
Hello All,
Firstly, a big thank you to @marcus for this great set of tools, and to @kueblc for maintaining the ‘tuya convert’ toolset.
After many hours of wrestling with a Lohas B22 RGBW smart bulb that I bought online here in the UK, I managed to get the generic tasmota.bin firmware flashed onto what was ‘v1.5’ of the Lohas / Tuya firmware, and then managed to get the Tasmota software on the bulb to work with T4HE.
Although I got this to work eventually, there are probably better routes that I should have taken, and there may be things I’ve missed out in the configuration, so would like to ask for comments.
• I managed to get ‘tuya convert’ to work off Ubuntu 20.04, whereas it didn’t seem to work off of Lubuntu v16
• Flashed the generic Tasmota.bin before reading about the HE specific version, but none the less, the generic version works.
• Installed all of T4HE and created the universal parent device
• The parent device was able to communicate with the bulb Tasmota, but seemingly would not recognise what to do with it, so it wouldn’t create any child. The log entries for this were:
dev:5802020-06-18 05:04:55.764 pm infoDevice info found: [hasEnergy:false, numTemperature:0, numHumidity:0, numPressure:0, numDistance:0, numSensorGroups:0, sensorMap:[:], numSwitch:0, isDimmer:false, isAddressable:false, isRGB:false, hasCT:false, hasFanControl:false]
dev:5802020-06-18 05:04:25.313 pm infoDevice info found: [hasEnergy:false, numTemperature:0, numHumidity:0, numPressure:0, numDistance:0, numSensorGroups:0, sensorMap:[:], numSwitch:0, isDimmer:false, isAddressable:false, isRGB:false, hasCT:false, hasFanControl:false]
dev:5802020-06-18 05:04:25.120 pm infogetDriverVersion() = v1.0.2.0613T
dev:5802020-06-18 05:04:25.094 pm infotasmota_refresh(metaConfig=null)
dev:5802020-06-18 05:04:25.087 pm infogeneralInitialize()
• I think now that this is because the Tasmota Template in the device was set at 255 for all of the GPIO values (?)
• After lots of reading and experimenting, I managed to get the bulb to respond through the browser to the following template :
{"NAME”:”Generic”,”GPIO”:[0,0,0,0,38,37,0,0,40,39,0,0,0],”FLAG":0,"BASE":18}
• This template configures the GPIO pins to 4 PWM ‘components’, representing R,G,B and W
• Running ‘Configure’ back on my Hubitat parent driver now recognised the bulb as a Generic Component RGBW device with a name of Tasmota - Universal CT/RGB/RGB+CW+WW (POWER1)
• I’ve now been able to control the device in HE and am free of the cloud!
Please do comment if you think I could / should have done something smarter and quicker.
Ok, I'm going the TuyaConvert path. I'm so close! I created a Kali laptop, installed tuyaConvert. I run 'start_flash.sh', I connect to vtrust-flash from my iphone, I get a browser screen auto open that says I'm connected to vtrust-flash. I press and hold the button on the switch, and it blinks fast red. I hit Enter. It cycles through SmartConfig complete, Resending SmartConfig Packets... Until it stops and says 'Device did not appear with the intermediate firmware, Check the *.log files.
Suggestions?
Thanks
I had a similar thing when I was flashing my downlights. All but one worked and gave the same error and I left it for a day and tried again and it worked for that time.
If I look in the wifi log file, I can see AP-STA-CONNECTED messages for the mac of my iphone as well as a mac from EXPRESSIF as the mac vendor.
@markus Thanks again. I Tamotised 3 more switches today.
I'm adding them to the Hubitat app that checks last activity - it's called Device Watchdog. My question is: should I just check the universal parent device for activity. It just checks that there is activity in the last x hours - just in case a device had fallen off the network. It works for zigbee, zwave, and network devices, probably even cloud devices.
In my case, I have tasmotised switches that have 3 child switches. Do i just check the parent?
Great to hear it is working out for you. 
I would recommend to check against the presence attribute, that one takes into account how the actual device reports events. When present the device is connected, when not present it is not available.
Sorry @markus, I just realised I spelled your name wrong in my post yesterday. Again, a big thank you to you for creating the T4HE app and drivers. Wonderful work!
cheers
Without changing to my version of Tasmota you will not have status updates and the device state could become out of sync. If you provide the link to the Tasmota device repository page for your device I can add it to the drop-down of devices for future releases.
Happy to hear it is working well for you! The biggest hurdles are to get started.
