[gelöst] Uplink check failed : Neue Nodes werden nicht erkannt

[alru]

Moin,

bei mir ist der Repeater ausgefallen. Bei der Fehlersuche hab ich dann bemerkt, dass er die Verbindung zum Gateway (serielles GW am Raspi/Fhem-Server) nicht findet.
Anschließend habe ich verschiedene HW (Uno, Nano) und verschiedene bereits zuvor verwendete Sketche versucht in Betrieb zu nehmen: Kein Erfolg!
Die Nodes waren alle zuvor zu Testzwecken schon mal verbunden!
Zwei Nodes. die ohne den Repeater direkt mit dem GW verbunden sind, arbeiten noch fleißig...
Updates von Fhem wurden eingespielt und Fhem und GW wurden neu gestartet: Kein Änderung
Anschließend habe ich den Sketch mit fester NODE_ID und PARENT_NODE_ID versucht: Ebenfalls keine Erfolg

Hier der Sketch:

Code Auswählen Erweitern

/**
* Repeater Sketch
  */

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24

// MSG1
#define MY_RF24_CHANNEL 96

// Optional: Define Node ID
#define MY_NODE_ID 103
#define MY_PARENT_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC

// Enabled repeater feature for this node
#define MY_REPEATER_FEATURE

#include <MySensors.h>
#include <SPI.h>

void setup()
{
}

void presentation()
{
//Send the sensor node sketch version information to the gateway
sendSketchInfo("repeater", "1.6");
}

void loop()
{
}



Als Fehlermeldung beim Node ist im Monitor zu finden (Alle Versuche enden mit !TSM:UPL:FAIL):

Code Auswählen Erweitern

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:INIT:STATID=103
41 TSF:SID:OK,ID=103
43 TSM:FPAR
45 TSM:FPAR:STATP=0
46 TSM:ID
47 TSM:ID:OK
48 TSM:UPL
51 TSF:MSG:SEND,103-103-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2059 TSM:UPL
2064 TSF:MSG:SEND,103-103-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
4071 TSM:UPL
4073 TSF:MSG:SEND,103-103-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
6081 TSM:UPL
6086 TSF:MSG:SEND,103-103-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
8093 !TSM:UPL:FAIL

Bei Fhem kommt der Verbindungsversuch an, wie man im Log sieht (Einträge für ID 103):

Code Auswählen Erweitern

2018.10.07 19:50:39 4: MYSENSORS/RAW: /0;255;3;0;9;16662636 TSF:MSG:R
2018.10.07 19:50:39 4: MYSENSORS/RAW: 0;255;3;0;9;16662636 TSF:MSG:R/EAD,103-103-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1

2018.10.07 19:50:39 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '16662636 TSF:MSG:READ,103-103-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1'

2018.10.07 19:50:39 5: MYSENSORS gateway MSG1: 16662636 TSF:MSG:READ,103-103-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
2018.10.07 19:50:39 4: MYSENSORS/RAW: /0;255;3;0;9;16662642 TSF:MSG:PINGED,ID=103,HP=1

2018.10.07 19:50:39 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '16662642 TSF:MSG:PINGED,ID=103,HP=1'

2018.10.07 19:50:39 5: MYSENSORS gateway MSG1: 16662642 TSF:MSG:PINGED,ID=103,HP=1
2018.10.07 19:50:39 4: MYSENSORS/RAW: /0;255;3;0;9
2018.10.07 19:50:39 4: MYSENSORS/RAW: 0;255;3;0;9/;16662682 !TSF:MSG:SEND,0-0-103-103,s=255,c=3,t=
2018.10.07 19:50:39 4: MYSENSORS/RAW: 0;255;3;0;9;16662682 !TSF:MSG:SEND,0-0-103-103,s=255,c=3,t=/25,pt=1,l=1,sg=0,ft=0,st=NACK:1

2018.10.07 19:50:39 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '16662682 !TSF:MSG:SEND,0-0-103-103,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1'

2018.10.07 19:50:39 5: MYSENSORS gateway MSG1: 16662682 !TSF:MSG:SEND,0-0-103-103,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1

Die Einstellungen des GW wurden nicht geändert (inclusion on, autocreate on). Startet man den Sketch ohne feste ID (so wie bisher) dann gibt es im Monitor die Fehlermeldung

Code Auswählen Erweitern

6175 !TSM:FPAR:NO REPLY
6177 TSM:FPAR
6213 TSF:MSG:SEND,103-103-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8221 !TSM:FPAR:FAIL

Das war jetzt mein Sonntagnachmittag ...

[Beta-User]

Kannst du als erstes mal versuchen, den Repeater mit der aktuellen Version zu flashen? (Im Hinterkopf habe ich die Info, dass es da ein Problem gab, kann aber auch falsch sein).

Ansonsten klingt es nach einem Problem mit der Stromversorgung - tendenziell am GW. Hast du da seither weitere USB-Geräte zusätzlich angeschlossen? (Wenn ja: mal einen aktiven Hub testen). Es sind überall Kondensatoren verbaut?

[alru]

Kannst du als erstes mal versuchen, den Repeater mit der aktuellen Version zu flashen? (Im Hinterkopf habe ich die Info, dass es da ein Problem gab, kann aber auch falsch sein).

Muss ich dann nicht auch das GW mit der Version 2.3.0 flashen? Ich kenn mich bei MYSENSORS noch nicht mit der Kompatibilität aus und habe noch alle Geräte auf der Version 2.2.0 laufen.

Ansonsten klingt es nach einem Problem mit der Stromversorgung - tendenziell am GW. Hast du da seither weitere USB-Geräte zusätzlich angeschlossen? (Wenn ja: mal einen aktiven Hub testen). Es sind überall Kondensatoren verbaut?

Ich denke inzwischen auch, dass es ein Problem beim GW ist: Fhem empfängt und gibt Sendebefehle raus. Die neuen Nodes senden, empfangen aber nichts. Die beiden funktionierenden Nodes sind nur Sensoren, die senden also nur. Dazwischen ist eigentlich nur noch das GW...

Das GW ist über USB mit dem Raspi vebunden, hat aber zusätzlich eine eigene Stromversorgung, da ich ein NRF24L01+PA+LNA angeschlossen habe. Das Funkmodul wird über die Vin vom GW und einem DC-DC Wandler versorgt. Die Funkmodule haben bei mir alle Kondensatoren. Der DC-DC Wandler hat am Ein- und Ausgang Kondensatoren, so wie spezifiziert.

Ich werde heute Abend mal das GW austauschen, bzw. mal ein anderes Funkmodul anschließen.

[Beta-User]

Ein Repeater mit 2.3.0 oder 2.3.1-beta sollte ohne weiteres mit einem 2.2.0-er GW zusammenarbeiten, Garantien gibt es aber keine.

Deine Beschreibung der Konstruktion mit zwei Power-sourcen für den Arduino und den nRF klingt selbst für meine Begriffe etwas abenteuerlich, das sollte m.E. nur über die (ggf. über einen Hub aktiv unterstützte) USB-Seite kommen.

Ich würde im ersten Schritt mal nur einen aktiven Hub verwenden, dann ggf. den Repeater mit 2.3.0/1 flashen und zuletzt dann dasselbe mit dem GW, wenn es nicht so schon funktioniert. Dabei bei den GW-Einstellungen ggf. die TX-Power mal verändern.

[alru]

Moin,

so, ich glaube den Fehler gefunden zu habe! Mich hat folgende Info in die Irre geführt:

Vin. The input voltage to the Arduino/Genuino board when it's using an external power source (as opposed to 5 volts from the USB connection or other regulated power source). You can supply voltage through this pin, or, if supplying voltage via the power jack, access it through this pin.

Quelle: https://store.arduino.cc/usa/arduino-uno-rev3

Für den Betrieb des Funkmoduls NRF24L01+PA+LNA benötigt man über 115mA im Sendemodus. Man kann also nicht einfach den 3,3V Ausgang des Arduino verwenden, der leistet beim UNO max. 50mA. Ich habe dafür die externen Spannungsversorung (12V) des Arduino verwendet (über einen DC-DC Konverter) und dachte diese wird direkt zum Pin Vin durchgeleitet. Da muss aber noch eine Strombegrenzung dazwischen sein...

Also habe ich jetzt direkt, ohne Umwege über das Bord, den DC-DC Konverter an die externe Spannungsversorung angeschlossen. Und siehe da, es geht!

[Beta-User]

Schön, dass du das lösen konntest.

Dennoch wäre es m.E. als "Referenzdesign" besser, den 5V-Pin auf dem Arduino (der wiederum über USB gespeist wird) als Quelle für den DC-DC-Wandler zu nutzen.
Damit hat man "nur" das Problem, dass der zur Verfügung stehende Strom an USB auf dem PI begrenzt ist, was ebenfalls zu seltsamen Effekten führen kann, aber ggf. besser über einen aktiven Hub (oder gleich eine andere Plattform) zu lösen ist (die 115mA kann man m.E. teilweise durch einen weiteren Kondensator kompensieren, jedenfalls, wenn der nRF nicht Dauerfunken muß).

[alru]

Moin,

das "Referenzdesign" sehe ich ein wenig anders.
Wenn man die 5V/3,3V Pins des Arduino benutzt, dann ist die Strombegrenzung von zwei Faktoren abhängig:

• Die externe Spannungsquelle, kann über den Power-Jack (7-12V) und/oder USB erfolgen. Wird beides verwendet, nutzt das Bord den Power-Jack
• Der on-board Spannungsregler

Aus dem Arduino Forum habe ich erfahren, dass daraus dann auch unterschiedliche Maximalwerte für den 5V Ausgang resultieren.
http://forum.arduino.cc/index.php?topic=199410.0 (Siehe Post #4)

Ich sehe es als kritisch an, die stromfressenden Module (RF+PA, Relais, ...) über den Arduino laufen zu lassen, da dann immer die Spannungsregler belastet werden, die auch den Controller versorgen. Ich bin eher ein Freund davon, das Arduino Board möglichst wenig mit der Spannungsversorgung von externen Komponenten zu belasten.
Beim nächsten Gateway wird bei mir noch zusätzlich zum RF Modul ein Ethernet Modul angeschlossen. Das will dann auch noch ein paar mA haben, u.s.w...

Für den Fall (so wie hier), dass ich ohnehin einen DC-DC Konverter für meine 3,3V brauche, macht der Umweg über die 5V des Boards für mich keinen Sinn.

Vereinfacht gesagt würde ein Referenzdesign für mich lauten:
Wenn die Spannungsregler des Boards ausreichend Leistung haben um externe Komponenten direkt zu versorgen, dann nutze sie.
Wird mehr Leistung benötigt, versorge die Komponenten über eine eigene Spannungsversorgung.

[Beta-User]

Mahlzeit.

Das mit den 500mA@USB ist klar, das ergibt sich aus der allgemeinen USB-Spec. für USB-Ports an PC's; bei einem reinen GW ist man aber unterhalb dieses Werts, ein reines USB-Netzteil liefert aber uU. mehr, das kann auch mehrere Ampere haben/können.

Ich hatte mir mal Probleme eingefangen, als ich mehrere Regler parallel angeschlossen hatte, hat also seine Vor- und Nachteile...

Nutzt man weitere Komponenten (v.a. ein Relais-Board), die sehr viel Strom ziehen, gebe ich dir dahingehend recht, dass man dieses gesondert versorgen sollte; die Relais sind ja in der Regel extra zu dem Zweck mit Optokopplern angebunden.

Meine persönliche Schlussfolgerung:
Geht es "nur" um den PA+LNA-nRF braucht man eigentlich noch keine Sorgen haben, dass die 500 mA nicht reichen könnten (allerdings erreicht der PI die schon nicht immer). Und ein GW sollte nicht viel mehr machen als nur den Datentransfer, die Argumentation paßt dann eher auf einen Repeater, und da kann und sollte man ggf. wirklich einen ordentlichen Step-Down davor setzen (über den ich dann aber wieder _alles_ versorgen würde; der Regler auf dem Arduino erzeugt dann nur unnötige Hitze).

Aber da ich nur Laie bin, kann und will ich das nicht wissenschaftlich belegen, mir geht es eher darum, eventuelle Stolperfallen möglichst gar nicht erst aufzumachen, über die andere Laien fallen könnten; und da gehört eben nach meiner pers. Erfahrung ein 2. Spannungswandler dazu (aber klar ist, dass der hier in jedem Fall benötigt wird).

Just my2ct.