Edomi im Docker-Container - revised

[Pretorianer]

i know, aber auf dem nvidia tx2 läuft leider kein amd64 image
muss mir am abend nochmal anschaun was es da haben kann

[tger977]

also ich habe nun doch noch ein Problem: der LBS 19001642 Verbrauchsstatistik funktioniert seit dem EDOMI Containerupdate wohl nicht mehr, es kommen bei jedem Aufruf folgende Errormeldungen und diese führen auch zu keinem Abfrageergebnis aus den Datenarchiven von EDOMI:

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
 	 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:26[/TD]
 			[TD]962156[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage MAX Tag[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:26[/TD]
 			[TD]971467[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage MAX vorherige Stunde[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:26[/TD]
 			[TD]976473[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage MAX vorherige Stunde -1h[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:26[/TD]
 			[TD]983658[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage MAX Wert[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]002938[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch Gestern[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]011059[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch aktuelle Woche[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]017035[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch vorherige Woche[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]023667[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch aktueller Monat[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]029715[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch vorheriger Monat[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]037631[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch aktuelles Jahr[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-07 16:25:27[/TD]
 			[TD]051290[/TD]
 			[TD]27893[/TD]
 			[TD]err[/TD]
 			[TD]EXE19001642 [v0.8]: Fehler bei SQL Abfrage Verbrauch vorheriges Jahr[/TD]
 		[/TR]
 	 [/TABLE]

Da scheint nun irgendwas bei einer SQL Datenbankabfrage nicht mehr zu funktionieren.

Im LBS ist dies eine Beispielabfrage die offensichtlich schief geht:

$sql_query="SELECT datetime, ms, targetid, gavalue FROM `edomiLive`.`archivKoData` WHERE datetime=(SELECT MAX(datetime) FROM `edomiLive`.`archivKoData` WHERE targetid=".$targetid_Zaehlerstand." AND datetime >=".$time_day_max.") AND targetid=".$targetid_Zaehlerstand;

Ist das nur bei mir so?

Ich habe auch im Systemlog noch folgenden Eintrag gefunden:

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
 	 		[TR="class: cke_show_border"]
 			[TD]2021-04-05 22:10:27[/TD]
 			[TD]243025[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Datenbank: Verbindung herstellen[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR="class: sErr cke_show_border"]
 			[TD]2021-04-05 22:10:39[/TD]
 			[TD]211343[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Datenbank: edomiLive.archivKoData (automatische Reparatur aktiviert - siehe System-Log): Table is marked as crashed and last repair failed[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-05 22:10:39[/TD]
 			[TD]246233[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Datenbank: edomiLive.archivKoData repariert. Die Reparatur kann u.U. wirkungslos bleiben - bitte überprüfen![/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR="class: sErr cke_show_border"]
 			[TD]2021-04-05 22:10:40[/TD]
 			[TD]414823[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Datenbank: 117 Datenbanken überprüft (1 Fehler)[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-05 22:10:40[/TD]
 			[TD]416294[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Datenbank: RAM reservieren (100 MB pro RAM-DB)[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-05 22:10:40[/TD]
 			[TD]653568[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Datenbank: edomiLive erstellen[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-05 22:10:40[/TD]
 			[TD]655766[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Projektaktivierung...[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR="class: cke_show_border"]
 			[TD]2021-04-05 22:12:14[/TD]
 			[TD]201433[/TD]
 			[TD]MAIN[/TD]
 			[TD]24980[/TD]
 			[TD]Projektaktivierung: Arbeitsprojekt (1) aktiviert[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 	 [/TABLE]

Wie kann ich da weiter prüfen ob es da irgendwas an der Datenbankstruktur zerschossen hat bzw. dies ggf. auch reparieren?

[tger977]

hab nun nochmal ein Autobackup vor dem Update von vor 2 Tagen eingespielt, damit funktionierte der LBS wieder. Es scheint wohl wirklich was an der DB zerschossen worden zu sein. Ob und wie das mit dem Update nun zusammenhängt weiß ich leider nicht.

Die Frage ist nun ob und wenn ja wie ich am besten die Daten retten kann in der edomiLive.archivKoData... Hat mir da jemand einen Tip?

[wolfib]

Hallo,

ich habe den Docker Container relativ problemlos auf meiner Synology NAS zum Laufen bekommen, Vielen Dank dafür!
Ich möchte nun aber gerne eine zweite Instanz laufen lassen. Die http und websocket Ports kann man ja ändern aber den Multicast Port 3671 kann man nicht ändern oder? Und was ist mit den 50000 und 50001 Ports, welchen Zweck haben die?

LG Wolfgang

[beauty]

Wozu eine zweite Instanz??

[wolfib]

Um bei der zweiten Instanz ein Beispielprojekt öffnen zu können. Ich bin auf die Lösung aber selbst draufgekommen. MIt dem Parameter KNXACTIVE=false startet Edomi auch ohne KNX Anbindung.

[starwarsfan]

Hi

ich habe den Docker Container relativ problemlos auf meiner Synology NAS zum Laufen bekommen, Vielen Dank dafür!

Freut mich zu hören, danke für das Feedback.

Ich möchte nun aber gerne eine zweite Instanz laufen lassen. Die http und websocket Ports kann man ja ändern aber den Multicast Port 3671 kann man nicht ändern oder? Und was ist mit den 50000 und 50001 Ports, welchen Zweck haben die?

Diese drei Ports werden für die KNX-Kommunikation verwendet. Was da wie genau auf welchem Port läuft, kann ich Dir auch nicht sagen. gaert kann dass ggf. genauer beleuchten.

Aber unabhängig davon: Warum solltest Du diese Ports nicht ändern können? Du hast sogar zwei Möglichkeiten:

a) Kannst Du einfach ein anderes Mapping machen. Also bspw. 3672:3671, so dass von aussen auf 3672 zugegriffen wird, Docker das intern aber auf 3671 mappt. Damit brauchts an Edomi keinerlei Anpassung.
b) Falls a) doch nicht funktioniert (hab's nicht ausprobiert), dann so, dass das Mapping auf beiden Seiten gleich ist. Also bspw. 3672:3672, wobei dass dann auch in der Edomi-Basiskonfiguration angepasst werden muss. Die Option heisst KNX-IP-Router: UDP-Port.

Es ist halt einfach nicht so, dass das automatisch in der Edomi-Konfiguration eingetragen wird sondern Du das händisch machen musst.

[beauty]

Also ich habs mal bei meiner Syno probiert.
Also wenn es rein zum öffnen eines Demo Projekts geht ohne Funktionalität auf den Bus, reicht es wenn man den Port 80 mappt. Hab bei mir aussen 82 auf innen 80 gemappt und Edomi ist über Edomi-IP:82/admin erreichbar. Projekt kann auch geöffnet werden.

[wolfib]

Vielen Dank für die Rüchmeldungen, eventuell sehe ich mir das nochmal genauer an.

Ich habe aber noch ein weiteres Problem gefunden, in das Fehler-Log wird laufend folgende Fehlermeldung geschrieben:

Datei: /usr/local/edomi/main/include/php/ModbusMaster.php | Fehlercode: 8192 | Zeile: 38 | Methods with the same name as their class will not be constructors in a future version of PHP; ModbusMaster has a deprecated constructor

Bei meiner vorherigen Installation (CentOS 6 auf VM) trat das nicht auf, liegt das an der im Contaier eingesetzten PHP-Version? Oder muss der LBS 19001030 ModBus TCP Master Read aktualisiert werden?

LG Wolfgang

[starwarsfan]

Hi

Ich habe aber noch ein weiteres Problem gefunden, in das Fehler-Log wird laufend folgende Fehlermeldung geschrieben:

Schonmal an die Suche gedacht?

[wolfib]

Danke

[MKHR]

wolfib :
Wie beauty sagte kann man die KNX-Ports komplett weg lassen. Aber den Websocket braucht man trotzdem zusätzlich.
Eigentlich sollte alles automatisch auch in der edomi-config geregelt werden. Fahre das setup schon länger und bin mir keiner manuellen Nacharbeit bewusst.

Wenn man die ports nicht weg lässt dann müssen sie natürlich auf etwas "freies" gemappt werden, sonst kann der container nicht erstellt werden.
Beispiel:

sudo docker run -d\
--name edomi\
--restart=on-failure\
-p 9080:80\
-p 9081:9081\
-p 3671:3671/udp\
-p 50000:50000/udp\
-p 50001:50001/udp\
-p 9022:22\
-p 9306:3306\
-e KNXGATEWAY=10.06.91.7\
-e KNXACTIVE=true\
-e HOSTIP=10.06.91.25\
-e WEBSOCKETPORT=9081\
-e ROOT_PASS=123456\
-e PGID=1000\
-e PUID=1000\
-e TZ='Europe/Berlin'\
-v /mnt/backup/edomi/:/var/edomi-backups/\
starwarsfan/edomi-docker:amd64-latest

sudo docker run -d\
--name edomiTest\
--restart=on-failure\
-p 4080:80\
-p 4081:4081\
-p 4671:3671/udp\
-p 40000:50000/udp\
-p 40001:50001/udp\
-p 4022:22\
-p 4306:3306\
-e KNXGATEWAY=10.06.91.7\
-e KNXACTIVE=false\
-e HOSTIP=10.06.91.25\
-e WEBSOCKETPORT=4081\
-e ROOT_PASS=123456\
-e PGID=1000\
-e PUID=1000\
-e TZ='Europe/Berlin'\
-v /mnt/backup/edomi-test/:/var/edomi-backups/\
starwarsfan/edomi-docker:amd64-latest

[starwarsfan]

Hallo miteinander

wolfib :
Eigentlich sollte alles automatisch auch in der edomi-config geregelt werden. Fahre das setup schon länger und bin mir keiner manuellen Nacharbeit bewusst.

Das sind zwei verschiedene paar Schuhe.

wolfib :
Wenn man die ports nicht weg lässt dann müssen sie natürlich auf etwas "freies" gemappt werden, sonst kann der container nicht erstellt werden.

Was genau meine Variante a) aus #757 ist.

[MKHR]

Ich schau es mir (aus Eigeninteresse) später noch mal an. Zumindest der websocket muss zwangsweise gleich sein. Steht seit einem pr auch so in der beschreibung und da kommt auch meine aussage mit "wird automatisch gemacht" her. Für die anderen ports will ich das nicht behaupten.

Vielleicht war das mit automatisch nicht klar genug:
Dein script im container sollte automatisch aus den env variablen die edomi config mit dem korrekten port bauen. Wie gesagt, definitiv für websocket, um welchen es mir ging. Die anderen nicht ganz sicher

[jonofe]

Die Option heisst KNX-IP-Router: UDP-Port.

Mein Verständnis war immer, dass der Port 3671, der Port auf Seiten des KNX Routers und nicht auf Seiten von EDOMI ist.
Wenn eine Verbindung von EDOMI zum KNX Router aufgebaut wird, müsste EDOMI einen zufälligen hohen Port wählen und sich mit dem Port 3671 am KNX Router verbinden.Ich würde daher vermuten, dass der Port 3671 gar nicht an den Container durchgereicht werden muss. Der Container müsste somit nur ausgehenden Traffic auf Port 3671 erlauben. Und da es dann eine ausgehende Verbindung wäre, müsste dies eigentlich unkritisch sein.

Aber wie gesagt, ich kenne das KNX nicht so genau. Aber wie sonst sollte dann von einem PC zwei Clients gleichzeitig auf einen KNX Router zugreifen können.