Regelmäßiges neighborUpdate

[rudolfkoenig]

Warum werden eigentlich die mehrfachen Log Einträge überhaupt erzeugt? Ich habe nämlich bei den Geräten "event-on-change-reading .*" eingestellt.

event-on-change-reading ist kompliziert. Fuer eine sinvolle Antwort brauche ich die zum Geraet passenden Debugdaten, Logs und Geraetedefinitionen.

z-way scheint auch sein Spass mit dem Geraet zu haben. Ich habe nach Kommunikation mit ID 13/0D gesucht (ST.sz.HR.Heizung), und bin bei versionClassAll gelandet (Frage: 0D .. 86 13 <classId>, Antwort: 0D .. 86 14 <classId>).
- es werden 10 Fragen abgeschickt, in etwa 0.1-0.2s Abstand, fuer die Klassen 20 26 31 40 43 72 77 80 84 86
- auf die erste Frage kommt sofort eine Antwort, danach erstmal keine. z-way sendet munter weiter.
- 3 Sekunden spaeter kommen die Antworten fuer die Klassen: 20 26 31 40 40 43 40 40 40.
- eine Minute spaeter versucht z-way nochmal, mit vergleichbar lustigen Ergebnis.

Noch unerklaerbar fuer mich:
- wieso macht z-way nach ca 0.2s weiter, obwohl keine Antwort auf die Frage kommt.
- wer Puffert 3s lang die Fragen oder die Antworten

Ich sehe nur den Einsatz eines ZWCULs an strategischer Stelle, wenn wir die Probleme genauer verstehen wollen. Ob wir danach eine Loesung bauen koenne, ist was anderes.

[ToKa]

Ich will nicht ausschließen, dass ich am Verhalten von z-way Schuld bin. Da ich nicht wirklich weiß, wie z-way funktioniert, habe ich teilweise mehrfach auf die "buttons" z.B. SendNIF geklickt. Was man aber im Job Queue Monitor von z-way beobachten kann, ist dass jede ausgehende Nachricht mit einem eigenen, meist unterschiedlichen Timer versehen ist. Erst nach Erhalt der Antwort oder Ablauf des Timers wird die Nachricht aus der Queue gelöscht.

Habe mal zum weitern Testen all event-on* attribute entfernt und habe gefühlt weniger Mehrfacheinträge im Log. Könnte das auf ein Timingproblem hindeuten, ich habe bei den beiden vorwiegend betroffenen Geräten auch immer mal wieder extrem schwankende, hohe TimeToACK Werte? Kann man TimeToACK ins Filelog mitprotokollieren lassen (hab es bislang nicht hinbekommen)?

Ich weiß für eine Analyse benötigt Ihr ein verbose 5 log. Wenn allerdings nur ich das Problem habe, will ich nicht länger Eure Zeit in Anspruch nehmen. Ansonsten investiere ich auch gerne noch Zeit. Wenn ein ZWCUL keine Rieseninvestition bedeutet und Ihr mir sagt, was ich machen muss, gerne auch das.

Beste Grüße
Torsten

[rudolfkoenig]

Kann man TimeToACK ins Filelog mitprotokollieren lassen (hab es bislang nicht hinbekommen)?

Nur mit Bastelei, indem man per notify+trigger timetoack als Event zur Verfuegung stellt.

Wenn ein ZWCUL keine Rieseninvestition bedeutet und Ihr mir sagt, was ich machen muss, gerne auch das.

Wenn du nicht basteln willst, kostet ein CUL 50 EUR+Lieferung von busware.de
Das irgendwo an USB anschliessen, und ein FHEM ueber das ZWCUL Modul darauf zugreifen lassen. Wenn man bei der ZWCUL Definition homeId 00000000 setzt, dann werden alle ZWave Funknachrichten protokolliert, aber das CUL antwortet nie. Da das CUL nur auf einer der drei moeglichen Datenraten (9.6k, 40k, 100k) eingestellt werden kann, ein ZWave-Chips aber auf allen 3, muss man rausfinden, was bei dir verwendet wird. Neue Chips versuchen 100k, aeltere koennen nur 40k. 9.6k wird mWn nur noch bei NIF-Senden verwendet.
Das CUL kann man spaeter auch fuer andere Sachen verwenden.

[ToKa]

Hallo zusammen,

naja 50€ ist nicht gerade wenig... Mein Controller und die Geräte geben mit nodeinfo maxBaud 40k und die zwavplus Geräte zusätzlich noch SpeedExt:100k an. Wenn ich routeFor ausgeben lasse, tauchen verschiedene Geschwindigkeiten 9.6k, 40k und 100k zwischen den Geräten auf.

Habe mal nach "zwave duplicate messages" gegooglet und siehe da, das Problem kommt nicht nur bei mir bzw. mit FHEM vor, aber immer in Kombination mit RPi 

https://github.com/openhab/openhab1-addons/issues/1564
https://github.com/openhab/openhab1-addons/wiki/Z-Wave-Binding

Code Auswählen Erweitern

Known Issues

ARM Compatibility issue (fixed - updated Dec. 11, 2016 see below): There seems to be an issue with the binding running on the latest oracle VM Beta, on ARM based architectures (e.g. raspberry PI). It manifests itself as messages being received multiple times and causes considerable problems with the operation of the binding. In large networks, the queue can get extremely long, which can delay initialisation considerably and cause potentially long delays in sending messages. Some time has been spent investigating this issue and a solution has not been found - the issue doesn't appear to be with the binding itself as the problem doesn't manifest itself on an other platform. If anyone with the hardware and programming experience can help with this it would be useful (add information to https://github.com/openhab/openhab/issues/1564).

(Update Dec. 11, 2016): This issue is no longer affecting "all" ARM processors. The above issue report has been closed as the problem has vanished in newer Java JRE versions.
I recently built a successful setup with no duplication problems with these versions of software and hardware:
Raspberry Pi 3 (ARM v7l) Aeon Zstick Gen5 Raspbian - November 2016 - Kernel 4.4 Openhab 1.8.3 Z-wave binding version 1.8.3 Java Runtime SE: build 1.8.0_65-b17

The original issue (1564) has been closed and the symptoms have vanished since an update to Java JRE's serial library that is now standard in the new versions of Raspbian. I have not tested with original Raspberry pi (ARM v5) nor a Raspberry pi 2 (ARM v6). Assuming it was fixed in Java those should work now too. But maybe it is only fixed based on Raspberry pi 3 being ARM v7l.

You should no longer fear using OpenHAB with raspberry pi 3 and Z-wave! For my install it is very successful and zero errors.

Unter Openhab scheint das Problem gelöst zu sein.

Beste Grüße und ein schönes Wochenende
Torsten

[rudolfkoenig]

Wenn ich den Text richtig deute, handelt es sich um ein JRE Bug auf ARM. Ich gehe davon aus, dass bei dem perl Interpreter dieses Problem nicht besteht. Du kannst natuerlich einen anderen Perl-Interpreter versuchen, oder (z.Bsp. mit strace) die Hypothese direkt beweisen.

Unter Openhab scheint das Problem gelöst zu sein.

Kannst du das auch fuer deinen Fall testen? Wuerde mich wirklich interessieren.

[ToKa]

Das war keine gute Idee oder ich habe mich zu blöd angestellt. Habe mir die Nacht um die Ohren geschlagen und versucht die perl Version (5.20) zu aktualisieren. Auf der raspbian Seite gibt es eine 5.24, aber die lässt sich auf Grund der Abhängigkeiten nicht installieren. Der Versuch mit cpan auf 5.24 zu aktualisieren funktionierte zwar, aber danach war im FHEM der ZWAVE Dongle nicht mehr ansprechbar.

Habe dann alles mühsam zurück "gedreht" und auch mit der 5.20 war dann der Dongel erst mal nicht ansprechbar. In der fhem.cfg war er weg... Erst nach dem Einspielen einer Sicherung von fhem.cfg lief dann wieder alles. Jetzt weiß ich natürlich nicht, ob es auch mit der 5.24 gegangen wäre, wenn ich die Sicherung der cfg eingespielt hätte. Durch die Aktualisierung mit cpan sind jetzt auch die meisten perl Module auf dem aktuellsten Stand. Am Verhalten der Kommunikation und der mehrfachen Antworten hat sich leider nichts geändert. An OpenHab wage ich mich jetzt erst gar nicht ran, da würde ich bei Null anfangen.

Im Beitrag https://forum.fhem.de/index.php/topic,64973.msg576709.html#msg576709 sind im log ja auch mehrfache Antworten enthalten. Haben die Fälle miteinander zu tun?

Gruß
Torsten