Umzug Edomi von Synolgy auf NUC best practice

[fudi6489]

Ich hab mir zu Weihnachten einen BXNUC10I3FNHN2 i3-10110U gegönnt und möchte in ein paar Tagen darauf Edomi installieren. 8GB Ram und 512GB SDD sind auch vorhanden.

Ein paar Fragen tun sich auf:

1. Edomi läuft aktuell auf einer VM in der Synology 918+. Ebenso MQTT, und Grafana und InfluxDb die letzten beiden sind nur installiert aber nicht aktiv/produktiv. Zusätzlich läuft noch ein Raspberry 4 auf welchem NibePi und NodeRed laufen mit denen ich die Anbindung Wärmepumpe/Stromzähler auf NodeRed und sich dann via MQTT der Kreis zu Edomi wieder schließt. Die Installation auf dem Raspberry sollte so bleiben wie sie ist. Alles andere ist individuell möglich und könnte aus Leistungsgründen auf dem anderen System installiert werden. Welche Anordnung wäre hier die beste?
2. Aktuell schaukelt sich die Queque sehr oft auf, beim Tageswechsel hängt das System über 10min, eine Projektaktivierung nimmt bis zur Synchronität der Uhr 45min in Anspruch, und das muss ich auch in den Griff bekommen. Datenbank ist über 1GB groß, und gefühlt hat es mit den Zugriff auf diese zu tun. Wenn ich eine Datenarchiv mittels IKO lösche hängt die Uhr auch für 10sek obwohl die Last ansonsten gering ist. Bei den Logiken habe ich unterschiedliche Verzögerungen eingebaut um der Gleichzeitigkeit entgegenzuwirken. Leider auch mit mäßigen Erfolg. In Zukunft sollten die Daten in Edomi nur für einen kleinen Zeitraum gespeichert bleiben und in der InFluxDB für den längeren Zeitraum gespeichert werden. Sollte das System dann performanter werden, oder muss ich hier den Hebel wo anders ansetzen?
3. Gefühlt haben die MQTT Bausteine, Edomi auch langsamer gemacht. Gibt es hier Möglichkeiten die verursachte Last der jeweiligen Logiken auszulesen ohne diese händisch abzuschalten und einen Neustart durchzuführen. Bei meiner Neustartdauer werde ich da alt....
4. Auf der jetzigen Edomi Installation mussten für manche Bausteine immer wieder Pakete installiert werden. Wie stelle ich das jetzt am besten an dass die neue Edomi Installation auf dem NUC gleich läuft? Gibt es wo eine CENTOS Installation wo diverse Pakete schon dabei sind. Um ehrlich zu sein weiß ich nicht mehr exakt was ich da die letzten 4 Jahre so installiert habe.
5. Die alte Edomi Installation wird solange produktiv bleiben bis die Punkte 4 einwandfrei laufen. Wie gehe ich hier am besten vor damit sich die parallelen Installationen nicht in die Quere kommen.
6. Ich möchte das Edomi Backup auf der Synology speichern um bei einem Hardwaredefekt des NUC darauf zugreifen zu können. Wie kann ich das am besten Handeln dass zusätzlich zu Backup auf dem NUC das letzte auf die Synology gespeichert wird, und nur zB 5 Stück behalten werden?
7. Je nachdem wo ich dann nach euren Empfehlungen die Systeme installieren soll, wird es auch von Vorteil sein auf dem NUC eine VM zu installieren, oder? Welches System würde sich hierfür anbieten?

Liebe Grüße und einen schönen Start ins neue Jahr
Jürgen

[oefchen]

N gutes Neues Jürgen,
ich würde denken ich bin auf dem gleichen Level unterwegs wie Du....also reiner Anwender der sich eher auf Empfehlungen verläßt.
Hier läuft Edomi auf einem Odroid H2+ unter Proxmox. Edomi, InfluxDB, NodeRed & Grafana jeweils im Container.
Daten gar nicht in Edomi sondern direkt in die InfluxDB, bin noch am überlegen ob ich dauerhaft NodeRed nutz oder die Daten über KNX-PlugIn´s der Influx direkt ziehe....ohne den Umweg.

Proxmox könnte Dir andere Maschinen direkt als Cluster verbinden, Backups gehen hier richtig gut. Für Edomi gibts direkt einen fertiges Template.
Einfach zu installieren und zu pflegen....ich bin dankbar

[fudi6489]

Danke oefchen

Dann werde ich mir Proxmox mal genauer ansehen, gelesen hab ich eh schon öfters davon.

Vorgestern habe ich bezüglich Punkt 2&3 mal Logiken ein und ausgeschaltet um der Ursache für die Trägheit auf die Spur zu kommen.

• Wenn ich alle Logiken ausschalte, dauert der Neustart 5min, dann ist auch die Uhr wieder synchron, Hänger zu bestimmten Zeiten gibt es nicht.
• Beim Einschalten der meiner Meinung nach ressourcenschonensten 75 von 98 Logiken hat sich an der Neustartdauer und Hängern faktisch nichts geändert.
• Danach habe ich die nächsten 8 Logiken eingeschaltet (u.a die Darksky Wettervorschau für 7 Tage welche 250 stündlich getriggerte IKOS beinhaltet)- auch ohne Unterschied.
• Dann blieben noch die MQTT Logiken und die Sensorenwerte und Stromwerte die ich in die Datenbank schreibe. Habe als nächstes die MQTT Logiken und Wechselrichter Anbindung mittels Modbus TP aktiviert, und die Geschichten die die Datenbank direkt betreffen noch ausgelassen (Auslesen 2x Eastron Stromzähler Wärmepumpe+Wohnraumlüftung, Auslesen Nibe WP vom Raspberry, Auslesen Smartmeter Netzbetreiber und eben der Wechselrichter) Hier werden die Werte sehr oft getriggert. Die meisten davon 10 sekündlich bis minütlich. Eine Seite zur Berechnung diverser Stromwerte habe ich in diesem Zug auch noch aktiviert (zB Berechnung COP, Autarkie, Eigenverbrauch usw) Auch hier gibt es sehr viele Berechnungen da die Werte eben so oft aktualisiert werden und in diesem Zug die Berechnungen stattfinden. Erfreuliches Ergebnis: keine drastische Leistungseinschränkung. Neustartdauer 6 Minuten, und zur nächsten Viertelstunde mit einem 5min Hänger, danach einwandfrei.
• Zu guter Letzt habe ich noch die Logikseiten aktiviert welche direkt in die Datebank schreiben. Ab hier gab es wieder eine deutliche Leistungseinschränkung mit einer Startdauer von 23 Minuten. Vor dem kompletten Unterfangen mit Stand alle Logiken aktiv-Neustart mit allen Logiken aktiv, hat der Neustart 45min in Anspruch genommen. Ich schreibe vermutlich zuviele Werte in die Datenbank, wüsste jetzt aber auch nicht wo ich hier soviel sparen könnte, wenn ich aktuele Diagramme visualisieren möchte. Vor allem die Stromwerte müssen einfach relativ oft aktualisiert werden. In Summe ist die Datenbank 380 Datenarchive mit 18.000.000 Einträge und 1,1GB groß.

So sieht die Seite fürs Wegspeichern aller Stromwerte aus. Vermutlich würde hier ein zeitversetztes Triggern eine leichte Verbesserung bringen, hatte aber eigentlich bewusst darauf verzichtet damit die zusammenhängenden Werte auch zeitgleich ins Archiv geschrieben werden. Wird alle 5min getriggert, noch selteneres Triggern führt irgendwie nicht zum gewünschten Ergebnis, da man die Werte ja doch in "Echtzeit" haben möchte.

image.png

image.png

Und hier noch eine typische Seite für die Sensoren (davon gibt es 7)

image.png

Ich möchte die Performanceprobleme noch vor dem Umzug etwas in den Griff bekommen. Was sagt ihr? Datenbank zu groß? Zuviele unnötige Daten die geschrieben werden? Verbesserung wenn die Daten in Edomi nur kurz vorgehalten werden und in InfluxDB langfristig gespeichert werden?

Liebe Grüße
Jürgen

[jonofe]

Die Ursache für träges Starten ist die Anzahl der Einträge in den Datenarchiven. Hier kommen schnell einige Mio. Einträge zusammen. 18 Mio Einträge machen das System langsam, dafür ist Edomi nicht ausgelegt.
Ich würde Überdenken was davon wirklich genutzt wird und entsprechend reduzieren und verdichten. Brauch man wirklich den aktuellen Stromverbrauch minutengenau von vor 3 Jahren? Zusätzlich den Zeitraum der Speicherung verkürzen und wenn nötig für Langzeitarchivierung nach InfluxDB überführen.

[oefchen]

18 Mio Einträge

Musst Du denn alle Daten über Edomi ziehen und auf den Bus schreiben ? Müssen alle Logiken zwingend auf Edomi laufen ?
Ich hab versucht soviel wie möglich im eig. KNX-Systen abzuhandeln. Natürlich ist ne Logik in Edomi schön angelegt. Ich möcht aber bei einem Serverausfall nicht auf wichtige Logiken verzichten.
Ja, man muss sich dann mehr mit KNX-Logik auseinandersetzen....aber es lohnt sich.....m.M.n.

Ebenso hab ich alles an Sensorik direkt auf dem Bus und schreibe praktisch nix in Edomi. Alle Werte gehen im Moment über NodeRed (Prox-CT) in die influxDB(Prox-CT)
Musst Du über ModBus TCP an Deine Geräte wär vlt ein Gateway schlauer als ein LBS in Edomi ?

[fudi6489]

18 Mio Einträge machen das System langsam, dafür ist Edomi nicht ausgelegt.
Ich würde Überdenken was davon wirklich genutzt wird und entsprechend reduzieren und verdichten. Brauch man wirklich den aktuellen Stromverbrauch minutengenau von vor 3 Jahren? Zusätzlich den Zeitraum der Speicherung verkürzen und wenn nötig für Langzeitarchivierung nach InfluxDB überführen.

Der künftige Plan wäre in Zukunft die Daten nur für einige Tage in Edomi zu behalten, und auch die Charts von Grafana zu machen da auch diese teils sehr lange zum Laden brauchen.
Dann hätte ich eine schlanke Datenbank damit Edomi flott arbeiten kann, und nur bei der Darstellung der Charts müsste ich auf die große Influx Datenbank zugreifen, und Influx sollte damit vermutlich besser zurechtkommen wie Edomi.
Zur Speicherung ist es halt so eine Sache wo ich auch noch nicht so recht weiß.
Vor der Aufrüstung der PV hab ich Informationen gebraucht ob der Wechselrichter bei weiteren Modulen nicht überlastet wird. Dies wäre ohne solch eine Speicherung nicht möglich gewesen.
Letztens mit den Nachbarn gerade geredet dass die Winde teils echt stark sind bei uns in der Gasse. Kann man auch wunderbar nachsehen.

Für die standarmäßige Visu macht es aber keinen Sinn, für manche Informationszwecke aber durchaus sinnvoll ev. auch nötig.
Da ich das Projekt aber noch gerne 10 Jahre+ so weiterbetreiben möchte, ist die Frage ob dann nicht auch Influx irgendwann an seine Grenzen kommt?

oefchen

Ja eigentlich sind die meisten Daten schon nötig da es ja auch die Live Ansicht in der Visualisierung gibt. Es ist aber nicht nötig die Datenarchive via Edomi zu beschreiben. Für mich war es aber so am logischsten, da ich dann alles über ein System manage. Also die Daten müssen via MQTT sowieso importiert werden, die Weiterverarbeitung könnte ich mir sparen.

Die Logiken sind ganz unterschiedlicher Natur: Direkt in KNX wären aber vermutlich nur 10% darstellbar. Zusätzlich ist es in Edomi auch deutlich einfacher zu lösen.
Eine extra Logikhardware besitze ich auf KNX nicht, nur was halt die aktuelle Hardware hergibt. Da stößt man aber schnell an die Grenzen, weil zuwenige Eingänge etc. und weiß bald nicht mehr in welchem Aktor man was macht. Hab das dann schnell verworfen, und mit Edomi gemacht.

Bei einem Serverausfall lässt sich das gesamte Haus noch händisch bedienen. Das ist für so einen Fall vollkommen ausreichend.
Der letzte Punkt mit den Sensoren ist wieder der gleiche Punkt wie weiter oben. Ich hab mich damals dazu entschieden da ich noch nicht mal ein anderes System wie NodeRed, MQTT etc laufen hatte. Bei Edomi scheint mir vieles schon logisch, bei MQTT müsste die Lernkurve noch sehr steil sein um mich zu verwirklichen können. Bis dato war das mehr Copy-Paste. Manche Werte werden auch in Edomi Logiken noch weiterverarbeitet und erst dann weggeschrieben.
Nachdem ich mich dann auch bald noch mit Influx und Grafana außeinandersetzen muss traue ich mir das fast nicht zu.

Der Modbus TCP LBS kostet mich nix und funktioniert einwandfrei. Den Wechselrichter könnte ich auch über NodeRed auslesen, sehr mir aber da jetzt keinen Sinn darin.
Mein Selbstversuch, siehe Beitrag #3, hat aber ganz gut gezeigt dass es nicht die Logiken ansich sind die Edomi so stark zusetzen sondern das Beschreiben der Datenbank.
Die Frage ist halt ob das besser wird wenn ich von Edomi die Daten regelmäßig nach Influx schreibe, auch wenn das die Edomi datenbank nicht zusätzlich belastet.

LG und danke für eure Mithilfe

[jonofe]

die Frage ob dann nicht auch Influx irgendwann an seine Grenzen kommt?

Nicht die Datenbank wird an seine Grenzen kommen, sondern deine Infrastruktur.