!!!ABGELÖST!!! [74_XiaomiFlowerSens.pm] Xiaomi Flower Monitor

[CoolTux]

Hi,
teste gerade die neue Version. Komischerweise hängt bei mir schon seit einigen Stunden eine Pflanze im Status "call data":
Ein StatusRequest hat auch nichts gebracht.. Bleibt auf "call data"..

vg stoxx

Oh je, das ist Kacke. Da hilft nur ein reboot von FHEM. Hoffe das ist kein Dauerzustand. Bei mir läuft das Teil sehr sauber.

[CoolTux]

Sollte sich das wiederholen, hätte ich glaube eine Erklärung. Grund könnte ein gatttool Fehler sein, den zurück geben will Blockierend.pm sich aber muckiert weil irgend ein Newline Zeichen mit reingerutscht ist.

Musst Mal bitte verbose 5 an machen und dann ein statusRequest machen.

[stoxx]

Musst Mal bitte verbose 5 an machen und dann ein statusRequest machen.

Mist, jetzt habe ich fhem schon rebootet und alle Sensoren sind active. Ich lasse mal bei der besagten Pflanze nen verbose 5 laufen..

[stoxx]

Habe gerade gemerkt, dass heute zwei Pflanzen im Status "call data" hängen.
Status Request mit verbose 5:

2017.01.24 09:32:44 4: Sub XiaomiFlowerSens_Run (Plant2) - start blocking call
2017.01.24 09:32:44 5: Sub XiaomiFlowerSens_stateRequestTimer (Plant2) - Request Timer wird aufgerufen

Danach tut sich irgendwie nichts mehr..
vg stoxx

[CoolTux]

Ok dann wird es das sein was ich oben geschrieben habe. Schaue ich mir an.

[CoolTux]

So an alle deren Device im call Data hängen bleibt. Bitte einmal die neue Version aus meinem master Github branch laden und testen. Danke Euch

[stoxx]

Okay, ist gemacht. Jetzt habe ich eine Planze, die permanent im Status "charWrite faild" ist.

Hier der verbose 5 Log:

2017.01.24 11:44:47 4: Sub XiaomiFlowerSens_callGatttool (Plant1) - processing gatttool response. sensData: aa 00 00 5b 02 00 00 30 4d 00 00 00 00 00 00 00

2017.01.24 11:44:47 4: Sub XiaomiFlowerSens (Plant1) - call gatttool readBatFw loop 5
2017.01.24 11:44:47 4: Sub XiaomiFlowerSens_callGatttool (Plant1) - processing gatttool response. batFwData: 5c 10 32 2e 36 2e 32

2017.01.24 11:44:47 4: Sub XiaomiFlowerSens_BlockingRun (Plant1) - Processing response data: aa 00 00 5b 02 00 00 30 4d 00 00 00 00 00 00 00

Edit: Jetzt ist der Status auf active gegangen. Komisch..

vg stoxx

[CoolTux]

Okay, ist gemacht. Jetzt habe ich eine Planze, die permanent im Status "charWrite faild" ist.

Hier der verbose 5 Log:

Edit: Jetzt ist der Status auf active gegangen. Komisch..

vg stoxx

Nicht komisch sondern richtig. Das char write faild war die Fehlermeldung von gatttool. Da hatten wir das Problem das er im call data hängen blieb. Jetzt haben wir eine korrekte Fehlermeldung.
Wieso das fehlgeschlagen ist lässt sich wohl nur raten.

[stoxx]

Hi,
das Problem scheint noch nicht gelöst zu sein. Plant2 wieder seit ca. 16 Uhr im Status "call data". Ausschnitt aus dem Log:

2017.01.24 22:06:14 5: Sub XiaomiFlowerSens_stateRequestTimer (Plant2) - Request Timer wird aufgerufen
2017.01.24 22:17:16 4: Sub XiaomiFlowerSens_Run (Plant2) - start blocking call
2017.01.24 22:17:16 5: Sub XiaomiFlowerSens_stateRequestTimer (Plant2) - Request Timer wird aufgerufen
2017.01.24 22:28:29 4: Sub XiaomiFlowerSens_Run (Plant2) - start blocking call
2017.01.24 22:28:29 5: Sub XiaomiFlowerSens_stateRequestTimer (Plant2) - Request Timer wird aufgerufen
2017.01.24 22:39:22 4: Sub XiaomiFlowerSens_Run (Plant2) - start blocking call
2017.01.24 22:39:22 5: Sub XiaomiFlowerSens_stateRequestTimer (Plant2) - Request Timer wird aufgerufen
2017.01.24 22:43:09 4: Sub XiaomiFlowerSens_Run (Plant2) - start blocking call

vg stoxx

[CoolTux]

Wenn er hängt dann bitte ein list machen
Danach musst du leider neu starten. Sorry.
Ich schaue mal nachher was das noch sein kann. Bzw wäre dann auch ein verbose 5 gut. Ich kann auch noch mehr Logausgaben einbauen.

[CoolTux]

Ach ich sehe gerade. Wenn Log dann um die Uhrzeit wo er hängen blieb. Also bei dir 16 Uhr

[Waldmensch]

Bei mir hängen beide Sensoren ebenfalls im Call Data mit der letzten Release. Aber ich glaube sowieso, dass mein Problem VOR FHEM und nicht im Modul zu suchen ist.


Gesendet von iPhone mit Tapatalk

[CoolTux]

Denke nicht. Hängendes Call Data ist ein Problem vom Modul.

Verbose 5 einstellen

FHEM neustarten. Und im Log später um die Zeit schauen welcher timestamp beim state Call Data steht.

[andi11]

Werden die Anfragen eigentlich irgendwie serialisiert, oder anderweitig abgearbeitet, so dass nicht 2 Devices aus FHEM das Gattool gleichzeitig aufrufen?

[CoolTux]

Es kann nicht passieren das gatttool zweimal aufgerufen wird. Die Anfrage landet in einer Warteschleife und wird dann ausgeführt wenn eine etwaige vorhige beendet ist.