ZWave UZB via Z-Way an FHEM binden

[BananaRama]

Guten Morgen Zusammen,

nachdem ich bereits Google und hier das Forum hoch und runter gesucht habe, ohne Erfolg, wollte ich mal in die Runde fragen, ob sich schonmal jemand mit folgendem Thema beschäftigt hat:

- FHEM läuft aktuell auf RPi (soll später in VM auf einem NUC laufen)
- ZWave UZB1 Stick an Z-Way Server auf RPI, um sinnvoll Backup-Mechanismus nutzen zu können
- Zugriff von FHEM auf den Stick am Z-Way Server

Genau dieses Konstrukt ist mit OpenHAB2 und Z-Way möglich.

Aktueller work around:

- ZWave UZB1 steckt in RPi und wird via ser2net über Netzwerk an den FHEM präsentiert.

Leider habe ich kein Tool für Linux gefunden, mit dem man sinnvoll den Stick sichern kann.

Die Backupfunktionalität aus FHEM heraus ist leider unbrauchbar, weil es blocking ist.

Mir geht es im wesentlichen darum die Netzwerkinformationen auf dem ZWave Stick zu sichern, um im Falle eines Ausfalls diese wieder auf einem neuen (gleichen) Stick wiederherstellen zu können.

Generell die Themen Backup/Restore und Hochverfügbarkeit scheinen im Bereich Heimautomation faktisch nicht vertreten zu sein.

Viele Grüße,
Nico

[rudolfkoenig]

Die Backupfunktionalität aus FHEM heraus ist leider unbrauchbar, weil es blocking ist.

Gewagte und unfreundliche Behauptung. Meiner Ansicht nach reicht es, wenn man jeweils nach der letzten Inklusion ein Backup erstellt. Wenn der FHEM-Server auch in diesen seltenen Faellen so lebenswichtig ist, dass es fuer eine Minute nicht blockieren darf, dann koennte man mit modify das ZWDongle auf ein nicht existierendes Geraet temporaer umbiegen, mit einem anderen FHEM den Dongle sichern, und es danach wieder zurueckbiegen.

Bedient Z-Way waehrend des Stick-Backups den restlichen ZWave Funkverkehr?

[rudolfkoenig]

Generell die Themen Backup/Restore und Hochverfügbarkeit scheinen im Bereich Heimautomation faktisch nicht vertreten zu sein.

Wg. Backup/Restore: in diesem Forum gibt es bestimmt 100+ Diskussionen ueber Backup und Restore, FHEM selbst bietet auch etwas an, auch wenn das meiner Ansicht nach nicht die Aufgabe von FHEM ist.

Hochverfuegbarkeit ist nicht ganz trivial und relativ teuer, wie es jeder weiss, der sich damit ernsthaft beschaeftigt hat. Wir bewegen uns hier in einem Umfeld, wo es den Anwendern dieses Feature den Aufwand nicht Wert ist.

Generell zeigen diese Aussagen, dass man den Text "Google und hier das Forum hoch und runter gesucht habe" nicht ernst nehmen kann.

[krikan]

Genau dieses Konstrukt ist mit OpenHAB2 und Z-Way möglich.

Mit welchem Binding?
Mit dem z-wave binding, das mit den FHEM-ZWave-Modulen vergleichbar ist, kann der Stick mWn nicht gleichzeitig von z-way und openhab angesprochen werden.
Mit dem z-way binding mag das funktionieren, dann muss man das aber auch entsprechend in FHEM einrichten und nicht die ZWave-Module nutzen.

Gruß, Christian

[BananaRama]

Gewagte und unfreundliche Behauptung.

Oh ich sehe, hier ist es genauso wie in anderen Foren: es wird sich gleich angegriffen gefühlt und man reagiert auch Emotionen.

FHEM ist geil und ich bin hoch zufrieden damit! Soviel mal dazu.

Mir ist nur aufgefallen, dass KEIN mir bekanntes Controllersystem (selbst IPSymcon nicht) wirklich gute Umsetzungen für Backup/Restore der Subsysteme (z.B. Zwave Network) mitbringt.
Mir fehlt leider die Fähigkeit gut zu programmieren und auch die Zeit, daher bin ich froh um jeden, der hier seinen Beitrag zum code leistet.

So, genug abgeschweift.

Bzgl. HA: es ist in der Tat kein einfaches Thema, aber wenn man Heimautomation als komplettes System betrachtet, ist es nach meiner Meinung nötig, da irgendwann zentrale Komponenten davon abhängig sind, die einfach funktionieren müssen, WENN man es soweit treiben möchte! Ich rede nicht davon dass Heizung schaltet, um ein paar Cent im Monat zu sparen.
Wenn Licht nicht mehr schaltbar ist, weil der Controller ausgefallen ist, dann stört das nicht nur meine Freundin, sondern auch mich selbst.

Mit welchem Binding?

Hier ist einfach beschrieben, wie die Kombination aus OpenHAB und Z-Way möglich ist
https://github.com/pathec/openhab2-addons/blob/zway-binding/addons/binding/org.openhab.binding.zway/doc/GETTING_STARTED.md
Das beide Systeme nicht gleichzeitig auf den ZWave stack zugreifen können ist logisch, aber in dem Moment, wenn Z-Way ein Backup erstellt, bekommt OpenHAB nur einen Timeout, statt für ca. 1 Minute komplett zu hängen.

Wenn ich aus FHEM heraus mit dem backup Befehl den ZWave Stick sichere, hängt der komplett Hauptprozess. Ja das kommt höchstens einmal Nachts zur regelmässigen Sicherung vor, ist aber dennoch unschön.

Ich möchte hier niemanden kritisieren, ich wollte nur erklären, was der Grund meines Anliegen ist.

Danke erstmal für die "Antworten".

Grüße,
Nico

[rudolfkoenig]

Oh ich sehe, hier ist es genauso wie in anderen Foren: es wird sich gleich angegriffen gefühlt und man reagiert auch Emotionen.

Wer mit "unbrauchbar" kommt, der sollte bei "das ist unfreundlich" nicht beleidigt sein.
Viele Leute koennen gut austeilen, haben aber Probleme bei vergleichbaren Antworten.

Wenn Licht nicht mehr schaltbar ist, weil der Controller ausgefallen ist, dann stört das nicht nur meine Freundin, sondern auch mich selbst.

Dann muss das Licht direkt schaltbar sein, ohne auf dem Controller angewiesen zu sein. Und selbst wenn der Controller ausfallsicher ist, hilft es wenig, wenn die anderen lebenswichtigen Komponenten das nicht sind. Aber selbst die Heizung ist in den seltensten Faellen ausfallsicher, und keiner Regt sich darueber auf. Mein FHEM faellt nicht haeufiger aus, als meine Heizung, ich hatte in den letzten 10 Jahren einmal einen Hardwarefehler. Deswegen Hochferfuegbarkeit einzubauen finde ich uebertrieben.

[krikan]

Hier ist einfach beschrieben, wie die Kombination aus OpenHAB und Z-Way möglich ist
https://github.com/pathec/openhab2-addons/blob/zway-binding/addons/binding/org.openhab.binding.zway/doc/GETTING_STARTED.md
Das beide Systeme nicht gleichzeitig auf den ZWave stack zugreifen können ist logisch, aber in dem Moment, wenn Z-Way ein Backup erstellt, bekommt OpenHAB nur einen Timeout, statt für ca. 1 Minute komplett zu hängen.

Das ist genau das z-way-Binding. Damit ist der z-way-Server und dessen Funktionsfähigkeit zusätzlich zu openhab notwendig. Das ist mMn gerade im Sinne von "Hochverfügbarkeit" kontraproduktiv. Man ist nicht nur von einem Server, sondern von mehreren Servern abhängig. Das kannst Du, wenn Du es für sinnvoll hältst auch mit FHEM abbilden, indem Du FHEM an die z-way-API ankoppelst und nicht die ZWave-Module nutzt. Und damit ist das Konstrukt mit FHEM genauso wie mit openhab möglich. 

Wenn ich aus FHEM heraus mit dem backup Befehl den ZWave Stick sichere, hängt der komplett Hauptprozess. Ja das kommt höchstens einmal Nachts zur regelmässigen Sicherung vor, ist aber dennoch unschön.

Wenn jemand herausfindet, wie das besser geht, kann man es ja einbauen. Bisher hat es nur niemand erforscht und ich glaube auch nicht, dass das in der ZWave-API anders vorgesehen ist. Vermute eher, dass z-wave.me eine spezielle Funktion eingebaut hat. Aber das ist Spekulation.
Letztlich genügt, wie Rudi schon schrieb, eine Sicherung nach jeder Inklusion. Darum muss man sicherlich nicht jede Nacht ein Backup des Controllers machen. Damit schafft man sich mMn unnötige Probleme.

Gruß, Christian

[BananaRama]

Das ist genau das z-way-Binding. Damit ist der z-way-Server und dessen Funktionsfähigkeit zusätzlich zu openhab notwendig. Das ist mMn gerade im Sinne von "Hochverfügbarkeit" kontraproduktiv. Man ist nicht nur von einem Server, sondern von mehreren Servern abhängig. Das kannst Du, wenn Du es für sinnvoll hältst auch mit FHEM abbilden, indem Du FHEM an die z-way-API ankoppelst und nicht die ZWave-Module nutzt. Und damit ist das Konstrukt mit FHEM genauso wie mit openhab möglich. 

Darauf wird es wohl hinauslaufen, wenn ich das so umsetzen möchte, dass ich mich mit der API auseinandersetze. Danke.

Wenn jemand herausfindet, wie das besser geht, kann man es ja einbauen. Bisher hat es nur niemand erforscht und ich glaube auch nicht, dass das in der ZWave-API anders vorgesehen ist. Vermute eher, dass z-wave.me eine spezielle Funktion eingebaut hat. Aber das ist Spekulation.
Letztlich genügt, wie Rudi schon schrieb, eine Sicherung nach jeder Inklusion. Darum muss man sicherlich nicht jede Nacht ein Backup des Controllers machen. Damit schafft man sich mMn unnötige Probleme.

Die Aussage macht mich nicht glücklich, aber ich verstehe wie andere das Thema bewerten.

Ich bin halt kein Fan von manuellem Backup, da es schnell vergessen werden kann. Alles was automatisch läuft und funktioniert, läuft einfach!

Grüße,
Nico

[krikan]

Ich bin halt kein Fan von manuellem Backup, da es schnell vergessen werden kann. Alles was automatisch läuft und funktioniert, läuft einfach!

Auch dafür gibt es Lösungen. Baue Dir ein notify, das auf die Events der Inklusion

Code Auswählen Erweitern

ZW_ADD_NODE_TO_NETWORK [learnReady|nodeFound|slave|controller| done|failed]
einige Zeit später ein (blockierendes) Backup erstellt.

Aber selbst die blockierende tägliche Datensicherung würde ich einer Kombination von 2 verschiedenen Hausautomatisierungs-Servern ("Konstrukt") vorziehen. Die Gefahr von Ausfällen vergrößert sich damit doch nur.

[gamauf]

Das angesprochene Konstrukt mit OpenHAB2 und Z-Way schaltet einfach zwei Heimautomatisierungssysteme, per HTTP verbunden, hintereinander. Das eine System kümmert sich um die (Kommunikation mit) Z-Wave Geräte(n) das andere um den Rest. Wenn wegen Backup der Z-Wave Konfiguration die Kommunikation mit Z-Wave Geräten ausfällt funktioniert der Rest trotzdem.

Das wäre natürlich auch mit FHEM möglich:
Entweder spricht FHEM via HTTP mit Z-Way, oder du baust nur auf FHEM und betreibst eine FHEM Instanz für die Z-Wave Geräte und eine zweite für den Rest...

Die Nachteile (höhere Ausfallwahrscheinlichkeit weil komplexer) hat krikan ja schon erwähnt.