MySensors WLAN Gateway ... FHEM "redet" nicht mit dem Gateway

Begonnen von Meister_Petz, 26 Oktober 2016, 13:19:27

Vorheriges Thema - Nächstes Thema

Meister_Petz

Moin,

habt Ihr eine Idee warum mein MySensors WLAN Gateway von FHEM nicht angesprochen werden möchte?

Ist Zustand
:
- das Gateway ist in FHEM hinterlegt und meldet "startup complete"
define WlanGateway MYSENSORS 192.168.18.241:5003
attr WlanGateway first-sensorid 1
attr WlanGateway group WlanGateway
attr WlanGateway requestAck 1
attr WlanGateway room 0_GATEWAY
attr WlanGateway stateFormat connection
attr WlanGateway autocreate


- Ein 0815 Sensor fragt permanent nach einer ID. Über Seriell sehe ich:req ID
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:


- Am Gateway (über Seriell und Terminal) sehe ich jedesmal wenn der Sensor was schicken möchte  Connecting to wlan
......Connected!
IP: 192.168.18.241
0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;


- In FHEM kommt nichts an und der Sensor bekommt keine ID

was mache ich flasch?

Danke

Petz

Beta-User

Hallo Petz,

habe leider auch nicht die grandiose Idee dazu, aber ein ähnliches Problem, von dem ich bis zu deinem Post hier dachte, es selbst verursacht zu haben:

Mein serielles GW will ebenfalls nicht mehr und wechselt nach jedem click auf "connect" sofort wieder von "connected" auf "startup complete" (in der Anzeige oben, unten in den readings bleibt es idR. bei "connected"). Das dauert manchmal einen kleinen Moment, in der Regel aber nicht mal eine Sekunde. Die (komplett unveränderte und erwiesenermaßen funktionierende) 2.0.0-beta-Node, die ich zum Testen verwendet habe, zeigt über die serielle Konsole genau das Verhalten, das Du bei Deiner 08/15-Node auch beschreibst: erfolglose Suche nach einem GW...

Zuerst hatte ich den Verdacht, dass es mit einem Update des GW's auf den Stand 2.0.1-beta zu tun haben könnte (es lief vorher als 2.0.0-beta mehrere Monate problemlos), dann habe ich den Punkt "check your wirings" ausgiebig strapaziert, diverse neue GW's zusammengestöpselt und mit unterschiedlichen Versionen und Sendeleistungen geflashed (2.0.0 und 2.0.1-beta), zwischendurch den Pi x-mal neu gestartet, die USB-Buchsen (HUB, aktiv gepowered) durchgewechselt, immer dasselbe Ergebnis :(.

Vorgestern habe ich dann eines der GW's mal zum Repeater umgeflashed. Es wurde auch FHEM-seitig als neues Gerät erkannt und diese eine Node aktualisiert ihre Daten (Sketch-Info etc.) auch, wenn ich sie neu strate; die NRF's scheinen also auch noch zu funktionieren :-\. Und FHEM-seitig scheint ebenfalls kein Verarbeitungsproblem vorzuliegen. Was ich noch nachsehen wollte war, ob das GW auch wieder in einen "startup complete"-Status wechselt, wenn es die Sketch-Info-Daten vom Repeater erhalten und an FHEM weitergegeben hat.

Wobei ich hinsichtlich der selbst gesetzten Ursachen noch eines ergänzen sollte: Das Problem besteht seit Samstag vor einer Woche und da hatte ich kurzzeitig mal zwei gepatchte *.pm von Hauswart im Einsatz. Die wollten nicht wie geplant (die FHEMWEB-Seiten der devices waren ganz leer), daher habe ich sie wieder runter und durch die Version von sourceforge ersetzt; danach sah alles erst mal wieder wie gewohnt aus, nur habe ich halt keine (bzw. nach meiner Erinnerung nicht mehr alle) Daten von meinen Nodes empfangen (also z.B. nur 2 von 5 Temperaturwerten einer 5-fach-Temperatur- und-anderes-Node). Das habe ich aber erst mal einem Sektch-Update zugeschrieben, bis ich dann festgestellt habe, dass gar nichts mehr ankommt...

Demnächst wollte ich dann mal testen, ob eine komplett neue Sensor-Node mit demselben SW-Stand erwartungsgemäß funktioniert. Das alles ist irritierend, da das Funkprotokoll sich eigentlich nicht geändert hat und daher die "alten" Sensoren ohne weiteres weiter funktionieren sollten (was kurzzeitig auch der Fall war). Und bislang hatte ich nie Probleme beim Mischen unterschiedlicher Versionsstände.

Aber nachdem Du offenbar ein ähnliches Problem zu haben scheinst, liegt es evtl. doch an etwas generellem.

Welche MySensors-Version hat das GW?
Was ist der Stand Deiner Module?
Hast Du sonst irgendwelche Änderungen an Deinem Setup vorgenommen?

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

Meister_Petz

Bei mir sind die Eckdaten wie folgt:
- 2 unterschiedliche FHEM Installation getestet (Raspian / Debian)
- Debian läuft schon länger und hat ein funktionierendes MySensors Gateway via USB dran
- Raspian ist ziemlich frisch installiert

- MySensors Version ist (1.5.4) sowohl Node als auch Gateway

Beta-User

Das verstehe ich nicht ganz.

Heißt das Du nutzt beide OSe abwechselnd am selben Rechner?

Da das eher nicht so klingt: Laufen beide GW's gleichzeitig mit demselben Kanal nebeneinander? Oder nur mal das eine, dann das andere?

Funktioniert das serielle (=USB)-GW wie es soll, wenn es an dem PI (Raspbian) angeschlossen ist? Oder funktionieren dort beide GW's nicht?
Funktioniert das WLAN-GW an dem Debian-Rechner oder zeigt es dort dasselbe Verhalten mit dem "startup complete"?

MaW: liegt es ggf. an der OS-Version?!?

(Anmerkung:
Es gab einige Leute, die mit dem ESP-GW seltsame Werte empfangen haben, sobald mehrere Sensoren im Netzwerk funken; da wäre wohl ein Update anzuraten, aber das ist eine andere Geschichte)
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

Meister_Petz

Aaaalso,

die zwei FHEMs (Debian/Raspian) laufen unabhängig von einander und waren nicht gleichzeitig am WLAN Gateway. Am Debian hängt das serielle GW und das funktioniert prächtig.

nun hab ich aber mal das WLAN GW auf 2.0 geflasht und tata... nun klappts auch mit nem 1.5.4 BinarySwitchSensor... was meine eher komplexen selbst gestrickten sensoren auf 1.5.4 machen, weiß ich noch nicht, aber ich werde berichten

Beta-User

Schön zu hören, dass es tut!

Zitat von: Meister_Petz am 26 Oktober 2016, 16:29:47was meine eher komplexen selbst gestrickten sensoren auf 1.5.4 machen, weiß ich noch nicht, aber ich werde berichten
Das sollte kein Thema sein, hatte auch lange eine komplexere 1.5.4-Node an dem 2.0.0-beta-GW...
Nach meinen letzten Erfahrungen: Don't touch it!
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

Sidey

 Ich hatte kürzlich auch Probleme , neue Sensoren anzulernen.

Ich glaube, das Gateway speichert sich die IDs der einzelnen nodes. Wenn ein Node neu geflasht wird, dann klappt eventuell die Zuweisung der ID nicht.

Probiert mal, eurem node eine feste ID zuzuordnen oder sein eeprom zu löschen.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Na ja, wie es ausschaut, war bei Petz das Problem die veralteten ESP-Sourcen bei dem GW, die vermutlich timing-Probleme verursachen.
Zitat von: Sidey am 26 Oktober 2016, 20:25:34
Ich hatte kürzlich auch Probleme , neue Sensoren anzulernen.

Ich glaube, das Gateway speichert sich die IDs der einzelnen nodes. Wenn ein Node neu geflasht wird, dann klappt eventuell die Zuweisung der ID nicht.

Probiert mal, eurem node eine feste ID zuzuordnen oder sein eeprom zu löschen.

Grüße Sidey
Die ID's vergebe ich immer "hart" per Sketch, weil ich die Arduinos für's Testen in der Regel erst mal im Kreis rum verwende und damit genau das Problem umgehe, das Du andeutest; allerdings glaube ich nicht, dass auf dem GW irgendwas gespeichert wird, die ID findet sich m.E. nur im EEPROM der Nodes.

Womit ich im Moment rumkämpfe, ist etwas definitiv anderes, ich weiß nur noch nicht so genau, was :(
Am Wahrscheinlichsten erscheint mir, dass die aktuelle 2.0.1-beta mit allen Vorversionen inkompatibel ist! Im Moment blicke ich noch nicht so richtig durch, was da eigentlich passiert (ist), weil dann an diesem Chaos-Wochenende irgendwann auch noch meine Festplatte vom Laptop kaputt gegangen ist und ich die jeweils letzten Stände der vielen Änderungen noch nicht im Backup hatte....
Jedenfalls habe ich vorhin noch einen existierenden 2.0.1-beta-Temperatursensor in Betrieb genommen und siehe da: das GW ist zwar lt. FHEM immer noch auf "startup complete", empfängt aber trotzdem Daten von der Node ???.

Zwischenbefund also: Funktechnisch sind die 2.0.1-beta-Nodes nicht kompatibel mit den Vorversionen, mögliche Ursachen:
- Der NRF-Treiber wurde massiv überarbeitet  (und der Chip braucht deswegen evtl. mehr Strom, was Reboots verursachen könnte?)
- Der Initialisierungsablauf zwischen GW und Nodes läuft etwas anders als zuvor (before()->presentation()->setup()) und das bringt die "alten" Nodes aus dem Tritt. Das halte ich zwar für eher unwahrscheinlich, es ist aber GW-mäßig die letzte mir bewußte Änderung.
Da letzteres wohl für eine saubere Ansprache von SPI-Geräten erforderlich zu sein scheint, werde ich wohl jetzt erst mal alle meine Nodes auf 2.0.1-beta bringen, Eingriffe in die Sketches sind dabei nach meinen bisherigen Erfahrungen an sich nicht erforderlich (jedenfalls wenn man nicht die Funktionalität gleich mit ändern will/muß ;) oder die libs für einzelne Sensoren geändert wurden (Dallas-Temp...)).

Weitere Info folgt.
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

Boomel

Hallo,

sorry für die Wiederbelebung des alten Threads, aber ich hätte eine kleine Bitte.

Ich habe ein mysensors Netzwerk für jeden Raum, dass unter der 1.5er super lief. Mit Switch auf die 2.0 bzw. die aktuelle 2.1 funktioniert nur noch mein serial gateway mit einem dht22.

Kein einziger Sensornode bekommt eine ID zugewiesen.

Könntet ihr euren Node-Sketch und die Settings bzgl. MY_NODE_ID ; MY_PARENT_NODE_ID etc hier posten?

Das die Hardware sicher geht und es irgendwas am Code ist, weiß ich durch die Funktionalität der HW unter 1.5.


Vielen lieben Dank!

Beta-User

Hi Boomel,

Du lieferst m.E. etwas wenig Info, was Dein Problem angeht...
Vorab: an welcher Stelle steht Dein GW in der fhem.cfg. Das klingt erst mal danach, als hättest Du Dein altes WIFI-GW gelöscht und das serielle neu angelegt. Das führt vermutlich zum ersten Problem. Das solltest Du ggf. als erstes tauschen, u.U. müssen die alten Nodes erst mal gelöscht werden...

Was war das "alte" für ein GW? Wenn es ein Sensbender-GW war: entsprechende Board-Def von MySensors dafür ausprobieren. Für ein LAN-GW und serielles GW: Board-Definitionen <=1.6.11 verwenden (IDE: Board-Manager).

Ansonsten: Infrastrukturangaben, IDE (Art+Version), MS, Linux- oder ...?????

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