Aqara e1 valve (TRV) device

Does anyone have experience with this device (zigbee/matter) with Z2M/NR, possibly with some example flow?

I remember seeing something mentioned about this, but I can’t remember where. I could do some digging. Do you have one and are trying to set it up? Or are you considering a purchase?

I’ve One on my hands since few hours. Paired to z2m. I would link It to an external temperature device (internal feature) but I have no idea about how-to. Very good quality at First glance

Would the external device you’re referring to be a thermostat. Maybe? Do you have a smart stat? Have you tinkered with it with a temperature sensor of some sort? Anything that will report temperature maybe. Just throwing some suggestions out there.

This is the device:

It has an internal (biased) temperature sensor.
It allows to use temperature coming from an external zigbee device. Unfortunately I do not know how to. It seems It needs the zigbee address of the ext device, but I have no idea how to put it inside the aqara.

It works, Is supported by Z2M, probably not fully. It has a very good color display. The UI Is very friendly

Gosh, I remember someone talking about it, but I can’t for the life of me remember where I read the conversation. I apologize that I’m not much help on this one. we cold plan a teams meeting at a time that works better for you and see if we can help you work it out.

Did a bit of research and believe I found the relevant info for you… I’ll leave the rest up to you guys :slight_smile:


The header for all commands on 0xfff2 is described here: Aqara S1 Smart Scene Panel Protocol · dresden-elektronik/deconz-rest-plugin Wiki · GitHub

Command Start Command category CMD Size CMD Type Counter Integrity CMD Action Data Type Params Size
aa 71 31 44 10 60 02 41 2e

I wrote a quick implementation of this:

const aqaraHeader = (counter, params, action) => { // Based on Aqara S1 Smart Scene Panel Protocol · dresden-elektronik/deconz-rest-plugin Wiki · GitHub const header = [ 0xaa, // static 0x71, // to device params.length + 3, // CMD Size (all params after integrity) 0x44, // CMD Type counter, // Counter ]; const integrity = 512 - header.reduce((sum, elem) => sum + elem, 0); return [ …header, integrity, action, // 0x02 for linking sensor, 0x04 for unlinking, 0x05 when setting temperature state 0x41, // Octet string params.length, // Params size ]; };

Some more details about “link sensor”:

Linking consists of two commands which are always sent in the same order. I’m not sure if both are required but at least one of them has to be sent before setting temperature state.
The first 4 hex codes are unix timestamp in seconds encoded as int. E.g. 0x6339bf17 => 1664728855 => Sun Oct 2 06:40:55 PM CEST 2022.

Link 1:

Timestamp Const Link 1 Device address Sensor address Const shared between first link and write temp state Const for link 1 Common between links Const link 1 End
63:39:bf:0e 3d 04 54:ef:44:10:00:51:c2:5a 00:15:8d:00:07:f8:06:22 00:01:00:55 13:0a:02:00:00:64:04:ce:c2:b6:c8 00:00:00:00:00:01:3d 64 65

Link 2:

Timestamp Const Link 2 Device address Sensor address Const for link 2 Common between links Link 1(?) End
63:39:bf:0e 3d 05 54:ef:44:10:00:51:c2:5a 00:00:00:00:00:00:00:00:00:00:00:00 08:00:07:fd:16:0a:02:0a:c9:e8:b1:b8:d4:da:cf:df:c0:eb 00:00:00:00:00:01:3d 04 65

Set external sensor temp

While reverse engineering the temperature I didn’t realize that the value was encoded as float so I accidentally wrote a shitty implementation of floating point. Glad that never has to see the light of day. :smile:
Instead we can just use this:

const value = 23.57; const temperatureBuf = Buffer.allocUnsafe(4); temperatureBuf.writeFloatBE(Math.round(value * 100));

temperatureBuf: <Buffer 45 13 50 00>
As a side note I find it weird that they use floating point instead of int here since they don’t even use the fraction part.

When an external sensor temperature is set the TRV reports LocalTemperature with the specified temperature so it doesn’t look like we have to any special handling here compared to using the internal sensor.

Unlinking (going back to internal sensor):

Looks like this time the commands are sent in opposite order (05 then 04).

Timestamp Const Link 2 Device address Const
63:39:bf:0e 3d 05 54:ef:44:10:00:51:c2:5a 00:00:00:00:00:00:00:00:00:00:00:00
Timestamp Const Link 1 Device address Const
63:39:bf:0e 3d 04 54:ef:44:10:00:51:c2:5a 00:00:00:00:00:00:00:00:00:00:00:00

Sending temperature in zigbee2mqtt

const params = [ …sensor, 0x00, 0x01, 0x00, 0x55, // static? …temperatureBuf, ]; const value = [ …(aqaraHeader(0x12, params, 0x05)), …params, ]; await entity.write(‘aqaraOpple’, {0xfff2: {value, type: 0x41}}, 0x115f);

I’m not sure if the sensor address actually matters but the same address has to be used when linking and when setting temperature. Likely we can get away with using a static address.
I’m also not sure if increasing the counter actually makes a difference as just using the same value does seemingly work. Might make a difference if commands are sent rapidly

This info was extracted from this thread: [New device support]: Aqara Smart Radiator Thermostat E1 (SRTS-A01) · Issue #13993 · Koenkk/zigbee2mqtt · GitHub

It makes sense if I think to groovy drivers. I have no idea how to do It in a z2m/nr framework.
Are the hex values allowed in a msg ? How can I map the above msg layout to a NR msg ?

EDIT: this sounds more Z2Mish:

But… What Is zigbee2mqtt_edge ? I cannot find “Settings/Scene and automations” entry in zigbee2mqtt…

First possible solution with NR in the middle
For any external termometer value change, set the TRV’s sensor_temp attribute to the external value

It works, however I’m sure it’s possible to let the TRV get directly (without NR in the middle) the external value by setting the zigbee id of the external device, but I don’t know how.

[{"id":"083fe2b27536cd99","type":"zigbee2mqtt-in","z":"3d65fe21b7f1f802","name":"TH03-SALOTTO","server":"411e2b8e9bdac70b","friendly_name":"TH03-SALOTTO (WSDCGQ11LM)","device_id":"0x00158d0002d7f3b7","state":"0","outputAtStartup":true,"filterChanges":false,"enableMultiple":false,"x":640,"y":180,"wires":[["a5bce0e7db4ca5f7"]]},{"id":"a5bce0e7db4ca5f7","type":"function","z":"3d65fe21b7f1f802","name":"function 20","func":"msg={\"payload\":{\"sensor_temp\":msg.payload.temperature}}\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":810,"y":180,"wires":[["84283dd7767bfc15"]]},{"id":"84283dd7767bfc15","type":"zigbee2mqtt-out","z":"3d65fe21b7f1f802","name":"","server":"411e2b8e9bdac70b","friendly_name":"TRV-SALOTTO-FINESTRA (SRTS-A01)","device_id":"0x54ef441000705b54","command":"state","commandType":"z2m_cmd","payload":"payload","payloadType":"msg","optionsValue":"","optionsType":"nothing","x":1060,"y":180,"wires":[]},{"id":"411e2b8e9bdac70b","type":"zigbee2mqtt-server","name":"CORE","host":"","mqtt_port":"1883","mqtt_username":"","mqtt_password":"","mqtt_qos":"0","tls":"","usetls":false,"base_topic":"zigbee2mqtt"}]

Watching this thread with interest and an E1 TRV on the way. I don’t know which v3 hub they refer to for later Matter support?

No idea about future aqara Matter steps

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.