HMUARTLGW queue full und Device not initialized but asked to send data

[noansi]

Hallo gritob,

und was passiert, wenn Du die Zeile nochmal raus nimmst?
Martin wird es wohl nur in die aktuelle Version einbauen, wenn es sich reproduzieren lässt.

Gruß, Ansgar.

[gritob]

Hallo gritob,

und was passiert, wenn Du die Zeile nochmal raus nimmst?
Martin wird es wohl nur in die aktuelle Version einbauen, wenn es sich reproduzieren lässt.

Gruß, Ansgar.

Dann kommt es wieder! Hab den Fehler jetzt auch bei nem anderen System gesehen wo es auch viele Wandthermostate gibt. Hab die Zeile dann 1-2 Mal ein- und auskommentiert. Es verschwindet und kommt dann wieder, je nachdem. Also hier funktioniert es wirklich einwandfrei. Weiss zwar nicht was ihr gemacht habt aber die Änderung aus dem letzten Post reicht aus für die Behebung.

[martinp876]

das mit Ansgars Fix kann ich nicht nachvollziehen.
hier meine Fragen:
- Das problematische Device ist ein EP oder en TC?
- es ist immer das gleiche device?
- msgRepeat ist auf 1 gesetzt - damit wird max ein mal wiederholt (darf werden...)
- wenn der Fehler passiert werden nachrichten kontinuierlich wiederholt - alle 3 sec?

wenn der Fehler auftritt bitte
- verbose dieses Device auf 5 setzen
- beim HMLAN das Attribut logId setzen auf die HMid des problematischen Device.
- ein List des Device wenn der Fehler ansteht.

[noansi]

Hallo Martin,

ein Problemdevice ist ein TC. Das List war hier https://forum.fhem.de/index.php/topic,94035.msg870405.html#msg870405.

Problematische messages sind Burst messages gewesen, wie Michael schon bemerkt hatte, https://forum.fhem.de/index.php/topic,94035.msg871132.html#msg871132.

msgRepeat steht beim dem list auf 1, das hat mich auch gewundert, warum es bei dem mit der einen Zeile als Fix helfen sollte. Aber vielleicht war es ein temporärer Zustand. @gritob:
Daher bitte ein aktuelles "frisches" list.

Mehr Infos müssen die User mit Problemen versuchen zu liefern. Eventuell mal mit verbose 5 ab Systemstart für das HMLAN, damit die Vorgeschichte klarer wird.

Gruß, Ansgar.

[gritob]

das mit Ansgars Fix kann ich nicht nachvollziehen.
hier meine Fragen:
- Das problematische Device ist ein EP oder en TC?
- es ist immer das gleiche device?
- msgRepeat ist auf 1 gesetzt - damit wird max ein mal wiederholt (darf werden...)
- wenn der Fehler passiert werden nachrichten kontinuierlich wiederholt - alle 3 sec?

wenn der Fehler auftritt bitte
- verbose dieses Device auf 5 setzen
- beim HMLAN das Attribut logId setzen auf die HMid des problematischen Device.
- ein List des Device wenn der Fehler ansteht.

Frohes Neues, ich kann es bei Gelegenheit nochmal machen. Gibt da nur 1-2 Probleme.

- Ist ein TC
- es ist nicht immer das gleiche Device, weder das TC noch HMLAN
- msgRepeat ist immer noch auf 1 korrekt
- die Nachrichten werden nach Log viel häufiger wiederholt, geschätzt hunderte Male pro Sekunde und dann ist fhem auch tot.

- da es immer ein anderes Device ist, ist das mit dem verbose 5 schwierig
- ähnliches Problem hier auch, müsste theoretisch jeden HMLAN auf jedes in der Nähe erreichbare Device loggen lassen
- wenn der Fehler ansteht, dann kann ich leider Fhem gar nicht mehr bedienen. Also auch nicht per telnet.

Komm ich denn sonst noch etwas intelligenter an die Infos die für euch wichtig sind?

[martinp876]

Du kannst auch einfach alle loggen lassen. Ich wollte nur die Größe reduzieren. Läuft bei mir aber kontinuierlich problemlos mit.

[mgernoth]

Hallo Martin,

das mit Ansgars Fix kann ich nicht nachvollziehen.

Bei einem Burst-Device kann folgendes passieren:

• CUL_HM_respPendTout inkrementiert $pHash->{rspWait}{reSent} (Zeile 7207)
• CUL_HM_respPendTout ruft CUL_HM_responseSetup auf (Zeile 7245)
• CUL_HM_responseSetup liest die resends nur aus $hash->{helper}{prt}{wuReSent} und wenn das leer ist wird 1 angenommen (Zeile 6830ff)
• CUL_HM_responseSetup ruft CUL_HM_respWaitSu mit diesen "falschen" Wert auf (an mehreren Stellen)
• CUL_HM_respWaitSu überschreibt das reSent im Device-Hash mit dem falschen Wert (Zeile 6811)

Damit gibt es dann ein endloses resend, da reSent nie die 3 erreicht.

Ansgars fix setzt vor dem Aufruf von CUL_HM_responseSetup den Wert von $hash->{helper}{prt}{wuReSent} auf den Wert aus $hash->{rspWait}{reSent} und verhindert so das überschreiben. Evtl. ist der korrekte fix aber, in CUL_HM_responseSetup die Variable $rss nicht nur auf den Wert aus $hash->{helper}{prt}{wuReSent} zu setzen sondern auch in $hash->{rspWait}{reSent} zu schauen.

Viele Grüße
  Michael

[noansi]

Hallo Michael, hallo Martin,

danke für's mitschauen!

Ich hatte mich zum Fix an Zeile 7230 und  7233 orientiert, das schien mir wegen der Nähe verständlicher und beeinflusst nicht die bisherige Funktion von CUL_HM_responseSetup/CUL_HM_respWaitSu, um nicht auf die schnelle den Teufel mit dem Beelzebub auszutreiben.

Auch wenn das Attribut msgRepeat auf 1 gesetzt ist, wird bei Zeile 7195 der Spuck nicht beendet, da erst in der Folge auf 2 erhöht wird, dann aber in CUL_HM_responseSetup/CUL_HM_respWaitSu für ein Burst device wieder zu 1 wird.

$hash->{rspWait}{reSent}

hatte ich als $hash->{helper}{prt}{rspWait}{reSent} verstanden?!

Gruß, Ansgar.

[martinp876]

@Michael,

gute Analyse.
Das Problem ist 2. Ich nutze die Burst settings - aber das reSent wird gelöscht.
Ich rette es nun vorher.
@Ansgar: wuReSent macht auch so etwas - aber da es schon namentlich auch für Wakeup ist sollte man es nicht misbrauchen

comming today - danke euch beiden.