(Garza) Tuya Wifi Smart Breakers

🛎️ Get Help
1

Hi, just received my Hubitat (yay!) so I'm new to Hubitat but have these (Garza) Tuya Wifi Smart Breakers and plugs set up in Home Assistant with local Tuya working just fine but the idea is to get rid of HA running in docker on my Raspberry pi 4 and go full Hubitat.

I searched the forums, albeit superficially, but I couldn't find an answer, I apologize in advance if this has been covered before, and I welcome anyone that'll point me in the right direction.

What I have:
10 Smart Breakers by the brand Garza named 1 through 8, Bathroom, and Workshop 3.
3 Smart Plugs by the brand Garza named Living room light, Workshop light, and Label writer.

What I've done:
Followed the steps here: hubitatappndevice/Device/tuyaDevices at master · ivarho/hubitatappndevice · GitHub
On the last step of python -m tinytuya wizard I get this result:
Polling local devices...
[1 ] Error: No IP found
[2 ] Error: No IP found
[3 ] Error: No IP found
[4 ] Error: No IP found
[5 ] Error: No IP found
[6 ] Error: No IP found
[7 ] Error: No IP found
[8 ] Error: No IP found
[Bathroom ] Error: No IP found
[Label writer ] Error: No IP found
[Living room light ] 192.168.1.128 - No Response
[Workshop 3 ] Error: No IP found
[Workshop light ] 192.168.1.129 - [Off] - DPS: {'1': False, '9': 0, '18': 0, '19': 0, '20': 2280, '21': 1, '22': 677, '23': 24487, '24': 15589, '25': 2670, '26': 0}

I got the IPs, deviceids and local keys off HA diagnostics files, and added them into Hubitat, no dice for the Smart Breakers, but the plugs named Living room light, and Workshop light are controllable through Hubitat (yay!).

The problem:
The thing is that all devices with "Error: No IP found" actually have IPs, are pingable and controllable through HA. Label Writer is unplugged so I understand the error.

What I tried:
Reset my home wifi.
Both 3.1 and 3.3 protocols

Logs:
1: https://logpaste.com/J1KLxNXA
2: https://logpaste.com/46vfteb8
3: https://logpaste.com/hSnpREAh
4: https://logpaste.com/82X4gBAh
5: https://logpaste.com/fnGze9Xz
6: https://logpaste.com/Ws9yaFYO
7: https://logpaste.com/wDTy57FA
8: https://logpaste.com/qFUlK7B2
Bathroom light: https://logpaste.com/x2hVsf2k
Workshop 3: https://logpaste.com/QavL3C5m

Questions:
I read somewhere about custom firmware for Tuya devices, do I actually need to do this?

One thing I noticed, not sure if this is actually relevant, when adding the device called "1", its IP is 192.168.1.133, got the deviceid and local key off HA diagnostics. The local key in question is Mnc8-:Y25<BGNK!1 although when I save it in Hubitat, the local key gets changed to Mnc8-:Y25**&**lt;BGNK!1 the < gets changed into an ampersand, the letter L, and the letter T. Is that just cosmetic?

What am I missing/doing wrong?

Thanks in advance for any help!

2

Tagging @kkossev

1 Like
3

I can help with Zigbee devices only, not WiFi...

3 Likes
4

Tagging @holand.ivar

1 Like
5

thanks anyways!

6

You can try also [BETA] Tuya Cloud Driver (Limited device support), but this will be a Cloud, not a local connection.

1 Like
7

Thanks, yeah got them working like that :slight_smile:
Ideally I'd run them locally but this'll do for now. Hopefully someone'll have an idea of where I was going wrong.

Also, I think the fact that the character < in the local keys gets turned into & has something to do with it but what the hell do I know? :sweat_smile:

1 Like
8

I think you are on to something about the key containing "<". I would expect the input fields in Hubitat to be protected from special character input. I need to do some experimenting on my side to see if I can fix that. As long as you have the IP addresses and local keys I would not worry too much about the tinytuya wizard not working.

2 Likes
9

"Dear diary, today I feel smart" :rofl:
Awesome, thanks a bunch!

2 Likes
10

An attempted fix has been added for all my tuya drivers (hubitatappndevice/Device/tuyaDevices at master · ivarho/hubitatappndevice · GitHub)

It is a bit of a hack where it updates the localKey to unescape the character "<" - "&lt; " back to "<".

settings.localKey = settings.localKey.replaceAll('&lt;', '<')

It seems that Hubitat only escape the "<". as I could not find other characters that are escaped the same way.

Give it a try and let me know how it goes.

2 Likes
11

Thanks, but the issue is still present. I paste Mnc8-:Y25<BGNK!1 and as soon as I hit save, blamo! it turn into this:
Screenshot 2023-07-01 at 01.31.22

However, the switches that previously didn't work and with local keys without < now work! :smiley:
One example is &vdHLGbF#CF'Ca!?

12

Yes, that is just a Hubitat thing that we have to live with. Before driver uses the key the < gets converted to a single byte value of 60 as expected.

Could you post a debug log from the failing device?

13

Yes of course, here's the one from the switch with local key Mnc8-:Y25<BGNK!1

dev:902023-07-01 01:46:53.232errorjava.security.InvalidKeyException: Invalid AES key length: 19 bytes on line 355 (method on)
dev:902023-07-01 01:46:53.220debugpayload before={"devId":"6260147598cdac261a4e","uid":"6260147598cdac261a4e","t":"1688168813","dps":{"1":true}}
dev:902023-07-01 01:46:53.218debug33
dev:902023-07-01 01:42:40.723warndebug logging is: true
14

I think I managed to fix it in the latest update. I had to dig further down in the code to do the string replace. Try the latest versions on my github and let me know how it goes.

1 Like
15

That did it, the < still does get changed cosmetically, but the devices are now controllable. Thank you so much!

Is there any way I can buy you a beer/coffee/tea/soda?

2 Likes
16

You're very welcome, it is cool to see that the stuff i make is useful for someone.

1 Like
17

This is most definitely useful to me right now all day every day :heart:

18

Gotta love the Hubitat Community devs!

1 Like