Probleme mit Z-Wave Polling

Polling heisst, dass Du den Aktor von IPS aus aktiv fragst (anpollst) wie denn sein momentaner Status ist. Das brauchts Du dann, wenn Du einen Aktor von Hand bedienst (z.B. am Schalter den Rollo runterfährst) und Du möchtest, dass IPS auch den momentanen Zustand (runter) mitkriegt.

Sonst hast Du unschöne Effekte, dass z.B. IPS denkt der Rollo ist oben, in wirklichkeit ist er aber unten. (=alles durcheinander)

Pollen geht in einem Skript, welches Du zyklisch aufrsufst z.B. so:


<?
$id1 = 29341 /*[Rollos\Bad OG\Z-Wave Rollo Bad OG (NodeID 19)]*/;
$id2 = 50904 /*[Rollos\Bad UG\Z-Wave Rollo Bad UG (NodeID 003)]*/;
$id3 = 20648 /*[Rollos\Gaeste UG\Z-Wave Rollo Gaestezimmer UG (NodeID 004)]*/;
$id4 = 21831 /*[Rollos\Hauswirtschaftsraum EG\Z-Wave Rollo Hauswirtschaftsraum EG (NodeID 005)]*/;
$id5 = 49345 /*[Rollos\Kind UG\Z-Wave Rollo Kind UG (NodeID 002)]*/;
$id6 = 10363 /*[Rollos\Kueche Fenster EG\Z-Wave Rollo Kueche Fenster EG (NodeID 006)]*/;
$id7 = 45630 /*[Rollos\Kueche Terasse EG\Z-Wave Rollo Kueche Terasse EG (NodeID 007)]*/;
$id8 = 29002 /*[Rollos\Schlafzimmer OG\Z-Wave Schlafzimmer OG (NodeID 013)]*/;
$id9 = 31948 /*[Rollos\Wohnzimmer Balkon 1 EG\Z-Wave Rollo Wohnzimmer Balkon 1 EG (NodeID 010)]*/;
$id10 = 14867 /*[Rollos\Wohnzimmer Balkon 2 EG\Z-Wave Rollo Wohnzimmer Balkon 2 EG (NodeID 011)]*/;
$id11 = 10482 /*[Rollos\Wohnzimmer Terasse 1 EG\Z-Wave Rollo Wohnzimmer Terasse 1 (NodeID 008)]*/;
$id12 = 17823 /*[Rollos\Wohnzimmer Terasse 2 EG\Z-Wave Rollo Wohnzimmer Terasse 2 EG (NodeID 009)]*/;
$id13 = 49566 /*[Licht\Z-Wave Licht Treppe Aussen (NodeID 014)]*/;
$id14 = 52055 /*[Garten\Z-Wave Mauerlicht (NodeID 015)]*/;

$id1_status = ZW_requeststatus($id1);
ips_sleep(50);
$id2_status = ZW_requeststatus($id2);
ips_sleep(50);
$id3_status = ZW_requeststatus($id3);
ips_sleep(50);
$id4_status = ZW_requeststatus($id4);
ips_sleep(50);
$id5_status = ZW_requeststatus($id5);
ips_sleep(50);
$id6_status = ZW_requeststatus($id6);
ips_sleep(50);
$id7_status = ZW_requeststatus($id7);
ips_sleep(50);
$id8_status = ZW_requeststatus($id8);
ips_sleep(50);
$id9_status = ZW_requeststatus($id9);
ips_sleep(50);
$id10_status = ZW_requeststatus($id10);
ips_sleep(50);
$id11_status = ZW_requeststatus($id11);
ips_sleep(50);
$id12_status = ZW_requeststatus($id12);
ips_sleep(50);
$id13_status = ZW_requeststatus($id13);
ips_sleep(50);
$id14_status = ZW_requeststatus($id14);
?>

Wenn Du im Skripteditor STRG-Leer drückst, kommt die Liste der Befehle. Z-Wave fangen alle mit ZW_ an.

@Horst: Sieht dann aus wie im attachment. Mist, passiert auch mit der 2.1

Ich muss nur den einen Aktor pollen. Alle anderen werden über den Merten 4fach Binäreingang oder direkt über Bewegungsmelder ausgelöst.
Es gibt eine Verordnung oder ähnliches, die dafür sorgt, dass z.B. FS20 nicht permanent senden darf. Die könnte auch auf Z-Wave passen. Du könntest nochmal die Zeit zwischen dem Polling auf 200ms erhöhen. Meiner Erinnerung nach hatten wir beim Implementieren 200ms für Request-Response beim Pollen der Assoziationsgruppen als zuverlässigen Wert gefunden. Und meine Merten-FB hat immerhin 48 Gruppen, die damit durchgehen.

Das mit dem Zwang zum Pollen bei den Aktoren liegt daran, dass ein US-Hersteller ein Patent auf das Senden von Ereignissen zu Controllern über die erste Assoziationsgruppe hat. Mal wieder ein Beispiel dafür, dass das Patent-System zu trivial ist. Wenn ein Hersteller keine Patentgebühren zahlen will hat er übrigens ganz einfach die Möglichkeit die erste Gruppe leer zu lassen und die Funktionalität in die zweite Gruppe zu packen ;). Sollen z.B. neuere HomePro-Geräte machen. Auch wurden dadurch Z-Wave-Szenen entwickelt. Von denen haben wir jedoch noch kein EU-taugliches Gerät hier gehabt.

Nein, ist laut Fa Schwaiger, den Entwicklern der Düwi/Popp Geräte, sowie auch dem CTO von Tricklestar bei Z-Wave nicht implementiert.

Ok, mache ich.

Auch mit 200ms gleiches Problem.
Kannst Du mal versuchen das Problem nachzustellen.
Ich habe 17 Aktoren, die ich jede Minute einmal abpolle. Das geht dann ein paar Stunden, und dann kommt (RF) Zeitüberschreitung beim warten auf Antwort in zeile…

Das seltsame ist:

In meinem Meldungsfenster kam die Fehlermeldung genau um 08:31:16.
Im Dump der Schnittstelle sehe ich da aber nur genau ein Paket: „Wait Error“

05.08.2009 08:31:05.00 | (RF) Waiting for transmit… | 25 02
05.08.2009 08:31:05.00 | Waiting for transmit… | 13 11 02 25 02 05 11
05.08.2009 08:31:05.00 | Transmitted | 09 00 13 11 02 25 02 05 11 C5
05.08.2009 08:31:05.00 | Received OK | 09 00 13 11 02 25 02 05 11 C5
05.08.2009 08:31:05.00 | (RF) Transmitted | 25 02
05.08.2009 08:31:10.00 | (RF) Wait Error | 25 02
05.08.2009 08:31:10.00 | (RF) Waiting for transmit… | 25 02
05.08.2009 08:31:10.00 | Waiting for transmit… | 13 12 02 25 02 05 12
05.08.2009 08:31:10.00 | Transmitted | 09 00 13 12 02 25 02 05 12 C5
05.08.2009 08:31:10.00 | Received OK | 09 00 13 12 02 25 02 05 12 C5
05.08.2009 08:31:11.00 | (RF) Transmitted | 25 02
05.08.2009 08:31:11.00 | Waiting for transmit… | 05
05.08.2009 08:31:11.00 | Transmitted | 03 00 05 F9
05.08.2009 08:31:11.00 | Received OK | 03 00 05 F9
05.08.2009 08:31:16.00 | (RF) Wait Error | 25 02
05.08.2009 08:32:00.00 | (RF) Waiting for transmit… | 25 02
05.08.2009 08:32:00.00 | Waiting for transmit… | 13 13 02 25 02 05 13
05.08.2009 08:32:00.00 | Transmitted | 09 00 13 13 02 25 02 05 13 C5
05.08.2009 08:32:00.00 | Received OK | 09 00 13 13 02 25 02 05 13 C5
05.08.2009 08:32:00.00 | (RF) Transmitted | 25 02
05.08.2009 08:32:05.00 | (RF) Wait Error | 25 02
05.08.2009 08:32:05.00 | (RF) Waiting for transmit… | 25 02
05.08.2009 08:32:05.00 | Waiting for transmit… | 13 03 02 25 02 05 03
05.08.2009 08:32:05.00 | Transmitted | 09 00 13 03 02 25 02 05 03 C5
05.08.2009 08:32:05.00 | Received OK | 09 00 13 03 02 25 02 05 03 C5
05.08.2009 08:32:05.00 | (RF) Transmitted | 25 02

Ich habe aber auch vorher einige Wait Errors. Woher die kommen ? Keine Ahnung.

Ein IPS restart hilft nichts. Nach restart kann ich auch keinen Aktor mehr fahren, hier um 08:37:47:

05.08.2009 08:37:08.00 | (RF) Waiting for transmit… | 26 01 00
05.08.2009 08:37:08.00 | Waiting for transmit… | 13 02 03 26 01 00 05 02
05.08.2009 08:37:08.00 | Transmitted | 0A 00 13 02 03 26 01 00 05 02 C7
05.08.2009 08:37:08.00 | Received OK | 0A 00 13 02 03 26 01 00 05 02 C7
05.08.2009 08:37:08.00 | (RF) Transmitted | 26 01 00
05.08.2009 08:37:13.00 | (RF) Wait Error | 26 01 00
05.08.2009 08:37:14.00 | Waiting for transmit… | 05
05.08.2009 08:37:14.00 | Transmitted | 03 00 05 F9
05.08.2009 08:37:14.00 | Received OK | 03 00 05 F9
05.08.2009 08:37:47.00 | (RF) Waiting for transmit… | 26 01 00
05.08.2009 08:37:47.00 | Waiting for transmit… | 13 02 03 26 01 00 05 02
05.08.2009 08:37:47.00 | Transmitted | 0A 00 13 02 03 26 01 00 05 02 C7
05.08.2009 08:37:47.00 | Received OK | 0A 00 13 02 03 26 01 00 05 02 C7
05.08.2009 08:37:47.00 | (RF) Transmitted | 26 01 00
05.08.2009 08:37:52.00 | (RF) Wait Error | 26 01 00

Für mich als Laien sieht es so als ob er 0A 00 13 02 03 26 01 00 05 02 C7 und empfängt, das 26 01 00 (ACK?) scheint irgendwo zu hängen?

Und so siehts dann aus, nachdem ich den Tricklestart abgezogen und wieder angesteckt habe:
05.08.2009 08:42:45.00 | (RF) Waiting for transmit… | 26 01 63
05.08.2009 08:42:45.00 | Waiting for transmit… | 13 04 03 26 01 63 05 04
05.08.2009 08:42:45.00 | Transmitted | 0A 00 13 04 03 26 01 63 05 04 A4
05.08.2009 08:42:45.00 | Received OK | 0A 00 13 04 03 26 01 63 05 04 A4
05.08.2009 08:42:45.00 | (RF) Transmitted | 26 01 63
05.08.2009 08:42:45.00 | (RF) Received OK | 26 01 63

Jetzt wirds interessant:
Habe jetzt IPS_Sleep(5000) gesetzt und das Skript alle 5 Minuten ausgeführt.
Bei 5 Sekunden Sleep, 5 Sekunden Zeit für Ausführen des Befehls und 14 Aktoren ergibt sich eine Laufzeit des Skriptes von circa 2,3 Minuten.

Also eigentlich genug Zeit, damit das skript in Ruhe durchlaufen kann.
Trotzdem waren jetzt nach schon 60 Minuten meine Aktoren nicht erreichbar und nicht nach mehreren Stunden wie bei IPS_Sleep (200).

Ich musste dann im Anschluß NICHT! den USB dongle ausstecken, sondern nach einem restart von IPS gings wieder. Irgendwie scheint es doch mit IPS zusammenzuhängen.

@Horst: Kannst Du nicht das mal nachstellen, abpollen von 14 Aktoren (alle ausser 3 geroutet) über mehrere Stunden?

Ich kann Dir nur 4 Aktoren ohne Routing bieten. Geroutet werden bei mir in der derzeitigen Konstellation nur ein paar Bewegungsmelder, aber die kann ich nicht abfragen. Polling läuft jetzt jedenfalls bei mir.

Ok, ich habe jetzt mal mein Skript so umgestellt, dass es jede Minute nur die 3 direkt vom Kontroller erreichbaren Aktoren abpollt. Jeweils mit 200ms Pause dazwischen.

Welches Intervall/Pause nutzt Du?

IPS_Sleep(5000) mit Ausführung alle 5 Minuten. Wie von Dir als besonders problematisch beschrieben. Bisher keine Probleme.

Nach 16 Stunden beim abbpollen meiner 3 direkt ansprechbaren Aktoren -> nix geht mehr.

Welche SW Version hat Dein Tricklestar Dongle?

Keine Ahnung. Wie bekomme ich das raus?
Benutze übrigens Windows Server 2008 Standard.

Ich denke IPS -> Splitter -> Z-Wave gateway -> Version. Bei mir ists z-wave 2.48 wobei das 2.48 glaube ich der SW Stand ist. Ich bin auf W2003R2 Server.

Welche CPU/Mainboard Kombi hast Du?

Bei obigem Versuch war mein Tricklestar komplett blockiert. Selbst ein reboot des Servers hat ihn nicht dazu bewegt wieder zu senden. Ich glaube fast, dass entweder die firmware defekt ist oder ich evtl. einen defekten Stick habe.
Du nutzt auch Tricklestar? Gibts noch andere von Euch getestete Gateways?

Da habe ich auch die 2.48.
Mein Server ist mein altes HP Compaq nc4200 Subnotebook. Daran hängt ein aktiver No-Name-USB-Hub ohne Netzteil und darin steckt der Tricklestick.
Getestet haben wir noch das Homepro ZCU201 Z-Wave USB-Interface. Das hat aber seine Unzulänglichkeiten. Eine Übersicht an Interfaces mit Hardware-Kritik findet man unter Z-Wave - LinuxMCE wiki. An sich sollte IPS mit allen Interfaces arbeiten, da Z-Wave schließlich genormt ist. Aber ich würde mich da jetzt nicht drauf verlassen wollen.

Komplett ratlos. Ich versuch jetzt mal noch 2 Sachen:

  1. Z-Wave USB stick über einen USB over Ethernet Extender mehr in die Mitte des Hauses

  2. Den Act Homepro 201, der kostet nicht die Welt und mal sehen, ob mit dem die gleichen Probs kommen.

Den Homepro würde ich nicht kaufen. Ich kann mich nicht mehr genau erinnern, was wir an ihm nicht mochten, aber es hat uns zum Kauf des Tricklestar-Sticks gebracht. Mit der seriellen Version sollten die Probleme allerdings nicht auftreten.

Naja, 60 Euronen und um zumindest den Fehler einzugrenzen…
Heute Morgen ist mein Network USB Hub gekommen. Sollte mein Mainboard I/O das Problem sein, dann müsste es danach ja funktionieren.

So, LAN USB Extender dazwischen. Alle 18 Aktoren nach jeweils 1 Minuten abgepollt. Nach 90 mins war Schluss. Mainboard/CPU ist es schon mal nicht.

Funktioniert der HS noch, wenn IPS nicht mehr geht? (jetzt mit dem USB Extender)

Wenn nein, reicht es das System neu zu starten oder musst du den Stick am USB Extender raus- und reinstecken?

paresy

Nein: „Faild to send to Device xyz“

Muss den Stick powercyceln. Meinst Du mein Stick hat einen Knacks?
Komisch ist, heute lief es problemlos die ganze Nacht. Nachdem ich dann 10 Minuten wach war und meinen panel PC mit Dashboard in der Küche angechaltet habe waren dann die Fehler da.

Das einzige was sonst noch nebenher lief war eine installation einer Virtuellen Maschine in VM, die war aber (wenn auch auf user input wartend) die ganze Nacht aktiv.

Komisch ist, heute lief es problemlos die ganze Nacht.

Kannst du das mal länger ausprobieren? (Quasi ohne Konsole/Dashboard) In Anlehnung an diesen Post: http://www.ip-symcon.de/forum/65447-post25.html

Denn ich weiß nicht so Recht, warum IPS den Stick zum Abstürz bringen sollen.

paresy