I am home sick today and just had time to read this thread.
What a mess.
I am home sick today and just had time to read this thread.
What a mess.
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.