Please report any issues and feel free to raise pull requests. Many others have contributed their help already.

This is a Home Assistant add-on to support Wi-fi devices running Tuya firmware without going via the Tuya cloud. Currently only WiFi devices are supported, Tuya also makes Zigbee, BLE and other devices that connect to WiFi using a gateway, such devices are not yet supported.

Note that most Tuya devices seem to support only one local connection. If you have connection issues when using this integration, ensure that other integrations offering local Tuya connections are not configured to use the same device, mobile applications on devices on the local network are closed, and no other software is trying to connect locally to your Tuya devices.

Using this integration does not stop your devices from sending status to the Tuya cloud, so this should not be seen as a security measure, rather it improves speed and reliability by using local connections, and may unlock some features of your device, or even unlock whole devices, that are not supported by the Tuya cloud API.

A similar but unrelated integration is rospogrigio/localtuya, if your device is not supported by this integration, you may find it easier to set up using that as an alternative.

Note that devices sometimes get firmware upgrades, or incompatible versions are sold under the same model name, so it is possible that the device will not work despite being listed.

A list of currently supported devices can be found in the DEVICES.md file.

If your device is not listed, you can find the information required to add a configuration for it in the following locations:

1. When attempting to add the device, if it is not supported, you will either get a message saying the device cannot be recognised at all, or you will be offered a list of devices (maybe a list of length 1) that are partial matches, often simple switch is among them. You can cancel the process at this point, and look in the Home Assistant log - there should be a message there containing the current data points (dps) returned by the device.

2. If you have signed up for iot.tuya.com to get your local key, you should also have access to the API Explorer under "Cloud". One of the functions under the "Device Control" section - the last "Get Device Specification Attribute" function listed, returns the dp_id in addition to range information that is needed for integer and enum data types.

3. By following the method described at the link below, you can find information for all the data points supported by your device, including those not listed by the API explorer method above and those that are only returned under specific conditions. Ignore the requirement for a Tuya Zigbee gateway, that is for Zigbee devices, and this integration does not currently support devices connected via a gateway, but the non-Zigbee/gateway specific parts of the procedure apply also to WiFi devices.

https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html

If you file an issue to request support for a new device, please include the following information:

1. Identification of the device, such as model and brand name.
2. As much information on the datapoints you can gather using the above methods.
3. If manuals or webpages are available online, links to those help understand how to interpret the technical info above - even if they are not in English automatic translations can help, or information in them may help to identify identical devices sold under other brands in other countries that do have English or more detailed information available.

If you submit a pull request, please understand that the config file naming and details of the configuration may get modified before release - for example if your name was too generic, I may rename it to a more specific name, or conversely if the device appears to be generic and sold under many brands, I may change the brand specific name to something more general. So it may be necessary to remove and re-add your device once it has been integrated into a release.

Installation is via the Home Assistant Community Store (HACS), which is the best place to get third-party integrations for Home Assistant. Once you have HACS set up, simply click the button below or follow the instructions for adding a custom repository and then the integration will be available to install like any other.

You can easily configure your devices using the Integrations configuration UI.

The first stage of configuration is to provide the information needed to connect to the device.

You will need to provide your device's IP address or hostname, device ID and local key; the last two can be found using the instructions below.

    (string) (Required) IP or hostname of the device.

    (string) (Required) Device ID retrieved as per the instructions below.

    (string) (Required) Local key retrieved as per the instructions below.

At the end of this step, an attempt is made to connect to the device and see if it returns any data. For tuya protocol version 3.3 devices, success at this point indicates that all settings you have supplied are correct, but for protocol version 3.1 devices, the local key is only used for sending commands to the device, so if your local key is incorrect the setup will appear to work, and you will not see any problems until you try to control your device. Note that each time you pair the device, the local key changes, so if you obtained the local key using the instructions linked above, then repaired with your manufacturer's app, then the key will have changed already.

The second stage of configuration is to select which device you are connecting. The list of devices offered will be limited to devices which appear to be at least a partial match to the data returned by the device.

    (string) (Optional) The type of Tuya device. Select from the available options.

If you pick the wrong type, you will need to delete the device and set it up again.

The final stage is to choose a name for the device in Home Assistant.

If you have multiple devices of the same type, you may want to change the name to make it easier to distinguish them.

    (string) (Required) Any unique name for the device. This will be used as the base for the entitiy names in Home Assistant. Although Home Assistant allows you to change the name later, it will only change the name used in the UI, not the name of the entities.

    (boolean) (Optional) Additional options may be available for deprecated entities exposed by the device. They will be named for the platform type and an optional name for the entity as a suffix (eg climate, humidifier, lock_child_lock) Setting them to True will expose the entity in Home Assistant.

It is strongly recommended that you do not enable deprecated entities when setting up a new device. They are only retained for users who set up the device before support was added for the actual entity matching the device, or when a function was misunderstood, and will not be retained forever.

As of 0.18.0, there are no longer any deprecated entities, but they may be reintroduced in future if better representations of existing devices emerge again.

Many Tuya devices will stop responding if unable to connect to the Tuya servers for an extended period. Reportedly, some devices act better offline if DNS as well as TCP connections is blocked.

Goldair GPPH heaters have individual target temperatures for their Comfort and Eco modes, whereas Home Assistant only supports a single target temperature. Therefore, when you're in Comfort mode you will set the Comfort temperature (5-35), and when you're in Eco mode you will set the Eco temperature (5-21), just like you were using the heater's own control panel. Bear this in mind when writing automations that change the operation mode and set a temperature at the same time: you must change the operation mode before setting the new target temperature, otherwise you will set the current thermostat rather than the new one.

When switching to Anti-freeze mode, the heater will set the current power level to 1 as if you had manually chosen it. When you switch back to other modes, you will no longer be in Auto and will have to set it again if this is what you wanted. This could be worked around in code however it would require storing state that may be cleared if HA is restarted and due to this unreliability it's probably best that you just factor it into your automations.

When child lock is enabled, the heater's display will flash with the child lock symbol ([]) whenever you change something in HA. This can be confusing because it's the same behaviour as when you try to change something via the heater's own control panel and the change is rejected due to being locked, however rest assured that the changes are taking effect.

When setting the target temperature, different heaters have different behaviour, which you may need to compensate for. From observation, GPPH heaters allow the temperature to reach 3 degrees higher than the set temperature before turning off, and 1 degree lower before turning on again. Kogan Heaters on the other hand turn off when the temperature reaches 1 degree over the targetin LOW mode, and turn on again 3 degrees below the target. To make these heaters act the same in LOW power mode, you need to set the Kogan thermostat 2 degrees higher than the GPPH thermostat. In HIGH power mode however, they seem to act the same as the GPPH heaters.

The Inkbird thermostat switch does not seem to work for setting anything. If you can figure out how to make setting temperatures and presets work, please leave feedback in Issue #19.

Reportedly, Goldair fans can be a bit flaky. If they become unresponsive, give them about 60 seconds to wake up again.

Anko fans mostly work, except setting the speed does not seem to work. If you can figure out how to set the speed through the Tuya protocol for these devices, please leave feedback on Issue #22.

It has been observed after a while that the current and power readings from the switch were returning 0 when there was clearly a load on the switch. After unplugging and replugging, the switch started returning only dps 1 and 2 (switch status and timer). If HomeAssistant is restarted in that state, the switch detection would fail, however as Home Assistant was left running, it continued to work with no readings for the current, power and voltage. I unplugged the switch overnight, and in the morning it was working correctly.

Cumulative Energy readings seem to be reset whenever the reading is successfully sent to the server. This leads to the energy usage never moving from the minimum reporting level of 0.1kWh, which isn't very useful. It may be possible to get useful readings by blocking the switch from accessing the internet, otherwise an integration sensor based on the Power sensor will need to be set up on the Home Assistant side, and the Energy sensor ignored.

Although these look like simple devices, their behaviour is not consistant so they are difficult to detect. Sometimes they are misdetected as a simple switch, other times they only output the temperature sensor so are not detected at all.

These devices support switching between Celcius and Fahrenheit on the control panel, but do not provide any information over the Tuya local protocol about which units are selected. Two configurations for this device are provided, beca_bhp6000_thermostat_c and beca_bhp6000_thermostat_f, please select the appropriate one for the temperature units you use. If you change the units on the device control panel, you will need to delete the device from Home Assistant and set it up again.

These support configuration as either heating or cooling controllers, but only have one output. The HVAC mode is provided as an indicator of which mode they are in, but are set to readonly so that you cannot accidentally switch the thermostat to the wrong mode from HA.

You can find these keys the same way as you would for any Tuya local integration. You'll need the Goldair app or the Tuya Tuya Smart app (the Goldair app is just a rebranded Tuya app), then follow these instructions.

• Instructions for iOS
• Instructions for Android

1. This component is mosty unit-tested thanks to the upstream project, but there are a few more to complete. Feel free to use existing specs as inspiration and the Sonar Cloud analysis to see where the gaps are.
2. Once unit tests are complete, the next task is to complete the Home Assistant quality checklist before considering submission to the HA team for inclusion in standard installations.
3. Discovery seems possible with the new tinytuya library, though the steps to get a local key will most likely remain manual. Discovery also returns a productKey, which might help make the device detection more reliable where different devices use the same dps mapping but different names for the presets for example.