Mysensors . Ein Node klappt, eins nicht

Begonnen von Komaandy, 07 März 2017, 22:35:02

Vorheriges Thema - Nächstes Thema

Komaandy

Hallo zusammen,

folgendes,

ich habe 2 identische Nodes zusammengebaut und beide mit dem selben Sketch geflasht.
Einer der beiden Nodes liefert auch alle Werte sauber im FHEM (MSPIRAndy) ab, der andere(MYSENSOR_106) allerdings nicht.
Über den Serial-monitor im Arduino-Editor liefern beide Nodes korrekte Werte.
Bei dem einen Node werden Sie einfach nicht ins FHEM geschickt...
Ich weiss wirklich nicht weiter und bin für jeden Tipp dankbar.


Beta-User

Hallo Komaandy,

die einfachste Ursache könnte sein, dass es an einem Neuladen des Browserinhalts fehlt (siehe auch Starter-Guide im Wiki).

Ansonsten bitte (in Code-Tags, # oben) mal ein list aller beteiligten Devices (auch des GW!). Screenshots sind nicht so das Gelbe vom Ei...

Dann: Hast Du die serielle Ausgabe an dem Ort angesehen, an dem sich die nicht funktionierende Node jetzt befindet? Dazu bitte ggf. auch in Code-Tags mal die Ausgabe beim Starten bzw. bis nach dem ersten Senden von Meßwerten.

An sich würde ich Dir einen Update auf 2.1.1 anraten, irgendwann zwischen 2.0.0 und 2.1.1 war die Funkstrecke kaputt...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Komaandy

Dieser Node funktioniert einwandfrei



define MSPIRAndy MYSENSORS_DEVICE 105
attr MSPIRAndy IODev meinMSG
attr MSPIRAndy group Bewegungsmelder
attr MSPIRAndy mapReading_humidity57 57 humidity
attr MSPIRAndy mapReading_temperature33 33 temperature
attr MSPIRAndy mapReading_tripped92 92 tripped
attr MSPIRAndy mode node
attr MSPIRAndy room 3_Sensoren
attr MSPIRAndy stateFormat tripped92\
temperature33\
humidity57
attr MSPIRAndy version 2.0.0


Dieser Node ist identisch von der Hardware aber  er liefert nicht alle Readings.

define MYSENSOR_106 MYSENSORS_DEVICE 106
attr MYSENSOR_106 IODev meinMSG
attr MYSENSOR_106 mapReading_humidity59 59 humidity
attr MYSENSOR_106 mapReading_temperature35 35 temperature
attr MYSENSOR_106 mode node
attr MYSENSOR_106 version 2.0.0



Aber eben wie gesagt. Die Attribute sind zwar da (wenn auch nicht alle)  FHEM bekommt aber keine readings angezeigt.

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Komaandy

#4
Sorry,

das ist ein WiFi Gateway auf Grundlage eines ESP8266.
8 andere Nodes funktionieren problemlos.


define meinMSG MYSENSORS 192.168.178.20:5003
attr meinMSG autocreate 1
attr meinMSG requestAck 1
attr meinMSG stateFormat connection


und ja die serielle Ausgabe wurde an dem Ort getestet an dem das Node sitzen soll.

Beta-User

Poste Doch bitte mal die Sketche.

Ganz identisch können die nicht sein, sonst wären ja die ChildID's gleich.
Vielleicht solltest Du den 106-er auch nochmal löschen und per autocreate neu anlegen lassen.

Wenn Du an der seriellen Ausgabe der Node keine Sendefehler siehst, ist das wirklich mysteriös.

Was noch denkbar ist - für den Fall, dass Du die nicht funktionierende Node erst vor kurzem geflasht hast und die Arduino-IDE (oder die libs) zwischenzeitlich upgedated hast: Änderungen am nRF-Treiber, die zur Folge haben, dass der Funkverkehr iVm. älteren MySensors-Versionen (vor 2.1.1) deutlich unzuverlässiger geworden ist. Ich hatte auch mal so einen Fall, dass ich dachte, Funk muß ja passen, wenn die Node einmal Kontakt zum GW hatte. Leider kamen aber auch da Meßwerte nicht mehr an (obwohl die HW vorher mit 2.0.0-beta gut funktioniert hat; da waren an der seriellen Ausgabe auch keine Fehler zu sehen). Wenn Du das Testen willst, solltest Du entweder das Risiko gehen, das GW und die "Problemnode" auf 2.1.1 upzudaten oder alternativ mal ein anderes GW mit dieser Version nutzen. Nicht empfholen, aber evtl. auch möglich wäre, nur die Node erst mal auf 2.1.1 nochmal zu testen, vielleicht reicht das ja schon.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Komaandy

Hallo,

ja sie sind nicht ganz identisch,

ich habe im Sketch jeweils die Child ID´s fortlaufend um +1 erhöht.
Ich denke ich werde heute abend das GW auf 2.1.1. updaten um einen Status Quo zu schaffen.

Ich habe den 106er bereits gelöscht, FHEM neugestartet, autocreate gesetzt, aber die readings kommen nicht durch...

Beta-User

Anmerkungen noch, auch wenn manches vielleicht blöd klingt:

Den Browser-Refresh nach einiger Zeit hast Du gemacht? Es müssen erst Meßwerte übertragen werden, bevor die Readings sichtbar werden...
Im Sketch arbeitest Du mit Variablen, oder? Nicht, dass das überall manuell vergeben ist und Du eine ChildID n präsentierst, dann aber unter n+1 sendest... (Warum machst Du das überhaupt? Ich kann darin keinen wirklichen Vorteil erkennen.)

Wenn update, dann nicht nur das GW, ich würde erst mal mit der Node anfangen.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

Was mir noch eingefallen ist: Der neuere nRF-Treiber hat einen höheren Strombedarf. Den obligatorischen Kondensator hast Du drin (bzw. auch mal mehrere unterschiedliche durchgetestet)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Komaandy

Guten Abend zusammen,

es scheint ein "defekter" Arduino zu sein...
Wenn ich auf meinem Breadboard den Arduino (pro mini 3,3v) durch einen "identischen", also gleiches gerät,gleicher sketch etc. ersetzte funktioniert es sofort...
Wobei ich nicht verstehe warum dann BEIDE per Arduino-serial-monitor saubere Werte liefern.

Gruss

Komaandy