Eurotronic Spirit ZigBee (SPZB0001) temperature not updated on device since deCONZ 2.12.6

[double1968]

Describe the bug

Temperature set in Home Assistant is never being sent to the device. Local changes are sent back to Home Assistant. As deCONZ sits in between and there were no firmware updates, we believe this issue has been introduced with v2.12.6 (where v2.11.5 not have this issue - full disclosure: I can guarantee the issue didn´t exist with addon v6.8.0/deCONZ v2.10.4).

Steps to reproduce the behavior

Set new temperature in Home Assistant
Wait forever for the device to update
No temperature update on the valve

Expected behavior

Set new temperature in Home Assistant
Valve target temperature is being updated within max. 20 second

Screenshots

Reading on the net it seems that the problem is due to an incorrect writing of the value in the ID 0x0012 / 0x4003.
I remember after the DECONZ update if I changed the values via Phoscon the temperatures were transmitted to the valve

Environment

• Host system: Raspberry Pi
• Running method: Home Assistent deCONZ Add-on
• Firmware version: 26720700
• deCONZ version: 2.12.6
• Device: ConBee II
• Do you use an USB extension cable: yes -- only relevant for ConBee I/II
• Is there any other USB or serial devices connected to the host system? Yes : Zwave Dongle

deCONZ Logs

Additional context

See issue raised within HA repo (which is not the right place I think) here home-assistant/addons#2244

See another user @bcutter with similar setup and same issue (closed for non-compliant) here #5422

[Mimiix]

Asked manup to check :)

[manup]

There are multiple firmware versions for the Spirit out there. Somehow the newer ones are "tricky".
Mine has Datecode 20181205 shown in the Basic Cluster.

Does writing the 0x4003 attribute work for you when done directly in deCONz Cluster Info Panel?
(double click on the attribute which open)

Here I set mine to 10°C.

[double1968]

I rolled back to the working Deconz version so as not to be cold.
My Spirit firmware version has never been updated and is dated 20191014

The 0x4003 attribute does not accept write, but it seems to remember after Deconz update the write was possible.

At the moment the temperature setup works by writing attribute 0x0012 and it is sent to Spirit

Set 20°C

[SwoopX]

The interesting thing with all this is that the API sends the setpoint to both attributes, 0x0012 and 0x4003, as there's no known way to determine which attribute the device actually uses.

[double1968]

I am stupid, but it could not be that in the new version of Deconz one of the two data is sent in text format instead of numeric

[SwoopX]

No. In fact, it's more the other way around. A few versions back, I implemented a mandatory type check for all configuration values send via REST API to deconz so that exactly that cannot happen anymore. In this particular case, the heatsetpoint values must be an integer. Hence, this would have a different cause.

I presume the previous version was 2.11.05?

[double1968]

Right now I'm using version 2.11.05 and everything works !

[petermarasek]

I can confirm the same behavior as described by @double1968

[SwoopX]

Found the root cause. What you guys experience is what should have been addressed with #3626 and #3680, however, the implementation was slightly incorrect (the devil is always in the details). It's remarkable that this just pops up or gets more prominent after a year... 🤷‍♂️

Short recap: Due to the firmware chaos with the Eurotronic Spirit, there's devices out there behaving differently although they show the very same firmware version. Older devices had their heating setpoint being set through attribute 0x4003, for newer devices, this is apparently only possible via the standard attribute 0x0012. As there's no way to determine which version of the device a user has, the aforementioned PRs have been implemented to send a request for each attribute BUT, that never seems to have worked correctly.

The root cause is that the very same request was used twice and therefore had identical task and request IDs. Before the 2nd request could be served (with the amended attribute and manufacturer code), it got deleted as the 1st request was determined to be successful due to the identical IDs.

The fix is to create a completely new 2nd request which now gets served as well.

[Mimiix]

Found the root cause. What you guys experience is what should have been addressed with #3626 and #3680, however, the implementation was slightly incorrect (the devil is always in the details). It's remarkable that this just pops up or gets more prominent after a year... 🤷‍♂️

Short recap: Due to the firmware chaos with the Eurotronic Spirit, there's devices out there behaving differently although they show the very same firmware version. Older devices had their heating setpoint being set through attribute 0x4003, for newer devices, this is apparently only possible via the standard attribute 0x0012. As there's no way to determine which version of the device a user has, the aforementioned PRs have been implemented to send a request for each attribute BUT, that never seems to have worked correctly.

The root cause is that the very same request was used twice and therefore had identical task and request IDs. Before the 2nd request could be served (with the amended attribute and manufacturer code), it got deleted as the 1st request was determined to be successful due to the identical IDs.

The fix is to create a completely new 2nd request which now gets served as well.

Great work :)

[bcutter]

Great work :)

Copy that. Awesome!

I'm curious to know what will be the next steps to estimate on a timeline how long it will take for my TRVs to finally work again (it's autumn with winter temperatures here so... 😀).
Unfortunately I can't run beta versions of deCONZ (HA addon) which means usually it takes a lot of time until new stable versions are available.

If I can test something, please notify me.

[Mimiix]

I'm curious to know what will be the next steps to estimate on a timeline how long it will take for my TRVs to finally work again (it's autumn with winter temperatures here so... 😀). Unfortunately I can't run beta versions of deCONZ (HA addon) which means usually it takes a lot of time until new stable versions are available.

Brrr!

I think we are out of luck in this case. Assuming this could be fixed with DDF's (introduced in 13.x), this can't be done on the fly on HA As it still is on 12.x

So indeed, you need to wait for stable. The other solution would be using a seperate machine for deCONZ. So if you have another RPI around you can just put deCONZ on there.

What i can do, is make sure it is in the next stable (assuming Swoop makes a fix before that release).

[double1968]

Found the root cause. What you guys experience is what should have been addressed with #3626 and #3680, however, the implementation was slightly incorrect (the devil is always in the details). It's remarkable that this just pops up or gets more prominent after a year... 🤷‍♂️

Short recap: Due to the firmware chaos with the Eurotronic Spirit, there's devices out there behaving differently although they show the very same firmware version. Older devices had their heating setpoint being set through attribute 0x4003, for newer devices, this is apparently only possible via the standard attribute 0x0012. As there's no way to determine which version of the device a user has, the aforementioned PRs have been implemented to send a request for each attribute BUT, that never seems to have worked correctly.

The root cause is that the very same request was used twice and therefore had identical task and request IDs. Before the 2nd request could be served (with the amended attribute and manufacturer code), it got deleted as the 1st request was determined to be successful due to the identical IDs.

The fix is to create a completely new 2nd request which now gets served as well.

Great job, thanks

[manup]

@SwoopX for reference the Basic Cluster Attributes of my Spirit

[SwoopX]

That's mine

[bcutter]

What i can do, is make sure it is in the next stable (assuming Swoop makes a fix before that release).

That would be great 👍🏼

Here's my basic cluster for all my devices if helpful somehow in the further process: