it is a mess mate
Call me a cynic, but i doubt there was ever an intention to add local control and was a ploy just to get people into their ecosystem knowing full well people will be loath to ditch something they paid for because a feature isn’t there.
Just take a look at a response very early on from one of their own about why local control isn’t required, which after todays outage makes their point rather invalid.
@zlinoliver clearly doesn’t understand the ethos of HA. That statement doesn’t even need comment because it is so stupid.
It is like saying “you have a telephone, you won’t mind if we tap it, and we might occasionally and randomly release your tapes”.
it is in 2021.10, according to the beta release notes.
Well, that’s great, since switches are currently broken, according to GitHub Issues on the official integration’s page. </sarcasm>
Folks, I am not sure whether it is related but my Tuya integration stopped working. I have one valve to control. The valve can be open by their Tuya app, so it seems it’s not related to the outage.
Sure, local control would be the best. The firmware that came with it is not hackable by the Tasmota, so I kept using cloud but it stopped working. What’s happening? Will the local control be available thanks to the HA/Tuya cooperation?
Try power cycling the valve (unplug it for a moment and let the capacitors discharge).
the onboarding for the new integration looks a pain…
noway, it really helped. Was it related to the current issues with Tuya? Devices should not need restarting, especially when my garden depends on them…
Huh. It didn’t even occur to me to turn my switches off and on but it did work.
I presume this was related to the issue at the weekend - how frustrating…
Well… same. I feel stupid and now I hate those damn cloud services a little bit more.
It looked a bit like DNS was failing during the Tuya outage.
My guess is that once DNS failed on the devices, they stopped trying. But yes, this highlights perfectly why the integration should be entirely local, and not dependent on a cloud API once authentication succeeds and the devices are enrolled into Home Assistant @zlinoliver
Since this issue, I have decided that Tuya is too unreliable to use with HA and am going 100% Tasmota.
I’d give LocalTuya a look if you can’t tasmotize any devices. Works perfectly for me 
Damn right. What I don’t understand is that the people behind Home Assistant are making a big fuzz about this new “official Tuya integration” when this integration does not seem to be in line with their original philosophy whatsoever.
Paulus has been talking for years how local control and privacy are his main focus points for home assistant, he even threw Google under the bus for cancelling their local API and now he’s embracing Tuya.
Home Assistant was supposed to be all about local control, privacy etc. and now they are embracing a big bad giant that does not care about your privacy at all, just about the bottom line.
A quote from Home Assistants founder:
and…
I don’t care much for Tuya’s “promises” of local control at a later time. These things never happen, just like Panasonic always promises features in future firmware that will never be released!
I don’t trust tuya. If you buy their hardware you are depending on the internet to work 24/7 and if they have a new way of making money, your products will be not get firmware updates anymore.
Even much criticised Philips Hue has a local API for it’s gateway and their products work fine with a Zigbee2Mqtt gateway as well. I can really not recommend anybody buying Tuya hardware, unless you’ll be running esphome or tasmota on it (if at all possible).
Be warned!
I already do, but it doesn’t implement the same level of functionality.
Last time I tried to look at LocalTuya I gave up after google found several projects and confusing advice.
Does anyone have a definitive guide?
Also, what are these level of functionality that you are not seeing?
This is getting a little off-topic, so I’ll be as brief as possible. One example are light buttons created by LocalTuya, which don’t include dimmer functionality on the button (those created by Tuya or Tuya v2 include it).
+1 I think it’s best to stay away from Tuya WiFi products, though their zigbee units seems cheap enough and don’t have any of this cloud stuff to deal with. I don’t understand any excitement about this given they said they were going to do local control and now are not going to deliver that.
Lots of alternatives available in most cases to their products. Hopefully the folks who are building products will pick a non-Tuya stack that supports local control. Sonoff and others seem to be doing fine without being forced to use a cloud component.
Nick, I have just been through this, as I bougt some Arlec bulbs that do not use 8266 chips.
From my experience, basically process is:
A video from @MarkWattTech on how to get the developer account is here (from 6:15):
Once that is done - here are the notes I made on what I need to do in the future if I want to add another device (When It says ‘table above’ these notes are in a spreadsheet and I just copy and paste the information into it to save me having to go through the process again):
Once the hurdle with creating a Tuya developer account is taken and tuya-cli wizard is installed you’ll be rewarded with a local tuya which works quite well on different installations here. Nothing too fancy here though, just switches, plugs and blinds left which I will replace with zigbee/tasmota on the long term anyway.
However, during that tuya server blackout a few days ago tuya devices here managed by Local Tuya were not affected at all in contrast to a friend’s installation with HA’s tuya integration in place: Her Tuya based devices could not be managed for hours.
Only problem with local tuya is you cant block some devices from the internet entirely.
edit, scrub that as long as you block dns (even local) they will work
