Verteilte Datenerfassung

[Tom Bombadil]

Hallo,

gibt es jemanden, der bereits eine "verteilte Installation" mit mehreren sh.py's produktiv und dauerhaft am Laufen hat?

Hintergrund:
Mangels "grüner Kabel" habe ich kein KNX-Installation (GA's fallen also aus). Dafür verfüge ich aber über mehrere LAN-Anschlüsse in jedem Raum.
Im EG habe ich einen Samson Heizungsregler, der über Raspi / RS485 angebunden werden soll (mein nächstes Plugin-Projekt).
Im OG steht eine Helios KWL, die bereits über Raspi / RS485 mit sh.py kommuniziert (Plugin läuft seit >1 Jahr 24/7).
Im DG werde ich demnächst vermutlich eine QNAP TS-251+ in Betrieb nehmen, die neben der NAS-Funktion auch performant genug für mehrere parallele VM's ist.

Auf der QNAP soll eine VM mit Debian und der sh.py/smartVisu-"Zentrale" laufen. Das eliminiert auch gleich die bekannte SD-Ausfall-Problematik.
Die beiden Raspis sollen über LAN die Anbindung von Heizung und KWL zum "zentralen" Smarthome übernehmen.

Wie geschrieben: Ist alles noch in der Planungsphase.Die Sufu hat mir bisher Hinweise auf das network-Plugin geliefert, aber praktische Umsetzungs-/Erfahrungsberichte habe ich nicht gefunden.

Hat jemand so ein verteiltes System produktiv im Einsatz? Gibt es Dinge, die man bei der Umsetzung unbedingt beachten sollte? Danke für Eure Erfahrungen im Voraus!

/tom

[knxmfbp]

Ich betreibe produktiv zwei Instanzen, beide auf Raspberry Pi's. Angefangen habe ich mit der ersten Instanz im Keller für den KNX Bus, der Zweite musste ins Erdgeschoss wegen EnOcean Empfang. Ich nutze EnOcean Temperatur und Hygrometer Sensoren.
Die Daten vom EnOceanPi werden über das network Plugin übertragen. Funktioniert bei mir einwandfrei, bei im Moment 6 Sensoren die ca. alle 15 Minuten oder öfters ein Telegram senden.
Zum SD Ausfall kann ich nur raten die root-Partition auf ein USB-Stick zu schieben und die SD Karte dient somit nur noch zum Booten und in meiner Anwendung ebenfalls als Backup Laufwerk (wöchentlich rsync). Bei einem Ausfall vom USB was in > 18 Monaten noch nicht passiert ist einfach in der Boot Konfiguration die root-Partition auf die SD Karte verweisen und schon hätte ich ein aktuelles System am laufen und hätte ein paar Tage zum USB Stick wechsel.
Auch habe ich die gesammte Konfiguration in einem Git Repository was es mir auch sehr erleichtert einen neuen sh.py hochzufahren.

[Sandman60]

Hi Tom,

muß leider passen, denn bei mir laufen zwar mehrere Systeme, allerdings "syncen" sich diese via GA's indem beide hören beide auf den Bus schreiben können, aber nur einer aktive Logiken mit Busaktivitäten auf den Bus schreibt.

Andere Dinge laufen dann parallel, bspw. das Hören auf Plugins. Bei mir hat es allerdings den Hintergrund, dass ein System Prod., eines Int. und eines Dev. ist und das Int.-System i.d.R. durch einen Parameter/Item dann schnell zu einem prod. gemacht werden kann. Wichtiger Erfahrungswert: Ich verwende die gleichen Item- und Logik-Files auf allen Systemen und "transportiere" (kopiere) diese nur von Stage zu Stage, womit das rausfieseln von einzelnen Items entfällt. Analog mache ich dies auch mit der SV.

Was mir selbst noch fehlt und auf der laaangen Liste steht ist ein Sync. von Items zwischen den Systemen, was eigentlich m.E. über die gleiche Schnittstelle wie sh.cli laufen müßte, sprich mit Telnet einen Item-Dump abziehen und dann in das andere System reinfahren.
Das Delta sollte dann hoffentlich zeitlich gesehen minimal sein.... Ist aber noch Theorie, fehlt mir allerdings für einen quasi Hot-Standby-Failover noch.

Bzgl. SD-Karte mal mein Erfahrungsbericht: Bislang laufen 2 der 3 Systeme auf den PI's (seit Jan 2014) und bis dato hatte mal ein SD-Adapter eine Macke, ansonsten kein SD-Sterben. Aber: Die Karten waren nicht vom Krabbeltisch und ich betreibe kein exzessives Logging oder Debugmode-Arien, damit schreibt sich der PI auch nicht zu Tode auf den SD's.
Und wenn es doch mal notwendig ist lagere ich das Thema via Mount auf das NAS aus, mache ich aber nur temporär da das Error-Handling bei NAS-Problemen mir zu High war.

Cheers,
Oliver

[Tom Bombadil]

Hallo Raoul und Olli,

danke für die Erfahrungen.

Um das Thema SD abzukürzen: Im Raspi läuft seit 2 Wochen ein NAND-Stick, auch die SD gehört zur eher 'handverlesenen' Sorte. Keine Ausfälle bisher - allerdings zeichne ich seit 2 Wochen diverse Parameter der KWL im Minutentakt auf, und der Raspi knickt beim Liefern von Plots langsam ein.

Wenn die Heizung in Kombination mit der Wetterstation dran ist, werden wir vermutlich über ganz andere Datenmengen reden - SLC-NAND hin oder her, irgendwann gibt jeder Stick auf. Also brauche ich hier vermutlich mehr Performance und Langzeit-Datensicherheit, um vernünftige Analysen über die Schaltvorgänge fahren zu können.

Ansonsten:

Es läuft dann wohl tatsächlich auf mehrere autonome item-Files hinaus (Zentrale liest, Satelliten senden). Klingt nach ziemlichem (Pflege-) Aufwand allein schon für meine heutigen paar hundert KWL-Items - da muss ich mir was überlegen, das das automatisiert ...

/tom

[Sandman60]

Hi Tom,
fang bloß nicht mit mehreren Item-Files an, das endet im Chaos.
Ich habe bei mir auf jeder Maschine ein "spezielles Systemitem". Dort schreibe ich einen Status wie Test oder Prod und jede Logik (geht m.E. auch in einem Plugin) prüft ab ob es sich um Prod. handelt, ansonsten wird die Logik beendet. Erfordert halt immer die gleiche Anfangsstruktur bei den Logiken, aber mit einem Template geht das wunderbar...

Cheers,
Oliver

[Morg]

Auch wenn es knapp offtopic ist - ich habe meinem "HausPi" eine SD-Diät verordnet. Auf der Karte ist nur noch der BerryBoot-Lader; das gesamte Dateisystemimage wird per iSCSI eingebunden und der Pi läuft quasi komplett im Netz, das Image liegt auf dem NAS (Linux: iscsitarget). Dass er spürbar langsamer wäre, kann ich nicht feststellen.

Ich habe zwar nur ein sh.py laufen, bekomme aber von einem anderen Rechner per network-Plugin regelmäßig Daten ins System (und dann entweder auf den Bus oder in die Datenbank) eingespeist. Das sollte mit einem zweiten sh.py genauso gut gehen - nur eine Datensynchronisierung stelle ich mich aufgrund des Laufzeitverhaltens von sh.py ggf. etwas schwierig vor.

[Tom Bombadil]

Hi Olli,

ömmm .... das würde in meiner angedachten config ein spezielles 'eval'-item pro sync-item erfordern. (?)

<Unfug geschrieben, Rest bitte ignorieren>

/tom

[Sandman60]

Bin nun nicht in den Details Deiner Config drinnen, aber im Falle einer "Eval-Logik" dann ggf. ein weiteres Prüf-Item in die Bedingung miteinbauen (@mumpf) oder eben direkt mit einer Logik arbeiten.
Den Vorteil den ich sehe: Du kannst Änderungen einfach per Batchscript durchtransportieren, bei mir ist das ein simpler Diff-Copy. Ich hatte das mal anders, dann aber schnell den Überblick verloren wo was nachzupflegen ist und das immer via manuellem Diff. Und da Item-Änderungen ja immer einen Restart des Systems nachsichziehen tut jeder Fehlversuch weh (bei mir zumindest, Neustart des PI braucht aktuell rund 5 Minuten).
Poste doch mal ein/zwei Beispiele wo was laufen würde usw. M.E. sind das meist Denksportaufgaben die sich hier im Forum leicht und effizient lösen lassen. Andererseits führen 1000 Wege nach Rom, meiner ist zugegeben sehr am SAP-Staging und Transporting orientiert....

[Tom Bombadil]

Habe gestern noch gedanklich auf meinem oben selbst titulierten "Unfug" rumgekaut - vielleicht gehe ich ja etwas blauäugig an die Sache ran, aber sollte nicht sowas wie im Anhang skizziert funktionieren?

Ich nutze derzeit schon mehrere item-Files (z.B. sind alle Helios-items in einer Datei 'helios.conf') - das klappt zumindest auf einem einzigen System prima. Und wenn ich einzelne conf-Dateien wie im Anhang gezeigt komplett spiegeln kann, sollte sich doch der Verwaltungsaufwand in Grenzen halten, oder?

Einzige Schwachstelle sind meiner Meinung nach die Connector-Items in das jeweilige Plugin hinein - die müssten wahrscheinlich in einer separaten .conf _nur_ auf dem Raspi liegen, der die Datenerfassung für die jeweilige Anlage macht ...

Oder bin ich da auf dem Holzweg?

/tom

--> Verteilt.pdf

[knxmfbp]

Um nochmal auf den Ursprung der verteilten Datenerfassung zurückzukommen, könnte man an sich auch Mosquitto mir dem mqtt Plugin nutzen. Dies könnte Vorteile haben wenn man zusätzlich von anderen Systemen Daten empfangen/senden möchte, beispielsweise wenn man mal schnell Openhab oder FHEM testen möchte oder das einbinden von Node-RED.

[Tom Bombadil]

Das wäre natürlich ein Traum - und schwupps reden sie alle miteinander.

Gefühlt aber eine Nummer zu groß für mich allein, da zu viele Unbekannte im Spiel - ich versuche es erstmal mit einem verteilten sh.py und sniffe in der dadurch entstehenden "Freizeit" dann doch lieber wieder die RS485-Pakete meiner Anlagen.

/tom

[Sandman60]

Die Auslagerung von Maschinenspezifischen Items wäre natürlich ein Ansatz, dann könntest Du das entsprechend über ein "Transportskript" steuern, bspw. "Kopiere alle Itemfiles vom Sourcesystem und lösche dann individuell die Config-Files die nicht auf dem System laufen sollen".

Das sog. "Transportskript" liegt bei mir auf meiner Windows-Admin-Büchse und macht erst einen NET USE und kopiert dann via XCOPY (nach einem Diff-Check) die geänderten Files; mit sowas könntest Du bei Dir dann einfach noch einen zweiten Befehl nachschiessen und dann pro System das weglöschen was auf der Maschine nicht sein darf...

Ich kann Dir das bei Bedarf mal zukommen lassen falls von Interesse.

Für mich ist einfach wichtig das ich auf einem PI die Änderungen mache (bei mir mein DEV System) und dann nur noch bei Erfolg die Änderungen weitertransportiere und nicht mehrmals manuell anpassen muss...

[Tom Bombadil]

Hi Olli,

vermutlich wird es von der Implementierung der reinen "Datenconnectoren" abhängen. War mir bis heute Abend nicht sicher, ob ich auf das richtige System gesetzt habe - und bin es jetzt noch weniger. Insofern: Ich hol erstmal das neue NAS und probiere ein paar Alternativen aus ...

/tom

[manu241]

Hallo Tom,

hast du deine verteilte Datenerfassung noch zum laufen bekommen?
Wenn ja, könntest du mir deine Items zur Verfügung stellen, sodass ich mir das abgucken kann?

Gruß Manuel