Cannot start truma miqro service

[7wells]

Hi Daniel, I followed your installation guide, i.e. first installed as normal user. It further reads: "After you have tested that the software works for you". Erm, how can I test it? 😊

BTW, I put this in my .bashrc: export PATH="$HOME/.local/bin:$PATH"

Then I installed everything as admin (with sudo) but got this error message after trying to start this service:

pi@pi4:~ $ sudo systemctl status miqro_truma
● miqro_truma.service - truma MIQRO microservice
     Loaded: loaded (/etc/systemd/system/miqro_truma.service; disabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Tue 2022-10-04 18:53:39 CEST; 12s ago
    Process: 3095 ExecStart=/usr/bin/env python3 /usr/local/bin/truma_service (code=exited, status=1/FAILURE)
   Main PID: 3095 (code=exited, status=1/FAILURE)
        CPU: 336ms

Can you please point me to a direction where I should have a closer look? Thank you!

[danielfett]

Please check the log files using journalctl -xf -u miqro_truma.service. Any errors there?

[7wells]

Yes:

pi@pi4:~ $ sudo journalctl -xf -u miqro_truma.service
-- Journal begins at Thu 2022-09-22 05:17:24 CEST. --
Oct 04 18:56:44 pi4 env[3118]:     service(
Oct 04 18:56:44 pi4 env[3118]:   File "/usr/local/lib/python3.9/dist-packages/inetbox/truma_service.py", line 14, in __init__
Oct 04 18:56:44 pi4 env[3118]:     super().__init__(*args, **kwargs)
Oct 04 18:56:44 pi4 env[3118]:   File "/usr/local/lib/python3.9/dist-packages/miqro/__init__.py", line 224, in __init__
Oct 04 18:56:44 pi4 env[3118]:     self._read_config(add_config_file_path)
Oct 04 18:56:44 pi4 env[3118]:   File "/usr/local/lib/python3.9/dist-packages/miqro/__init__.py", line 318, in _read_config
Oct 04 18:56:44 pi4 env[3118]:     raise Exception(
Oct 04 18:56:44 pi4 env[3118]: Exception: No MIQRO config file found; searched paths: miqro.yml, /etc/miqro.yml
Oct 04 18:56:44 pi4 systemd[1]: miqro_truma.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit miqro_truma.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Oct 04 18:56:44 pi4 systemd[1]: miqro_truma.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit miqro_truma.service has entered the 'failed' state with result 'exit-code'.

No MIQRO config file found - is that the problem?

Before I continue with this: How should I test the program (as non-admin, i.e. before installing as admin) as you suggest in your guide?

[danielfett]

Seems that you need to create the config file as per the README.

Yes, testing as a normal user is easier. It is important, however, that you don't do both (running the service twice will lead to errors).

[7wells]

Ok, I will sudo pip3 uninstall, then test as normal user, and only later come back to setting up the service as admin etc.

However. I still not fully understand how I should test this as normal user.

I am stuck here:

After you have tested that the software works for you

What exactly after installing the software as normal user do I have to do? How is the program executed? Usually, I would do some python code.py, but here?

Do I need mqtt already at this point?

I have everything else set up on my desk ("fliegende Verdrahtung") and only need to carry the stuff over to my caravan and plug the LIN bus cable and the power supply. But before I do this. I need to understand how to deal with the software part.

Thanks for bearing with me!

[danielfett]

You can just run truma_service from the command line. Note that pip3 uninstall will remove both the service and the executable, so sudo service miqro_truma stop might be the better option to stop the service.

Yes, you need some mqtt broker running for that to work.

[7wells]

I have set up mosquitto and mosquitto-client with username 'pi' & password 'Pitest' for testing purposes. I can subscribe from one terminal and get text from the publishing terminal on the same RPi. I created /etc/miqro.yml with this content:

broker:
  host: localhost
  port: 1883
  keepalive: 60

auth:
  username: "pi"
  password: "Pitest"

log_level: INFO

services:
  truma:
    serial_port: /dev/ttyS0

As plain user (non-admin):

pi@pi4:~ $ truma_service
2022-10-05 15:03:00,673  truma.main  INFO       started
2022-10-05 15:03:00,674  truma.main  INFO       Using serial device /dev/serial0
2022-10-05 15:03:00,676  truma.main  INFO       Loop stats:
2022-10-05 15:03:00,677  truma.main  INFO        - Loop(_update_online_status) called 0 times, average duration 0.0s, load=0%
2022-10-05 15:03:00,677  truma.main  INFO        - Loop(send_status) called 0 times, average duration 0.0s, load=0%
2022-10-05 15:03:00,683  truma.main  INFO       MQTT connected, client=<paho.mqtt.client.Client object at 0x7f8af9caf0>, userdata=None, rc=0
2022-10-05 15:03:00,683  truma.main  INFO       Subscribing to ...
2022-10-05 15:03:00,683  truma.main  INFO         - service/truma/set/#
2022-10-05 15:03:00,683  truma.main  INFO         - service/truma/enabled
2022-10-05 15:06:00,678  truma.main  INFO       Loop stats:
2022-10-05 15:06:00,679  truma.main  INFO        - Loop(_update_online_status) called 1 times, average duration 0.001298s, load=0%
2022-10-05 15:06:00,680  truma.main  INFO        - Loop(send_status) called 60 times, average duration 3.376666666666665e-05s, load=0%

In MQTT Explorer (subscribed to /service/truma/online), whenever the service is started, the line comes up, else it goes down: Nothing spectacular but a sign (I assume) that it's working so far.

Is this now the right time to move the hardware over to my caravan and attach it to the Truma Combi?

PS: What number/ID is "object at 0x7f8af9caf0"?

[danielfett]

Yes, looks good.

The hexadecimal number is a memory location, not particularly helpful here.

[7wells]

Got everything hooked up, but the CP+ shows a "W255 H" warning and the truma_service stops after lots of checksum errors. I'm going to append the output later.

Oh, I just now did the PR SET => INIT.

[7wells]

Ah, this looks a bit better, but still checksum errors after PR SET:

(how can I pipe truma_service's output to a logfile?)

pi@pi4:~ $ truma_service
2022-10-05 16:12:23,752  truma.main  INFO       started
2022-10-05 16:12:23,753  truma.main  INFO       Using serial device /dev/serial0
2022-10-05 16:12:23,755  truma.main  INFO       Loop stats:
2022-10-05 16:12:23,755  truma.main  INFO        - Loop(_update_online_status) called 0 times, average duration 0.0s, load=0%
2022-10-05 16:12:23,756  truma.main  INFO        - Loop(send_status) called 0 times, average duration 0.0s, load=0%
2022-10-05 16:12:23,762  truma.main  INFO       MQTT connected, client=<paho.mqtt.client.Client object at 0x7f7f80aac0>, userdata=None, rc=0
2022-10-05 16:12:23,762  truma.main  INFO       Subscribing to ...
2022-10-05 16:12:23,762  truma.main  INFO         - service/truma/set/#
2022-10-05 16:12:23,763  truma.main  INFO         - service/truma/enabled

And why does the CP+ now only show the time and offer the settings menu? Other entries are not shown anymore. Is it because the service has taken over?

[7wells]

I seem to miss this row from your guide:

2022-10-02 14:21:27,234 inet-lin INFO Received status data from cp plus

It does not show up for my setting as you can see in my previous post.

[danielfett]

It seems that the operation of the script interrupts the connection between CP Plus and the heater. Is everything connected correctly?

[7wells]

My Truma Combi EDIT: 4 (not 6) without "E" has 2 LIN connectors. One plug is occupied with the LIN bus cable to the CP+. The other plug was empty, and I connected to it the LIN bus cable that came with the iNet box. So one end convects to LIN plug 2 of the Truma Combi and the other end to the splitter you mentioned (I have the same). I use the splitter just as a connector to an RJ12 cable, of which one wire (the one you highlighted) is connected to LIN on the UART board. I will post some photos later, of that helps.

Does it matter if I use the hitherto unused LIN plug 2 of the Truma Combi, or do I have to use the splitter to have both CP+ cable and "your" cable connect to the same LIN plug 1 of the Truma Combi?

If I use the splitter just as a connector, does it matter which way around the cables are connected?

(real photos will follow)

[danielfett]

The second LIN plug on the Combi should be fine. I wonder if there might be a short circuit between some of the lines.

[7wells]

Here are some photos.

The 2 black cables in the background connect to the Truma Combi LIN plugs - the one more in the foreground (plug 1) is the original cable going to my CP+, whereas the one more on the background (plug 2) is my new LIN cable (taken from the iNet box set) that goes to the splitter:

Splitter (cable below comes from the Truma Combi LIN plug 2, cable above goes to my UART board:

The yellow wire (the only one in use from the cable above the splitter) goes to UART's LIN screw port. And there are black (GND) and red (+12V). The green light of the UART is lit (on):

The green wire (TX from UART) goes to my RPi's RX, and the blue wire (RX from UART) goes to my RPi's TX pin:

[7wells]

I will check the lines tomorrow with a multimeter. Would it be correct to unplug the CAN cable from the Truma Combi and then simply check all lines if they "go through"? (i.e. between the CAN cable from the Truma combi and the UART, the RPi, and the CP+)

I'm no electrician and fear to destroy something by wrongly "measuring". All your hints here I take without any warranties, of course. ;) Thank you so much for your help - I truly appreciate it!

[danielfett]

Two things:

• Are you sure the yellow one is the correct one from the RJ12 cable? While the colors are not standardized, it was the green line for me.
• How are RX and TX connected (which one is on GPIO #14 and #15, respectively)?

[danielfett]

I will check the lines tomorrow with a multimeter. Would it be correct to unplug the CAN cable from the Truma Combi and then simply check all lines if they "go through"? (i.e. between the CAN cable from the Truma combi and the UART, the RPi, and the CP+)

There's not too much you can measure there. I rather suspect that something is not connected properly. Did you ensure that there is no short-circuit between any of the other lines coming from the RJ12?

[7wells]

• Are you sure the yellow one is the correct one from the RJ12 cable? While the colors are not standardized, it was the green line for me.

It is the same number as in your case. Sorry that I cannot take another look now but for sure will do tomorrow (also check that I have not counted from the wrong side).

• How are RX and TX connected (which one is on GPIO #14 and #15, respectively)?

And sorry that I took the photo of my RPi with the colours of the wires not visible. I know that RX is connected to TX and vice versa (between RPi and UART board). However, I will check this too, tomorrow (and also take another photo).

[7wells]

I will check the lines tomorrow with a multimeter. Would it be correct to unplug the CAN cable from the Truma Combi and then simply check all lines if they "go through"? (i.e. between the CAN cable from the Truma combi and the UART, the RPi, and the CP+)

There's not too much you can measure there. I rather suspect that something is not connected properly. Did you ensure that there is no short-circuit between any of the other lines coming from the RJ12?

No, I have to check this, too. Thanks for your many hints! :)

PS: Does truma_service save to some logfile, or should I pipe STDOUT/ERR somewhere?

[7wells]

PS: Does truma_service save to some logfile, or should I pipe STDOUT/ERR somewhere?

Sorry. I now saw it in the readme: python3 bin/read-logfile.py logfile.log

[7wells]

I checked the cable and indeed found that I mixed up wires 4/5. I.e. in my case, it should be the green not the yellow wire connected to LIN on UART. I corrected this, and now the CP+ display shows as usual.

However, when executing truma_service, the last row is still truma_service enabled.

Here is the (updated) photo with the RX/TX wires (better visible) connecting to my RPi:

[7wells]

Oh my bad, I was too stupid about the right wires but hope that the yellow one (which I initially selected) is correct! On the left side is a copy from your guide, on the right side my cable. It should be wire number 3 from the right of the terminal with the fasting latch facing towards the bottom, correct?

And this goes there:

[7wells]

Interestingly, when I connect the yellow cable (and do RESET => PR SET), the CP+ only shows the icons for the clock and the settings, the others disappeared:

[7wells]

When using any of the 3 debug options, where would the debug info appear? I tried all 3 (separately) but the output always is the same as posted before, i.e. the row about "inet-lin INFO Received status data from cp plus".

I tested the wires and don't know what else to do.

PS: I have enabled the serial interface (login shell via serial disabled) and disabled SPI, I2C, 1-Wire, and Remote GPIO. I tried also with them enabled (except for the login shell via serial, which I always kept disabled), but that did not help.

Maybe I should try a different RJ12 cable? Our is there anything else I should try?

You mentioned in your guide:

If the connection works, it can take up to a minute to receive the first status data. Everything is fine if you see the last line shown in the following in the service output:

Do you mean by "first status data" the last line? So as long as that does not appear something is wrong?

And I'm still curious if your CP+ shows only the clock and the settings icons when connected (as in my case).

[7wells]

So, nach aktualisierter Verkabelung kommt nun das:

pi@pi4:~ $ truma_service
2022-10-12 19:15:17,216  truma.main  INFO       started
2022-10-12 19:15:17,217  truma.main  INFO       Using serial device /dev/serial0
2022-10-12 19:15:17,218  truma.main  INFO       Loop stats:
2022-10-12 19:15:17,218  truma.main  INFO        - Loop(_update_online_status) called 0 times, average duration 0.0s, load=0%
2022-10-12 19:15:17,219  truma.main  INFO        - Loop(send_status) called 0 times, average duration 0.0s, load=0%
2022-10-12 19:15:17,226  truma.main  INFO       MQTT connected, client=<paho.mqtt.client.Client object at 0x7f80318af0>, userdata=None, rc=0
2022-10-12 19:15:17,226  truma.main  INFO       Subscribing to ...
2022-10-12 19:15:17,226  truma.main  INFO         - service/truma/set/#
2022-10-12 19:15:17,226  truma.main  INFO         - service/truma/enabled

Das ist unverändert, würde ich sagen...

[7wells]

Da bei mir nun Werte angezeigt werden, erlaube ich mir, mein Thema hier zu schließen. Vermutlich macht es ja auch eh mehr Sinn. dort bzgl. Verbindungsproblemen weiter zu diskutieren: https://github.com/danielfett/inetbox.py/issues/11#issuecomment-1277390484

@danielfett Ich hoffe, das ist so ok für Dich, zumal es die Übersichtlichkeit verbessern hilft.