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

[ToM_ToM]

Hallo Zusammen,

das Thema mit dem sporadisch "unreachable" hatte ich auch lange Zeit und bin fast daran verzweifelt.
Die Lösung war, den Bluethooth-Stick an eine USB-Verlängerung zu stecken und somit von den anderen Funkquellen zu entfernen. Seitdem nie wieder "unreachable" und es läuft super. *auf Holz klopf*

VG, Thomas

[CoolTux]

Hier läuft ein Ubuntu in einer VirtualBox VM auf einen MacMini.

Magst Du mal die neue Version testen?

[fhainz]

Jetzt funktioniert es!
state ist auf unreachable, lastGattError auf none und die Werte bleiben erhalten!

Danke!

[CoolTux]

Super. Für das none lass ich mir noch was aussagekräftigeres einfallen. Vielen Dank fürs testen.

[fhainz]

Kommando zurück 

Gerade eben nochmals state = active, werte = 0. Hab davon aber kein Log. Jetzt kommt wieder unreachable, ich lass die Pflanze jetzt mal drüben stehen und beobachte ob das nochmals vorkommt.

[CoolTux]

Nimm mal bitte die neue Version 1.1.47

Danke

[fhainz]

none response data ist besser!

[fhainz]

Morgen!

Über Nacht sind mir 2 Dinge aufgefallen:
- Bei 2 Pflanzen sind die Werte 3x auf 0 gegangen.
- Hast du etwas bei Event-Handling umgestellt? Mir kommt es laut Plot so vor als wenn nur events erzeugt werden wenn sich der Wert geändert hat. Ich hab aber nicht genauer nachgesehen. (Bei mir übergibt das Ubuntu System die Readings via MQTT an mein Haupt-FHEM auf dem MacMini, wo auch die Plots erzeugt werden. Event-on-* ist am Ubuntu System nicht gesetzt, am Haupt-System sehr wohl.)

Die beiden Logs der 0-Werte sehen gleich aus. Hier der Fall um ca. 4 Uhr (grüne Linie).

Code Auswählen Erweitern

2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - WriteSensData: call function ExecGatttool_Run
2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - stateRequestTimer: Call Request Timer
2017.10.01 03:53:14 5: XiaomiFlowerSens (dracaena) - ExecGatttool_Run: call gatttool with command gatttool -i hci0 -b C4:7C:8D:65:55:8B --char-write-req -a 0x33 -n A01F 2>&1 /dev/null and loop 0
2017.10.01 03:53:14 5: XiaomiFlowerSens (dracaena) - ExecGatttool_Run: gatttool loop result connect,Device or resource busy (16)

2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - ExecGatttool_Run: gatttool result connect,Device or resource busy (16)

2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - ExecGatttool_Done: gatttool return string: dracaena|C4:7C:8D:65:55:8B|ok|write|0x33|{"gtResult":"Device or resource busy (16)\n"}
2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - CallSensData: call function ExecGatttool_Run
2017.10.01 03:53:14 5: XiaomiFlowerSens (dracaena) - ExecGatttool_Run: call gatttool with command gatttool -i hci0 -b C4:7C:8D:65:55:8B --char-read -a 0x35 2>&1 /dev/null and loop 0
2017.10.01 03:53:14 5: XiaomiFlowerSens (dracaena) - ExecGatttool_Run: gatttool loop result connect,Device or resource busy (16)

2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - ExecGatttool_Run: gatttool result connect,Device or resource busy (16)

2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - ExecGatttool_Done: gatttool return string: dracaena|C4:7C:8D:65:55:8B|ok|read|0x35|{"gtResult":"Device or resource busy (16)\n"}
2017.10.01 03:53:14 5: XiaomiFlowerSens (dracaena) - ProcessingNotification
2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - ProcessingNotification: handle 0x35
2017.10.01 03:53:14 5: XiaomiFlowerSens (dracaena) - Handle0x35
2017.10.01 03:53:14 4: XiaomiFlowerSens (dracaena) - WriteReadings: Readings were written

Grüße

[CoolTux]

Guten Morgen,

Ich habe in der Tat das schreiben der Readings umgestellt, es werden nur Readings geschrieben welche sich geändert haben und dann auch nur da Events erzeugt.
Ist es sehr störend oder gleicht der Plot das aus?


Grüße

[CoolTux]

Gerade die Fehlermeldung angeschaut. Sieht gut aus das kann ich abfangen. Wird aber wohl nicht bei dieser einen Meldung bleiben. Ich muss mir da was anderes einfallen lassen. Nicht auf Fehler sondern auf Korrektheit prüfen ist da besser.

[fhainz]

Anscheinend gibt es auch noch ein Problem mit dem batteryFirmwareAge Attribut. Die readings wurden gestern ~21:30 das letzte mal aktualisiert. Attribut ist auf 8h gesetzt.

Code Auswählen Erweitern

Internals:
   BTMAC      C4:7C:8D:65:55:8B
   DEF        C4:7C:8D:65:55:8B
   INTERVAL   300
   NAME       dracaena
   NR         30
   STATE      active
   TYPE       XiaomiFlowerSens
   VERSION    1.1.47
   READINGS:
     2017-09-30 21:26:24   battery         ok
     2017-09-30 21:26:24   batteryLevel    99
     2017-10-01 09:14:05   fertility       275
     2017-09-30 21:26:24   firmware        3.1.8
     2017-09-30 21:25:20   lastGattError   none response data
     2017-10-01 09:23:06   lux             131
     2017-10-01 09:08:18   moisture        33
     2017-10-01 09:23:06   state           active
     2017-10-01 09:23:06   temperature     23.3
   helper:
     CallBatteryFirmware 0
     updateTimeCallBatteryFirmware 1506799584.91567
     updateTimestampCallBatteryFirmware 2017-09-30 21:26:24
Attributes:
   batteryFirmwareAge 8h
   interval   300
   room       FlowerSens
   verbose    5
   webCmd     statusRequest

Ist es sehr störend oder gleicht der Plot das aus?

Wenn ich ehrlich bin, ja, handle ich die Events lieber selber. Je nachdem wie ich sie brauche.  Das kann man ja mit den event-on-* attributen wunderbar steuern. Jetzt funktioniert auch leider das event-on-update Attribut nicht mehr. Vielleicht denkst du ja nochmal drüber nach. Würde mich freuen.

Grüße

[justme1968]

um dir sensoren mit dem DeviceMonitor zu überwachen wäre es gut wenn state immer aktualisiert wird wenn das auslesen erfolgreich war und sonst nicht.

[CoolTux]

Du meinst das ein state wie unreachable hinderlich wäre? Aber der User soll doch sofort erkennen wie der Status ist, also unreachable oder disabled.
Hättest Du einen Vorschlag?


Grüße

[CoolTux]

Anscheinend gibt es auch noch ein Problem mit dem batteryFirmwareAge Attribut. Die readings wurden gestern ~21:30 das letzte mal aktualisiert. Attribut ist auf 8h gesetzt.

Muss nicht zwingend kaputt sein. Es gab ja keine Änderungen.
Aber ich merke schon, das mit dem nur bei Änderung aktuallisieren ist doof. Ich Stelle das wieder um 

[justme1968]

er ist nur hinderlich wenn er aktualisiert wird.