Hardware connection details?

[olivluca]

Hello,

I'm using this library (actually my fork just to adjust a couple of things) to try and control a truma combi d (i.e. to emulate a CP plus control panel). I adapted this code https://gitlab.womolin.de/public-repository/esp32-tin-master and I'm using the connection described here https://github.com/danielfett/inetbox.py Additionally, since this is a master, I connected the INH and LIN terminals of the breakout board (as per the datasheet, the board has already a resistor and a diode between the INH pin and the INH terminal) and an output of the esp32 to the SLP terminal. Unfortunately I don't get any answer from the truma. I see the echo of what I send (only if I supply 12V to the board) but nothing else. I'm wondering if the board is faulty, I connected it wrong or I didn't adapt the software correctly. I also tried the origina repo (after adapting it from the original esp8266 to the esp32) with no success either (and since it doesn't control the state machine I think it's expected, however the inetbox.py repo doesn't control it either and there are people using it). Any hint?

[mestrode]

Hi, Olivluca, thank you for your code enhancements!

Hope in the meantime you were able to solve the issue, you described.

Anyway, in case your troubleshooting is ongoing:

• keep the statemachine of the transceiver in mind. otherwise there is only silence on the lin-bus
• since a constant dominant level is surpressed by the transceiver, try sending 0x55 contentious and verify the output by using a multimeter (guessing you don't have a scope available)
• ensure your pullup of the LIN line, avoid long wire and high capacities until your system is running! The transition from dominant to recessive level is only driven by the pullup resistor - a smaller value will increase the slope. later you should be able to handle increased wire lengths
• verify your baud rate, may analyse the sync byte: 0x55 leads to toggeling bits on the bus or try to sniff in read only mode the original data on the line. If you can read those bits, you should be prepared for the next step

I got confirmation from third party, the library is running on ESP32

I'm looking forward, hearing about your success to control your truma heater!

[olivluca]

Thank you for your reply. I still had no success in controlling my truma. I checked the adapter with an oscilloscope at work and I'm not sure it's working well (I see an apparently good signal but the dominant level voltage seems too high). Now I'm trying with another lin transceiver (mcp2021) and I'm using this one to monitor the communication (and to optionally fake the reply from the heater and that is working, so I'm not sure about my previous comment about the voltage too high). I also use it to sniff the communication on the lin bus, but unfortunately I still couldn't get any reply from the heater. Somebody on the womolin telegram group offered to test my sketches, let's see if he finds something (I suspect either a timing issue or my truma is busted).

[mestrode]

The tja datasheet says, V_IL < 0.8V. In fact this is only the voltage drop of the transistor and some margin for wire and ground. Did you ensure your ground has a good connection? However, since your were able to talk between tja and mcp, may it's more likely there is an other issue? Guess sniffing is also an good idea, on the real connection between Heater and Panel. May Truma does use one of the non-standard baud rates?

[olivluca]

It turns out that it is using a different, older, set of IDs: truma gas heaters are using the new IDs since 2018 (in fact somebody tested my sketch and it works with his truma), however my diesel heater (a 2020 model) still uses the old ones. Now I see replies from my truma, I just have to send the correct bytes and interpret the replies (easier said than done :wink:). In fact I don't even need to manage the state machine with this library, I'm doing the tests with a linux pc and an usb/ttl-serial adapter (thanks to your trick of using half the bitrate to create a valid lin break).