[DEPRECATED]TuyaHubitat - (jinvoo, smart life, tuya smart - switches only)

I am going to try and flash the only single plug I have at my disposal today. There seem to be lots of drivers around that use this firmware or a derivative of it. Hopefully there is something around that will me point me in the right direction to create a driver. I believe @damon.dinsmore has already found a driver that works for the bulbs. If the node server can be eliminated this seems to be the way to go.

Perhaps a new topic should be created to keep all this info easy to find in one place?

1 Like

@cwwilson08 Agreed on the new topic. Would you mind creating it? Also probably need one for flashing other Tuya devices so we dont continue to jack this thread.

1 Like

Agreed it should be split even though I'm more interested in where the new one is going. lol

My one experience with Tassmota, there were many nights where my board would get stuck in this state. It would come back eventually but I don't know what was happening...

@damon.dinsmore if I achieve some success with the switches I will.

1 Like

@cwwilson08 Here is the link to the driver i used for Hubitat.

I can only get it to do on off and dim but i can only get white still in the web interface. @JulesT can you see if it controls color for your bulb?

1 Like

Ok so found a thread talking about the tuya bulbs that uses the chipset SM16716 for the RGB LED controller. Once this is released the bulbs will be able to work with RGB properly. So as a driver is created for Hubitat it will hopefully have this functionality.

How are you talking to these things?
MQTT or http?
I thought color worked for tasmota using MQTT...

This is probably really similar to the Sonoff 4 Channel and only needs the GPIO pin numbers updated for it to work with my firmware.

@ericm once these are determined will you be willing to add that and modify any new Device Handlers?

Ok @damon.dinsmore and @JulesT I'm joining the party.
I have the software running on my Pi.
I seem to be getting some successful results but at the end of the day it's still not switching firmware.
I do get this:

Response: HTTP/1.1 200 OK
{"t":1548135327,"e":false,"success":false,"errorCode":"SING_VALIDATE_FALED_TOKEN_EXPIRE","errorMsg":"非法请求"}
Shutting down...

Sound familiar? Did I miss a step?
Thanks!

@keithcroshaw ok I've seen that error before. But I'm going to ask a few questions to get a good idea of what you have.

  1. Ver of pi
  2. Ver of Raspbian
  3. Product your trying to OTA update
    1. Ver of pi: Raspberry Pi 3 Model B
  1. Ver of Raspbian: VERSION="9 (stretch)"
  2. Product your trying to OTA update: https://www.amazon.com/gp/product/B07D13LS7Z/ref=ppx_yo_dt_b_asin_title_o07__o00_s00?ie=UTF8&psc=1

@keithcroshaw Ok so open tuyota.pl and edit line 277 or so

change :
my $payload = sprintf('{"passwd":"%s","ssid":"%s","token":"EUb6IPWXYTn455"}',$Password,$SSID);
to:
my $payload = sprintf('{"passwd":"%s","ssid":"%s","token":""}',$Password,$SSID);

And post the result

1 Like

Thanks I'll try this tonight.

Right. So... my current plan - which I might even get fixed this evening with a following wind (will be friday if not - I'm in work all day tomorrow), is to simply cheat. Tasmota really wants MQTT, but it looks to be to be pretty trivial to abuse the console page to simply shout HTTP at it. http:///ax?c1= looks to execute, although I might have to some faintly 'orrible parsing to pull back the JSON if I actually want return values. Simply lobbing HTTP at it blind would probably work most of the time, though.

So... I've got a nasty hacked up driver that can currently do the following:

  1. Turn the light on and off.
  2. Set the colour. My HSV calculations are currently off - the bulb looks to accept a number between 0 and 360... but we don't specify it like that. More research required there.
  3. Set the bulb to white mode. Easy to do... but I need to dig a little, as this bulb looks to be RGBW, not RGBWW, so it doesn't do colour temperature as such. Not sure what the preferred command for switching modes is yet.

What it doesn't yet do is parse any of the responses it gets, or properly track the light's state (which it'd have to by keeping track internally, and maybe periodically polling to catch up with other people controlling it).

So... anyway... nearly there. OH ... one thing I would say, though... is that Tasmota clearly expects the PWM channels to be in 'RGBW' order, not 'WRGB', as I'd mistakenly initially configured it.

-- Jules

1 Like

Well I think i just bricked my socket. A little digging shows it is similar to sockets other have reported as bricked. Not sure I will be ordering any more. :frowning:

OK gang.

So... here's my VERY early attempt at a working DH for Tasmota RGBW bulbs.

It just about does colour and, while it doesn't do Color Temperature (I don't think the bulb itself does), selecting a temperature will move it over into 'white' mode.

It's very early, very nasty, and might do almost anything up to and including eat your hub alive. It's also based off some of @ericm's code, and I've set about destroying all his good work in the name of prototyping getting this to work. Sorry, Eric!

Anyway... have a play... let me know if it works for you. I'll tidy it up in the coming days, I'm sure.

-- Jules

1 Like

@cwwilson08 What were you doing when it bricked?

following the walkthrough for the ota.

Got near the end - seems the device should have reset then setup an access point for the final steps - after reset though nothing.

here is the console output

Starting Access Point with SSID ZAGDU-789
Giving Access Point IP address 10.44.57.2, pid is 1147
Redirecting device 192.168.1.75 to use Access Point ZAGDU-789
**** New device detected. ID: 12000222c3ae817a6f0 IP:192.168.1.75
Asking device to move networks and upgrade...
Redirecting device 192.168.1.75 to use Access Point ZAGDU-789
**** Redirect appears successful
DHCP Discover 2c:3a:e8:17:a6:f0 10.44.57.203
DHCP Request 2c:3a:e8:17:a6:f0 10.44.57.203
**** Device 12000222c3ae817a6f0 has changed IP from 192.168.1.75 to 10.44.57.203
Received DNS query for mq.gw.tuyaus.com.
Sending 10.44.57.2 as response
Accepting MQTT connection, forwarding to mq.gw.tuyaus.com.
Received DNS query for a.gw.tuyaus.com.
Sending 10.44.57.2 as response
Receiving www request
Fetching Request Content
URL: /gw.json?a=s.gw.update
Response: HTTP/1.1 200 OK
{"t":1548178042,"e":false,"success":true}
Receiving www request
Fetching Request Content
URL: /gw.json?a=s.gw.dev.update
Response: HTTP/1.1 200 OK
{"t":1548178043,"e":false,"success":true}
Receiving www request
Fetching Request Content
URL: /gw.json?a=atop.online.debug.log
Response: HTTP/1.1 200 OK
{"result":true,"t":1548178045,"e":false,"success":true}
Receiving www request
Fetching Request Content
URL: /gw.json?a=tuya.device.upgrade.silent.get
Sent upgrade response
Receiving www request
Fetching Request Content
URL: /gw.json?a=s.gw.upgrade.updatestatus
Response: HTTP/1.1 200 OK
{"t":1548178045,"e":false,"success":true}
Received DNS query for fakewebsite.
Sending 10.44.57.2 as response
Receiving www request
Sending firmware image_user2-0x81000.bin
Receiving www request
Sending firmware image_user2-0x81000.bin
Sending bytes 51-239270 from offset 0
Shutting down...
Setting up IP Address 192.168.4.2 for Final Stages
Getting interface into stable state
RTNETLINK answers: Cannot assign requested address
Done
Setting up wifi scan
Setting up listener for FinalStage
Shutting down...
Getting interface into stable state
RTNETLINK answers: Cannot assign requested address
Done
Finished
Exiting....
Shutting down...
1 Like