[New device support]: Aqara Smart Radiator Thermostat E1 (SRTS-A01) #13993
Comments
|
I have already added thermostat converters, but they are not complete. you can add/correct them as needed. |
Nice work! Thanks :) |
|
I am named them 'away_preset_temperature' and 'preset' |
|
According to the product page, this thermostat can be linked to an external temperature sensor in the Aqara app. Is it possible to support this as well or is this allegedly based on some proprietary Aqara implementation? |
|
Yes, there is such a possibility. |
|
Thanks! Could you explain this part a little further: |
|
I think if understand the data format, then we can use other sensors. |
|
I propose to think about how to parse the commands that the gateway sends to the thermostat: their structure and meaning. Partially I managed to understand the composition of the package.
|
|
Thank you @kirovilya for your contribution! I'm using the thermostat with the latest dev branch. Edit: My first device actually had a defective temperature sensor. |
|
@0ip as far as I understand, these are the readings of the internal temperature sensor, according to which the thermostat is adjusted |
|
Just checking in to request this device be added. I'm happy to help test things - how do I switch my HA addon installation to the dev branch without losing all my existing devices/config? cheers |
|
Any news on this? I just received and installed my thermostat as well, so I'd also help if possible/necessary. |
|
Thanks for your work. |
Just stop the normal Z2M, copy the settings from the addon to the dev version and start it :) |
|
One issue I've found is that when you change the set point to either above or below the current temperature, and you hear the physical valve open/close, the valve state switch doesn't update, meaning you cant know if its open or not (without making an assumption from the temperature difference) |
|
|
|
Not sure if this is useful, here's an unhandled message (247/0xf7) that I receive |
|
send command "link sensor"
|
HeaderThe header for all commands on 0xfff2 is described here: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Aqara-S1-Smart-Scene-Panel-Protocol#general-commands-structure
I wrote a quick implementation of this: const aqaraHeader = (counter, params, action) => {
// Based on https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Aqara-S1-Smart-Scene-Panel-Protocol
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. Link 1:
Link 2:
Set external sensor tempWhile 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. 😄 const value = 23.57;
const temperatureBuf = Buffer.allocUnsafe(4);
temperatureBuf.writeFloatBE(Math.round(value * 100));
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).
Sending temperature in zigbee2mqttconst 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. |
May I ask which topic in MQTT you are using to check if the valve is open or closed? I don't seem to find this feature. I can only find the switch "Valve_detection", but I guess this is to enable/disable the feature of reading the valve state. Is this generally supported by the device, to see valve state? |
I'm not sure if this is a feature, but I'd expect it to be. I'm expecting the on/off switch to have its state updated if the valve determines it should be on/off automatically or through physical adjustment of the device. Is this not the case? Valve Detection seems to be a badly named feature, and is really something else:
It might be helpful to either alude to this in the UI or otherwise completely rename it to something sensible |
This function can show an icon on the thermostat screen in case one of the conditions above fires. The manual refers to this as "fault icon". So maybe this function / switch should rather be called something like "fault detection" in combination with further documentation (e.g. the conditions above) and that this enables this icon on the screen. |
I think if anything is done here it should be additive, e.g. call it "Fault (Valve) Detection", as renaming it alone creates a mismatch between feature names which is arguably more confusing - Whos to know theyre the same feature and not different features? |
I definitely agree with you. Something like is expected to be present from a smart thermostat, otherwise how can you monitor when it is operating or not? |
|
|
|
Now that we know how the linking procedure to an external temperature sensor works, thanks to @duvholt and others, should/can it be integrated into Z2M, or should that be left to applications built on top of Z2M? |
For reference, this is broken since Koenkk/zigbee-herdsman-converters#6066, just like the "window detection" and "valve detection" states (labeled "State") and the "window open" flag (label missing).
This requires clock synchronization, which isn't implemented yet (example from pet feeder: Koenkk/zigbee-herdsman-converters#5364), and also regular re-synchronization to avoid time drift.
This is described in the user manual of the device, hinted by the description in the Z2M UI, and also enforced by the validator when changing the schedule. But you are right, it could be described more precisely.
This isn't possible directly on the device. The recommended approach is using HA (or any other home automation system) to program advanced schedules. |
|
@protyposis thank you for your answer, seems few topic has been properly addressed but have one more topic. In another smart radiator thermostat from Aqara E1, I had a function called "anti-calcification valve system" and idea is if last change position of valve was more then 7 days then made full open-close valve move to prevent making calcification inside the valve. Similar functionality is here? If no then is possible add such functionality in Z2M? |
|
Schedule switch in frontend z2m works but it doesn't work in home assistant. An attempt to enable it in the home assistant results in an error: Error 2023-06-19 22:20:19 No converter available for 'state' ("ON") And in general it is not clear that this switch is responsible for the schedule. |
|
@kzajac83 This thermostat doesn't seem to have this functionality, thus it can't be added to Z2M. You can implement a workaround automation in HA though to force the valve to move. Unfortunately it can't be done conditionally, i.e., only if the valve didn't move, because the thermostat doesn't expose the valve position, so there is no way to actually figure out whether the valve moved.
|
|
And some nonsense with the battery readings .... |
|
|
From 31 Jun the issue is closed, not sure our talks is visible in some dashboard / notifications for developers point of view. @Koenkk can you please re-open the issue or maybe suggest something else? General we have few problems with Aqara E1 thermostat (SRTS-A01) |
This doesn't make sense. This item was created to initially make the device work. That has been delivered. If you experience any new issues you should create new problem tickets for that, so that these can be individually be looked into, tracked and solved. |
|
Hi, |
|
0.0.0_01030 |
@protyposis @kzajac83 In the latest Z2M version I can run the calibration command. This does a full open and close movement. |
|
This may be a dumb question but ... Thanks for your help, |
e.g. |
|
Thank you so much, works like a charm. |
|
I now had this for the second time with two different devices out of my four E1 TRVs: The device successfully sends updates to Z2M when I make changes on the TRV itself but commands from Z2M to the TRV don't work anymore. Error message in Debug mode is as follows: Publish 'set' 'window_detection' to 'Heating Living Room' failed: 'Error: Write 0x54ef44100073c510/1 aqaraOpple({"627":{"value":0,"type":32}}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 23060 - 1 - 91 - 64704 - 4 after 10000ms)' This unidirectional situation of the device speaking with Z2M but Z2M not being able to speak to the TRV has also not changed after waiting for a day. Very frustrating since my TRVs are set to "external" temperature and because the last temperature value the half-lost TRV had received was below the set target temperature of the TRV. Because of this it heated continuously throughout the day until I came home and was able to intervene. Anyone with similar issue and is somebody able to interpret this error message? The TRV concerned this time is just 2 meters away from my SLZB-06 coordinator (which acts perfectly well with 60 devices in my network, including some repeaters, and no devices ever get lost except those Aqara TRVs sometimes; also the Zigbee channel is set to 15 to make the network even more robust, but anyway this doesn't really look like a network issue to me but maybe more like a protocol issue (?)). Thanks! Found this similar but very pretty old issue where the coordinator firmware seemed to have been the issue: Zigbee2MQTT Aqara E1 TRV publish set error using Sonoff Zigbee Dongle Plus V2 (Dongle-E) |
|
Mayber #19747 |
|
@Ra72xx Thank you. My error message has the timeout in it, I couldn't find this in the debug log in the issue you referenced. Nevertheless the general error pattern is similar. |
May I ask how do you run that command? |
|
Hi, not sure to understand all wait is writtent all above but i think my issue is related with this post. I have an AQARA E1 valve connected to a Zigbee anntenna managed in HA with Z2M. |
|
I don't know about direct linking, but you can also use HA automations like this one: |
|
Thanks, so should i just add this code to the yaml of the E1 valve ? Edit : but i see that this is a blueprint... so i just added the blueprint (i am a real beginner...) , it seems added now, oh and working !!! here below on left temp from external sensor, right remp noticed by the E1 Valve !!! Seems fully ok !! Thanks a lot |
|
so now, i will have a second question, not sure if i am in the right post, how to create schedules for the TRV, i saw some posts about that but with some code, and i don't understand how i can implement that. I would like to have different temp target for different hours in the day, or for different days also. |
|
The scheduler integrated in the thermostat is very limited. So look at either the "schedule helper" which is integrated in HA, or use some custom (HACS) scheduler component. This is, however, a Homeassistant topic, but all these options are well documented. You might also be interested in something like this: https://github.com/jmcollin78/versatile_thermostat |
Am i wrong or ist the latest firmware version for this device 259 ? |
|
Hi everyone. I would find it very useful to be able to estimate and monitor energy consumption. |
and others
Link
https://www.aqara.com/eu/product/radiator-thermostat-e1
Database entry
{"id":80,"type":"EndDevice","ieeeAddr":"0x54ef441000128356","nwkAddr":12635,"manufId":4447,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.airrtc.agl001","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":769,"inClusterList":[0,1,3,64704,10,513],"outClusterList":[3,64704,513],"clusters":{"genBasic":{"attributes":{"appVersion":23,"modelId":"lumi.airrtc.agl001"}},"aqaraOpple":{"attributes":{"247":{"type":"Buffer","data":[3,40,30,5,33,1,0,10,33,75,16,13,35,23,8,0,0,17,35,1,0,0,0,101,32,0,102,41,250,10,103,41,140,10,104,35,0,0,0,0,105,32,100,106,32,0]},"625":1,"626":0,"627":0,"628":1,"629":0,"630":{"type":"Buffer","data":[4,62,1,224,0,0,9,96,4,56,0,0,6,164,5,100,0,0,8,152,129,224,0,0,8,152]},"631":0,"633":500,"634":0,"635":1,"636":0,"637":0,"638":0,"640":0,"1034":100}},"hvacThermostat":{"attributes":{"localTemp":2810,"occupiedHeatingSetpoint":2700}},"genPowerCfg":{"attributes":{"batteryVoltage":33}}},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":23,"hwVersion":1,"dateCode":"Apr 25 2022","swBuildId":"0.0.0_0023","zclVersion":3,"interviewCompleted":true,"meta":{"configured":1906590817},"lastSeen":1663048175699,"defaultSendRequestWhen":"immediate"}
Comments
The device is unsupported. I've created a basic external converter and am able to manually control the heating setpoint, but there are still many custom aqaraOpple messages to be implemented.
For the moment, I'm sure the aqaraOpple message with key id 626 is the antifreeze option (value 2 is on, value 0 is off)
aqaraOpple message with key id 625 is manually setting off the TRV (0 is off, 1 is on)
External converter
const definition = { zigbeeModel: ['lumi.airrtc.agl001'], // The model ID from: Device with modelID 'lumi.sens' is not supported. model: 'SRTS-A01', // Vendor model number, look on the device for a model number vendor: 'Xiaomi', // Vendor of the device (only used for documentation and startup logging) description: 'Aqara Smart Radiator Thermostat E1', // Description of the device, copy from vendor site. (only used for documentation and startup logging) fromZigbee: [fz.thermostat, fz.aqara_opple, fz.battery], toZigbee: [tz.thermostat_local_temperature, tz.thermostat_occupied_heating_setpoint, tz.thermostat_control_sequence_of_operation, tz.thermostat_system_mode, tz.thermostat_keypad_lockout, tz.thermostat_occupied_heating_setpoint], // Should be empty, unless device can be controlled (e.g. lights, switches). exposes: [e.battery_voltage(), exposes.climate() .withSetpoint('occupied_heating_setpoint', 5, 30, 0.5, ea.STATE_SET).withLocalTemperature(ea.STATE) .withSystemMode(['off', 'auto', 'heat'], ea.STATE_SET) .withRunningState(['idle', 'heat'], ea.STATE)], // Defines what this device exposes, used for e.g. Home Assistant discovery and in the frontend configure: async (device, coordinatorEndpoint, logger) => { const endpoint = device.getEndpoint(1); await endpoint.read('genPowerCfg', ['batteryVoltage']); }, };Supported color modes
No response
Color temperature range
No response
The text was updated successfully, but these errors were encountered: