Possibility to list all the boiler error codes #938
Comments
|
AFAIK only the last error code is sent over the bus, previous ones are overwritten. |
|
that is the best solution. the ESP32 has limited memory and not enough to store historic data |
|
can be done in home assistant using a template sensor and a log card
|
|
Actual errors are send with telegram 0xBE from device and 0xBF from boiler, but only as long as the error exists. The errors logged in ems telegram 0x10 (need reset) and 0x11 (boiler tries again). 0x10 holds up to 8 last errors, 0x11 up t o 5, the newest first. EMS+ logs errors in 0xC2 with start of error and end of error, don't know how much errors really logged. It's 20byte per error, so the telegram could hold max 12 errors. But this is a lot of redundant data, so we only read th newest error and publish it. If HA or any other system log, you have all data in history. If somthing is missing, use teminal an type |
|
I agree that storing the past errors is not a viable way on ESP32. I probably did not specified that correctly. I always need to know all of the active errors. Unfortunately the last error may not be the last active, but it has the last starting time. In that case the lastcode may show, not active, last error, but there may be an active error in the system (with earlier start time). If the lastcode will always show the last, or the last active if any, it would probably be enough. What I find useful is the MichaelDvP comment. I will try to dig into it in that space. |
|
Just for information: Here is the sensor in the new Home-Assistant template format for all status numbers for the Buderus GB192i-19 in German: |
thanks. I've added it to the wiki - https://emsesp.github.io/docs/tips-and-tricks/#home-assistant-sensor-template-for-all-status-numbers-on-a-gb192-boiler |
|
BTW: all codes (2019) are here: https://productslu.buderus.com/buderus/productslu.buderus.com/user/de/buderus_servicehandbuch_ems_2019.pdf |
|
I was not aware of the maximum sensor length of 255 chars, so I shortened some messages. I updated my answer above, but maybe you should also update the Wiki. |
|
In my opinion, EMS_ESP should show/publish everything it can decode from the EMS bus. After all, each user can use the customization and block those entities that he does not need, right? However, I agree that decoding error numbers to text messages via EMS-ESP is not a good idea. As shown above, this can easily be done on the HomeAssiatant side. BTW, in the new EMS+ systems (at least that's how it works in my Buderus WSW196i) you can read the entire log of the last 20 errors (the same as displayed by the RC300 controller). These errors can be read from Boiler with telegrams |
|
BTW, I found an interesting file with many error codes, descriptions and potential causes: |
It does that now, right? Everything is published that is decyphered.
Flash is 99% full now. The ESP32 is a tiny thing. A lot of time has gone into making the software fit within the constraints of the ESP32. It's a tiny chip, the size of your pinky's nail and only has 0.5 MB RAM and 4 MB Flash. We've optimized the hell out of the code to make it all work and still facing memory issues. Compared to something like the RC300 ESP32 RC300 If we're storing error codes in the Flash, it may fit with some compression but there will be a lot of wear with all the writes and rotation, which is never a good thing. |
|
Yes, currently EMS-ESP decyphers all known parameters. What I meant was that it is no longer possible to add more (e.g. list of last 20 errors) due to out of memory. The limitation here is not ESP32 itself, but FLASH and RAM. In order to free up some FLASH memory, it would be probably necessary to change the way of updating the firmware (currently ~2MB of the Flash is "wasted"!), e.g. as it is done in TASMOTA (they use "minimal" firmware during update) or drop the multilingual version and publish each language version separately (like TASMOTA). I don't like any of these ideas. Do you have any others? I think a decision has to be made to abandon ESP32-4MB and switch to ESP32 with 16MB Flash and PSRAM. This will increase resources 4x! It would provide plenty of room for future project development. What do you think? From what I can see most of the interfaces produced by BBQKees are based on the ESP32-WROOM module. Upgrading them would be relatively simple (for anyone who can solder and has the necessary equipment). Just replace the module with the latest WROOM-32E-N16R2 version and add a 10kohm pull-up resistor to GPIO16. This version has 16MB of flash and 2MB of PSRAM. Of course, future versions of the interface can use also e.g. (easily available) ESP32-WROVER-E-N16R8. WROOM-32E-N16R2 is still hard to get (I saw it only in the official ESPRESSIF store on Aliexpress), so I'm currently testing using "ordinary" WROOM-32UE-N16 with soldered 8MB PSRAM chip. After enabling PSRAM (by adding
|
|
you're spot on. We realized this last year and already have started coding for the larger chips S2 and S3 with more Flash and PSRAM. For the 4MB variants, there is #608 which is done, and works but is still experimental and needs to be explained to end-users. We adapted the concept from Tasmota and Michael did all the coding so kudos to him. I'm still worried about the wear on the Flash though if we're constantly updating the last error codes. |
|
I think, it is not the question, if, but how the upgrade to 16 MB will be handled. In my case, I use a dedicated ESP-Board with an EMS-Bus converter from BBQKees. I didnt found 16 MB ESP32 Boards, which can be used directly, but only the chips. In my opinion, soldering the chip is no sufficient way. |
https://www.lilygo.cc/products/t7-s3 |
|
The S32 has had a 16MB flash chip for a long time now. The E32 has 4MB, which I cannot upgrade to 16MB in the current format. With the addition of all the languages the problem is more in the RAM of the ESP32 chip. For the next gen S32 the choice is pretty simple. I am looking to use the S3 with 16MB flash and 8MB PSRAM. This is the biggest leap forward we can currently make on the ESP platform. However, for reasons unknown to me, they removed the convenient hardware Ethernet support from the ESP32-S3. That's why I asked Proddy to have a look at the W5500 Ethernet chip. But this will take some time. So for the next gen E32 I may have to do an intermediate version with an ESP32 with additional PSRAM. |
|
I'm not convinced that abandoning the "old" ESP32 in favor of the S3 (or other "S" or "C") variants is a good idea. As you noticed variants C and S no longer have native support for Ethernet. The only option left is to connect the ethernet chip via SPI. It will certainly be a much slower (fast enough for us?) and supposedly much less stable solution (W5500 is considered not very stable). Maybe, after all, it's worth staying with the "old" ESP32 but in the version with 16MB of Flash and PSRAM? I know thet there is no direct successor of WT32-ETH01 used in E32 (with more flash and PSRAM), but I found a nice ESP32 board with LAN8720, 16MB Flash and PSRAM - LILYGO®TTGO T-Internet-COM. It would be enough to design an EMS interface board with an edge connector that fits mini-PCIE connector (there are GPIO signals in it) and we have the successor of the E32 interface. Of course it should be also possible to design completely own PCB (even only 2-layer) with LAN8720 onboard and use ESP32 module or even discrete ESP32, Flash and RAM chips. |
|
You may be right about the E32 indeed. It's a shame they removed the Ethernet support in the S3. So maybe it's better to remain a bit longer on the ESP32+PSRAM platform for the next E32 until the official Ethernet support in the IDF for the S3 etc has matured enough. (For the next-gen S32 the S3 is still the better choice). The ETH01 was convenient, and that LilYGO looks nice but for the next E32 I am going for a complete board with all chips on it like as in the S32. |
I insert your code to template sensor, but facing issue. How to correct it? |
|
@misa1515 You have to use the service code number instead of the last service code |
Is your feature request related to a problem? Please describe.
Sometimes the boiler may present multiple error codes. Sometimes even one error code, which is still valid, is masked with newer error code which happened after the running error but last only for a short time. This prevents investigating error codes from EMS-ESP at all and the possibility of reset them.
Describe the solution you'd like
The thermostat shows all the error codes present in system. It is a question if it has memory for all of them and snoop any error notification and then present them on the duration basis (or let say missing error ending notification). Or it has some EMSs to query all the present errors. I expect the first one is more probable.
On this observation the final implementation will be based.
Additional context
I have a IVT AIR X HP which will need to have diagnosed the circuit between outdoor and indoor unit. Probably replace the weak circulation pump. Meanwhile this is done I'm experiencing regular defrost issues, in lower freezing temperatures it may be multiple errors. So I'm able to snoop that out and provide some information for correct implementation of diagnosis of multiple error issues. And also being able to reset them correctly.
The text was updated successfully, but these errors were encountered: