Node findet Gateway nicht

The Grue · 03 Dezember 2017, 19:30:43

Servus,

gerade bin ich dabei, das erste Gateway mit Node zu bauen, aber der Node findet das Gateway nicht. Ich habe schon im MySensorsForum geposted, aber weil ich nicht sicher bin auf welcher Seite der Fehler liegt, bitte ich Euch, mal hier vorbei zu schauen:

https://forum.mysensors.org/topic/8670/gateway-receives-brocast-but-node-fails-to-find-parent

Vielen Dank,
Markus

Ranseyer · 03 Dezember 2017, 19:43:54

Die finden nicht zusammen. Kennst Du den Logfileparser ? https://www.mysensors.org/build/parser

PS: Als ersten Sensor würde ich immer "Motion" nehmen, der braucht gar keinen Sensor und meldet dann einfach pausenlos "tripped", also ausglöst...

The Grue · 03 Dezember 2017, 19:48:38

Hallo Ranseyer,

ja, den Parser habe ich schon mit diesen Ausgaben gefüttert. Leider hilft mir das nicht bei der Suche nach der Ursache...

Mit dem Motion-Sensor wirst Du Recht haben, aber ich hätte halt gern schon was, das ich in FHEM integrieren kann - quasi schon mal sehen, daß "round-trip" vom Sensor über's Gateway in FHEM funktioniert...

Danke für Deine Anregung!
Markus

Ranseyer · 03 Dezember 2017, 19:57:53

Hm, wir könnten mal ein Beispiel posten wie es aussieht wenn der Controller (=FHEM) fehlt...
Aber in deinem Fall würde ich mal bei groben Lesen behaupten gar keine Kommunikation. Das wäre also noch vor dem Bedarf einen Controller zu haben.

Ich bin gerade auch am experimentieren. Evtl. kann ich die Tage mal 1-2 Beispiele von Problemen erzeugen...

Beta-User · 04 Dezember 2017, 09:32:01

Hallo Markus,

auf MySensors.org kam das irgendwie nicht so klar raus:

Du hast in FHEM autocreate (global oder auf das GW bezogen) eingeschaltet (Includion mode am GW war ja "on", oder verstehe ich den Post falsch)?

Ansonsten: wie weit sind GW und Node voneinander entfernt?

Gruß, Beta-User

The Grue · 09 Dezember 2017, 13:14:37

Servus zusammen,

Wochenende, endlich Zeit zum Fehlersuchen :/ Würde ja lieber Sensoren bauen...

Schon mal vielen Dank für Eure Hinweise! Im MySensors-Forum herrscht ja totales Schweigen

Also zu Euren Fragen:

Zitat
Aber in deinem Fall würde ich mal bei groben Lesen behaupten gar keine Kommunikation.

Das glaube ich nicht, weil:

Ich stecke das Gateway an USB+Ethernet
FHEM schreibt ins log: 2017.12.09 12:26:02 1: 192.168.178.3:5003 reappeared (MySensors.Gateway)
Kommunikation via Ethernet geht also schon mal (war aber, glaube ich, auch nicht was Du meintest...)
Auf ttyUSB0 sehe ich die Initialisierung des Gateways. Ich warte etwas ab, bis sich hier nichts mehr tut.
Ich schalte den Sensornode ein
Sofort tut sich was im Log des Gateways und das immer wieder, solange der Sensor eingeschaltet ist (WAS sich da tut habe ich oben schon gepostet). Also: Der Sensor sendet etwas und das Gateway empfängt auch etwas -> Kommunikation in mindestens einer Richtung

Ich vermute ganz naïv, weil ich von MySensors keine Ahnung habe: Das Gateway kommt nicht in den Inklusionsmodus. Das Gateway aus Sicht von FHEM:

Code Auswählen

defmod MySensors.Gateway MYSENSORS 192.168.178.3:5003
attr MySensors.Gateway autocreate 1
attr MySensors.Gateway room Maschinenraum
attr MySensors.Gateway stateFormat connection

setstate MySensors.Gateway connected
setstate MySensors.Gateway 2017-12-09 12:26:02 connection connected
setstate MySensors.Gateway 2017-12-09 12:26:02 state opened

@Beta-User: Autocreate ist also IMHO an. Gateway und Sensor sind ca. 20cm voneinander entfernt. Sie waren noch nie weiter als 50cm getrennt...

Ich versuche also, das Gateway in den Inklusionsmodus zu setzen:

Erst mal abschalten, nur um sicher zu gehen, daß der Modus nicht schon aktiv ist:

Code Auswählen


set MySensors.Gateway inclusion-mode off

Im Eventlog:

Zitat
2017-12-09 12:48:23 MYSENSORS MySensors.Gateway inclusion-mode off

Im Log auf ttyUSB0 tut sich nichts. Im FHEM-Log auch nicht.

Dann:

Code Auswählen


set MySensors.Gateway inclusion-mode on

Im Eventlog:

Zitat
2017-12-09 12:50:34 MYSENSORS MySensors.Gateway inclusion-mode on

Im Log auf ttyUSB0 tut sich nichts. Im FHEM-Log auch nicht.

Dann schalte ich den Sensor ein. Auf ttyUSB0:

Zitat
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0

uswusf....

Code Auswählen


TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0

Sent Message
Sender: 0
Last Node: 0
Next Node: 255
Destination: 255
Sensor Id: 255
Command: INTERNAL
Message Type:I_FIND_PARENT_RESPONSE
Payload Type: P_BYTE
Payload Length: 1
Signing: 0
Failed uplink counter: 0
Status: OK (OK=success, NACK=no radio ACK received)
Payload: 0

Klingt für mich nach: Gateway schickt dem Sensor erfolgreich eine Antwort. Aber gleich danach...

Code Auswählen


TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:

Received Message
Sender: 255
Last Node: 255
Destination: 255
Sensor Id: 255
Command: INTERNAL
Message Type: I_FIND_PARENT_REQUEST
Payload Type: P_STRING
Payload Length: 0
Signing: 0
Payload:

... empfängt das Gateway schon wieder ein I_FIND_PARENT_REQUEST. Ist der Node taub?

Ich gelobe feierlich einen Kasten Bier (oder äquivalentes Getränkt) für den Hinweis der mich weiterbringt. Ich würde so gerne endlich richtig loslegen

Schönes Wochenende (und hoffentlich bis bald)
Markus

The Grue · 09 Dezember 2017, 13:22:32

Oh, und weil danach immer wieder mal gefragt wird:

Das Oszi zeigt an der Stromversorgung des Funkmoduls 3.28V aber sowas von glatt an. Kein Ripple, nix. Es sind auch 22µ über Vcc und Gnd.

Selbiges an der Stromversorgung des Gateway-Funkmoduls. Das ist eines mit pa und Antenne, das per LM317 seine 3.3V bekommt. Was mich hier wundert: Das Multimeter zeigt eine Stromaufname von 20mA nach der Initialisierung - da hätte ich mehr erwartet $:-\$

Ranseyer · 09 Dezember 2017, 13:56:25

...es gibt ja auch Fake-Module inkl. zueinander inkompatiblen...
(Ich habe kürzlich meine lange gelagerten NRFs verkauft, damals gab es noch kaum Fakes. Wenn der Chip fein abgeschliffen aussieht, also oben rauher ist als seitlich würde ich mal in Richtung Fake denken)

Denke sinnvoll testen kann man nur wenn man bei nem HW Fehler sowohl den Sensor und auch notfalls das Gateway doppelt hat.

Beta-User · 09 Dezember 2017, 14:37:37

Jup, mehr Hardware zum gegenseitigen Testen hilft.

Das mit dem "ist der Sensor taub" kling für mich plausibel. Spekulation: MOSI-Leitung mit Wackler? (sowas hatte - wenn ich das richtig verstanden habe - neulich jemand mit einem CC1101, ich konnte es kaum glauben, weil der Chip scheinbar spielte...)

Wenn es an der Antwort auf die ID-Anfrage scheitert, kannst du die testweise ja mal manuell vergeben, dann siehst du wenigstens, ob der Sensor dann ordentlich angelegt wird (dürfte eigentlich dann keine oder weniger Antworten vom GW erwarten).

Ich würde auch erst mal nicht mit einem Ethernet-GW anfangen, aber auch daran scheint es ja nicht zu liegen. Trotzdem: Welche Version nutzt du aktuell? - Neulich gab es einen Bericht über ein Eth-GW unter 2.1.1, bei dem sich die Probleme in Luft auflösten, als 2.2.0-beta einfach funktionierte.

Um erste funktionierende HW zu haben, wäre ein serielles GW -ggf. an einem Test-System - eine Idee. Erst mal das ans laufen bekommen, dann hat man ein erstes Gefühl, wie es "eigentlich" gehen sollte. Das GW kann nachher ja auch zum Repeater umgewidmet werden, dann kann man die Kommunikation mithören.

Wo gäbe es ggf. den Kasten?

The Grue · 10 Dezember 2017, 14:25:58

Zitat von: Beta-User am 09 Dezember 2017, 14:37:37
Das mit dem "ist der Sensor taub" kling für mich plausibel. Spekulation: MOSI-Leitung mit Wackler? (sowas hatte - wenn ich das richtig verstanden habe - neulich jemand mit einem CC1101, ich konnte es kaum glauben, weil der Chip scheinbar spielte...)

Werde ich gleich mal testen.

Zitat
Wenn es an der Antwort auf die ID-Anfrage scheitert, kannst du die testweise ja mal manuell vergeben, dann siehst du wenigstens, ob der Sensor dann ordentlich angelegt wird (dürfte eigentlich dann keine oder weniger Antworten vom GW erwarten).

Würde ich auch versuchen... weiss leider nicht wie

Hinweise auf die Doku sind sehr willkommen

Zitat
Welche Version nutzt du aktuell? - Neulich gab es einen Bericht über ein Eth-GW unter 2.1.1, bei dem sich die Probleme in Luft auflösten, als 2.2.0-beta einfach funktionierte.

VER=2.1.1 ... Mal sehen, wo ich 2.2.0-beta finde. Danke für den Hinweis!

Zitat
Um erste funktionierende HW zu haben, wäre ein serielles GW -ggf. an einem Test-System - eine Idee.

Daran soll's nicht scheitern. Was sind denn die Vorteile am seriellen Gateway? Ich hab' halt noch so wenig Ahnung von der Stuktur...

Zitat
Wo gäbe es ggf. den Kasten?

Äh, wie bitte? Keine Ahnung, was du meinst...

Jetzt werde ich erst mal Punkt für Punkt Eure Hinweise durchgehen - vielen Dank dafür! Außerdem habe ich ein "RF24-GettingStarted" gefunden, mit dem ich vielleicht testen kann, ob und in welche Richtungen die beiden Chips miteinander reden.

Wenn's zeitlich rausgeht, melde ich mich heute Abend wieder, bis dahin schon mal einen schönen Sonntag!

cu
/me

Sweeman · 10 Dezember 2017, 14:44:39

Hallo The Grue,

ich kann ein kleines Lied von diesen Problemen singen. Leider habe ich keine richtige Lösung parat, aber ein paar Hinweise, die vielleicht zu einer stabilen Connection führen.

1. nRF24 Module sind (soweit ich sie in Händen hatte) eher Schrott

Als ich mal den Widerstand zwischen Ant und Grnd gemessen habe, kam ich da auf gerade mal 3 Ohm und ich bin zwar kein Kommunikationstechniker, aber eigentlich sollte der dort recht Hoch sein (die Erfahrung habe ich auch mit allen anderen Modulen, wie dem RFM69 gemacht. Dort ist keine Verbindung).
Die Antennenposition war hier schon teilweise ausschlaggebend, da anscheinend ein Wackler ab Werk verbaut war. Also mal beherzt rumwackeln, Antenne ab und gucken, ob es dann über eine kurze Distanz funktioniert, wieder dran etc....
2. Solltest du das ganze auf einem Breadboard laufen haben, versuche mal alle Verbindungen zu überprüfen oder die Jumper zu wechseln. Ein Jumperkabel mit Wackler kann einem ziemlich das Projekt verhageln.
3. Ich hatte schon Hardware, die nicht am gleichen PC auf einem Breadboard funktionieren wollte. Wirklich! Kaum habe ich das PCB vom Board gezogen funktioniert alles wunderbar. Die Lösung war hier für eine Komponente (GW oder Sender) eine andere Spannungsquelle zu verwenden. Also Batterien oder USB-Netzteil. Es ist also tatsächlich Hexerei im Spiel

4. Wie sieht denn dein Code aus? Mit so manchem hat FHEM seine Probleme. Strings z.B. sind so eine Sache... Das funktioniert nicht immer so einfach, wie man es sich vorstellt.
5. Du rufst aber nicht immer auch den seriellen Monitor ab, während du versuchst mit FHEM zu empfangen? Meine Erfahrung ist, dass nur eine Connection möglich ist.
6. Die ältere MySensors-Version kannst du unter "Bibliotheken verwalten" in der Arduino IDE installieren. Einfach MySensors suchen und dort auf die Version unten links klicken und installieren.
7. Welche ID hat dein Sensor? 0 ist vom Gateway besetzt. Du musst also irgendwas zwischen 1 und 255 wählen.

Ich hoffe ich konnte irgendwie helfen.
Viele Grüße

The Grue · 10 Dezember 2017, 14:47:41

Also auf Clock, MISO und MOSI tut sich schon mal was, das richtig aussieht. Ist MOSI active low?

The Grue · 10 Dezember 2017, 18:21:04

Mit 2.2.0-rc2 wurde immerhin schon mal MYSENSOR_0 vom Gateway automatisch angelegt. Ansonsten leider keine Fortschritte.
Ich habe auch mal versucht, das PingPong-Device zum Testen zu verwenden. Auf dem Sensor-Node hat das auch funktioniert, auf dem Gateway gibt's einen Fehler beim Initialisieren

Zu Deinen Fragen, Sweeman: 1-3: Klingt ja furchtbar. Ich hatte mich über MySensors gefreut, weil das ganze Framework so gut aussah, daß ich mit meinen Sensoren schnell loslegen kann. Geht ja gerade gründlich in die Hose.

4: Der Gateway-Code kommt direkt aus der MySensor-Bibliothek. Der Sensorcode ist 1:1 der aus den Examples zum DHT-Sensor.
5: Doch. Wie kann ich sonst überhaupt debuggen? Die nächsten Male versuche ich nur jeweils einen Node zu debuggen.
6: Naja, eigentlich wollte ich ja die neueren Versionen

Hat aber geklappt.
7: Ich hatte die Defaults gelassen (also AUTO für beides). Aber jetzt hab' ich auch mal explizit 0 für's Gateway und 1 für den Sensor gesetzt - hat auch nichts geholfen.

Beta-User · 10 Dezember 2017, 18:44:57

Zitat von: The Grue am 10 Dezember 2017, 14:25:58
Äh, wie bitte? Keine Ahnung, was du meinst...

Dieser Kasten war gemeint:

Zitat von: The Grue am 09 Dezember 2017, 13:14:37
Ich gelobe feierlich einen Kasten Bier (oder äquivalentes Getränkt) für den Hinweis der mich weiterbringt. Ich würde so gerne endlich richtig loslegen

Das mit dem seriellen GW hat sich erledigt, wenn du die Node_0 angelegt bekommst; dann funktioniert jedenfalls dieser Arduino; ein serielles GW hat den Vorteil, dass alles als Fehlerquelle ausscheidet, was mit Netzwerk zu tun hat (eingeschlossen diverse Bugs, die aus dem Eth-Modul kommen können - Widerstände waren da manchmal ein Thema - selber suchen, ich nehme bewußt serielle GW's...).

Und die Ausgaben an den seriellen Konsolen sind esentiell - sonst hat man keine Chance, irgendwas zu debuggen (darum auch der Vorschlag, eine Repeater-Node zu nutzen, dann sieht man, was hin- und hergeht, oder eben nicht...). Ggf. muß man halt 2 Rechner nutzen, um zu sehen, was an beiden Enden läuft (das kann aber die Kommunikation mit FHEM stören, deswegen mache ich sowas am GW nie, wenn ich weiß, dass das GW funktioniert).

Das ganze klingt immer noch nach Funkproblemen auf Sensor-Seite, auch wenn ich zu den Soll-Pegeln an MOSI nix sagen kann. Du solltest neben dem GW und dem einen Sensor eine weitere HW nehmen, um testen zu können, wo genau der Fehler liegt - im Funkbereich oder in der (fehlenden) Antowort vom GW bzw. von FHEM.

Und 255 ist _keine_ zulässige Node-ID. Das ist die Broadcast-Adresse...

The Grue · 30 Dezember 2017, 11:59:10

Servus Beta-User,

Bitte entschuldige, daß ich mich erst jetzt wieder melde. War einfach zu viel Anderes los. Als nächstes möchte ich dann einen anderen Node bauen (Dallas one-wire Temperatursensor). Mal sehen, ob der in's Netz findet.

Das mit dem "Kasten" klingt ja ganz übel - von meiner Seite. Aber: ich habe ich nicht kapiert, was Du meinst und der Kasten ist auch noch ernst gemeint. Wenn ich meine erste laufende Kommunikation hinbekommen habe, lese ich mir diesen Thread nochmal genau durch und entscheide wer ihn bekommt. Ich wohne im Münchner Osten (Landkreis Ebersberg), aber ich hoffe doch, daß man heutzutage so ein Ding auch irgendwie zustellen lassen kann... jedenfalls im EU-Binnenmarkt

cu
Markus

Beta-User · 30 Dezember 2017, 13:22:43

Servus, kein Problem - und das mit dem Kasten war eher flapsig gemeint

.

Für's erste kannst du auch eine Repeater-Node nehmen, es braucht zumindest für Basistests der Kommunikation keine physische Sensor-Hardware. Damit sollte sich an deren serieller Konsole beobachten lassen, ob der Anmeldeprozess klappt. Kann aber natürlich auch ein Temp-Sensor sein.

Viel Erfolg jedenfalls,

Beta-User

The Grue · 28 Januar 2018, 15:53:37

Servus,

neues Jahr, neues Unglück, neue Gelegenheit sich den Kasten Bier zu verdienen

Inzwischen ist folgendes passiert:

- update der Mysensors-Bibliothek auf 2.2.0 stable
- ich habe mir neue NRF24-Module von itead bestellt. Die alten waren vom ganz billigen EBay-Händler, vielleicht eine Fälschung? Wer weiss.
- ich habe das Modul mit Antenne und PA durch eines der neuen "normalen" Module ersetzt. Mein Problem könnte ja an dem "exotischen" PA-Modul liegen. Stromversorgung ist immer noch mit LM371, das Oszi zeigt 0 Ripple.
- Ich habe den Node durch einen reinen Repeater, keine weitere Beschaltung ersetzt und auch hier ein "normales" NRF24-Modul von itead mit 22µF Elko verwendet.

Geht aber immer noch nicht. Ich könnte k*tzen, sorry für die Ausdrucksweise. Im Anhang ist mal ein Photo, wer weiss, ob's hilft. Zu sehen ist im Hintergrund, auf der Lochrasterplatine das Gateway. Mit dem Taster habe ich mal versucht, das Gateway in den inclusion-Modus zu versetzen, war aber bei diesem Versuch nicht aktiv. Im Vordergrund sieht man den fliegenden Aufbau des Repeaters. Ich habe alle Verbindungen öfters durchgemessen als ich zählen kann. Maximaler Widerstand: 1Ω

Das habe ich gemacht: Im FHEM das Gateway in den inclusion-mode versetzt. Reaktion im FHEM-Log:

Code Auswählen


2018.01.28 15:16:52 1: 192.168.178.3:5003 disconnected, waiting to reappear (MySensors.Gateway)
2018.01.28 15:16:57 1: 192.168.178.3:5003 reappeared (MySensors.Gateway)

Log des Gateways:

Code Auswählen

0 MCO:BGN:INIT GW,CP=RNNGA---,VER=2.2.0
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
12 TSM:INIT:GW MODE
14 TSM:READY:ID=0,PAR=0,DIS=0
17 MCO:REG:NOT NEEDED
319 GWT:TIN:IP=192.168.178.3
1323 MCO:BGN:STP
1324 MCO:BGN:INIT OK,TSP=1
27586 TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
27592 TSF:MSG:BC
27593 TSF:MSG:FPAR REQ,ID=255
27596 TSF:PNG:SEND,TO=0
27598 TSF:CKU:OK
27600 TSF:MSG:GWL OK
28616 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
30430 TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
30435 TSF:MSG:BC
30437 TSF:MSG:FPAR REQ,ID=255
30439 TSF:CKU:OK,FCTRL
30442 TSF:MSG:GWL OK
31226 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
32441 TSF:MSG:READ,255-255-0,s=1,c=3,t=3,pt=0,l=0,sg=0:
34450 TSF:MSG:READ,255-255-0,s=220,c=3,t=3,pt=0,l=0,sg=0:
36460 TSF:MSG:READ,255-255-0,s=183,c=3,t=3,pt=0,l=0,sg=0:
38469 TSF:MSG:READ,255-255-0,s=146,c=3,t=3,pt=0,l=0,sg=0:
50488 TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
50493 TSF:MSG:BC
50495 TSF:MSG:FPAR REQ,ID=255
50498 TSF:PNG:SEND,TO=0
50500 TSF:CKU:OK
50501 TSF:MSG:GWL OK
50867 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
52499 TSF:MSG:READ,255-255-0,s=107,c=3,t=3,pt=0,l=0,sg=0:
54509 TSF:MSG:READ,255-255-0,s=71,c=3,t=3,pt=0,l=0,sg=0:
56518 TSF:MSG:READ,255-255-0,s=34,c=3,t=3,pt=0,l=0,sg=0:
58529 TSF:MSG:READ,255-255-0,s=254,c=3,t=3,pt=0,l=0,sg=0:
70549 TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
70554 TSF:MSG:BC
70556 TSF:MSG:FPAR REQ,ID=255
70558 TSF:PNG:SEND,TO=0
70560 TSF:CKU:OK
70562 TSF:MSG:GWL OK
71532 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
72560 TSF:MSG:READ,255-255-0,s=217,c=3,t=3,pt=0,l=0,sg=0:
74570 TSF:MSG:READ,255-255-0,s=181,c=3,t=3,pt=0,l=0,sg=0:
76579 TSF:MSG:READ,255-255-0,s=144,c=3,t=3,pt=0,l=0,sg=0:
78589 TSF:MSG:READ,255-255-0,s=107,c=3,t=3,pt=0,l=0,sg=0:
90607 TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
90613 TSF:MSG:BC
90614 TSF:MSG:FPAR REQ,ID=255
90617 TSF:PNG:SEND,TO=0
90619 TSF:CKU:OK
90621 TSF:MSG:GWL OK
91171 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
92619 TSF:MSG:READ,255-255-0,s=69,c=3,t=3,pt=0,l=0,sg=0:

Code Auswählen


16 MCO:BGN:INIT REPEATER,CP=RNNRA---,VER=2.2.0
26 TSM:INIT
27 TSF:WUR:MS=0
34 TSM:INIT:TSP OK
35 TSM:FPAR
37 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
801 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
806 TSF:MSG:FPAR OK,ID=0,D=1
2046 TSM:FPAR:OK
2048 TSM:ID
2049 TSM:ID:REQ
2052 TSF:MSG:SEND,255-255-0-0,s=1,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4059 TSM:ID
4060 TSM:ID:REQ
4062 TSF:MSG:SEND,255-255-0-0,s=220,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
6070 TSM:ID
6071 TSM:ID:REQ
6073 TSF:MSG:SEND,255-255-0-0,s=183,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
8081 TSM:ID
8082 TSM:ID:REQ
8084 TSF:MSG:SEND,255-255-0-0,s=146,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
10092 !TSM:ID:FAIL
10093 TSM:FAIL:CNT=1
10095 TSM:FAIL:DIS
10097 TSF:TDI:TSL
20100 TSM:FAIL:RE-INIT
20102 TSM:INIT
20109 TSM:INIT:TSP OK
20111 TSM:FPAR
20113 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20458 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
20463 TSF:MSG:FPAR OK,ID=0,D=1
22121 TSM:FPAR:OK
22122 TSM:ID
22124 TSM:ID:REQ
22126 TSF:MSG:SEND,255-255-0-0,s=107,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
24134 TSM:ID
24135 TSM:ID:REQ
24138 TSF:MSG:SEND,255-255-0-0,s=71,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
26145 TSM:ID
26146 TSM:ID:REQ
26149 TSF:MSG:SEND,255-255-0-0,s=34,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
28157 TSM:ID
28158 TSM:ID:REQ
28162 TSF:MSG:SEND,255-255-0-0,s=254,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
30169 !TSM:ID:FAIL
30170 TSM:FAIL:CNT=2
30172 TSM:FAIL:DIS
30174 TSF:TDI:TSL
40177 TSM:FAIL:RE-INIT

Code Auswählen


806 TSF:MSG:FPAR OK,ID=0,D=1	Find parent response from node 0 is valid, distance 1 to GW

\o/ Party!!! Alles klar, funktioniert! Endlich! Aber dann, einige (erfolgreiche) Messages später:

Code Auswählen


	10092 !TSM:ID:FAIL	
        10093 TSM:FAIL:CNT=1	Transition to Failure state, consecutive failure counter is 1

WAS ZUR HÖLLE...? Warum denn?

Also für mich sieht das nach funktionierende Kommunikation aus, die in einem Fehlerfall endet. Macht echt keinen Spaß. Ich bin versucht den Kasten Bier in eine Kiste Champagner zu wandeln. NEIN! Nur ein Scherz. Das Bier gibt's aber wirklich

Kann denn bitte jemand helfen?

cu
Markus

The Grue · 28 Januar 2018, 19:12:49

Es gibt Neuigkeiten aus dem MySensors-Forum. Die NodeID-Vergabe scheint nicht zu klappen: https://forum.mysensors.org/topic/8940/connection-failure/2
Mache ich (oder FHEM?) da noch was falsch? Oder muss man die NodeId manuell vergeben?

cu
Markus

Beta-User · 29 Januar 2018, 09:22:18

Moin The Grue,

die manuelle Vergabe der NodeID ist "nur" eine Notlösung und jedenfalls bei nRF-Netzen nicht erforderlich (das sieht bei RS485 anders aus).

Für mich sieht das eher so aus, als würde der MySensors-Teil auf den Nodes an sich klappen (Kommunikation und so), aber der GW-Output dann in FHEM nicht erwartungsgemäß behandelt. Da diese Mechanismen aber erwiesenermaßen an sich funktionieren, würde ich darauf tippen, dass die Einstellungen in FHEM nicht passen. Also: Hast du den inclusionmode (am GW) und autocreate (FHEM generell) jeweils eingeschaltet?

Ansonsten schadet es auch nicht, die ID's manuell zu vergeben (ich mache das immer so, da ich die Arduinos beim Testen neuer Funktionalität ggf. hin und her wechsle...).

Gruß, Beta-User

KarlHeinz2000 · 29 Januar 2018, 09:59:30

Ich habe es gerade mal ausprobiert. Bei mir geht die ID Vergabe durch FHEM. Aktuelles FHEM und MYSENSOR 2.2.1.
Hast du irgendwann mal das EEPROM vom Node gelöscht? Vielleicht mit dem eeprom_clear? Der schreibt 0 statt 0xff rein und dann geht es nicht. Das hatte ich schon mal. Darum bitte mal das EEPROM richtig löschen und nochmal probieren.

Code Auswählen


/*
 * EEPROM Clear
 *
 * Sets all of the bytes of the EEPROM to 0xff.
 * Please see eeprom_iteration for a more in depth
 * look at how to traverse the EEPROM.
 *
 * This example code is in the public domain.
 */

#include <EEPROM.h>

void setup() {
  // initialize the LED pin as an output.
  pinMode(13, OUTPUT);
  
  /***
    Iterate through each byte of the EEPROM storage.

    Larger AVR processors have larger EEPROM sizes, E.g:
    - Arduno Duemilanove: 512b EEPROM storage.
    - Arduino Uno:        1kb EEPROM storage.
    - Arduino Mega:       4kb EEPROM storage.

    Rather than hard-coding the length, you should use the pre-provided length function.
    This will make your code portable to all AVR processors.
  ***/

  for (int i = 0 ; i < EEPROM.length() ; i++) {
    EEPROM.write(i, 0xff);
  }

  // turn the LED on when we're done
  digitalWrite(13, HIGH);
}

void loop() {
  /** Empty loop. **/
}

Nebenbei für alle mit mehreren Gateways: die vergebenen IDs sind leider nicht eindeutig. Kann sein das die gleiche ID mehrfach an verschiedenen GW vergeben wird.

Markus. · 31 Januar 2018, 10:09:51

Zitat von: KarlHeinz2000 am 29 Januar 2018, 09:59:30

Nebenbei für alle mit mehreren Gateways: die vergebenen IDs sind leider nicht eindeutig. Kann sein das die gleiche ID mehrfach an verschiedenen GW vergeben wird.

Konnte ich bisher nicht feststellen. Habe ein aktives WLAN NRF Gateway und am selben Server ein serielles RFM69 Gateway.
Die ID Vergabe bei autocreate funktioniert einwandfrei bisher. Das einzige Problem ist, das das IODEV des zuletzt definierten Gateways verwendet wird unabhängig davon wo der neue Sensor gefunden wird, also vom NRF- oder RFM-Gateway.
Das einzige was ich dann machen muss, ist das IOdev entsprechend anpassen in dem neu generierten Device.
Auch die "automatische Vergabe" der IDs funktioniert soweit, wobei ich einen mix zwischen fest hinterlegten NodeIds habe und
welchen die automatisch vergeben wurden.

Gruß

Markus

KarlHeinz2000 · 31 Januar 2018, 21:00:32

Ich hatte gerade das Problem bei jenem Test. Der neue NRF Node hat eine aktive ID vom RS485 Bus bekommen...

Beta-User · 31 Januar 2018, 21:04:09

Bist du sicher, dass da nicht eine "alte" ID im EEPROM war?
(Aus dem Grund, dass ich die sicher weg haben will, mache ich nur manuelle Vergabe, ist mir auch ein paar Mal passiert...)

KarlHeinz2000 · 31 Januar 2018, 21:25:43

Der Node hatte vorher eine andere ID. Dann habe ich das EEPROM komplett gelöscht und dann eine automatische ID vergeben lassen, welche dann eine aktive vom anderen Bus war.

Beta-User · 02 Februar 2018, 07:53:24

Habe gestern mal in die perl-Module geschaut. Bin zwar kein Experte (das muß also nicht zutreffen), aber soweit ich das verstanden habe, nimmt das Modul alle Devices her, die es zu dem IO findet (wobei neue Nodes immer dem letzten zugeordnet werden, auch wenn sie tatsächlich über ein anderes GW kommen) und sucht von 254 her kommend nach der niedrigsten noch nicht vergebenen ID.

Das führt häufig dazu, dass die Vergabe ok ist, aber eben nicht zwingend.

Empfehlung daher generell: ID's manuell vergeben (ist bei RS485 sowieso Pflicht). Dann kann man sich m.E. auch das Löschen (mit dem MySensors-Lösch-Sketch) sparen (alle anderen gespeicherten Daten sind "self-healing", wenn man es nicht aktiv ausschaltet).

The Grue · 04 Februar 2018, 17:06:30

Servus KarlHeinz2000,

In's Schwarze

nach Deinem EEPROM Clear hat der Node seine ID bekommen und sendet fleissig

cu
Markus

The Grue · 04 Februar 2018, 17:18:02

Servus,

Mittlerweile funktioniert die Geschichte

Leider habe ich keinen einzelnen Punkt, der "schuld" war. Was ich als letztes probiert habe:

- Verwendung von MySensors Version 2.2.0 (released)
- Um unterschiedliche NRF24-Module testen zu können, habe ich das Modul am Gateway gesockelt und die Anschlüsse verlötet. War vorher nur gesteckt.
- Module bei ITEAD gekauft
- Den Node als Repeater konfiguriert

Es lag nicht an den Modulen. Ich kann die billigen von Ebay genauso verwenden wie die von ITEAD, beide funktionieren.
Es lag auch nicht am Sketch: Ich hab' den DHT-Sensor-Sketch unverändert aufgespielt, funktioniert.
Bleibt also eigentlich nur noch, daß Release 2.2.0 irgendwelche Verbesserungen gebracht hat, oder - was wohl weitaus wahrscheinlicher ist - , daß die gesteckten Anschlüsse das Problem waren. Ich mag so eine fliegende Verdrahtung eigentlich gar nicht, die nächsten Sensoren werden ordentlich aufgebaut.

Es steht noch ein Kasten Bier aus. Ich werde mir noch etwas Gedanken machen und mich dann bei demjenigen melden, von dem ich glaube, er hat mir am meisten geholfen...

Danke für Eure Unterstützung, Leute. Echt ein gutes Forum

cu
Markus