Seit kurzem versuche ich zunächst testhalber ein Zwave System in IP Symcon „unterzukriegen“.
Dazu habe ich mir einen ZWave.me Stick, sowie drei AN-158 Zwischenstecker und eine AEON Multisensor gekauft.
Das Anlernen der Geräte mit dem IP Symcon(3.0) Konfigurator hat schon mal überhaupt nicht funktioniert. Ich habe zwar den Stick als Node 1 Static Controller hinbekommen, das Anlernen der anderen Komponenten endet aber immer mit „Zeitüberschreitung …“.
Also das Zensys Tool installiert, auch das meldet ab und zu einen Fehler bei der Kommunikation, aber Zwischenstecker und und Sensor ließen sich anlernen. Diese sehe ich auch jetzt in IP Symcon, der Zwischenstecker lässt sich auch schalten, allerdings sehe keine Meter Variablen. Der Sensor hat auch drei Variablen, eine Bewegung wird mir aber nicht angezeigt. Auch der Static Controller hat zwei Variablen (data (boolean), data (integer)).
Ich habe jetzt hier schon sehr viele Beiträge gelesen, aber folgende Fragen bleiben :
Ist der Zwave.me Stick überhaupt geeignet? Welche Alternative Vision oder AEON Labs ist denn zu empfehlen und läuft mit dem IP Symcon Konfigurator?
Müssen die Geräte zum Anlernen am Stick sein, oder muss das Gerät am Zielort sein, und somit auch der Stick? Dann bräuchte ich wohl auch einen Inclusion Controller (den Server will ich nicht durch die Gegende schleppen)
Wenn Inclusion Controller nötig und sinnvoll, welcher funktioniert mit IP Symcon relativ „schmerzfrei“?
Gibts vielleicht auch schon IP Gateway, dass mit IP Symcon arbeitet?
Der zwave.me Stick spielt einwandfrei !
Habe z.Zt. zwei Sticks an meinem System (aufgeteilte Zwave-Komponenten zum Testen der Timeouts).
Einrichten: Mit Laptop (z.B. Test-IPS-System) an den Schaltern gestanden und Einlernen (zwave Konfigurator).
Oder mit Z-Tool Software (auch auf dem Laptop). Die Schalter werden grundsätzlich in dem Stick verwaltet.
Wenn alles eingelesen, den Stick an dein Wirksystem und die Schalter (Sensoren und Aktoren, Sorry) in dem IPS zWave Konfigurator erstellen und konfigurieren.
Vielen Dank für die schnelle Rückmeldung. Das Hauptproblem schien wirklich die Entfernung zu sein. Durch erneutes Auslesen des AN-158 habe ich jetzt auch mehr Variablen. Er will zwar noch nicht von sich aus aktualisieren (beim Auslesen der Parameter via IP-Symcon Konsole kommt nix), das muss ich mir aber noch mal in Ruhe ansehen.
Also nochmal vielen Dank. Jetzt kann ich erst mal weiter experimentieren.
Wichtig ist, dass Du das Netz (gerade am Anfang) öfter optimierst.
Übrigens, wenn man nicht mit einem Laptop zum Gerät laufen möchte, kann man auch das Networkinclude Feature der Z-Wave Tools verwenden.
Es braucht zwar öfter mehrere Versuche ist aber komfortabler.
Wenn es jetzt diese Funktion noch in IPS geben würde.
Danke für den Hinweis.
Nochmal eine Frage zur Software. Ich bin jetzt zunächst mit dem ZwaveController (Zensys) an den Start gegangen, aber ist es die Software mit der Du arbeitest, oder ist es das Z-Tool von Homeseer?
Inzwischen ist es mir gelungen, von meinen drei AN 158 die Momentanleistung zu bekommen, auch der Aeon Multisensor liefert (dank Script) alle gewünschten Infos. Danke auch hier für die hilfreichen Hinweise.
Allerdings ist die Reichweite weiterhin eine „Katastrophe“. Das System schafft es einfach nicht, durch die Kellerdecke zu kommen, obwohl ich den Dongle schon an die Kellerdecke „geklebt“ habe und sich ein AN158 quasi direkt darüber in einer Steckdose befindet. Die Leistungsdaten kommen durch, schalten ist aber unmöglich, DEBUG sagt da immer Readerr.
Von gleicher Stelle kommen Homematitc, Projet und selbst Enocean locker bis ins EG und gut bis ins DG.
Ich fürchte, das Zwave System lebt einfach von vielen verteilten Knoten, damit wirds bei mir nicht passen, sodass ich mir eine anderer Lösung suchen werde.
Das einzige, was ich nicht gemacht habe, ist zugegebenermaßen das „vor Ort einlernen“. Der Aktor hat aber nach der Optimierung über 7-8 Meter Luftlinie funktioniert. Da nahm ich an, dann wird er auch die 80cm nach „oben“ schaffen.
Mir ist aus technischer Sicht der Bedarf des Einlernens vor Ort nicht klar. Der Stick wird ja nicht GPS Koordinaten des Aktors ermitteln und dann später seine Sendeleistung darauf einstellen. Das „vor Ort“ Einlernen kann doch nur den Sinn haben, von diesem Punkt aus zu „sehen“, ob andere Teilnehmer in Reichweite liegen, über die dann geroutet werden kann. Bei meiner sehr geringen Anzahl an Teilnehmern wird der Stick in meinem Falle „vor Ort“ also keine Alternativen finden.
Es kommen ja auch Daten „durch“ die Decke, sonst hätte ich die aktuelle Leistung ja nicht gesehen(Pakete kommen lt. Debug auch fehlerfrei durch). Aber Schalten geht eben nicht( erfordert so denke ich aus Sicherheitsgründen mehr Übertragungsinhalt) und zigfaches Optimieren hat keine Verbesserung gebracht.
Dieses Optimieren stellt sich für mich zudem ziemlich „schwammartig“ dar. Beim Node 1 (Controller) schlägt sie lt. IP-Symcon Meldungen immer fehl, bei den Aktoren geht sie manchmal gut, manchmal schlägt sie fehl, und beim Sensor schlägt sie immer fehl, es sei denn, ich drücke die ganze Zeit die Taste am Sensor. Manchmal bleibt sie auch einfach hängen, ohne das es eine Meldung gibt.
Spannend wirds auch, wenn man einen Aktor wegnimmt. Dann kommt es vor, das andere Aktoren erstmal wieder nicht erreichbar sind, und man wieder optimieren muss. Könnte ich ja verstehen, wenn der Fehlende als Router fungiert hat, aber bitte doch nicht, wenn alle Teilnehmer im Umkreis von 5 Metern vom Controller sind.
Das Routing bei Z-Wave darf man sich nicht so dynamisch vorstellen wie z.b. beim Routing von TCP Paketen.
Einen Node optimieren bedeutet er fragt über einen Broadcast wer seine Nachbarn sind.
Dazu sollte der Node natürlich wach sein. Batterienodes scheiden als Relaystation aus, da sie nur sporadisch wach sind.
Die erkannten Nachbarn wandern in eine Liste. Dann wird noch ermittelt (weiss auch nicht wie) über welchen Nachbarn Telegramme an den Controller gesendet werden.
Diese Ermittlung scheint ihre Tücken zu haben. Es kommt immer wieder vor, das der Node erst nach mehrmaligen „Optimieren“ auch den neuen Weg benutzt.
Das Anlernen vor Ort hat den Vorteil, dass bereits beim „Include“ die Nachbarn ermittelt werden.
Die leere Routingtabelle wird direkt mit den richtigen Nodes gefüllt und muss nicht nachher umgekrempelt werden.
Meiner Erfahrung nach sind die AN-158 nicht die zuverlässigsten Geräte. Auch was die Empfangsleistung angeht.
Mit den Wallplugs habe ich bessere Erfahrungen gemacht.
Deine Beschreibung deckt sich mit dem, was ich mir dachte. Da ich nicht vorhatte, komplett auf Zwave umzubauen, sondern es nur partiell zu nutzen, passt es dann wohl nicht so richtig bei mir und ich werde mich von den Teilen wieder trennen.
Naja, Versuch macht kluch.
Das ist ein gewollter Effekt, ansonsten würden leichte Schwankungen der Empfangsstärke sofort die Tabelle umschmeißen.
Als Daumenregel: 4x optimieren ohne Fehler = neue Routingtabelle.
:
