Open lephisto opened 3 years ago
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.
Did someone send you the xffff device? I have different of them and send to you, I just connect to deconz discord server, but can't find you.
@ebaauw the previous message was for you
I'm ebaauw#6903 on Discord.
I received the TRV, thanks.
Sniffing confirms that it sends a Query Next Image Request with Manufacturer Code 0xFFFF, Image Type 0xFFFF, and File Version 0xFFFFFFFF (as shown in the table entry in the OTAU plugin). After selecting the firmware file and pressing Update, the OTAU plugin sends a Query Next Image Response with the proper Manufacturer Code 0x1037, Image Type 0x110C, and File Version 0x0122C380 (from the file). Then the TRV falls silent.
I patched the OTAU plugin to send the response with Manufacturer Code and Image Type 0xFFFF instead, and behold: the TRV starts sending Image Block Request messages for 48 bytes. The plugin responds with Image Block Response messages with 28 bytes. However, after three requests/responses the TRV sends an Upgrade End Request and reboots (at least I see a Rejoin Request followed by a Device Announcement_). Could also be the OTAU plugin requesting a reboot, not sure I'm capturing all packets. I suspect the TRV checks the file header against the response and rejects the file because the Manufacturer Code and Image Type don't match.
My next attempt will be patching the firmware file instead of the OTAU plugin.
My next attempt will be patching the firmware file instead of the OTAU plugin.
Your effort and progress on this is awesome! If it would be possible to exchange the file header to somewhat the TRV expects, it should be alright.
thank you ebaauw for your work.
I'm trying to flash the chips too, and maybe you can give me an advice.
The device is composed by 2 different chips, the zigbee JN5179 and the microcontroller STM8L052c6t6. They communicate by serial port, can be easily divided and programmed individually. After few test I was able to program with the zigbee chip (with garbage), but not with the microcontroller ( without further study ).
Before going on I'd like to know, from your experience, if it is possible to extract the firmware to flash on the chip from the ota file, and on which chip it has to be written.
I don't care to test and break it.
Thank you
Without proper documentation, I can only do some (hopefully intelligent) guessing.
As the JN5179 already contains a microcontroller, I would guess that the Zigbee application runs on that. Consequently, the OTA file would contain the firmware for that microcontroller. Manufacturer Code 0x1037 is for Jennic, which has been acquired by NXP, so that adds up.
I would theorise the STM8L052c6t6 controls the thermostat hardware, running the thermostat's PID algorithm. I guess it makes sense to use a separate ultra-low-power MCU for that, as it probably runs continuously, and you don't want to power up the Zigbee radio all the time. I wouldn't be surprised if the same component would also be present in the Zwave version of the Spirit.
If you find a way to flash the JN5179 on the Spirit, you would need to extract the firmware from the OTA file. It contains a 56-byte header, followed by single segment with the firmware. The segment contains a 2-byte tag, followed by a 4-byte length, so the firmware itself starts at offset 62. I understand it's encrypted, and it's only decrypted by the device, presumably before flashing. I wouldn't know if the serial interface would expect to receive the firmware encrypted or unencrypted.
When trying to get the Hue firmware to work, I (mistakingly) created some corrupted firmware, which was downloaded by the light in full, but it didn't activate it. I don't know if other Zigbee devices have similar safeguards.
Unsurprisingly patching the file header runs into the same issue: the Spirit aborts the download after the third block. Effectively I had patched the file in the OTAU plugin.
Also tried to leave the file header intact, and only patch the Manufacturer Code and Image Type in the Zigbee commands.
Inceased the max block size, so the OTAU plugin now sends 48 bytes (the max size from the Spirit's request). Now the Spirit sends the abort after the seconds request. Looking at the timings, it hasn't yet processes the second block. It seems to choke on something in between offset 28 and 48 in the OTAU header, maybe the description string DR1175r1v2--JN5179--ENCRYPTED00
? I tried patching the file putting all \0
s in the description string, but no joy.
I'm afraid I've run out of ideas what else to try. In summary, the OTAU function of the Spirit with the 20191014 firmware v22190930 seems broken. It requests the wrong Manufacturer Code and Image Type. Ik looks like I can workaround that in the OTAU plugin, but then the Spirit aborts the download, presumably because it doesn't like the header.
@Witriol do you have any insights what's happening here? Can you find out what checks the faulty firmware is doing on the firmware file header?
so in the worst case, we are left with a faulty TRV - which can't even be patched, because it is so faulty, that it wont accept other firmwares....
@solvisit was able to flash the JN5179 with garbage. Can you find out if it accepts the encrypted firmware this way?
Thank you ebaauw for the tips. @jeankon Flashing the encrypted firmware doesn't work.
@Witriol any news from you in regards of firmware? Even old firmware cannot be applied to a lot of devices..
I don't see much action here on github, you wrote "Another update is that in February Eurotronic will have an employee for maintaining this GitHub page." Is new employee active here?
@vrabac I do not have any update from Eurotronic side since they could not attend last 3 weekly calls and I did not receive any update to my questions via email... So I don't know about the new employee or any future plans, unfortunately. Hopefully tommorrow's call will shed some light and I can write here some new information.
EDIT: The update is that new employee for maintaining GitHub page should start at beggining of March.
Unsurprisingly patching the file header runs into the same issue: the Spirit aborts the download after the third block. Effectively I had patched the file in the OTAU plugin.
Also tried to leave the file header intact, and only patch the Manufacturer Code and Image Type in the Zigbee commands.
Inceased the max block size, so the OTAU plugin now sends 48 bytes (the max size from the Spirit's request). Now the Spirit sends the abort after the seconds request. Looking at the timings, it hasn't yet processes the second block. It seems to choke on something in between offset 28 and 48 in the OTAU header, maybe the description string
DR1175r1v2--JN5179--ENCRYPTED00
? I tried patching the file putting all\0
s in the description string, but no joy.I'm afraid I've run out of ideas what else to try. In summary, the OTAU function of the Spirit with the 20191014 firmware v22190930 seems broken. It requests the wrong Manufacturer Code and Image Type. Ik looks like I can workaround that in the OTAU plugin, but then the Spirit aborts the download, presumably because it doesn't like the header.
@Witriol do you have any insights what's happening here? Can you find out what checks the faulty firmware is doing on the firmware file header?
@ebaauw I have tried patching the firmware binary, but it only lead to OTA update either not even starting or bricking one device (it stayed in bootloader forever). I have access to source code only for Zigbee part (JN5179) and when I have flashed firmware of bricked TRV, it did not recover, so I think that bootloader is placed in ST chip... I will try to do some more digging in the code for the firmware check you have mentioned.
I run six Eurotronics Spirit Zigbee with date code 20191014 on a Raspberry Pi in Conbee II/deCONZ/homebridge-hue with ioBroker environment. Haven't tried any OTAU update because of this thread.
Usually, two random of the six become unresponsive during the day, they don't follow any heatpoint change or give the temperature back. The basic and temperatur cluster info cannot be read anymore, and the green/blue dots in deCONZ start flashing in red color from time to time, though the device still shows the green wiring and green flashing dots. ioBroker still shows the reachable state as True. I don't know what this attribute means, but they aren't reachable at all. Sometimes the wiring in deCONZ is lost too.
But the devices do not remain in a state where I have to reset them redoing pairing or something similar. Instead, I noticed that I can get them back by pressing "Leave" and "Join" network in the GUI window. Afters this, everything is fine again. Maybe this can be a workaround for other users too?
EDIT: This workaround does not help in all cases. If the wiring disappears in deCONZ, even a reboot of the pi has no effect. A solution can be a reset of the Spirit by pressing the three buttons simultaneously, which set the device in join mode. Without deleting the sensor, start an "add new sensor" dialogue in Phoscon Web-UI. The Sprit is found again, and the boost button LED flashes in green color. Phoscon fortunately uses the same devices ID after rejoin, but the device name is set to generic "Thermostat" again, which has to be edited afterwards.
@Witriol thanks for update regarding GitHub page maintaining.
How about firmware update for other device? See this comment above? Is there any other Firmware from Eurotronic? I also ordered two new devices, and one can't even be paired, other it does pair but have Firmware build date: 20191014 ; Firmware version: 22190930. zigbee2mqtt point this message Failed to call 'OTAUpdate' 'onZigbeeEvent' (AssertionError [ERR_ASSERTION]: No image available for imageType '65535'.
So what we should do now with this new "bad" firmwares which doesn't work correctly? Termostat is useless atm, any info from manufacturer @Eurotronics about replacements or sth like that?
@iWelna exectly... @Eurotronics: Any reaction??
Hi, i had no success with OTAU i resend this to "Eurotronics" get a new one with firmware "20190408" Date Code. And this one is working perfect! I had no issues over two weeks, no connection failure. I can switch it off, it works as it should. Now i would buy some more :-) p.s.: if you get one from Eurotronics and connect it, the led will light red the first time after you finish the install process. You have to wait 5-10 Minutes... than it is working!!
Strangely enough I have Builddate=20191014 / Firmware=22190930 and do not experience any connection issues. I am running ConbeeII with Zigbee2mqtt and have the ConbeeII in the basement and 3 Ikea repeaters (one on ground floor and two on first floor) and since then connectivity is good.
Flashing Initiated but I aborted since the provided version is older than what I have.
Hi, i had no success with OTAU i resend this to "Eurotronics" get a new one with firmware "20190408" Date Code. And this one is working perfect! I had no issues over two weeks, no connection failure. I can switch it off, it works as it should. Now i would buy some more :-) p.s.: if you get one from Eurotronics and connect it, the led will light red the first time after you finish the install process. You have to wait 5-10 Minutes... than it is working!!
@dako76 How did You process replacement? through warranty with seller or directly with Eurotronic? I've got ofc common problem cant controll it fully, switch off etc.
@magicdude4eva ts's not about connection issues, they just don't work properly with Hassio, You cant turn them off, only seting temp works and power on. I want to setup some automations but can't coz of that. Before i had z-wave version was perfect but drained a lot of battery.
@magicdude4eva ts's not about connection issues, they just don't work properly with Hassio, You cant turn them off, only seting temp works and power on. I want to setup some automations but can't coz of that. Before i had z-wave version was perfect but drained a lot of battery.
I am ussing Hassio with AppDaemon and Schedy - with this I automate the schedule - in the example below settings for our bedroom:
This is controlled via Schedy/AppDaemon and you see that it matches the schedule:
I also use schedy and in HA it seems to work, but if you have a look at the TVR, sometimes the values don't match. Window opened, schedy and HA say 6° and the TVR is still on 21°.
Today two of five had exactly this behavior.
With my and the others we cant control them. I can turn it on, change temp and thats all. Cant change mode or turn off. I had zwave versions b4 and the were working properly i just sold them some time ago.
Even when sending mqtt cant turn it off or change mode.
And for automatons im using node red.
pt., 26 lut 2021, 19:53 użytkownik Gerd Naschenweng < notifications@github.com> napisał:
@magicdude4eva https://github.com/magicdude4eva ts's not about connection issues, they just don't work properly with Hassio, You cant turn them off, only seting temp works and power on. I want to setup some automations but can't coz of that. Before i had z-wave version was perfect but drained a lot of battery.
I am ussing Hassio with AppDaemon and Schedy - with this I automate the schedule - in the example below settings for our bedroom: [image: image] https://user-images.githubusercontent.com/1632781/109342288-e85a5500-786b-11eb-898d-044b06a4f938.png
This is controlled via Schedy/AppDaemon and you see that it matches the schedule: [image: image] https://user-images.githubusercontent.com/1632781/109342369-0de75e80-786c-11eb-82c8-b15968bf6c59.png
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EUROTRONIC-Technology/Spirit-ZigBee/issues/1#issuecomment-786831016, or unsubscribe https://github.com/notifications/unsubscribe-auth/AON72JJZZPJNTPEMIL6UQZTTA7UZTANCNFSM4VPUQS7Q .
This Spirit TRV this is a piece of s.... I do have this OTA issue as well. It just hangs in idle state and doesn't get any further. Its not just that Eurotronic's QA has failed to an unbelievable degree. I mean these issues become visible almost instantly after pairing it with a coordinator. Further more it is the burden and duty of the end user to buy a ConBee/RaspBee, setup another Raspberry with deCONZ and hack around with the new but stale firmware. Unbelievable. Made in Germany in it's original sense. I will send them back too. @dako76 any hints to be successful with that?
@pumuugel82 Hi, no they are very friendly, i send my Spirit to them and get a new one back. Just tell you have this issues, they know this :-) ...
In my case they responded after more than one month and told the seller is responsible.
@dako76 thx, i have already sent them an email with this problem, lets see what they will respond. I want to buy 3 more but without working stuff i wont do it ... and didnt find any other solution with such quality tbh (maybe netatmo ? )
Just a few questions because of my lack of understanding:
I can read the attribute "Date Code" in the Basic Cluster Info in the deCONZ UI, it is "20191014" for all my six Spirits. Where do I find the "Firmware" attribute like "22190930" mentioned in many of the posts here?
In the OTAU plugin of deCONZ, one of my six Spirits shows Vendor/Image/Version 0x1037/0x110c/0x0162e9d2. The other five show 0x0000 for all three values. If I press "Query", nothing changes. What does this mean?
Can I find at this location https://github.com/EUROTRONIC-Technology/Spirit-ZigBee/releases offical release of the Spirit's firmware - or is it just a user compiled hack I better keep my fingers off?
1. _SW Build ID_ (0x4000);
Thank you for that hint! My six devices show nothing there, the value is empty. Good chance that I didn't pick up the faulty firmware with SW Build ID = 22190930 which can't be upgraded?
For (battery-powered) devices without Receiver on When Idle, the GUI only reads the attributes up to Date Code when pressing Read. For the other attributes, you need to double-click the attribute name to popup the Attribute Editor window, and then press Read in the popup window. See the User Manual (under Help).
you need to double-click the attribute name to popup the Attribute Editor window, and then press Read
Thanks again. Now all devices show the fateful SW Build ID "22190930" weird! Interesting, because they don't seem to behave unique. For example, one of the six doesn't show "Off" in display when set to "Off" mode by using iOS Eve (possible with your awesome homebridge-hue!), the others do. It seems to me that Eurotronics wasn't very carefully maintaining build IDs.
I tried an update with 20190408_EUROTRONIC_Spirit_Zigbee_0x00122C380.ota to this Spirit, but it ended on IDLE after a few seconds. Vendor/Image/Version was 0xFFFF afterwards, but this was cleared to 0x0000 after restarting the GUI, a query has no effect as mentioned above.
- Can I find at this location https://github.com/EUROTRONIC-Technology/Spirit-ZigBee/releases offical release of the Spirit's firmware - or is it just a user compiled hack I better keep my fingers off?
@univok
@Witriol thanks for update regarding GitHub page maintaining.
How about firmware update for other device? See this comment above? Is there any other Firmware from Eurotronic? I also ordered two new devices, and one can't even be paired, other it does pair but have Firmware build date: 20191014 ; Firmware version: 22190930. zigbee2mqtt point this message Failed to call 'OTAUpdate' 'onZigbeeEvent' (AssertionError [ERR_ASSERTION]: No image available for imageType '65535'.
@vrabac Unfortunatelly, I do not know. I do not have any new update from Eurotronic.
@Witriol Hello from me :) Thank you for your time and patience answering all our questions. I know how it is to have to react with dissatisfied costumers, and also not having all the right answers for them... I don't even know if you have an official role by Eurotronics. As you mentioned, at beginning of March should be here an employee to maintain the repository (after many "next week or two more weeks"). Please don't misunderstand us, many of us didn't yet refund the faulty Thermostats because we believe in the product and think that it's only a software problem that could be easily updated and corrected at a given time. We are like kids, if we been said "next week you will get what you want" we believe that and wait for it... If we don't get it we are upset! It's also not a present for us but what we have paid for...
So to come back to the issues, I also have the "no update" devices, that also overheat or don't even reach the given temperature or even don't react by changing the offset. Also can't turn them off or use the HEAT mode.
And I still got them...
Sorry for my English, I hope you are well and forgive me referring to you as you are the company "Eurotronics" :)
Any update?
I've got an email from Eurotronic to send them the broken termostat as i did. Now i'm waiting for the new one, lets hope it will work as it should.
I've got an email from Eurotronic to send them the broken termostat as i did. Now i'm waiting for the new one, lets hope it will work as it should.
I did the same, got offer from Amazon to return back or send them to Eurotronic, I did chose the second option as I need the TRVs.
I've got today new termostat directly from Eurotronic, everything working as it should. Now i need 2 -5 more, wondering what soft will get ><
heres the info of what i had:
<OLD>
"model":"SPZB0001"
"dateCode":"20191014"
"softwareBuildID":"22190930"
<NEW>
"model":"SPZB0001"
"dateCode":"20190408"
"softwareBuildID":"18190930"
That's the same Date Code, but a slightly higher version that the firmware posted here (18181120).
They have attached a letter with apologies and that this new spirit Zigbee is from "our current production batch"
Just made automations within hassio and can confirm TRV working perfectly fine.
I received an Email from their support that I am allowed to send the faulty trvs back to them. I've not managed to do so but I am delighted now that the trvs will get fixed soon.
same here : sent back faulty device with "dateCode":"20191014" after i contacted support via email and received already 4 days later a new device with "dateCode":"20190408". Now everything works as expected - great support from Eurotronics
There is no possibility to update the firmware ??? Is it necessary to send the products to Eurotronics? It seems crazy to me.
Guys do u have Firmware build date : 20191014 Firwmare version : 22190930 Like me? I can only publish occupied_heating_setpoint Can't they make new commit to fix it? grrr
There is no possibility to update the firmware ??? Is it necessary to send the products to Eurotronics? It seems crazy to me.
As already mentioned, there are some firmwares that couldn't get updates. If you have one of the TRVs with datecode that matches one of them, you can only send them back. If you can already update yours with the firmware that you can find here, there is no reason to send them. This story with "new firmware comes soon" goes way back in December 2020. We can only hope that eurotronic works on a stable new firmware, since there is no official statement about it...
Today, one of my Spirits didn't open the valve at 15 °C room temperature though 20 °C was set. I could fix this by setting 0x4000 "TRV Mode" to "unknown 2" and 0x4001 "Set Valve Position" to 100 Percent. and then back to normal mode.
After this, I thought it is time now to write an email to EUROTRONIC TECHNOLOGY GMBH info@eurotronics.org, asking for replacement / repair at Eurotronics.
I'll keep you informed what they'll say.
just for info, my experience with the Spirits: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-800863193
@saxn-paule
Also after removing/inserting batteries again it keeps flashing while the display shows nothing.
That's exactly how an OTA update (2h20min) from 20191014/22190930 ended for me today. The manual says that red flashing means an "Over the air update". It could be that the just finished data transfer is written to CPU EEPROM in this state? Just a guess. Fortunately it wasn't interrupted by taking out the batteries experimentally. After a few minutes, flashing stopped, showing "AdA" again. The unit was on 20190408/18181120 firmware then as intended.
I'll keep you informed what they'll say.
Within one hour, EUROtronic responded. They asked me to try the OTA update on all 6 Spirits, providing the well known links to Github. Fortunately, though showing the suspicous date code 20191014 and build 22190930, five of the six devices did the update to date code 20190408, this took the whole day (90 - 220 minutes per device), but one did not, showing IDLE, game over.
Worth mentioning that the deCONZ GUI OTAU plugin works a little bit fuzzy. One time it showed "Qeued" when pressing "Update", because there is only one update at a time, but mostly it didn't respond to the update button when there was another update in progress showing "IDLE", but starting anyway when the ongoing process had finished. It ended with either "done" or "no file", don't know why to distinguish between that. I think this is a little bit strange for a OTAU-plugin, because doing firmware updates is a delicate step.
I mailed back to EUROtronic and asked for the replacement of the one Spirit device that doesn't update. Keep you informed.
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