How to debug LIN bus / WOMOLIN (TI-CI-LIN Interface v2.0)

[fabikm]

Hi Magnus, thank you for a great work and very nice and usefull project.

I spent several hours trying to communicate with the TRUMA unit always failing to initialize the TRUMA CP plus, fake-iNetBox. The ESP32 works as expected (incl. MQTT), but it is not possible to verify the functionality with the LIN converter WOMOLIN (TI-CI-LIN Interface v2.0).

All connected as recommended (TX-RX, RX-TX, GDN, 3.3V) +12V and GND on the TI line. HW: ESP-WROOM-32 2.4GHz Dual-Mode WiFi+Bluetooth rev.1, CP2102 SW: esp32_inetbox2mqtt_v263_4M.bin TRUMA firmware: After init reset H2.00.01 C4.04.01

Is there a way to find out if the ESP32 and TI-CI-LIN intereface are working properly, or directly TI-CI-LIN interface to the TRUMA line (CPplus)?

Thanks for the advice, any help...

Btw according to the official statement, TRUMA does not anticipate the implementation of remote/cloud control (outside Bluetooth range) in the "new" type of TRUMA iNet X unit in the coming months. So, no possibility of remote starting of the heating is foreseen yet...

[mc0110]

Hi,

the error pattern sounds like a connection error or incorrect wiring. The LIN-Sw is set up in such a way that as soon as an INIT request comes from the CPplus, a response is also sent immediately. Then the third entry appears. This means that either the receive channel is not working, because then of course nothing is sent, or if you are receiving something, then the send channel is not OK.

There are debug functions in the software. These are controlled via the file args.dat. If you do not use a monitor (e.g. Thonny), you can also load the file via the file manager in OS mode up/down. In the file, please add the following in addition to the hw=ESP32: lin=debug This is how the line should look:

hw=ESP32 lin=debug

If you can receive data, you will see log entries here, even if the INIT process has not yet taken place. The init process and what the ESP32 sends, of course, also.

A small hint: You definitely need the ground from the on-board power supply, it is not enough to connect the ESP32-GND.

Finally: Let me recommend the latest version 2.6.4, which I just posted yesterday (firmware esp32). I have just revised the log messages here.

I'm keeping my fingers crossed for you - let me know if it worked (and of course if it didn't).

[fabikm]

OK With the new FW 2.6.4 I have changed args.dat exactly like this: hw=ESP32 lin=debug

But this file is still empty(without DEBUG data, still only with line "hw=ESP32 lin=debug" after reboot (both modes OS mode / RUN mode)

About the power supply - I have powered ESP32 from the external power-bank/USB port.

Does it automatically send data at certain intervals to the ESP32 serial interface, which would be captured on the TX, RX pins, which could be monitored by e.g. the TERMITE program?

On WomoLIN Interface is it better to have Jumper 7 at S(slave), or M(master) position? Jumper 6 (are all on UART - RXD, TXD, VCC)

WomoLIN is connected with all three ports (CPplus + TRUMA heater + TRUMA aircondition) +12V from CPplus power (caravan battery) GND from CPplus power (caravan battery)

Thank you

[fabikm]

Serial port report:

MPY: soft reboot INFO:args:args_file found -> loaded INFO:args:file: args.dat content: hw=ESP32 lin=debug INFO:main:release no: 2.6.4 HW: ESP32 INFO:connect:Detected micropython 1.20.0 10502 on port: esp32 INFO:main:Normal mode activated - for chance to OS-mode type in terminal: INFO:connect:DHCP: True INFO:connect:fixedIP: psoa1111 INFO:connect:LAN: False

[fabikm]

INFO:main1:Restart main_loop INFO:main1:del ha_autoconfig completed Task exception wasn't retrieved future: coro= <generator object 'main' at 3fff91a0> Traceback (most recent call last): File "asyncio/core.py", line 1, in run_until_complete File "main1.py", line 183, in main File "main1.py", line 172, in set_ha_autoconfig AttributeError: 'NoneType' object has no attribute 'publish'

[mc0110]

If you want to write the logs into a file (e.g. name.txt), you need to expand in args.dat: file=name.txt You mentioned a stable mqtt-connection, but I'm missing the log-message. I couldn't see LIN-Logs, so assume that your rx-chanel is damaged.