Bosch BTH-RA does not support setting pi_heating_demand

[rusitschka]

What happened?

According to Documentation Bosch BTH-RA supports setting pi_heating_demand. However that does not work. And looking at the Herdsman code the feature is missing.

Is this an error in documentation?

What did you expect to happen?

I can manually set pi_heating_demand.

How to reproduce it (minimal and precise)

Publish e.g. {"pi_heating_demand": 20} to zigbee2mqtt/FRIENDLY_NAME/set.

Zigbee2MQTT version

1.30.0 commit: 8f781db

Adapter firmware version

20221226

Adapter

Slaesh's RB2652

Debug log

No response

[wintersteiger]

Same here; I just received one today and it claims it doesn't support attribute 0x0008 on cluster 0x0201. It says that it's firmware is version 3.02.05 dated 20220627 and it looks like there's a newer one (here). I'll give it a try, but might take me a few days until I get around to it.

[wintersteiger]

Didn't take me quite as long as I thought it would, but sadly nothing changed after the update. It still rejects any attempt to read or write this attribute.

[wintersteiger]

See also https://github.com/Koenkk/zigbee2mqtt/issues/15782 and https://github.com/Koenkk/zigbee-herdsman-converters/pull/5150

@BBJake can you confirm that your BTH-RA's still report this attribute?

[BBJake]

@rusitschka The documentation is created from the code and there it is only possible to read that value! So I think that the "documentation" is wrong in that point. @wintersteiger The BTH-RA ist not using the attribute at 0x0008! It uses some custom attribute for that:

            if (data.hasOwnProperty(0x4020)) {
                result.pi_heating_demand = data[0x4020];

And this is (of course) still working:

[wintersteiger]

@BBJake thanks for the pointer! I can confirm, 0x4020 works exactly as it should, read & write.

[rusitschka]

@wintersteiger how is it possible write works for you if the code doesn't support it? I'm asking because I'm about to return my TRV because I bought it for the single reason that it supports setting valve position manually. I already implemented the feature. It's not working...

[BBJake]

@rusitschka I guess he wrote new code for that 😉

@wintersteiger Interesting. Isn't the value overriden by the thermostat if the temperature changes?

[wintersteiger]

That's right, I'm not using zigbee2mqtt, I just send raw zigbee frames to the network (over the serial port to a Sonoff dongle). It requires the manufacturer-specific flag and ID in the ZCL header, without that it will complain. It accepts my settings, i.e. when I read them back I get the right values, but I haven't checked whether it actually moves the pin when I do that. I don't expect it to be overwritten as long as it's in manual mode. I have tried changing the temperature setpoint after setting the valve position and it did not overwrite the valve position immediately. It could be delayed though, I didn't wait very long.

I also bought one of these TRVs because of this feature, so I'll be testing this further. The only other zigbee TRV I found with this feature is the Eurotronic Spirit, which hasn't been available for a long time (at least in the UK), so I really hope the Bosches work.

[rusitschka]

Oh that's awesome @wintersteiger! Can you keep us posted when you know if it is really working and how reliable it is? I returned mine already so I cannot help testing :-(

[dayt47]

I get an error too. "No converter available for 'pi_heating_demand' ("")"

[AndrejBor]

Also bought BTH-RA to get pi_heating_demand and direct position control working. Please keep us informing for updates.

[wintersteiger]

I've done some more experimenting, but I'm afraid I haven't found a way to set the valve position yet. It accepts the values I write to it and reports them back, but it doesn't move the pin. In auto and manual mode it resets my values (as you'd expect), but in pause mode it doesn't, so that's at least something.

I noticed that it accepts pretty much any value for the operating mode, so it's possible that there is one for valve position mode, but I haven't found it yet.

I don't have a Bosch Controller; if someone has one, could you take a look around the device settings in the Bosch app to see whether it's possible to set the valve position there?

[dayt47]

It's not possible to set it, but to see it.

[tkintscher]

I also bought one of these TRVs because of this feature, so I'll be testing this further. The only other zigbee TRV I found with this feature is the Eurotronic Spirit, which hasn't been available for a long time (at least in the UK), so I really hope the Bosches work.

I would love this feature as well, especially when it is working more reliably than with the Eurotronic devices. For the Eurotronic ones pi_heating_demand was also not writable (I guess it is intended as the output from the PID loop, which doesn't run in the fully manual scenario). Instead the valve position had to be written to the manufacturer-specific attribute 0x4001. I don't know whether there is a way to "scan" for these kind of attributes with z2m.

[wintersteiger]

There is Zigbee attribute and command discovery, but you get very little information out of them (essentially just existence and datatype). Eurotronics kindly provides detailed information about this in their manual (including e.g. 0x4001). The only other devices I found with that kind of documentation are the Danfoss Ally TRVs, but AFAICT they don't offer direct valve position control.

[tkintscher]

Right, I have a Danfoss Ally and it does not seem to support direct valve control.

[rusitschka]

Shelly TRV does but it's WiFi not Zigbee. For Zigbee Ubisys H1 may support it according to zigbee2mqtt documentation. But maybe it's a similar documentation bug as Bosch.

[tkintscher]

There is also the MClimate Vicki which supports it, but it’s using LoRaWAN.

[wintersteiger]

Bad news! Turns out my valves are a bit too sticky for the Bosches.

[wintersteiger]

Shelly TRV does but it's WiFi not Zigbee. For Zigbee Ubisys H1 may support it according to zigbee2mqtt documentation. But maybe it's a similar documentation bug as Bosch.

Thanks for the pointer, I had never heard of Ubisys before!

[DerDreschner]

I've done some more experimenting, but I'm afraid I haven't found a way to set the valve position yet. It accepts the values I write to it and reports them back, but it doesn't move the pin. In auto and manual mode it resets my values (as you'd expect), but in pause mode it doesn't, so that's at least something.

Can you tell us more Informations about what you did and find out? Would like to try it with the current Firmware. Like what you did to change the valve value etc. Thanks!

[wintersteiger]

@DerDreschner I'm not running zigbee2mqtt, but my own code, which works similarly (but no MQTT). I ran attribute and command discovery both generic and manufacturer-specific to find out what it supports and then set various values and observed the response. In this case mainly attribute 0x4020 and 0x4007 on cluster 0x0204. Like I said above, it accepts any value for the system mode or the valve position, but (apparently) just ignores them. I upgraded to the latest firmware before any of this, so if they didn't release a new one within the last month, it's probably not worth your time.

Here are the unknown manufacturer-specific attributes and their datatypes according to attribute discovery:

    ATTRIBUTE_CS(0x4008, unknown1,  uint16_t,     0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4009, unknown2,  uint16_t,     0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x400a, unknown3,  uint16_t,     0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x400e, unknown4,  bool,         0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x400f, unknown5,  uint16_t,     0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4021, unknown6,  uint16_t,     0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4022, unknown7,  ZCL::enum8_t, 0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4023, unknown8,  ZCL::enum8_t, 0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4024, unknown9,  ZCL::enum8_t, 0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4040, unknown10, int16_t,      0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4041, unknown11, ZCL::enum8_t, 0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x4050, unknown12, ZCL::enum8_t, 0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x5000, unknown13, ZCL::map8_t,  0x00, ZCL::OPTIONAL, C, ZCL::RWP);
    ATTRIBUTE_CS(0x5010, unknown14, ZCL::enum8_t, 0x00, ZCL::OPTIONAL, C, ZCL::RWP);

[DerDreschner]

@wintersteiger : Thanks for the informations! I just tried it with Zigbee2MQTT via an external converter. Looks like it works. At least my valve is getting opened and closed correctly when I set the attribute 0x4020 in cluster 0x0204. Looks like it's fixed in the latest firmware (v3.04.04 which I uploaded to Zigbee-OTA recently).

I work on a PR for zigbee-herdsman reguarding that issue now.

[wintersteiger]

Some updates from my side:

Bosch BTH-RA: @DerDreschner I'm not able to reproduce your success. After the update, mine behaves exactly as before. It remembers my settings, but doesn't move the pin. Sometimes, when it thinks it recognizes that its calibration is wrong, it will start a reference run. Is it possible that this is when you saw the pin move? Just for reference, mine claims to be a RBSH-TRV0-ZB-EU hardware version 01 date code 20221216 SWBuildID 3.04.04.

Eurotronic Comet Zigbee: The manual isn't on Eurotronics' website yet, but it behaves identical to the Spirit Zigbee, it even reports the same model number (SPZB0001). You can write to 0x0008 and it moves the pin immediately. The only difference to the Spirit I found was that they corrected the scaling of the attribute (0-100 instead of 0-255).

Ubisys H1: Heavy. Display unreadable as it doesn't have a backlight. It does not support writing to 0x0008 (reports read only error), but it has a number of manufacturer-specific attributes in the 0x0201 cluster. Most of them are also read-only (some obviously min/max temperature limits). I haven't found out whether it supports direct control of the valve position, but when I write to manufacturer-specific 0x0003, it sometimes shows activity after some time.

[ytugarev]

Got the device yesterday and can confirm that this slider indeed works. Every time I adjust - motor is buzzing and head changes position. Firmware is 3.05.05