Startseite Foren Group Forums RaZberry User Probleme bei einem Scondary Gateway

Ansicht von 6 Beiträgen - 1 bis 6 (von insgesamt 6)
 Udo 
Teilnehmer

Themen: 1

Antworten: 3

März 14, 2019 um 6:04 pm

Hi,
ich bin neu in diesem Forum und beschäftige mich auch erst seit kurzen mit diesem Thema.
Ich habe ca. 55 Device (Relais (Fibaro), Thermostate und Sensoren (Danfoss und Devolo) in meinem Netz. Ein Razberry kontrolliert das Netz. Weiterhin habe ich seit kurzen einen zweiten Razberry hinzu genommen (als Secondary).

Es gibt mit dem „Secondary) doch einiges zu beachten. Als Problem habe aber jetzt festgestellt, dass der Secondary neu includierte Devices nicht sofort erkennt.

Hat jemand Erfahrung mit Secondary-Controlern? Und speziell dabei mit der Inclusion von Devices?

VG Udo

 AntiTYP 
Teilnehmer

Themen: 0

Antworten: 5

März 20, 2019 um 11:02 am

Hallo Udo,

ich möchte mich dem Problem einmal anschliessen.

Auch ich betreibe ebenfalls ein Razberry mit aufgesetzen Z-Wave Modul.

Mein Z-Wave Netz umfasst ca 60 Devices.

Nun habe ich schon mehrfach einen Ausfall meiner Raspberry Speicherkarte erlebt, obwohl es sich immer um eine hochwertige Karte handelte. Natürlich kann ich eine neue Karte mit einen Backup Image beschreiben…aber hält man sich zu diesem Zeitpunkt nicht zu Haus auf, wird das schnell nervig.

Nun experimentierte ich auch schon mit einem sec. Gateway. … kam dort aber nicht wirklich weiter. Jetzt bin ich dran mit einer Z-Wave Remote Control wenigstens der Frau die Möglichkeit zu geben, bei einem Ausfall des Gateways, bestimmte Schalthandlungen durchzuführen. Aber insgesamt finde ich diese Lösung als nicht praxistauglich.

Wirke gern bei Experimenten mit.

Gruss Tino

 Udo 
Teilnehmer

Themen: 1

Antworten: 3

März 20, 2019 um 6:54 pm

Hallo Tino,
wie ich schon geschrieben habe, laufen in meinem Netz zwei Razberry: ein Primary- und ein Secondary-Gateway.
Der Unterschied der beiden ist: Auf dem Primary habe ich alle Regel, Scenen etc konfiguriert. Ausserdem besitzt er die ID 1. Der Scondary ist ohne den Regeln und Scenen. Er hat die ID 55.
Es wäre nun Wünschenswert Regeln und Scenen von dem Primary auf den Secondary zu synchronisieren ohne sie zu aktiven. Im Falle eines Ausfalls des Primary müssten sie dann aktiviert werden.
Diese Funktion müssten die Gateways unterstützen.

Es gäbe noch andere kleine Probleme: Wie sehen das die anderen Devices im Netz. Die sprechen standardmäßig erst einmal mit der ID 1 – oder?

Dann habe ich noch mein altes Problem, dass ich aber als Bug in der Software sehen: Neue Device werden im Secondary-Gateway nicht dargestellt.

Weiter komme ich zur Zeit nicht. Ich kenne auch keinen, der mir weiter helfen kann.

Gruss Udo

 AntiTYP 
Teilnehmer

Themen: 0

Antworten: 5

März 22, 2019 um 1:56 pm

Hallo Udo,

ich verfüge in etwa über ein ähnliches Szenario.

Möchte das aber noch einmal etwas unterteilen.

Nehmen wir mal einen Raspi auseinander….dort haben wir ja nun den Zwave-Controller der die Kommunikation mit den Zwave Devices unterhält. Dann haben wir den Raspi mit einer Distribution unserer Wahl um eine Software zu betreiben, die das ganze etwas KI verleiht und als Managementplattform genutzt werden kann.

Nach meinen Informationen, kann sich ein Zwave Device nur mit einem Controller unterhalten. Dagegen können Managementsysteme über das IP Protokoll gekoppelt werden.

Mein Ziel besteht nun darin einen zweiten Raspi mit Controller (R-B) bereit zu halten um den primären Raspi (R-A) gegebenfalls zu ersetzen.
Ich stelle mir das so vor… von R-A regelmässig ein Backup von Controller und Managementsystem anfertigen…dann R-A ausschalten (wichtig!) … R-B einschalten…den Controller auf R-B mit dem Backup anlernen…das Managementsystem auf R-B mit einem aktuellen Backup versorgen. Nun R-B wieder ausschalten und R-A einschalten.

Es darf dann aber immer nur einer der beiden eingeschaltet sein.
Dies könnte man auch aus der Ferne mit schaltbaren Steckdosen realisieren.
Nimmt man nun noch ein Stück NAS dazu, kann ich mir vorstellen das auch komplett zu automatisieren.

—-

Ein weitere folgende Möglichkeit konnte ich nie erfolgreich testen.
Dem Zwave Netz über die Inclusion einen zweiten Controller als statisches sekundäres Gateway hinzufügen, der dann nach meinen Infos das Z-Wave mit kennenlernt und sollte dann mit eigenen Managementsystem die Kontrolle übernehmen können.

Obige Variante gefällt mir besser weil ich das ständig hin und her schalten kann, um zu schauen ob beide Raspis das Netz steuern könnten.

Gruß Tino

 Udo 
Teilnehmer

Themen: 1

Antworten: 3

März 22, 2019 um 11:11 pm

Hallo Tino,

ich möchte mit dir deine Beschreibung (>) einmal unten besprechen (U:).

Am Freitag, 22. März 2019, 13:56:39 CET schriebst Du:

> Nehmen wir mal einen Raspi auseinander….dort haben wir ja nun den
> Zwave-Controller der die Kommunikation mit den Zwave Devices unterhält.
> Dann haben wir den Raspi mit einer Distribution unserer Wahl um eine
> Software zu betreiben, die das ganze etwas KI verleiht und als
> Managementplattform genutzt werden kann.
U: Das habe ich verstanden. Genauso habe ich das auch. Das Betriebssystem (OS) ist bei mir Debian stretch und der Controler ist Razberry.

>
> Nach meinen Informationen, kann sich ein Zwave Device nur mit einem
> Controller unterhalten.
U: Das ist glaube ich nicht ganz richtig. Der Primary kann als einziger Devices hinzufügen. Der Secondary kann aber alle Devices steuern. Mit einem Wandschalter von Z-Wave-Me habe ich ein Problem. Alle anderen Switche, Thermostate, Dimmer, etc kann ich vom Secondary problemlos ein und aus schalten, bzw. den Status erkennen. Ich sehe im Event-log alles was ich auch auf dem Primary sehe.

> Dagegen können Managementsysteme über das IP
> Protokoll gekoppelt werden.
U: Ja die sind im gleichen Netz. Bei mir haben die beide Raspberry über NFS ein gemeinsames Backup-Filesystem gemountet.

>
> Mein Ziel besteht nun darin einen zweiten Raspi mit Controller (R-B) bereit
> zu halten um den primären Raspi (R-A) gegebenfalls zu ersetzen. Ich stelle
> mir das so vor… von R-A regelmässig ein Backup von Controller und
> Managementsystem anfertigen…dann R-A ausschalten (wichtig!) … R-B
> einschalten…den Controller auf R-B mit dem Backup anlernen…das
> Managementsystem auf R-B mit einem aktuellen Backup versorgen. Nun R-B
> wieder ausschalten und R-A einschalten.
>
> Es darf dann aber immer nur einer der beiden eingeschaltet sein.
> Dies könnte man auch aus der Ferne mit schaltbaren Steckdosen realisieren.
> Nimmt man nun noch ein Stück NAS dazu, kann ich mir vorstellen das auch
> komplett zu automatisieren.
U: Ich verstehe: Das ist im Prinzip ein Activ-Passiv-Betrieb. Das war so nicht meine Idee.

Ich habe an einen Cluster-Betrieb gedacht. Der Cluster-Betrieb hat einige Vorteile. Er ist im Routing und kann z.B. aktiv in der Kommunikation beitragen. Devices, die R-A nicht direkt erreicht, könnte R-B erreichen usw. Fällt R-A aus macht R-B automatisch weiter.

Mein Vorschlag für den Activ-Passiv-Betrieb (Das ist ein uraltes Konzept aus meinem Beruf) :
1. R-A und R-B haben über ein NFS-Filesystem /opt/z-way-server gemoutet.
2. Im Normalbetrieb hat R-A den z-way-server-Dienst gestartet.

udo@zway1:~ $ systemctl status z-way-server
● z-way-server.service – LSB: RaZberry Z-Wave service
Loaded: loaded (/etc/init.d/z-way-server; generated; vendor preset:
enabled)
Active: active (exited) since Sat 2019-03-16 13:27:26 CET; 6 days ago
Docs: man:systemd-sysv-generator(8)
Process: 288 ExecStart=/etc/init.d/z-way-server start (code=exited,
status=0/SUCCESS)
CGroup: /system.slice/z-way-server.service

Auf R-B hingegen ist der Dienst gestoppt:

zway2:/home/udo# systemctl status z-way-server
● z-way-server.service – LSB: RaZberry Z-Wave service
Loaded: loaded (/etc/init.d/z-way-server; generated; vendor preset:
enabled)
Active: inactive (dead) since Fri 2019-03-22 16:48:58 CET; 8s ago
Docs: man:systemd-sysv-generator(8)
Process: 30931 ExecStop=/etc/init.d/z-way-server stop (code=exited,
status=0/SUCCESS)
Process: 288 ExecStart=/etc/init.d/z-way-server start (code=exited,
status=0/SUCCESS)

Mär 16 13:27:25 zway2 systemd[1]: Starting LSB: RaZberry Z-Wave service…
Mär 16 13:27:26 zway2 z-way-server[288]: Starting z-way-server: done.
Mär 16 13:27:26 zway2 systemd[1]: Started LSB: RaZberry Z-Wave service.
Mär 22 16:48:58 zway2 systemd[1]: Stopping LSB: RaZberry Z-Wave service…
Mär 22 16:48:58 zway2 z-way-server[30931]: Stopping z-way-server: done.
Mär 22 16:48:58 zway2 systemd[1]: Stopped LSB: RaZberry Z-Wave service.

Da beide das gleiche Filesystem gemountet haben, müsste das analog umschaltbar sein. Im Fehlerfall bei R-A müsste der Dienst gestoppt werden.
# root@zway1:/home/udo# systemctl stop z-way-server

und auf R-B gestartet werden:
zway2:/home/udo# systemctl start z-way-server

Das ist aber komplizierter als bedacht. Alles was sich der Razberry-Controler gemerkt hat (Routing-Tabelle etc.) steht nicht auf dem NFS-Filesystem.


>
> —-
>
> Ein weitere folgende Möglichkeit konnte ich nie erfolgreich testen.
> Dem Zwave Netz über die Inclusion einen zweiten Controller als statisches
> sekundäres Gateway hinzufügen, der dann nach meinen Infos das Z-Wave mit
> kennenlernt und sollte dann mit eigenen Managementsystem die Kontrolle
> übernehmen können.
>
U: Das habe ich erfolgreich gemacht. Auch das Interview der beiden
untereinander funktioniert jeder Zeit außergewöhnlich gut.


> Obige Variante gefällt mir besser weil ich das ständig hin und her schalten
> kann, um zu schauen ob beide Raspis das Netz steuern könnten.
U: Das ist im Cluster noch eleganter, denn da sehe ich z.B. auf R-B was R-A
macht.

Ich habe nur ein Problem: Wenn R-A ein neues Device includiert dann wirden das auf R-B nicht dargestellt. Im Routing sieht man aber, dass R-B den Kontakt zum neuen Device sogar direkt gefunden hat.

Ich möchte mein Cluster Konzept noch nicht „platt“ machen, wenn ich nicht sicher bin, dass ich hier auf dem „Holzweg“ bin. Ansonsten würde ich bei dem Activ-Passiv-Konzept den beiden Servern ein gemeinsames NFS-Filesystem geben und die RC-Skripte optimieren. … Starten und Stoppen müssen so automatisiert werden, dass die Dienste nur abwechselnd laufen. Das kann z.B. durch eine Lock-Datei kontrolliert werden.

Gruß Udo

 AntiTYP 
Teilnehmer

Themen: 0

Antworten: 5

März 27, 2019 um 5:43 pm

Hallo Udo,

vielen Dank für die ausführliche Beschreibung deiner momentanen bzw. zukünftigen Architektur.

Ich gebe Dir in allen Punkten recht….wahrscheinlich liegt es auch daran, dass ich schon viel in meiner Zwave Landschaft testete und somit auch bei weitem keine jungfräulichen Konfigurationen fahre.

Am WE hab ich mich ein wenig damit beschäftigt… mit Zwang weil ich auch wiederholt Probleme mit meinem primären Controller beheben musste.

Ich fahre in meinem Zwave Netz einen sekundären Controller, mit dem ich auch mindestens ein Device über die Expert Oberfläche schalten konnte… wie du auch schon richtig erwähntest.

Nachdem ich nun den primären Controller spannungsfrei stellte, wollte ich dem sekundären Controller das Zepter überreichen. Dies gelang mir aber nicht, da für den „Controller Change“ Vorgang der PrCo (primäre Controller) notwendig ist.
Ein .zbk Update einspielen war mein nächster Gedanke…dafür war es aber notwendig, den SeCo auf Werkseinstellungen zurückzusetzen und danach das zbk einzuspielen.
Was im Grossen und Ganzen funktionierte, nur leider fehlen mir vereinzelte Devices. Momentan suche ich nach einer Lösung, diese, dem Controller bekannt zu machen. Ich nehme an, das diese vermissten Devices kein vollständiges Interview mit dem eigentlichen PrCo ablegten.

Grundsätzlich gefällt mir deine Idee mit dem Cluster sehr gut.
Ich kann mir auch vorstellen das R-B den z-way-server Status von R-A überwachen kann und bei Bedarf den eigenen z-way-server startet
Ich experimentierte damit auch schon ein wenig, bekam nur des öfteren Fehlermeldungen, nachdem ich das /opt/z-way-server Verzeichnis bewegte…Meldungen aller „update data“ oder „load data“.
(kann aber auch viele andere Ursachen haben)

Auch in meiner momentanen Situation konnte ich dem SeCo nicht einfach das Verzeichnis geben, sondern musste z-way neu aufsetzen und dann eine .zab einspielen.

Die Frage ist, wenn in deinem Cluster, nach Inclusion oder Exclusion von Devices, ein Controller Change durchgeführt wird…. ob es so den SeCo auch mit den neuen Devices, neuen Konfigurationen, neuen Routen und eventuell neuen Interviews versorgen kann, dies könnte eventuell über die API einmal nachts durchgeführt werden.

Gruss Tino

Ansicht von 6 Beiträgen - 1 bis 6 (von insgesamt 6)

Du musst angemeldet sein, um auf dieses Thema antworten zu können.