I am totally noob with zigbee and tuya. And i need advice for smart thermostatic radiator valves

I want to add smart trv’s to room radiators. I found SASWELL SEA801 and better designed SITERWELL GS361A-H04. Both TRV’s have own zigbee gateway and using with tuya app. I watched vid how to add device gateway and use with alexa etc.

But i want add to home assistant and want to see room temp and set to room temp, on, off valve etc.
My questions is here:

  1. I need same brand zigbee gateway or i use any other zigbee gateway, maybe usb zigbee with raspberry? (I am totally noob for zigbee. If i use other zigbee gateway still using with tuya or not working at all?)
  2. I know tuya is cloud based and home assistant have tuya integration. But this integration works as i want? read temp set temp on off vs will working? I don’t know. If you know i will be happy.
  3. Here i saw topic tuya convert. I think this process convert tuya devices normal wifi based devices. and not need to use with tuya. But this convert is compitable with this TRV’s? I looked suported devices and can’t find TRV. Only simple devices like bulbs or switches. If TRV not supportted in future will add support? Maybe i can help with device logs or anything need to knows about devices.
  4. Or zigbee schema will be decoded? and used like simple zigbee device. I dont know.
1 Like

Hello BTopbas and welcome to the forum. A lot of good people are really active here in the forum, and they are happy to help. I am not a professional and I cannot answer your questions. But I also considered which thermostats I buy and then use. It is a bit more complex with the thermostats. Even if the thermostats that you have are displayed in HA, they have to be controlled via an appropriate integration or interface. This is certainly also possible if you are well versed and have experience with programming. As a new user of HA, I would start with smaller projects, or use thermostats that can be directly integrated via the “integrations”.
I hope that I have not written anything wrong here, and I also like to learn something new. That is my opinion and experience, also like to delete the posts if I am totally wrong …

Thank you for reply. You are right! After opened this topic i searched about zigbee. I love programming and i have some skills. I saw project called zigbee2mqtt. When i get radiator valves i will try to sniff zigbee traffic and maybe i will create data schema for this device. But not giving a guarantee. Any other advices and recommends will welcome.

Hello BTopbas. I am also reading about this TRVs and would suggest to compare between the new version SASWELL SEA802 and SITERWELL GS361A-H04.

In fact I only found this products available from Alibaba and not too much technical documents to decide, so I would appreciate additional information.

I don’t found any info like you about SEA802. But i think works like SEA801 and changed design.

Found this user manual for SITERWELL…

Seems to work with ‘default’ tuya zigbee hub.

I just bought 4 of these Siterwell GS361A-H04 radiators from Alibaba. Once they arrive I will try to make them wotk with my Zigbee2Mqtt installation.
I will keep this threat updated :wink: .

I’ve also just bought a Qiumi smart TRV (rebranded Siterwell GS361A-H04). From the log file i can only seem to get the setpoint (no current temperature or battery).

My log output looks like this:
Received Zigbee message from ‘0xccccccfffed854d6’, type ‘commandGetData’, cluster ‘manuSpecificTuyaDimmer’, data ‘{“status”:0,“transid”:5,“dp”:514,“fn”:0,“data”:{“type”:“Buffer”,“data”:[0,0,0,210]}}’ from endpoint 1 with groupID 0

That was for 21deg setpoint

If you get anywhere with this device please let us know! Thanks

Which supplier you used on Alibaba? The ones I find selling this one all have a MOC of 100 …

Very interested in changing all my manual TRVs as well, under control of HA and Z2M.

This one:

1 Like

The valves arrived via DHL. I had to pay 30USD for the shipping and another 27USD in customs. I spend 141USD in total. 32.25USD per valve. Not bad.

The first thing I noticed is that the quality is not as good as in the pictures. It uses a colored LCD screen but some parts of the screen are dim depending of the angle of vision. I also noticed that sometimes the screen doesn’t go fully bright. That last problem seems random and is not very common.

The instructions came in English along with an adapter for Danfoss radiators. Oh, and AAx2 batteries included too. Btw, the instructions says I should use always dry batteries (not rechargable ones).

The devices were able to pair with my zigbee gateway (a CC2531 USB stick connected to my RPI 3B) but zigbee2mqtt.io printed in the logs that the device was not supported.

So, I had to add the support manually using the instructions at | Zigbee2MQTT . Here is where the problems started.

After spend hours preparing the environment to run Zigbee2mqtt with debug support (inside my pi), figuring out how the internals of Zigbee2mqtt works and analizing the data send by the devices, I managed to read the temperature from the valves and send them to Home Assistant. But that’s it. Just reading the values.

The problem is that Tuya didn’t publish the specs of the Zigbee Profile they use. There are not to-zigbee examples for Tuya devices in the repo of Zigbee2mqtt neither. Actually, the support that Zigbee2mqtt has for Tuya doesn’t exceed 5 devices (counting a BlitzWolf device too which seems to use the tuya API).

The data these valves send to the zigbee gateway are very cryptic.

I will share you what I managed to figure out so far:

You need to read the instructions at How to support new devices to understand where to put these gists.


// ...
    // Siterwell
        zigbeeModel: ['ivfvd7h'],
        model: 'GS361A-H04',
        vendor: 'Siterwell',
        description: 'Radiator thermostat',
        supports: 'temperature',
        fromZigbee: [fz.tuya_temperature, fz.ignore_basic_report],
        toZigbee: [],
// ...


// ...
   tuya_temperature: {
        cluster: 'manuSpecificTuyaDimmer',
        type: 'commandGetData',
        convert: (model, msg, publish, options, meta) => {
            const key = msg.data.dp;
            const val = msg.data.data;
            if ((key === 515 || key === 514) && val[2] === 0) {
                const temp_raw = val[3] || 0;
                const temperature = (temp_raw / 10).toFixed(1);
                return { temperature };
            } else {
                console.log(`NOT RECOGNIZED dp ${key}: ${JSON.stringify(val)}`)
// ...


// ...
// Map homeassitant configurations to devices.
const mapping = {
   // ...
   'GS361A-H04': [cfg.sensor_temperature],
// ...

With that configuration you will end with something this:

Now, the problem I’m facing is how to discover the structure of the command to tell the valves to change their temperature. And also, how to disable the fucking detect-open-window option. I already have sensors on the windows and I would like to handle that fearure in HA.

I search all over the Internet but I couldn’t find what I needed to manually implement the missing piece. So I finally bought a tuya zigbee gateway and, once it arrives and I have it paired with the valves, I will sniff their comunication to figure out how to emulate the same commands from Zigbee2mqtt.

Btw, the approach how Zigbee2mqtt offers to add custom devices is awful.

Good news!

I managed to improve my previous configuration. Now I can read the room temperature, the setpoint (desire temperature) and the operation mode (anti-freezing, auto or manual).

The device is now published to home-assistant using the “climate” class.


Still no luck on changing the config remotely via mqtt. I managed to make the radiator valve move but the screen change to 73.8 celsius and since then the values were total nonsense. I had to restart the device (the config clears just by removing the batteries).


   tuya_temperature: {
        cluster: 'manuSpecificTuyaDimmer',
        type: 'commandGetData',
        convert: (model, msg, publish, options, meta) => {
            const key = msg.data.dp;
            const val = msg.data.data;
            if (key === 515 && val[2] === 0) {
                const temp_raw = val[3] || 0;
                const temperature = (temp_raw / 10).toFixed(1);
                return { local_temperature: temperature };
            } else if (key === 514 && val[2] === 0) {
                const temp_raw = val[3] || 0;
                const temperature = (temp_raw / 10).toFixed(1);
                return { current_heating_setpoint: temperature };
            } else if (key === 1028) {
                const mode_code = val[0];
                switch (mode_code) {
                    case 0: return { system_mode: "antifreezing" };
                    case 1: return { system_mode: "auto" };
                    case 2: return { system_mode: "manual" };
                    default: return { system_mode: "unknown" };
            } else {
                console.log(`NOT RECOGNIZED dp code "${key}" with data: ${JSON.stringify(val)}`)


const cfg = {
   //... line 471
   'thermostat': (
        minTemp = 7,
        maxTemp = 30,
        temperatureStateProperty = 'occupied_heating_setpoint',
        tempStep = 1,
        modes = ['off', 'auto', 'heat']
    ) => {
        return {
            type: 'climate',
            object_id: 'climate',
            discovery_payload: {
                state_topic: false,
                min_temp: `${minTemp}`,
                max_temp: `${maxTemp}`,
                mode_state_topic: true,
                mode_state_template: '{{ value_json.system_mode }}',
                mode_command_topic: true,
                current_temperature_topic: true,
                current_temperature_template: '{{ value_json.local_temperature }}',
                temperature_state_topic: true,
                temperature_state_template: `{{ value_json.${temperatureStateProperty} }}`,
                temperature_command_topic: temperatureStateProperty,
                temp_step: tempStep,
                action_topic: true,
                action_template: '{{ value_json.operation }}',
   // ...

const mapping = {
   //... line 1258
   'GS361A-H04': [cfg.thermostat(5, 30, 'current_heating_setpoint', 0.5, ['antifreezing', 'auto', 'manual'])],

Note: If you were using the previous config, don’t forget to remove the former properties of the devices from states.json or just delete states.json to start zigbee2mqtt from scratch.

You received gateway? I am still searching cheap and smart good design e-trv. This TRV will work in the future with Zigbee2mqtt?

I’m still waiting for the gateway.

I feel pretty much confident that, once I managed to sniff what the gateway sends to the TRVs, I will be able to replicate the commands.

As I said, so far I managed to figure out the format of the payloads the TRVs sends to the Zigbee Coordinator (Zigbee2Mqtt gateway).

The HomeAssistant buttons to change the temperature do nothing for now.

When i contact the supplier of this siterwell trv’s seller said 3 version of them.
One of tuya Zigbee.
One of tuya Bluetooth
One of ZigBee 3.0
I am confused. If i will buy zigbee 3.0 version can i add support for z2m without gateway? Or i need to gateway for sniffing communication. Or i will wait your work. And will buy tuya zigbee version like you.
Seller says siterwell member of zigbee alliance and uses global zigbee standarts.

Ha! They didn’t tell me they had a Tuya Zigbee and a Zigbee 3.0 version. I have no idea which zigbee-based device I bought.

Update 04/04/2020: I got the Zigbee 3.0 version @BTopbas (I read it from the data sent by the TRVs during the pairing process).

The zigbee gateway arrived. But I didn’t notice I need to have run an special firmware on my CC2531 usb stick to be able to sniff zigbee traffic. I don’t have the debugger hardware to do it. I will follow the instructions to do it using my raspberry pi instead but it will require at least a couple of hours of work. I will schedule that in one of these days of quarantine.

But, let me tell you about the Tuya gateway that I received. It was smaller than I expected and the final quality look cheap. But, well, it’s fucking cheap.

The instructions that came with the device said that I need to configure it with an app called Smart Life, published by Tuya. They have another app named Tuya Smart too, but the instructions within the box said Smart Life so, that’s what I installed. Seen the screenshots of Tuya Smart, it looks almost the same.

The most dificult part of pairing the gateway with the newly create Smart Life account was to select the correct device from their catalog. Fuck, they have more than one device named “Gateway” with the same icon. That’s when I started to realize the software might fall below my expectations. Sadly, I was not wrong.
The Smart Life UI responds quite slow, but the icing of the cake falls on the Siterwell UI for this app. It’s just ugly and not very intuitive. To give you an idea, the ugliest Climate component of Home Assistant looks better than this. It works though. With slow feedback, but it works.

Now, the ugliest part: The integration of Tuya with Home Assistant.

I was only interested in the integration of “climate” devices coming from Tuya. According to Home Assistant’s website this type of device is supported. And technically it does, but how is implemented is a joke.

This is the data that came for one Siterwell TRV from Tuya:

hvac_modes: off
min_temp: 50
max_temp: 300
target_temp_step: 1
current_temperature: 224
temperature: 235
friendly_name: Dormitorio
supported_features: 1

As you can see, no list of available HVAC modes, current HVAC mode, nor battery status. And yes, the decimal separator is not added, ending with a whopping 224 Celcius for room temperature.
Changing the target temperature from HASS does not work. My guess is that HASS sends “220” as a new target temperature and Tuya or the TRV rejects the order because the value is way higher than 30 Celcius (the max target value according to the TRV specs).

The bottom line, controlling these Siterwell TRVs from Tuya’s integration for Home Assistant is not an option.

I will keep you up to date.

I had some progress.

I create a tuya developer account and followed the instructions to register a new IoT device. The tuya web gui show a wizard to help me choose the features I would like to include on my device. It even generate me code to customize and then flash on my device.

In this generates assets I found a very useful pdf document in which my selected commands are described in detail.
I immediatelly noticed some similarities with the raw data I capture (which at this point I have printed on my retina).

For example, for the change mode command send from the TRV module I got the following (decrypted) raw data:

00 3e 04 04 00 01 02

And this is what the generated document says:

ID Function name Header version Command word Data length dpID Data type Function length Function command Checksum
2 Mode Module send 0x55aa 0x02 0x04 0x00 0x05 0x02 0x04 0x00 0x01 auto:0x00 manual:0x01 eco:0x02 Checksum

Do you notice how the captured data matches the table?

Data length?? dpID?? Data type Fn length Value
00 3e 04 04 00 01 02

I took several samples of the packets transmitted when different actions take place on the App and manually from the TRV. I will proceed to re-flash the normal firmware on my cc2531 and test my findings.

Wish me good luck.

You’ve made big progress here! :slight_smile:
If you’d need any help decoding/matching dumps to commands, please just ask.

I haven’t bought thermostat yet… but I’d like very much.

1 Like

I just wanted to inform you that I successfully managed to control the TRV from Home Assistance using zigbee2mqtt.

I was able to map most of the commands supported by the device. All the commands/actions except 2 which, honestly, I don’t know what the fuck they mean. The only two commands I didn’t sniff were “config pending” and “fault”. Maybe these are those, or maybe not. The important commands that I already can control are:

  • Set target temperature
  • Change mode (off/antifreeze, heat, and auto)
  • Enable/disable window detection
  • Enable/disable valve detection (although I don’t know what this means)
  • Enable/disable child lock

I’ll create the merge request with my implementation to the zigbee2mqtt author to review it. But that later. I’m tired right now.