Ongoing Issues with SPZB0001 / Eurotronic Spirit Zigbee

[lephisto]

To Track it down i quickly drop links to the ongoing issues with various Versions of the Heating Thermostat:

https://github.com/Koenkk/zigbee2mqtt/issues/4571

https://github.com/Koenkk/zigbee-herdsman-converters/issues/1893

[malfroid]

Other links:

https://github.com/dresden-elektronik/deconz-rest-plugin/issues?q=is%3Aissue+is%3Aopen+eurotronic+spirit

https://github.com/zigpy/zha-device-handlers/issues/689 https://github.com/zigpy/zha-device-handlers/issues/711

[malfroid]

@Witriol do you have any update or estimated timelines on an improved firmware (beta), or on improving the integration with Z2M, ZHA or deCONZ?

[Witriol]

@malfroid The main focus is currently on deCONZ related issues (that is what has Eurotronic approached us with) and ZHA and Z2M will be next in line. First release of improved firmware should be available in one or two weeks together with OTA update wiki guide. Currently I'm collecting information about other issues since it seems that there are more and more issues being reported.

[hargathor]

Hello @Witriol You can also follow an ongoing issue related to this version here: https://github.com/KiwiHC16/Abeille/issues/1582

In my case this is related to the support of a PiZigate board attached to a raspberry pi but it seems heavily related to the other issue listed above.

[klangfarbe]

I am having also the issue, that at least one of my six thermostats constantly breaks by not reacting to anything anymore. The local temperature is way higher (23.5 degree) than the _occupied_heatingsetpoint (20 degree) and it is still heating. The _pi_heatingdemand does not react and even changing the temperature directly at the thermostat does not do anything.

After removing batteries and readapting is is working now but shows a _pi_heatingdemand of 100 while the real valve is closed which is correct since the local temperature is way higher. Only after a new _occupied_heatingsetpoint is send to the thermostat, the _pi_heatingdemand is set correctly to 0. But it's only a matter of hours that it breaks again.

This thermostats firmware is way too broken and urgently needs to be fixed...

[BeistleA]

I have nine of these Thermostats running on Openhab. Coordinator CC2531 20190608 Software Zigbee2Mqtt 1.16.2 commit: 0514204 One Thermostat: 20190408/18181120 Eight Thermostats: 20191014/22190930 I use Osram Plugs as Repeater. The one Thermostat with FW18181120 on it is only running while directly connected to the Coordinator but also not always accepting commands (Timeout error) The others are all around the house and working nearly perfect. @Witriol: If I can support with any kind of logs or try something let me know. If more information is needed just ask.

Greetings Andy

[saxn-paule]

I have exactly the same issue like @klangfarbe 2 of my 5 thermostats drop once a day.

I also have an Osram plug next to each thermostat but it doesn't help.

[pY4x3g]

Same issue here (CC2531, z2m, home assistant), 2 new thermostats only work for some hours and then completely loose the connection and can only be controlled manually. I stopped counting and reinserting the battery after 15+ times, currently I only use them as "dump" thermostats and control them manually.

[ChristianHersevoort]

I have a similar issue where they stop responding for some time, but after a few days they start responding again. Restarting the zigbee2mqtt daemon doesn't seem to have an impact.

Another issue I'm having where 1 of 3 TRV sends event messages (visible in zigbee2mqtt) but the other 2 are silent.

[fribse]

I have 4 TRV's around the house, they are a bit older, connected to deConz, and I use IKEA bulbs / plugs. They accept routing for both xiaomi sensors and the Spirit zigbee. The biggest problem I have is in the adding process, it is daunting to add these to the deconz, requires forcing read of attributes, and doing things in the exact right order and timing.

But day to day, they work. Datecode is: 20191014 With the later reported problems, I've not had the nerve to buy more of these.

[saxn-paule]

All my TRVs have date code 20191014 and two of them have the connection loss issue.

[vangguppie]

I have 6 TRV's all date code 20191014 and all of them have the connection lost issue. 2 of them are still in the box and i am considering returning them because of this issue.

I use HA with deconz (with longer usb cable). Join of TRV's in the same room as deconz went well. When discovered in deconz goto clusterinfo and press read.

latest version of deconz firmware 7 routers (Ledstrips and light bulbs) and aprox. 10 endpoints.

[klangfarbe]

Just a quick update: Regarding a mail I received from Eurotronic Support, the OTA update should be released within the next 2-3 weeks.

[byterazor]

Lol,they are telling this since before christmas. I returned all 7 spirits back to amazon. They are unsuable.

[heggink]

That's not entirely correct, we have moved from 1-2 weeks to 2-3 weeks now so the bigger the slippage, the bigger the future time frame :-). Ah well, it will get resolved and my workaround (using the other setpoint) works for now.

[byterazor]

I have more problems:

• two do not join zigbee networks at all (tested with two different gateways), and yes i resetted them the hard way multiple times
• all newer versions have wrong mappings of zigbee attributes (i could cope with that)
• two spirits do not close the valve correctly, so it is hot in my sleeping room even the thermostats target temperature is 16

The first and last are blockers for me, because the PAF (Partner Acceptance Factor) is below zero.

I am doing software development for a living too and this looks like a serious quality management problem.

[saxn-paule]

• two spirits do not close the valve correctly, so it is hot in my sleeping room even the thermostats target temperature is 16

Exactly this behavior two of my TRV also have. Valve position is at 2% but the radiator is hot.

The TRV that wasn't able to join my network is probably bricked now, as long as somebody couldn't tell me how I could leave the OTA mode. I resetted it multiple times and tried the reset like the Z-Wave Spirit TRV Hold Boost button, remove battery while stil holding boost button, insert battery and still hold boost button. After a while boost button starts blinking red and never stopped blinking. Also after removing/inserting batteries again it keeps flashing while the display shows nothing.

[poiuztr123]

I have 6 TRV's. All with date code 20191014. I was able to pair all of them, but only when I was not too far away from the conbee stick in my raspi. I have 6 innr plugs in the house that act as routers/repeaters and help with very many Xiaomi Aqara devices that are spread across the different levels of our house and they work nicely. However, it seems that pairing and also operating the Eurotronic Spirits via the innr plugs as routers is not possible, at least i do not see a line between them in deconz-gui. Independently from where they are in the house I loose for 5 of the devices connection quite quickly after repairing. Thermostats are basically unusable in this state. If the firmware update doesn't come quickly I will have to buy different ones.

[Sjack-Sch]

I have 2 Spirits zigbee. One has the issue that is stops communicating after a few hours. It needs to get a factory reset before it starts communicating again and then stops after a few hours. It is now used as a dumb manual operated device.

For the second one the communication works OK, however the battery value does not work, always reported as zero, while the battery is a new full alkaline battery. It also reports "eurotronic_error_status":1˜ Does anybody know what this error status means, is this maybe related to the battery value zero issue?

{ "battery":0, "boost":false, "child_protection":false, "current_heating_setpoint":9.5, "eurotronic_error_status":1, "eurotronic_host_flags":{ "boost":false, "child_protection":false, "mirror_display":true, "window_open":false }, "eurotronic_system_mode":3, "linkquality":68, "local_temperature":12.85, "mirror_display":false, "occupied_heating_setpoint":9.5, "pi_heating_demand":100, "system_mode":"auto", "unoccupied_heating_setpoint":10, "window_open":false }

[Howaner]

I can't understand why the vendor / service provider doesn't use the issue functionality in github to track down the issues like any normal project does .. Each issue could be created as a seperate issue and the service provider can close it when it's fixed. This way we could see the status and it would be much easier to track down the issues.

Instead, 0 issues have been closed since december.

[gitolicious]

Isn't that something you=the users would need to, or at least could do? I was also overwhelmed by this long, unstructured list of "X is not working for me", "Y is not working for me". This definitely needs to be broken down into separate issues.

[heggink]

Not really. If you buy a commercial product, it should work out be fixed under support. This is neither open source not Kickstarter.

[Witriol]

I have added an already released firmware with date code 20190408 that I have received from Eurotronic for public release. It predates the problematic "double" release with same datecode.

Another update is that in February Eurotronic will have an employee for maintaining this GitHub page.

[heggink]

Does this firmware bring back the original (reasonably working) functionality then?

[Howaner]

I have added an already released firmware with date code 20190408 that I have received from Eurotronic for public release. It predates the problematic "double" release with same datecode.

Another update is that in February Eurotronic will have an employee for maintaining this GitHub page.

Thank you for the guide and the firmware file. I tried to do OTA updates on my thermostat (Broken version without the colorful packaging) but it looks like the thermostat ignores the OTA requests. After a click on "Update", the progress goes to "Queued" and remains at "Queued", even after hours. When I reset the device by pulling out the batteries, the progress goes back to "Idle"

[hackex]

I have added an already released firmware with date code 20190408 that I have received from Eurotronic for public release. It predates the problematic "double" release with same datecode.

Another update is that in February Eurotronic will have an employee for maintaining this GitHub page.

Do you know if it is possible to flash the firmware over ZHA integration of Home Assistant? If not, is there a way to just install deconz and use the conbee 2 stick as it used by Home Assistant and just do the OTA with deconz without any interference and then switch back?

Thank you

[CreatsheR]

After a click on "Update", the progress goes to "Queued" and remains at "Queued", even after hours. When I reset the device by pulling out the batteries, the progress goes back to "Idle"

Similar behavior here. I click on Update and the status changes to Idle. After that nothing happens in DeConz or at/on the thermostat...

[Witriol]

@heggink From what I have been told, it should. I have tested problematic attribute 0x4003 and it works fine.

@Howaner That as happened to me once as well, but it got fixed by first clicking Queue and then Update button. Could you check OTAU cluster attributes? It should show current OTA version string (the 20190408 update has OTA string 0x00122C380).

@hackex I have no experience with ZHA integration of Home Assistant, unfortunately. Will ask Eurotronic guys.

[CreatsheR]

@Howaner That as happened to me once as well, but it got fixed by first clicking Queue and then Update button. Could you check OTAU cluster attributes? It should show current OTA version string (the 20190408 update has OTA string 0x00122C380).

Tried that as well. Doesn't work... The Abort-button doesn't work as well. The Progress Idle stays there "forever".

[sushifrick]

@CreatsheR this looks a bit strange to me. My Spirits all have the Vendor ID 0x1037 and Image ID 0x110c. I Updated all of them yesterday. Some were on Version 0.22 before but after the update and the reboot of the devices, which takes a couple of minutes I hat do use the query button to show the "new" old Version number 0.18 (mousover).

Until now the devices do behave, I am looking forward to a new update nevertheless.

[sushifrick]

Just to make it more clear. The reboot of the device took a couple of minutes, the ota took a bit over 2 hours per device on default settings (25ms) and about 80-90 minutes with a packet spacing of 15ms.

[vrabac]

@Witriol

I have added an already released firmware with date code 20190408 that I have received from Eurotronic for public release. It predates the problematic "double" release with same datecode.

Can you please check why this can NOT be applied with zigbee2mqtt, @Koenkk wrote some info here that this image is not compatible with the device.

Your SPZB0001 requests a different image type than the one on https://github.com/EUROTRONIC-Technology/Spirit-ZigBee/releases/tag/20190408 (65535 vs 4364 https://github.com/Koenkk/zigbee-OTA/blob/51a087b0b6baa153ebe55d6d870fee32e6fe8af9/index.json#L699).

According to the Zigbee spec this means this image is not compatible with this device.

@MrMartin92 wrote here also some stuff about same thing:

Same Problem here with my docker container and latest-dev.

I noticed 65535 is 0xFFFF. For me it doesn't look right. So I checked zigbee-OTA's index.json and indeed the imageType here is 4364. So something is wrong. But I have no time to dig deeper at the moment.

My device:

"model":"SPZB0001"
"vendor":"Eurotronic"}
"genIdentify","hvacThermostat"
"power_source":"Battery"
"software_build_id":"22190930"

PS: I have only zigbee2mqtt (and mqtt (mosquitto)), building an home-assistant in progress).

[CreatsheR]

@vrabac I think you meant "can't" instead of "can"!?

Nevertheless, I see some parallels to my Problem. In deCONZ the 5 Spirits that doesn't work properly all show only maximum values after clicking Query. The one Spirit which works properly shows proper values in the Vendor, Image and Version Fields:

[poiuztr123]

I tried to update with the firmware posted here with no success (they remain in "idle"). Five of my Spirits show 0xffff. I am using deconz and a conbee, if that helps. Am I doing something wrong?

[ebaauw]

The rows in the table are populated from the data the device sends to deCONZ. I've never seen these 0xFFFF values; the table initialises at 0x0000 and stays on those values in case the device sends no data. Can you try and read the (client, grey) OTAU cluster attributes? Particularly interested if the Manufacturer ID and Current File Version show all Fs there as well.
Would also be interesting to double-check using a Zigbee sniffer whether the device is actually sending the Fs or whether there's something wrong in the OTAU plugin.

If it's really the device sending these values, it might reject the firmware, as the Manufacturer ID and Image Type don't match, or because it thinks it has a newer firmware version than the file. I've seen devices that allow firmware downgrades (IKEA), but also that don't (Hue).

If you download the firmware file to ~/otau and restart deCONZ, the OTAU plugin should copy the file to 1037_110C_0122C380.zigbee. When you next select the device and press Query, the OTAU plugin should match the file to the device. For end-devices, you need to start Update manually, as you might need to install fresh batteries first (especially for CR2032 button cells).

the ota took a bit over 2 hours per device on default settings (25ms) and about 80-90 minutes with a packet spacing of 15ms.

That's not bad. In my experience, routers typically take 10-30 minutes to upgrade the firmware, end-devices might take up to 4 hours. Note that the device is in control of the upgrade process: it decides when to request the next block. It helps when the device is in direct range of the OTAU server (i.e. the coordinator). I never tries messing with the packet spacing.

[poiuztr123]

Can you try and read the (client, grey) OTAU cluster attributes? Particularly interested if the Manufacturer ID and Current File Version show all Fs there as well.

here you go:

[CreatsheR]

Can you try and read the (client, grey) OTAU cluster attributes? Particularly interested if the Manufacturer ID and Current File Version show all Fs there as well.

here you go:

in my deCONZ it looks exactly the same

[ebaauw]

Hm, the Upgrade server shows all Fs as well. That should be the mac address of the coordinator, as returned by the OTAU plugin. At least it shows the correct Manufacturer ID.

The communication between the device and the OTAU plugin seems broken alright. Without sniffer logs it will be hard to determine what's causing this and whether the OTAU plugin can fix or workaround this.

I'm afraid I cannot be of much further help; my eight TRVs are (were) all on 15181120 (the 20181205 version). I updated one to 18181120 (20190408) in just under an hour. I'll be running that firmware for a couple of days before updating the others.

I'll be happy to have a deeper look, if I can borrow a spare TRV with the troublesome firmware. If you can lend me one, please PM me on Discord.

Edit Updated all my other TRVs without any issues, each update taking between 50 and 70 minutes.

[vangguppie]

Can you try and read the (client, grey) OTAU cluster attributes? Particularly interested if the Manufacturer ID and Current File Version show all Fs there as well.

here you go:

in my deCONZ it looks exactly the same

The same here....

[double1968]

Could not update too. Same problems

[dako76]

Hi, i can not get the firmware file to my raspberry pi to select it in deconz? I installed the homeassistant image on my pi and "ha docker cp" is not working... i copy files via ssh on /root/otau and restart deconz but nothing was copied can anyone give me some help? Otherwise i have to send back Spirit Zigbee :-(

[vangguppie]

Hi, i can not get the firmware file to my raspberry pi to select it in deconz? I installed the homeassistant image on my pi and "ha docker cp" is not working... i copy files via ssh on /root/otau and restart deconz but nothing was copied can anyone give me some help? Otherwise i have to send back Spirit Zigbee :-(

Followed this thread ?

https://community.home-assistant.io/t/update-zigbee-firmware-using-deconz-on-hass-io/157447

[double1968]

Hi, i can not get the firmware file to my raspberry pi to select it in deconz? I installed the homeassistant image on my pi and "ha docker cp" is not working... i copy files via ssh on /root/otau and restart deconz but nothing was copied can anyone give me some help? Otherwise i have to send back Spirit Zigbee :-(

I used this procedure: with winscp (ssh) I copied the fw in the share folder (located in the root) of Hassio. Then , run this command to copy the OTAU file to the Deconz addon (VIA SSH HOST !!!) docker cp /share/20190408_EUROTRONIC_Spirit_Zigbee_0x00122C380.ota addon_core_deconz:/data/otau/

Where 20190408_EUROTRONIC_Spirit_Zigbee_0x00122C380.ota is an example of an OTAU filename.

This is my file folder /mnt/data/supervisor/addons/data/core_deconz/otau/20190408_EUROTRONIC_Spirit_Zigbee_0x00122C380.ota /mnt/data/supervisor/share/20190408_EUROTRONIC_Spirit_Zigbee_0x00122C380.ota

[jeankone]

Can you try and read the (client, grey) OTAU cluster attributes? Particularly interested if the Manufacturer ID and Current File Version show all Fs there as well.

here you go:

in my deCONZ it looks exactly the same

exactly the same for me as well

[fribse]

Hi, i can not get the firmware file to my raspberry pi to select it in deconz? I installed the homeassistant image on my pi and "ha docker cp" is not working...

You have to use the community SSH addon, not the official one.

[Marlor]

@ebaauw Wenn did you buy yours? I have 1 from end 2019, working as expected. And 5 from beginning 2021, all of them reporting fs. The nut is different too: Old: New:

[jeankone]

I can also confirm this. Mine are from December 2020, reporting all Fs and have also the new nut.

[ebaauw]

Wenn did you buy yours?

First one on 12 Jan 2019 at amazon.de; the next seven on 9 Feb 2019 at yakodo.de. As I said, they all came with the 20181205 firmware.

[hasdf]

I can also confirm this. Mine are from December 2020, reporting all Fs and have also the new nut.

Same here.

[jeankone]

after days of trying and trying: no chance for me to update my 2 thermostats running on 22190930. not getting away from "idle". did anybody ever disassembled the devices and checked for a serial port for flashing?