Hm interesting that you can write this registers witout having a FEK registerd.
I tried 301/302 and 601/602 they are related to HK1/HK2. But I get -40 or -3276.8 as response…
But relating to your problem I guess its esp32 code related and not heat pumpe.
I’ve a LWZ504 but i don’t get it working.
I’ve already checked and measured the wiring and everything is fine. I’m using a ESP32 Wroom and a MCP2515 (now) without a resistor.
My log looks like this:
[12:25:43][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:25:44][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:25:45][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:25:46][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:25:47][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:26:02][I][QUEUE:050]: Requesting data for 059c
[12:26:02][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:26:09][I][QUEUE:050]: Requesting data for 059a
[12:26:10][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
[12:26:10][I][QUEUE:050]: Requesting data for 059b
[12:26:11][D][canbus:035]: send standard id=0x6a2 rtr=FALSE size=7
What could be the next steps to find the issue in my setup?
Forgot to mention that I’m using the setup from @kr0ner (GitHub - kr0ner/OneESP32ToRuleThemAll)
Can you increase the log level in the main yaml and look at the init logs? Cause from the logs above it seems to be fine
Here is a bigger log snipped:
You are not receiving any data. Can you upload a picture of your wiring? What could also help is to connect directly via UART and check the logs there … the MCP init is missing in the logs … I had trouble at some point, cause I used the wrong pins
spi:
id: McpSpi
clk_pin: GPIO14
mosi_pin: GPIO13
miso_pin: GPIO4
canbus:
- platform: mcp2515
id: my_mcp2515
spi_id: McpSpi
cs_pin: GPIO15
can_id: 680
use_extended_id: false
bit_rate: 20kbps
on_frame:
Maybe those pictures help you to understand my setup
Oh boy. canbus: cs_pin was configured on GPIO15 but is GPIO17 in my setup. Now it looks good! Thank you so much for the fast answer and the work you’ve already put into it (and in supporting people like me 
)
1 Like
Perfect 
hope you enjoy the code and feel free to push back improvements 
1 Like
Hello Daniel, you have the file picture_elements_card.yaml in your repository - can you show a screenshot or upload it to the repository for inspiration? Thanks
It is nothing special 
I just split the Betriebsmodus into the individual bits and show them as pictures in HA … Which then resembles the display of the WP. Don’t have good pictures yet. But this it what it looks like
Ah, so copied the display - but it’s also a nice idea. I’m still waiting for my hardware and then hopefully I’ll get my THZ404 properly integrated into HA. At the moment I’m doing it via FHEM.
Thank you for this awesome thread and the Github repo.
I think i wired up my setup correctly but i seem to get decoding issues with SOME CAN messages. I think this is because i have a Tecalor THZ 5.5 ECO.
Any pointers for me how to start adapting it to my heatpump?
In all implementations there’s only a small amount of sensors supported the easiest way to add more stuff or change the settings is to increase the log level and click around in the display and see what is being sent/received by the Display.
For my code I want to add an easier way for the configuration soon, so that also variant handling is possible
ah ok. but i dont have an ISG.
Good cause paying 800€ for a CAN Interface with webserver is a bad Idea xD
With display i meant the one mounted to the WP
Where can i find the CAN bus ID on the Tecalor WP Display that i have seen on the Stiebel WP ?
And how do i find out how to decode the messages correctly. Is there some documentation how they are encoded?
I think there is an Info tab in the display that shows the CAN-ID … but I don’t think it is necessary to know it. If you click around through the menu … new CAN messages will be shown in the log . Then look for the values e.g. SPEICHERISTTEMP 385 means 38.5° there is not really much encoding done … just for some specific values like year where you need to add 2000 or the Bit-coded BETRIEBSTATUS. Comparing with the values you see in the diplay helps. It is a bit of work, but you also don’t need all the sensors
1 Like
Maybe you want to look at the latest changes before adding too much stuff. Did quite some refactoring yesterday. Should now be easier to maintain the config and/or create variants for different WP types.
1 Like
Thank you for the awesome module. I get an error with the new version:
In file included from src/callback_handler.h:8,
from src/main.cpp:273:
src/communication.h:25:10: fatal error: mappings.h: No such file or directory
******************************************************************
* Looking for mappings.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:mappings.h"
* Web > https://registry.platformio.org/search?q=header:mappings.h
*
******************************************************************
#include "mappings.h"
^~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/thz404/src/main.cpp.o] Error 1
I have copied and included the mappings.h from the old code and get the following error:
Linking .pioenvs/thz404/firmware.elf
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/thz404/src/main.cpp.o:(.literal._Z17processCanMessageRKSt6vectorIhSaIhEE+0x10): undefined reference to `GetValueByType(unsigned short, Type)'
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/thz404/src/main.cpp.o:(.literal._ZNSt17_Function_handlerIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEjEZ5setupvEUlS5_jE33_E9_M_invokeERKSt9_Any_dataOS5_Oj+0x8): undefined reference to `Mapper::Mapper()'
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/thz404/src/main.cpp.o:(.literal._ZNSt17_Function_handlerIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEjEZ5setupvEUlS5_jE33_E9_M_invokeERKSt9_Any_dataOS5_Oj+0xc): undefined reference to `Mapper::getBetriebsartId(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/thz404/src/main.cpp.o: in function `processCanMessage(std::vector<unsigned char, std::allocator<unsigned char> > const&)':
/config/.esphome/build/thz404/src/communication.h:80: undefined reference to `GetValueByType(unsigned short, Type)'
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/thz404/src/main.cpp.o: in function `Mapper::instance()':
/config/thz/thz504_temperature_polled_throttled.yaml:34: undefined reference to `Mapper::Mapper()'
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /config/thz/thz504_temperature_polled_throttled.yaml:34: undefined reference to `Mapper::getBetriebsartId(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
collect2: error: ld returned 1 exit status
*** [.pioenvs/thz404/firmware.elf] Error 1
Do you have an idea?
holy cow … how did that even compile for me … esphome sometimes really has a weird caching behaviour. Gimme some minutes to fix it.
Edit: @StefanG84 try now
1 Like
