[gelöst]Probleme mit receive (alte Daten werden geladen)

[frober]

Hallo zusammen,

ich habe 2 Nodes, die ich für die Bewässerungssteuerung benutze. Als Funktion benutze ich S_Dimmer.
Aus Fhem wird die Zeit in Minuten über percentage gesetzt und mit status das Ventil geöffnet.
Nach Ablauf der Zeit wird das Ventil geschlossen und die Zeit auf 0 gesetzt, beide Zustände werden an Fhem gesendet.

Das funktioniert alles tadellos, weiter benutze ich noch SoftwareACK (V2.3.1), falls von Fhem "keine" Daten kommen, werden diese noch 3x angefordert.

Beim Start der Node werden alle Ventile geschlossen und die Zeiten auf 0 gesetzt, dann wird der letzte Status aus Fhem angefordert und hier liegt das Problem.

Egal, ob Neustart, Hardwarereset über den Taster oder Softwarereset über Bootloader, es wird die Zeit und der Status auf den vorletzten Zustand gesetzt. D.h. bei jedem Reset läuft die Bewässerung an, obwohl in Fhem alles aus war.

Wo liegt hier den Fehler, übersehe ich etwas?

Danke und Gruß
Bernd

[Beta-User]

Kurzfassung meiner Gedanken dazu:

Der einzig mögliche Puffer für Daten auf der FHEM-Seite könnte der ACK-Puffer sein.
Kannst du ggf. nach dem regulären Setzen (wenn also alles grade sauber läuft und der daher auf 0 sein sollte) die Anzahl der eventuell ausstehenden ACK's checken (müßte am IO zu sehen sein)?

Sonst würde ich das eher auf der Node-Seite verorten (Verkehr mit einer Repeater-Node mitschneiden?).

[frober]

ACK und outstandingAck stehen am Gateway auf 0.
Bei beiden Nodes auf 1.

Die letze Beregnung war Gestern, sollte aber zeitlich unabhängig sein, da ich bei dem Regenwetter selten beregnet habe und das Phänomen war trotzdem da.

Repeader-Node, geht das auch bei RS485?

Auf der Node-Seite!? Es passiert ja auch bei einem Kaltstart.

[Beta-User]

ACK und outstandingAck stehen am Gateway auf 0.

Keine outstandingAck => Schleife leer => ziemlich sicher nicht die Ursache...

Es ist ja im allgemeinen schon nicht so, dass FHEM außerhalb des Loggings Kenntnis von historischen Werten hätte, und die MySensors-Module bilden da keine Ausnahme.

Repeader-Node, geht das auch bei RS485?

Macht da afaik keinen großen Sinn, aber man sollte eigentlich den gesamten Verkehr an jeder Node sehen, die ein aktives debug hat. (=> falls es keine gibt, die man anzapfen kann, einfach eine mit leerer Loop an den Bus hängen?)

Auf der Node-Seite!? Es passiert ja auch bei einem Kaltstart.

Den Sketch zu sehen könnte helfen...? Und was unter "Kaltstart" zu verstehen ist, wäre ggf. auch interessant. Alle Readings an der Node gelöscht?

[frober]

Den Sketch zu sehen könnte helfen...? Und was unter "Kaltstart" zu verstehen ist, wäre ggf. auch interessant. Alle Readings an der Node gelöscht?

Mit Kaltstart meinte ich stromlos machen und dann starten. D.h.im Sketch sind die Zeiten auf 0 gesetzt...Die Readings habe ich nicht gelöscht, aber von der Inbetriebnahme weiß ich, dass percentage auf 0 gesetzt wird und Status auf Off. Nur pecentage4 steht auf 90, das ist die Notenschaltung für das Teichbefüllen.
Edit: aktuell wird bei Neustart percentage auf 20 und percentage1 auf 5 gesetzt. Das sind die Zeiten, mit denen ich aktuell beregne.

Im Anhang einer meiner Sketches, sind beide analog aufgebaut. Falls du Lust hast darüber zu schauen.

Debug ist überall ausgeschaltet, mit einer "leeren" Node kann ich es mal versuchen, das dauert aber, da meine Zeit aktuell begrenzt ist.

[Beta-User]

Umfangreicher Sketch, ist nicht so einfach...

Bin nicht sicher, ob es daran liegt, aber es scheint eine gewisse Überschneidung bei den Relay-ChildId's und den PIR-ChildId's zu geben, so dass es sein könnte, dass FHEM auf die Anfrage den aktuellen Status des PIR als Sollstatus des Relays zurückgibt.
Vermutlich kannst du das im Sketch einfacher nachvollziehen und ggf. dann mal testweise die ID's entzerren (ggf. einfach die Logik z.B. auf: PID-ID=Relay-ID+10 umstellen?)

[frober]

Umfangreicher Sketch, ist nicht so einfach...

Bin nicht sicher, ob es daran liegt, aber es scheint eine gewisse Überschneidung bei den Relay-ChildId's und den PIR-ChildId's zu geben, so dass es sein könnte, dass FHEM auf die Anfrage den aktuellen Status des PIR als Sollstatus des Relays zurückgibt.
Vermutlich kannst du das im Sketch einfacher nachvollziehen und ggf. dann mal testweise die ID's entzerren (ggf. einfach die Logik z.B. auf: PID-ID=Relay-ID+10 umstellen?)

Ich dachte die IDs hängen am "Namen" und wären in soweit eindeutig. Kann ich aber gerne testen.

Wobei  die PIR Wasserstandpegelschalter sind, wenn der Teich voll ist, sind alle auf Off.
Desweiteren wäre das auch kein Problem, wenn percentage auf 0 bleibt, dann wird das Relay direkt wieder ausgeschaltet.

Allgemein wg. receive, ich sende die empfangenen Daten in der Node ja nicht wieder zurück an Fhem. D.h. die Readings werden in Fhem beim Senden gesetzt. Soweit ich deinen Code im MysensorsDevice verstanden habe, auch bei receive!?

[Beta-User]

Ich dachte die IDs hängen am "Namen" und wären in soweit eindeutig. Kann ich aber gerne testen.

Das MySensors-Protokoll arbeit intern für die Zuordnung nur mit den Nummern. _Könnte_ also schon sein, dass da was durcheinanderkommt, ist nur ohne passende Devices und deren jeweilige Darstellung in FHEM etwas schwierig, das von hier aus zu beurteilen.

Gilt auch für die Pegelsschalter und die Zeit...

Allgemein wg. receive, ich sende die empfangenen Daten in der Node ja nicht wieder zurück an Fhem. D.h. die Readings werden in Fhem beim Senden gesetzt. Soweit ich deinen Code im MysensorsDevice verstanden habe, auch bei receive!?

Nein, aber das GW sendet vermutlich die mit Ack-Request versendeten Daten autonom zurück an die Node. Kannst du mal Testen, ob der Effekt auch auftritt, wenn das GW gar nicht mit FHEM verbunden ist, wenn die Node startet? Dann kannst du auch (z.B. in der Arduino-IDE) sehen, was da in FHEM an Infos zum Status der PIR ankommt usw..

Generell habe ich ein ungutes Gefühl, dass in dem Sketch die Ack-Behandlung "hinten" ist, mAn. sollte das zuerst abgehandelt werden und der eigentliche Anweisungs-Code nur dann angesteuert, wenn es kein Ack ist, was eingeht.

[frober]

Nach einigen Versuchen, bin ich auch nicht schlauer...

Betreffend dem anhängenden Sketch, es wird immer percentage auf 20 und Status auf on gesetzt, das ist der letzte Beregnerkreis der gestartet war.
Ein Neustart von Fhem oder vom Raspi bringt keine Änderung. Auch das GW hatte ich neugestartet.
Percentage auf einen anderen Wert gesetzt, Relais geöffnet, geschlossen, percentage auf 0, Neustart -> percentage wieder auf 20, hmm

Irgendwo hat sich das verbissen...

Du warst jetzt schneller mit schreiben, ich werde versuchen heute Abend zu testen.

[frober]

Nein, aber das GW sendet vermutlich die mit Ack-Request versendeten Daten autonom zurück an die Node. Kannst du mal Testen, ob der Effekt auch auftritt, wenn das GW gar nicht mit FHEM verbunden ist, wenn die Node startet? Dann kannst du auch (z.B. in der Arduino-IDE) sehen, was da in FHEM an Infos zum Status der PIR ankommt usw..

Ohne Fhem passiert nicht, also es wird nicht beregnet.
Das GW habe ich im laufenden Betrieb umgesteckt, kein Reset etc.
Im Anhang das Log, ich habe doppelte Daten, die nicht von Bedeutung sind, gelöscht und die Payloads kommentiert.
Ich sehe hier nichts, dass weiterhelfen könnte.
Was mir aber aufgefallen ist, beim Brunnenschacht ist aktuell alles ok und nur der Pumpenschacht bekommt die "fehlerhaften" Daten. Es scheint wirklich der zuletzt aktive Beregnerkreis zu sein.

Durch das Einstellen der Beregnerdüsen (Beregnung wurde abgebrochen und die Zeit wurde manuell genullt), Abbruch bei Regen etc. hatte ich hier auch andere Phänomene.

[Beta-User]

...dann müssen wir wohl wirklich mal checken, was am IO rein- und rausgeht...
Sieht jedenfalls auch für mich ok aus, was der logparser dazu ausspuckt.

Irgendwas verdächtiges an den FHEM-Devices zu erkennen? (Speicher mal eine RAW weg, solange die Nodes wieder im "normalen" Modus sind).

Dann bitte die beiden Nodes stromlos, GW verbose auf 5, und dann wieder Strom dran, bis die unbeabsichtigte Begießerei losgeht; danach kann verbose wieder auf default.
Auffälligkeiten im Logfile? (ggf. (auszugsweise) posten)

[frober]

...dann müssen wir wohl wirklich mal checken, was am IO rein- und rausgeht...
Sieht jedenfalls auch für mich ok aus, was der logparser dazu ausspuckt.

Irgendwas verdächtiges an den FHEM-Devices zu erkennen? (Speicher mal eine RAW weg, solange die Nodes wieder im "normalen" Modus sind).

Dann bitte die beiden Nodes stromlos, GW verbose auf 5, und dann wieder Strom dran, bis die unbeabsichtigte Begießerei losgeht; danach kann verbose wieder auf default.
Auffälligkeiten im Logfile? (ggf. (auszugsweise) posten)

Oh man ich sollte mich nicht mit Fhem beschäftigen, wenn ich andere Projekte im Kopf habe...seit Wochen suche ich, wo das Problem liegt und komme nicht darauf. 

Sorry Beta-User, dass ich deine Zeit gestohlen habe.

Ich habe eine Rasenneuanlage und deswegen meine eigentlich Bewässerungsautomatik ( myUtils) nicht in Betrieb.
Aktuell benutze ich Weekdaytimer für den ersten Kreis, die anderen werden nacheinander mit notify gestartet.
D.h. bei jedem Neustart wird das/ein notify ausgelöst.

Schäm....

Nochmals danke für deine Unterstützung.

[frober]

Jetzt weiß ich auch warum mir das nicht aufgefallen ist.
Ich habe nicht wie üblich event-on-change-reading gesetzt, da die Nodes nur geänderte Werte senden.

Das habe ich nun nachgeholt...

Sorry nochmal.

[Beta-User]

  ...kann passieren...

Danke für die Aufklärung, und manchmal ist es ja durchaus hilfreich, wenn man sein "Weltbild" mal wieder prüft.

Das mit der vorrangigen Ack-Behandlung im Sketch könntest du - wenn mal wieder etwas mehr Zeit ist - durchaus mal umstricken, und es ist auch nicht auszuschließen, dass das hier dann irgendwann wieder jemand findet, der ähnliche Symptome - aber andere Ursachen - hat...

PS: Da hast du dir einen guten Zeitpunkt für die Rasenanlage ausgesucht! Ein "besseres" Wetter für neuen Rasen wird man kaum mehr erwischen...

[frober]

Das mit der vorrangigen Ack-Behandlung im Sketch könntest du - wenn mal wieder etwas mehr Zeit ist - durchaus mal umstricken, und es ist auch nicht auszuschließen, dass das hier dann irgendwann wieder jemand findet, der ähnliche Symptome - aber andere Ursachen - hat...

Hmm, bin mir nicht sicher, was du damit meinst.
Ich setze doch einen Zähler, dieser wird, sobald die Nachricht eintrifft auf 0 gesetzt, ansonsten wird der Befehl neu gesendet.

Es gibt bestimmt Verbesserungspotential im Sketch, MySensors ist mein erstes Projekt mit der ArduinoIDE , davor hatte ich nur mal einen kleinen Sketch mit Bascom geschrieben.