LoxBerry V4.0.0 RELEASE!

[Onliner]

Ich nochmal. Das müsste die Stelle sein:

/opt/loxberry/libs/perllib/LoxBerry/System.pm

my $output = qx { $command };
my $exitcode = $? >> 8;

Vorschlag

In LoxBerry::System::execute() sollte optional oder generell stderr mitgeloggt werden, z. B. durch:
my $output = qx { $command 2>&1 };

oder einen optionalen Parameter:

execute(
command => "...",
log => $log,
capture_stderr => 1
);

[Prof.Mobilux]

Danke DIr. Mach dazu gerne ein Issue auf Github auf - dann schauen wir uns das an.

[mette1942]

Hallo zusammen

Bin neu hier im Forum, da ich ein Fehler habe welcher als Lösung das Loxforum angeben hat. Also bitte ein bisschen Nachsicht.

Beim Update auf v4.0.0.13 bricht mein Loberry mit folgender Fehlermeldung ab.

LoxBerry Update: Free diskspace is below 200 MB (available: 0). Update was prevented.

Bei der Analyse mit dem Selbsttest hab ich festgestellt, dass drei Stati auf Error stehen. Siehe Printscreen 1 im Anhang.
System Info ebenfalls im Anhang

Meine Vermutung geht in die Richtung der logs, dass diese zu gross sind. Jedoch habe ich keine Ahnung wie ich diese Löschen soll, geschweige denn wie ich den Prozess der Log verantwortlichen Anwendungen stoppe.

Loxberry habe ich schon mehrfach gebootet.

Setup: Loxberry läuft auf einer Virtuellen Maschine auf meinem Qnap NAS mit 4GB RAM und 512GB Diskspace zur Verfügung gestellt.

Vielen Dank für eure Unterstützung.
Gruess Mette

[AlexAn]

Probier das hier:

https://www.loxforum.com/forum/projektforen/loxberry/allgemeines-aa/394914-partitionsgr%C3%B6%C3%9Fe

[mette1942]

Probier das hier:
https://www.loxforum.com/forum/proje...r%C3%B6%C3%9Fe

Hoi Alex

Hab ich gemacht, /dev/sda1 ist nun gleich gross wie /dev/sda.
Jedoch wird im Loxberry die dev/sda1 immer noch mit den alten 8GB ausgewiesen.
Loxberry hab ich nach der Partionsgrössen Anpassung frisch gestartet

[mette1942]

Mittlerweile gelöst!

resize2fs /dev/sda1 hat ohne su nicht funktioniert. Danke für die Hilfe zur Selbsthilfe.

Gruess us de Innerschwyz

[Onliner]

Danke DIr. Mach dazu gerne ein Issue auf Github auf - dann schauen wir uns das an.

Erledischt

https://github.com/mschlenstedt/Loxberry/issues/1533

[karniplayer]

Hallo zusammen. Erstmal ein herzliches Dankeschön an die ganze Crew für eure ganze Arbeit und die Weiterentwicklung vom Loxberry (Donation ist letzte Woche raus).
Die neue Version ist wirklich gut gelungen und macht optisch echt was her, vor allem auch der neue AppStore! 🥳🎉👍

Ich habe Loxberry schon ne ganze Weile am Laufen, erst auf nem Raspberry3/ 4 und die letzten 2 Jahre auf nem Proxmox Minidesk. Es läuft alles super und zuverlässig.
Leider bin ich im Thema Linux usw. nicht so tief drinnen und wurstle mich da ein wenig durch.
Mit viel nachlesen hat bisher alles funktioniert, vor allem wenn man mal ne weile nicht dran war.

Da Proxmox VE8 ja am Auslaufen ist dachte ich, ich setz mal das ganze System mit VE9 neu auf und mach dann auch gleich den Loxberry mal neu (auch wegen dem Fehler mit der LogfileDB).
Also wieder mal die Anleitung rausgesucht und durchgearbeitet. Leider scheint die Anleitung schon etwas veraltet zu sein da Bookworm anscheinend schon durch Trixie ersetzt wurde. Wusste nur das man danach auf Trixie upgraden kann, aber nicht das es schon Grundlage ist. Hab dann erstmal ne weile gebraucht die richtige Version zu finden, hat dann aber irgendwie funktioniert.
Bei der installation von Loxberry v3.0.1 hatte ich dann auch einige Probleme, vor allem, weil ich die Passwörter nicht wie gewohnt eingeblendet bekommen habe.
Ich hab die komplette VM glaub ich 3x installiert, bis ich sie dann irgendwie zum Laufen gebracht habe und auch irgendwo ein root-PW gefunden habe oder eines vergeben konnte (weiß aber nicht mehr wie 🙈).
Ich war dann fast geschockt als ich 2- 3 Wochen später eine Benachrichtigung gesehen habe das ab sofort die v4.0 verfügbar ist.
Ich hab dann natürlich das Update gemacht und finde es super... momentan laufen bei mir eh nur 3 Plugins, werden aber demnächst wieder mehr.

Jetzt überlege ich gerade alles nochmal sauber mit Trixie und V4.0.0.13 neu zu machen, bin jetzt aber unsicher wegen der Anleitung und den Versionen.
Was wäre die aktuelle Empfehlung für DietPi und die VM-Einstellungen?
Wo bekomme ich das root-PW her bzw. ging es glaub ich um den Putty-Zugang (SSH) wo was nicht funktioniert hat? Bin mir leider nicht mehr sicher. Oder ich hab was überlesen und das falsche PW verwendet? 🙈
Reicht ein „normales“ DietPi Trixie aus oder würdet ihr auf jeden Fall die DietPi_Proxmox-x86 Trixie empfehlen? Oder ist das egal?
Sind die Einstellungen für die VM noch aktuell oder welche Maschine/ CPU/ Memory würdet ihr bei nem HP EliteDesk 800 G4 Desktop-Mini-PC mit 16GB Ram aktuell empfehlen.

Danke schonmal für eure Antwort und Hilfe

[Prof.Mobilux]

Das steht alles im Wiki. Du nimmst einfach die aktuellste DietPi Version. Das Root Passwort vergibst du während der DietPi Installation. DietPi fragt dich danach und du gibst es ein. Steht auch im Wiki.

[ledchab]

Moin,
ich habe LB4 ja auch auf Proxmox neu installiert (nach Updateversuchen) habe die empfohlene DietPi Proxmox Trixie Version verwendet - lief alles Problemlos
habe einen alten Fujitsu Mini PC - sieht so aus als dümpelt der da rum auf dem läuft noch Homeassistant, Mqtt, etc
ich finde das mit ner VM schon recht cool - man kann einfach mal was ausprobieren - könnte auch recht einfach auf LB3 zurück

[Backstein]

Ich empfange von einem Tasmota-Gerät in Loxone über den Loxberry-MQTT-Server ein Last WIll Telegram. Dabei wird mir seit ein paar Tagen immer um die selbe Uhrzeit in der Nacht (01:25) ein Ausfall des Geräts gemeldet, obwohl es normal läuft. Liegt das am Loxberry-MQTT-Server (Version 2)?

[Backstein]

Der tägliche Cronjob am Loxberry war verantwortlich. Ich konnte bei jedem Ausführen von /etc/cron.daily/dietpi den Ausfall des Tasmota-Geräts replizieren. Durch Erhöhen der MqttKeepAlive-Time am Tasmota wurde das Problem allerdings gelöst. Offen bleibt, warum das Problem erst seit ein paar Tagen aufgetreten ist. Hab am Loxberry nichts geändert und das Update auf 4.0.0.13 wurde schon Ende Juni installiert...

[Prof.Mobilux]

Das ist ein DietPi Cronjob. Der spielt Updates ein und macht Backups. Eventuell lastet das dein System aus. Wenn Du ein Backup erstellst zu diesem Zeitpunkt, könnte es auch sein, dass er diverse Services vor/nach dem Backup neu startet.

[Neocramencer]

Ich hab ein ähnliches Problem, bei mir hängt ein Nuki 5 via mqtt am loxberry mit der aktuellsten version und in unregelmäßigen abstand geht ein topic (nuki connected) auf 0, das war auf dem loxberry vorab nicht so, mein loxberry läuft auf einer synlogy vm mit dietpi. Ich habe auch das gefühl das ein background task (cron oder aehnliches) das problem triggert. Was benötigt ihr an logs um das Problem zu analysieren. Tritt wir gesagt erst mit dem loxberry 4 release und dem mqtt v2 auf.

[neu.bau]

Mahlzeit, ich habe ein kleines Problem mit dem MQTT Gateway. Wenn ich von V1 auf V2 umschalte, dann läuft das MQTT Gateway nicht mehr.
Das Log-File zeigt folgendes:


Woran kann das liegen?

[Prof.Mobilux]

Es gibt ein neues PreRelease V4.0.0.14. Achtung! Ich empfehle aktuell die Installation nicht auf Produktivsystemen oder nur mit Backup.

Das Release hatte zum Focus die Performance des MQTT Gateway V2 weiter zu verbessern und auch die Performance des Mosquitto Brokers weiter zu verbessern und zu stabilisieren. U. a. wird der Broker nun auch über den LoxBerry Healthcheck überwacht (z. B. dropped messages).

Release Notes:

Mosquitto Broker

• Robust systemd integration (self-healing): The fragile /etc/systemd/system/mosquitto.service symlink — which shadowed the whole distro unit and was silently lost on Mosquitto package upgrades (so the tmpfs logfile was never created, the broker kept running but its log stopped growing) — is replaced by a .service.d drop-in that extends the distro unit. The drop-in is re-created automatically on every WebUI save / config apply and is never touched by dpkg, so it now survives Mosquitto package upgrades.
• Boot-ordering fix: Mosquitto now starts only after createtmpfs.service, so the RAM-disk log folder exists before the broker opens its logfile. Fixes the boot race where Mosquitto ended up writing into a deleted inode (broker running, log frozen).
• Overload hardening: The LoxBerry-managed drop-in raises broker limits (max_queued_messages 5000, max_inflight_messages 40, 1 h persistent-client expiration) to buffer message bursts instead of dropping QoS-0 messages on client-queue overflow.
• Correct unit activation on update: On installs where the distro unit had become active again, the 4.0.0.14 update re-points /etc to the LoxBerry Mosquitto unit and reloads systemd.

Healthcheck

• The healthcheck now reads the Mosquitto $SYS broker load and prints a compact load line in every state: connected clients, inbound/outbound messages per minute with fan-out ratio, connection churn, stored messages, heap, and the dropped-message counter (total + 1m/5m/15m moving averages).
• Raises a WARNING when the broker is actively dropping messages. Automatically skipped when $SYS is not readable (external broker / ACL).

MQTT Gateway V2

• Parallel per-Miniserver send queues: A dispatcher fans out one queue/worker per configured Miniserver. Each Miniserver is served strictly sequentially (with a short pause between HTTP requests to protect it), while different Miniservers are processed in parallel — a slow or dead Miniserver no longer stalls the others.
• Mosquitto log in the Logs tab: The Mosquitto log is now shown and readable directly in the MQTT Gateway Logs tab, with date, size and an Open button like the other logs.
• The MQTT notification publisher now uses the short hostname as its topic base instead of a hardcoded loxberry (#1527).
• Python 3.9 compatibility fix for Gateway V2.