get ... config... -> Timeout

[toms01]

@Toms01: Stick mal stromlos gemacht? Beim neigbourUpdate die Entfernung zum Controller schrittweise erhöht? Betrifft das nur Fernbedienung und Motionsensor? Gibt es noch mehr batteriebetriebene Devices?

Hallo Krikan,
ich habe das System neu gebootet, mit und ohne Stick. Den Stick komplett stromlos zu machen ist glaube ich nicht möglich, da er einen Akku verbaut hat um damit
komfortabel im Haus Geräte anlernen/ablernen zu können.

Zusatz:
Klar, habe ich gemacht - schrittweise den Abstand erhöht und Neighbor-update gemacht - keine Änderung

[toms01]

@Rudi:
Kleiner Schönheitsfehler in 10_ZWave.pm; denke den hast Du nicht gesehen, da er im Edit kam:

Als reinen Schönheitsfehler hatte ich das nicht angesehen, eher als Funktionsfehler.
"0C" wird wohl dann als 0 angesehen und es werden keine Assoziationen abgefragt.
Für Neulinge vielleicht ein Problem, die nicht alle Werte manuell abfragen.

[krikan]

Den Stick komplett stromlos zu machen ist glaube ich nicht möglich, da er einen Akku verbaut hat.

Genau deshalb ist mir das Ding sehr suspekt.

um damit
komfortabel im Haus Geräte anlernen/ablernen zu können.

Eben dadurch sind doch falsche Routen vorprogrammiert. (3 Repeater ist auch schon heftig.)

Jetzt mal produktiv:
Welche Route hast Du denn aktuell in der neigbourList der Problemdevices stehen und was soll da rein (bzw. war bei funktionierend drin)? Ich bräuchte das jeweils als NodeIds. Wenn ich es dann im Laufe der Woche schaffe, grübel und bastel ich etwas.
Hast Du mal nach Firmwareupdates des Controllers geschaut?

Schönheitsfehler hatte ich das nicht angesehen, eher als Funktionsfehler.

Man kann immer noch die einzelnen Assoziationen abfragen. Und ich persönlich halte es nicht für größeres Problem und freue mich, wenn das jemand in seiner Freizeit anschaut und ggfs. ändert....

[toms01]

Genau deshalb ist mir das Ding sehr suspekt.Eben dadurch sind doch falsche Routen vorprogrammiert.
Hast Du mal nach Firmwareupdates des Controllers geschaut?

Mal abgesehen von dem Stromlos-Reset habe ich darüber andere Ansichten. Ich inkludiere einfach Geräte vorort mit dem Stick, die Nachbar-Nodes werden dann ja richtig erzeugt,
dann createnode und neighbor-update. In der Theorie sollte das dann ja gleich sein.
Von diesem Stick ist mir bisher nichts schlechtes/ungewöhnliches bekannt und (vielleicht auch deshalb) habe ich kein Firmware-Update gefunden.

Welche Route hast Du denn aktuell in der neigbourList der Problemdevices stehen und was soll da rein (bzw. war bei funktionierend drin)? Ich bräuchte das jeweils als NodeIds. Wenn ich es dann im Laufe der Woche schaffe, grübel und bastel ich etwas.

Vielen Dank für dein Angebot. Kann ich im Laufe der Woche mal erstellen. Allerdings habe ich nicht mehr die Alt-Nodelists. Ich weiss allerdings mit Sicherheit, dass da vorher die Controller-ID mit drin war.

Man kann immer noch die einzelnen Assoziationen abfragen. Und ich persönlich halte es nicht für größeres Problem und freue mich, wenn das jemand in seiner Freizeit anschaut und ggfs. ändert....

OT: Ich bin selbst Maintainer von einem OS-Projekt und freue mich eher über solche gemeldeten Funktionsfehler im Detail.
Unangenehmer finde ich immer die Aussage "funktioniert nicht" und man fängt dann immer von vorn an zu suchen.
Leider bin ich momentan nicht sehr nah an Perl - hätte dann womöglich ein diff gesendet. Vielleicht beim nächsten Mal.

[A.Harrenberg]

Hi Christian,

Bei mir aber wohl immer noch. Nicht bei allen, aber bei ungefähr der Hälfte. Mit einem Gerät habe ich neigborUpdate getestet und dort taucht Controller wieder auf. Hat aber nur Controller als neigbour.

ok, ich hätte jetzt gedacht das es allgemein so ist, aber das ist dann ja ein schlagkräfitges Argument dagegen 
Also da meine Testgeräte alle in einem Umkreis <1m voneinander, bzw. vom Dongle weg sind sollte die sich alle gegenseitig sehen. Keines meiner Geräte zeigt da was an, wobei ich das WakeUp-RFID-Pad noch mal testen muss.

Bestimmt, aber muss ich suchen und dauert. Ich bleibe aber dabei, dass der abgesetzte Befehl zum neigbourUpdate und neighbourList mMn gleich geblieben ist.Ja.

Das hat sich ja jetzt eigentlich erledigt da einige Deiner Geräte den Controller noch melden. Würde also keine neuen Erkenntnisse bringen.

neigborUpdate geht an Geräte. NO_ACK ist richtig, wenn Dein Device nicht antwortet.
neigborList nur an Dongle.

Das muss ich mir noch mal anschauen, ich habe da gestern nur kurz draufgeschaut und ich war der Meinung das da ein Controllerbefehl an das Dongle geschickt wird und der Dongle dann eine spezielle Nachricht an die Node.
Das mit dem NO_ACK habe ich ja nicht verstanden, daher dachte ich das es ein Controllerbefehl sei.

Hast Du vielleicht ein Log von Deinem erfolgreichen neigborUpdate?

Gruß,
Andreas.

[krikan]

Das muss ich mir noch mal anschauen, ich habe da gestern nur kurz draufgeschaut und ich war der Meinung das da ein Controllerbefehl an das Dongle geschickt wird und der Dongle dann eine spezielle Nachricht an die Node.
Das mit dem NO_ACK habe ich ja nicht verstanden, daher dachte ich das es ein Controllerbefehl sei.

Bin mir jetzt auch nicht mehr sicher, ob wir aneinander vorbeischreiben und Du nicht Recht hast!? Habe aber gerade keine längere Zeit zum Grübeln...

Hast Du vielleicht ein Log von Deinem erfolgreichen neigborUpdate?

Ja, auf die Schnelle:

Code Auswählen Erweitern

2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.23 22:47:54 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480122
2015.11.23 22:47:54 5: SW: 06
2015.11.23 22:47:54 5: ZWDongle_0 dispatch 00480122
2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done

[rudolfkoenig]

Kleiner Schönheitsfehler in 10_ZWave.pm

Habs gefixt.

"0C" wird wohl dann als 0 angesehen und es werden keine Assoziationen abgefragt.

Es werden nur die Gruppen mit ID >= 10 nicht abgefragt. Hast du diese auch konfiguriert?

neighborList: mein zme meldet sich selbst nicht in der Liste, der "alte" Goodway schon. Kann natuerlich auch an den jeweils assoziierten Geraete liegen. In beiden Faellen habe ich die aktuellen FHEM-Module verwendet. Die erwaehnten Aenderugen duerften an einem "Verschwinden" keine Auswirkung haben, da sie "nur" die Nummer vor der Ausgabe nach Text konvertieren.

[krikan]

neighborList: mein zme meldet sich selbst nicht in der Liste, der "alte" Goodway schon.

Überdenkenswerte Angabe. Ich habe mit einem 400er Chipsatz Stick probiert, bei dem tlw. mit gemeldet wird. Alle anderen hier Vertretenen nutzen mWn Sticks/Razberry mit 500er Chipsatz.

[toms01]

Es werden nur die Gruppen mit ID >= 10 nicht abgefragt. Hast du diese auch konfiguriert?

Vielen Dank fürs ändern!
Könnte sein, dass ich bei der genannten FB nach deiner Anleitung vorgegangen bin, also per mca.
Dann würde das dort nicht auftauchen, oder?


Hab noch folgende Anfängerfrage: Bei anderen Projekten lese ich immer von Network-Healing o.ä. - wird wohl meist über Nacht angeworfen.
Passiert da noch mehr als ein Nodelist-Update?

[rudolfkoenig]

Könnte sein, dass ich bei der genannten FB nach deiner Anleitung vorgegangen bin, also per mca.

mca (MULTI_CHANNEL_ASSOCIATION) und associationGroup (ASSOCIATION) sind unterschiedliche Klassen, und damit auch unterschiedliche Daten.

[toms01]

ok danke, hatte aber zumindest den Controller mit drin aber keine Assoziation zurückbekommen. Aber nun denn. Vielleicht hat ein Aufruf nicht gereicht.
Ist aber auch nicht so wichtig - mein Problem liegt momenten ganz woanders, vielleicht hängt ja alles damit zusammen. Ich bin gespannt ob eine sog. Healing-Funktion (ich teste mal OpenHAB über Nacht) am Stick die Funktionalität in FHEM zurückbringt. Vielleicht erstmal besser als alle Nodes neu zu assoziieren.

[krikan]

ok danke, hatte aber zumindest den Controller mit drin aber keine Assoziation zurückbekommen. Aber nun denn. Vielleicht hat ein Aufruf nicht gereicht.

Heißt das, dass die Geräte und Dongle nicht assoziert sind?

Ich bin gespannt ob eine sog. Healing-Funktion (ich teste mal OpenHAB über Nacht) am Stick die Funktionalität in FHEM zurückbringt.

Wenn es dort ausführliche Logs gibt, nehme ich die gerne. 

[A.Harrenberg]

Hi Christian,

anscheinend ist meine erste Antwort im Nirvana verschwunden, daher noch mal...

Code Auswählen Erweitern

2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.23 22:47:54 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480122
2015.11.23 22:47:54 5: SW: 06
2015.11.23 22:47:54 5: ZWDongle_0 dispatch 00480122
2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done

So sieht das bei mir prinzipiell auch aus, aber NACH dem "ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done" kam bei mir noch ein NO_ACK hinterher...

Ich habe den Rest der Woche nicht mehr viel Zeit werde das aber noch mal machen und das Log posten.

Gruß,
Andreas.

[krikan]

Hallo Andreas,
meinst Du "10s NO_ACK"? Habe ich hier nicht kontrolliert; könnte also existieren.
Ich suche mal den Thread mit der Umstellung von neigborUpdate bei WakeUp-Geräten auf Wakeup-Sendstack; vielleicht liefert der Infos.
Gruß, Christian

[A.Harrenberg]

Hi Christian,

meinst Du "10s NO_ACK"? Habe ich hier nicht kontrolliert; könnte also existieren.
Ich suche mal den Thread mit der Umstellung von neigborUpdate bei WakeUp-Geräten auf Wakeup-Sendstack; vielleicht liefert der Infos.

hmm, ich meine das da nichts von 10 sekunden drin war, irgendwie war das auch "komisch", das ganze hat mich ja dazu gebracht das dies ein Controller-Befehl ist. Ich kann versuchen das heute abend schnell rauszusuchen und zu posten, habe aber nachher nicht viel Zeit.

Gruß,
Andreas.