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 
.
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:
https://www.alibaba.com/product-detail/Manufacture-Reddot-design-award-Bluetooth-Z_60782820931.html
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.
devices.js
// ...
// Siterwell
{
zigbeeModel: ['ivfvd7h'],
model: 'GS361A-H04',
vendor: 'Siterwell',
description: 'Radiator thermostat',
supports: 'temperature',
fromZigbee: [fz.tuya_temperature, fz.ignore_basic_report],
toZigbee: [],
}
// ...
converters/fromZigbee.js
// ...
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)}`)
}
},
},
// ...
homeassistant.js
// ...
// 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).
converters/fromZigbee.js
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)}`)
}
},
},
homeassistant.js
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}`,
modes,
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.jsonor just deletestates.jsonto 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! 
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.
4 Likes
All my pull requests were merged. The implementation of the Siterwell GS361 valves will probably be included in the next zigbee2mqtt release.
- Added HA config for radiator valve Siterwell GS361
- Handle the command 0x02 of the cluster manuSpecificTuyaDimmer
- Added support for radiator valve Siterwell GS361
Before you rush to buy these valves I have to warn you though. The main and only complaint I have about these devices is that sometimes their reaction time is very slow. This is a problem I noticed when I was using the Tuya gateway with the Siterwell UI. The same delay is present using zigbee2mqtt.
When the Zigbee coordinator (zigbee2mqtt) sends an order, the TRV takes between 1 to 30 seconds to execute and reply, The reason for this delay is still unknown to me.
I also noticed that the TRVs sends to the Coordinators all their commands repeated 3 times. This happens even if both devices 20 cm appart. It may be that the waiting time for the acknowledges of the messages is too short. This is imperceptible for the final user. It’s just a curious detail. I use the “debounce_ignore” and “debounce” zigbee2mqtt options per device to avoid firing 3 mqtt messages in a row.
5 Likes
Hi Daniel,
Super work for this integration of these TRV to zigbee2mqtt.
I have been looking at this type of valve for a while. I of course came across the model that you integrated and also on these 2 other models:
The 2 models work with the Tuya gateway. Do you think these models can be integrated like the Siterwell GS361 trv?
I don’t think so. The implementation will be very similar thought.
It’s possible that only the dp codes (the codes that identify the actions) will be different.
Soon I will publish an article explaining what I did to reverse engineered the implementation of this tuya-based TRV.
1 Like
Thank you for your return I look forward to your article.
I had planned to write 3 articles but then I received a shit-ton of work and I couldn’t finish the 3rd article describing how to teach zigbee2mqtt to interact with a new device. Hopefully, I will do it soon.
4 Likes