Posts by KlausR

    hello, i`m facing probs with a special homeassistant (running in docker, docker on SSD) integration starting several weeks ago.

    Hass log says:

    2024-02-22 22:28:07.804 ERROR (MainThread) [homeassistant.components.fritzbox] Unexpected error fetching 21eeee3e2fd389a979c0cffb84d74ab3 data: could not convert string to float: ''
    Traceback (most recent call last):
      File "/usr/local/lib/python3.12/site-packages/homeassistant/helpers/", line 313, in _async_refresh = await self._async_update_data()

    Well, seems to look for "/usr/local/lib/python3.12/site-packages/homeassistant/helpers/". Not on my system (6.9.14-1 (Shaitan)), there is just /usr/local/lib/python3.9/dist-packages, and it's empty. Should i update?

    Thanx in advance!

    I fear that my skills are not sufficient to make a decisive contribution.

    On the question of frequency: I start from the scratch every time debian changes, like now with omv6 to omv7. And that for 4 devices. At this point in time... ;)

    Mein Rpi kam in den Bereichen Memory und CPU-Last mit der Zeit doch an seine Grenzen. Parallel natürlich hohe Temperatur-Werte (>60°).

    Ich konnte (und wollte) mich nicht so recht dazu entscheiden, ihn einfach auszumustern durch Austausch mit einem Rpi4. Also habe ich das Netz durchforstet und Lösungen gefunden, die bei mir (bislang zumindest, don't call the devil) bestens funktionieren. Obwohl er mit etlichen z.T. intensiven Docker Installationen belastet ist (va HA, aber auch Nodered, Mqtt, Zigbee etc), liegt die CPU-Temperatur zumeist bei ca 46° und die Memory-Auslastung etwas über 60%. Beides ist wohl ok. Btw, deutlich schneller ist er auch geworden, obwohl das nicht die intendiert war. Trotz Usb 2.0.

    Kurzfassung der Maßnahme:

    Das OS liegt auf einer SSD, Docker ebenso, und außerdem gibt es zum Ausweichen eine weitere SSD nur für die swap-Erweiterung (additiv, die systemeigene von 100MB habe ich bestehen lassen).

    Gehäuse Geekworm, passiv (ca 12€)

    3 SSDs 240 (je ca 12€)

    3 Usb-to-Sata-Adapter (je ca 5€)

    1 Usb-Hub (ca 17€)

    Kosten also ca über 70€, wobei swap ja nicht unbedingt eine eigene SSD braucht und der Hub auch optional ist.

    Ich kann nicht einschätzen, ob dieses Projekt hier für irgendwen interessant sein könnte. Falls dem so ist, schreibe ich gerne detaillierter (auch englisch, allerdings schlechter ;) )

    Besten Gruß an alle hier, von denen ich seit Jahren profitiere!


    My Rpi reached its limits regarding memory and CPU load. In parallel, of course, high temperature values (>60°).

    I couldn't (and didn't want to) decide to simply discard it by replacing it with a Rpi4. So I searched the net and found solutions that work fine for me (so far at least, don't call the devil). Although it is loaded with several, sometimes intensive Docker installations (especially HA, but also Nodered, Mqtt, Zigbee etc.), the CPU temperature is usually around 46° and the memory usage is slightly above 60%. Both are probably okay. Btw, it has also become significantly faster, although that was not the intention.

    Short version:

    OS is on SSD, Docker as well, and there is another SSD for swap expansion only (additive, I left the native one of 100MB).

    Geekworm case, passive (ca. 12€)

    3 SSDs 240 (each approx. 12€)

    3 Usb-to-Sata adapters (each ca 5€)

    1 Usb-Hub (ca 17€)

    So the cost is about 70€, but swap doesn't necessarily need its own SSD and hub is also optional.

    I can't estimate if this project could be interesting for anyone here. If so, I'm happy to write in more detail (also English, but worse ;) )

    Best regards to all here, from which I benefit for years!

    Translated with (free version) - with some interventions by me ;)

    I suppose I found a solution without making any changes to my configuration (e.g. running docker images). Maybe it is useful for other rpi users.

    I avoid to execute updates shown in the gui directly . First I run the update search. The installation is done afterwards.

    So basically apt update and apt upgrade separately.

    Since I choose this procedure, no more problems with crashing dpkg.

    I'm not an expert on Raspberrys, there are people here who know a lot more about Raspberrys than I do. I'm only saying this from what I've been able to read.

    Thank you for that.

    I could have a try to stop containers in compose before executing updates

    Thank you for answering, Chente. Just writing alone here all the time is a bit lonely ;)

    My second Rpi is a 2b. Running omv6 without probs, it contains docker for pihole e.g.

    The one with that dpkg prob (Rpi3b) has indeed some more docker containers running (on SSD). Do you think, that's the point?

    Am I asking the wrong questions here? It can't be due to a lack of politeness that no one responds...

    If someone should be found, here is the latest status:

    I have run a search in the gui because of the reported updates. Very long lasting, and in between, it looked like a crash (several points in the dashboard completely red). But then came to end, dashboard was ok.

    The updates themselves I then made via putty, to see possible errors immediately. I discovered the following:

    Setting up salt-minion (3006.0+ds-1+191.1) ...
    salt-minion.service is a disabled or a static unit not running, not starting it.
    Setting up openmediavault (6.8.0-1) ...

    I don't know if this could have anything to do with my problem....

    update2. Confusing. Dashboards "System Information" showed update as installed (6.7.1-2 (Shaitan), but email notifications still warned about updates available and

    E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to co=
    rrect the problem.

    So i logged in and ran 'dpkg --configure -a'. It crashed. Power off/Power on: no boot.

    Glad to have a second sdcard being halfway up to date. But obviously i got a real problem.

    Could anyone be so kind to help me with troubleshooting?

    Still got this update prob.´To give some further informations to potential helpers:

    When updating via gui process will crash (loosing connection) at "Setting up Salt environment". Dashboards "System Information" shows update itself installed, however, it still announces "Update available".

    Annoying being forced to run dpkg --configure -a after every update... ;)

    update: Dashboards "System Information" changed status after some time, "No update available". So, everything's fine but the "crash" (loosing connection) while updating. Maybe it's due to Rpi3 limitations needing more time to write?

    You may have a look into /var/log/apt/term.log and /var/log/dpkg.log if there is a hint what happens.

    Could not see a hint. Both with date from today. But i realized, dpkg has 0644 rights, while term.log has 0640. Could that be a hint?

    Btw, tried to upload logs, but failed (The file extension is invalid.)

    That command comes up when dpkg is interrupted and does not complete an upgrade process. Do you have a cron job to shut the server down after it updates, or are you powering off after upgrades for some reason?

    If it is happening regularly to you, it sounds like aren't finishing before the machine is shut down.

    Thank you for answering. But I am not aware to have any cron job, at least none installed by myself. And the system is on 24/7....

    Hello, every now and then i run in a prob with dpkg when doing updates. It´s always to be solved by dpkg --configure -a', but i would like to analyze it and remove the cause. How can i do that?

    Thanx in advance, Klaus