debmatic
debmatic copied to clipboard
alexreinert
debMatic WebUI
Alle 2-3 Tage stürzt nur bei debMatic die WEBUI ab und ich finde keine Fehlermeldungen. Kommunikation zwischen ioBroker und pocketControl ist leider nicht mehr möglich. Vermutlich seit dem letzten oder vorletzten Update Konfiguration: NUC 11 und vorher auf NUC 6, SSD, 32GB Speicher, Ubuntu, debMatic und ioBroker Fehlerbehebung: Putty Verbindung aufbauen und dann mit "sudo systemctl restart debmatic.service" wiederbeleben. Das funktioniert in der Regel ca. 2-3 Tage und fällt dann wieder genauso aus. Meine Vermutungen (die sich leider nicht bestätigten): war das der NUC 6 die LAN - Verbindung verliert darum habe ich den NUC 6 rebootet und nach Neustart hat alles wieder funktioniert. danach verdächtigte ich HM-Rega welcher auch wirklich ausgefallen ist - nach dem Update funktionierte dieser wieder korrekt. Tausch auf NUC 11, Neuinstallation und Widerherstellung aus Backitup war erst mal ca. 1 Woche ruhe dann wieder das gleiche. Nun weis ich nicht mehr weiter darum melde ich mich hier einmal. Bitte um Hilfe.
Ich habe dieses Problem ebenfalls. Alle 2-3 Tage versagen meine Lichtschalter (laufen über ioBroker) den Dienst. Die Homematic Weboberfläche ist dann nicht mehr zu erreichen und die Instanzen der Homematic-Adapter im ioBroker stehen auf "Gelb".
Debmatic läuft bei mir auf einem Ubuntu Server (22.04.3 LTS (Jammy Jellyfish)).
Hier ist die Ausgabe von debmatic-info: debmatic version: 3.73.9-112 OS: Ubuntu 22.04.3 LTS Kernel: 5.15.0-91-generic x86_64 Service Status: Running Kernel modules: Available Raw UART dev: Available HMRF Hardware: RPI-RF-MOD Connected via: HB-RF-USB-2@usb-0000:00:14.0-2 (/dev/raw-uart) Board serial: 5A4993F1E1 Radio MAC: 0xFFF1E1 HMIP Hardware: RPI-RF-MOD Connected via: HB-RF-USB-2@usb-0000:00:14.0-2 (/dev/raw-uart) SGTIN: 3014F711A0001F5A4993F1E1 Radio MAC: 0xB3AE33
Und die Logdateien. hmserver.log hm_mode.txt syslog.txt
Was liefern folgende Befehle nach einem Absturz (vor dem Neustart)
sudo systemctl status debmatic-rega.service
sudo journalctl -u debmatic-rega.service -n 100
sudo systemctl status lighttpd.service
sudo journalctl -u lighttpd.service -n 100
sudo systemctl status debmatic-lighttpd.service
sudo journalctl -u debmatic-lighttpd.service -n 100
Idealerweise bitte dann auch so gut wie möglich den Zeitpunkt des Absturzes eingrenzen.
Danke, für die Antwort ich warte auf den nächsten Absturz. Da ich debmatic.service eigentlich immer prüfe. Der ist eigentlich immer Online aber ohne WebGui kann ich da nichts mehr starten. Auch vom iobroker kann nichts mehr gestartet werden hm-Rega ist online, hm-rpc detto. Nach debmatic.service Restart funktioniert es wieder. Die gewünschten Abfragen liefere ich beim nächsten Ausfall vermutlich am Montag. LgHeinz Heinz Karl BERHUBERZinken 56A-4591 MollnMobil : +43 678 1217182Mail: @.*** 15.12.2023 um 16:27 schrieb Alexander Reinert @.***>: Was liefern folgende Befehle nach einem Absturz (vor dem Neustart) sudo systemctl status debmatic-rega.service sudo journalctl -u debmatic-rega.service -n 100 sudo systemctl status lighttpd.service sudo journalctl -u lighttpd.service -n 100 sudo systemctl status debmatic-lighttpd.service sudo journalctl -u debmatic-lighttpd.service -n 100
Idealerweise bitte dann auch so gut wie möglich den Zeitpunkt des Absturzes eingrenzen.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
debmatic.service ist nur die halbe Wahrheit, der startet eine Reihe von anderen Diensten.
Ausfall debMatic am 16.12.2023 zwischen 23:30 (letzte korrekte Lichtabschaltung) und 23:45 Uhr (hier wurde das iobroker Script korrekt gestartet jedoch hat die Kommunikation mit debMatic und HM-RPC.1 HomeMatic IP nicht mehr funktioniert) Nachstehend kommen die Ergebnisse der gewünschten Testzeilen:
sudo journalctl -u lighttpd.service -n 100.txt sudo systemctl status debmatic-lighttpd.service.txt sudo systemctl status debmatic-rega.service.txt sudo systemctl status lighttpd.service.txt sudo jouralctl -u debmatic-lighttpd.service -n 100.txt sudo jouranalctl -u debmatic-rega.service -n 100.txt
Danke fürs anschauen.
Die Logs sehen ehrlich gesagt nicht danach aus, dass die WebUI ausgefallen war, alle dafür notwendigen Dienste waren im Status running. War die WebUI bei diesem Ausfall nicht erreichbar?
Bitte beim nächsten Ausfall folgende Befehle, beim letzen Befehl ist die Farbe der Punkte wichtig (grün, rot, weiß), diese bitte kenntlich machen.
sudo systemctl status debmatic-rega.service
sudo journalctl -u debmatic-rega.service -n 100
sudo systemctl status lighttpd.service
sudo journalctl -u lighttpd.service -n 100
sudo systemctl status debmatic-lighttpd.service
sudo journalctl -u debmatic-lighttpd.service -n 100
sudo systemctl status debmatic-hmserver.service
sudo journalctl -u debmatic-hmserver.service -n 100
cat /var/log/hmserver.log
sudo systemctl list-dependencies debmatic
Ausfall war heute 20.12.2023 zw. 16:49 und 17:30 Uhr Ja Status ist auf running - WebUI ist aber leider nicht erreichbar - auch Pocket Controll kann sich nicht verbinden. die Punkte aus dem letzten File bzw. der letzten Abfrage sind: ● Alle schwarzen Punkte sind grün ○ haben keine Farbe
sudo systemctl status debmatic-rega.service.txt sudo journalctl -u debmatic-rega.service -n 100.txt sudo journalctl -u lighttpd.service -n 100.txt sudo systemctl status debmatic-lighttpd.service.txt sudo journalctl -u debmatic-lighttpd.service -n 100.txt sudo systemctl status debmatic-hmserver.service.txt sudo journalctl -u debmatic-hmserver.service -n 100.txt cat _var_log_hmserver.log.txt sudo systemctl list-dependencies debmatic.txt
Danke sehr für die Hilfe. sudo systemctl status lighttpd.service.txt
Ich selbst nutze auch Intel NUC. Anfangs den 6er-Celeron, zwischendurch einige Jahre lang den 8er i5 und jetzt den 12er. Für stabiles Netzwerk schalte ich einige Hardwarefunktionen ab (Die werden dann per Software vom Treiber übernommen). Seit ich das mache, sind die Netzwerkprobleme Geschichte. Für Infos dafür nach "proxmox nuc ethtool off" googeln.
Debmatic läuft bei mir in einer eigenen Debian VM. Wichtig sind mindestens zwei Kerne. mit nur einem Kern dauert der Start Ewigkeiten. Mit zwei Kernen geht das alles recht flott.
@Berli1960 Laut den Files laufen alle Services und es gibt in der Zeit keine Fehler. Rein in debmatic kann ich daher keinen Grund erkennen, warum du Probleme beim Zugriff hast. Kann es sein, dass du ein anderes Gerät hast, welches sich zu der Zeit zu einem IP Konflikt führt? Oder hast du irgendeine Firewall Software auf dem Nuc oder auf deinem Rechner? Oder irgendwelche anderen Netzwerkprobleme?
@alexreinert: Danke fürs drüberschauen mir kam das alles auch sehr komisch vor und darum suchte ich Hilfe. Zur Info auf dem NUC 11 und vorher auf NUC 6 läuft Ubuntu, dann wurde debmatic, ioBroker und zusätzlich habe ich auch noch influxdb und Grafana darauf installiert - alles mit der gleichen IP, nur bei ioBroker wird das WebUI mit IP:8081 Grafana mit IP:3000 und influxdb mit IP:8186 aufgerufen und bei debmatic geht's nur mit der IP da das WebUI mit Port 80 ja automatisch aufgerufen wird. Nach einem Ausfall kann ich auf dem ioBroker und alles andere ganz normal arbeiten nur das WebUI von debmatic öffnet nicht mehr. Auch Pocket Control kann keine Verbindung mehr zur debmatic aufbauen und somit ist auch nix mehr schaltbar. mit "sudo systemctl status debmatic.service" wird mir auch ganz normal running angezeigt. Nach "sudo systemctl restart debmatic.service" funktioniert alles wieder wie gewohnt. Wenn nicht die annähernd 100 Geräte (15 BidCos-RF, 84 IP) wären würde ich schon einmal neu installieren und wieder anlernen denn aus dem Backup wiederherstellen hatte ich schon 2x probiert, Erfolg leider negativ. Vielleicht wird's ja wieder einmal. Sollte jemand eine Lösung haben bitte gerne melden bin für alles dankbar. Danke nochmals.
Port 80 wird durch iob fix für Alexa Local freigeschaufelt. Möglich, dass sich da was beißt.
Warum kein Proxmox und da die Anwendungen auf mehrere VMs aufteilen?
@alexreinert: Danke für die Antworten bzw. Analysen. @peterfido: Warum kein Proxmox? -> da hab ich mich leider nicht ausgekannt und daher die Finger davon gelassen. Port 80 -> ich hab da zufällig was gefunden. Der Adapter ioBroker.welcome macht auch so etwas den hab ich nun deinstalliert vielleicht war das der Übeltäter -> ich werde mich dazu, in ca. 14 Tagen, noch mal melden.
@peterfido: Leider hat das Abschalten des Adapters Alexe und ioBroker.welcome nix genützt, Fehler ist wieder aufgetreten. @alexreinert: in debmatic habe ich die nicht benötigten Programme alle deaktiviert. > hat leider auch nix genützt. Jetzt werde ich nach und nach jeden Adapter abschalten und dann mit allen iobroker - Scripten das gleiche durchführen und hoffe so den Übeltäter herauszufinden. Dies erfordert sehr viel Zeit und Geduld, es ist aber auch nicht gesagt dass ich so den Fehler finde. Kann eigentlich ein Gerät in Debmatic welches nicht erreichbar ist (Weihnachtssteckdosen 5 Stk.) oder auch defekt ist, so etwas produzieren? Ich denke da an DutyCicle? LG Heinz
Hallo zusammen,
habe leider das gleiche Problem. debMatic läuft bei mir in einer dedizierten VM unter UNRAID mit einer eigenen IP-Adresse, was einen IP-Konflikt ausschließen sollte.
Der geschlossen Issue #150 kam meiner Fehlerbeschreibung am nächsten, sodass ich den Service lighttpd verdächtigt habe. Kenne mich mit dem Service aber leider nicht aus.
Verhalten des Fehlers
- WebUI ist nach undefinierter Zeit nicht mehr erreichbar.
- Weitere SmartHome Systeme (OpenHAB 4.1.0) erreicht HomeMatic Geräte nicht mehr.
- VM lässt sich pingen und Verbindung mittels ssh ist erfolgreich
- debmatic und lighttpd service sind im status active (running)
- Status des lighttpd service beinhaltet Warnings (siehe unten)
- Nach restart des service lighttpd ist die WebUI temporär wieder erreichbar (Dauer der Erreichbarkeit unbekannt)
Weitere Infos
uname -a ergibt hierbei:
Linux debmaticvm 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
sudo systemctl status lighttpd ergibt:
`● lighttpd.service - Lighttpd Daemon Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2024-01-06 14:01:47 CET; 4min 18s ago Process: 21163 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) Main PID: 21169 (lighttpd) Tasks: 1 (limit: 3342) Memory: 1.2M CPU: 324ms CGroup: /system.slice/lighttpd.service └─21169 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
Jan 06 14:01:46 debmaticvm systemd[1]: Starting Lighttpd Daemon... Jan 06 14:01:47 debmaticvm lighttpd[21163]: 2024-01-06 14:01:46: (configfile.c.426) Warning: mod_auth should be listed in server.modules before dynamic bac>Jan 06 14:01:47 debmaticvm systemd[1]: Started Lighttpd Daemon. Jan 06 14:01:47 debmaticvm lighttpd[21169]: 2024-01-06 14:01:47: (configfile.c.426) Warning: mod_auth should be listed in server.modules before dynamic bac>`
Die Ausgabe von sudo lsof -i -n beinhaltet viele Einträge von lighttpd (vgl. #150)
Der Vergleich mittels diff zwischen der lokalen Datei 20-debmatic.conf und der aus dem offiziellen Repository zeigt keine unterschiede.
Hoffe dies hilft etwas weiter.
VG Benny
Also die Warnmeldungen des lighttpd service habe ich in den Griff bekommen. Mal schauen ob es das Problem beseitigt hat.
