Autor Thema: [74_XiaomiBTLESens.pm] Xiaomi Bluetooth Sensoren FlowerSens/Thermometer  (Gelesen 78155 mal)

Offline Headhunter667

  • New Member
  • *
  • Beiträge: 6
"connect error: Transport endpoint is not connected (107)" kommt bei mir sporadisch wenn ich das Thermometer zu weit weg vom Raspi platziere - direkt daneben praktisch nicht. Das meinte ich mit begrenzter Reichweite: 3m und eine Betonwand gehen, 6m nicht zuverlässig.

Gehe jetzt ins Bett und habe zwei Logfiles voller Temperaturwerte - danke nochmal.
Morgen mache ich Temperaturkurven draus  8)
Gute Nacht!

Offline Kunibernd

  • New Member
  • *
  • Beiträge: 9
Guten Morgen,

bei mir lief das Modul ca. einen halben Tag, so wie es sollte. Doch nun bekomme ich einen "Error" zurück. Da ich dies auch ähnlich bei meinem Bewässerungscomputer GFPROBT beobachte, bin ich mir nicht sicher, ob es am FHEM oder dem Bluetooth meines Raspi 3+ liegt. Ich ein Wiedereinsteiger in FHEM und leider konnte ich nichts weiter in anderen Foren dazu finden. Ich würde mich freuen, wenn mir die Experten etwas auf die Sprünge helfen könnten.
Hier ist der Log:
2020.05.29 09:15:52 4: XiaomiBTLESens (Gartensensor) - Run CreateParamGatttool with mod: read
2020.05.29 09:15:52 4: BlockingCall (FHEM::XiaomiBTLESens::ExecGatttool_Run): created child (18247), uses telnetForBlockingFn_1590696078 to connect back
2020.05.29 09:15:52 5: Starting notify loop for Gartensensor, 1 event(s), first is read sensor data
2020.05.29 09:15:52 5: End notify loop for Gartensensor
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - Read XiaomiBTLESens_ExecGatttool_Run Gartensensor|80:EA:CA:89:48:DF|read|0x38
2020.05.29 09:15:52 4: XiaomiBTLESens (Gartensensor) - stateRequestTimer: Call Request Timer
2020.05.29 09:15:52 4: Connection accepted from telnetForBlockingFn_1590696078_127.0.0.1_44994
2020.05.29 09:15:52 5: Cmd: >{BlockingRegisterTelnet($cl,2262)}<
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: Execute Command ps ax | grep -E [g]atttool -i hci0 -b 80:EA:CA:89:48:DF
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: call gatttool with command: gatttool -i hci0 -b 80:EA:CA:89:48:DF --char-read -a 0x38 2>&1 and loop 0
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: gatttool loop result connect error,Device or resource busy (16)

2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: call gatttool with command: gatttool -i hci0 -b 80:EA:CA:89:48:DF --char-read -a 0x38 2>&1 and loop 1
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: gatttool loop result connect error,Device or resource busy (16)

2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: call gatttool with command: gatttool -i hci0 -b 80:EA:CA:89:48:DF --char-read -a 0x38 2>&1 and loop 2
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: gatttool loop result connect error,Device or resource busy (16)

2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: call gatttool with command: gatttool -i hci0 -b 80:EA:CA:89:48:DF --char-read -a 0x38 2>&1 and loop 3
2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: gatttool loop result connect error,Device or resource busy (16)

2020.05.29 09:15:52 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: call gatttool with command: gatttool -i hci0 -b 80:EA:CA:89:48:DF --char-read -a 0x38 2>&1 and loop 4
2020.05.29 09:15:53 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: gatttool loop result connect error,Device or resource busy (16)

2020.05.29 09:15:53 3: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: errorcode: "1", ErrorString: "connect error: Device or resource busy (16)
"
2020.05.29 09:15:53 4: XiaomiBTLESens (Gartensensor) - ExecGatttool_Run: gatttool result connect error,Device or resource busy (16)

2020.05.29 09:15:53 5: Cmd: >{BlockingStart('2262')}<
2020.05.29 09:15:53 5: Cmd: >{FHEM::XiaomiBTLESens::ExecGatttool_Done('Gartensensor|80:EA:CA:89:48:DF|error|read|0x38|{"gtResult":"Device or resource busy (16)"}')}<
2020.05.29 09:15:53 5: XiaomiBTLESens (Gartensensor) - ExecGatttool_Done: gatttool return string: Gartensensor|80:EA:CA:89:48:DF|error|read|0x38|{"gtResult":"Device or resource busy (16)"}
2020.05.29 09:15:53 4: XiaomiBTLESens (Gartensensor) - ProcessingErrors
2020.05.29 09:15:53 5: Starting notify loop for Gartensensor, 2 event(s), first is lastGattError: Device or resource busy (16)
2020.05.29 09:15:53 5: End notify loop for Gartensensor
2020.05.29 09:15:53 4: XiaomiBTLESens (Gartensensor) - WriteReadings: Readings were written

Lässt sich daraus eine mögliche Ursache ableiten?

Danke für die Unterstützung

Heiko

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25660
Ressource or Device Busy,

Dazu findet man im Internet ein paar Tips. Unter anderem das man den BT Stack neu startet.

sudo hciconfig hci0 reset
sudo invoke-rc.d bluetooth restart
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline Kunibernd

  • New Member
  • *
  • Beiträge: 9
Vielen Dank - das hat temporär funktioniert. Und ja, ich musser vor dem Foren-Eintrag noch besser recherchieren  ;)
Da sich der Stack scheinbar immer wieder mal aufhängt, werde ich mal nach einer Möglichkeit suchen, dies automatisch zu erkennen und diesen dann automatisch zu resetten.

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25660
Vielen Dank - das hat temporär funktioniert. Und ja, ich musser vor dem Foren-Eintrag noch besser recherchieren  ;)
Da sich der Stack scheinbar immer wieder mal aufhängt, werde ich mal nach einer Möglichkeit suchen, dies automatisch zu erkennen und diesen dann automatisch zu resetten.

Oder einfach für 5 Euro einen USB BT Stick holen  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Headhunter667

  • New Member
  • *
  • Beiträge: 6
An dem Punkt stehe ich auch gerade.
Ohne das jetzt zur Kaufberatung ausarten zu lassen: Welcher BT-Stick funktioniert bei Euch?
Da gibt es ja doch ein paar...  ;)

Offline tomcat.x

  • Full Member
  • ***
  • Beiträge: 101
Frage zu Batterielaufzeit und -status bei Flower Care Sensoren ...

Vor zwei Wochen habe ich mich endlich mal daran gemacht, die Sensoren über einen Raspi Zero W anzubinden. Weiß gar nicht, warum ich das so lange vor mir hergeschoben habe, ging dann doch relativ einfach und schnell.

Jetzt habe ich das Problem, dass ich ständig Batteriewarnungen bekomme (ist bei mir automatisch bei allen Geräten mit Reading batteryState so). Prozentwerte lagen unter 10, die entnommene und geprüfte Batterie hatte aber 80, war auch noch nicht sehr lange drin. Nach dem Wiedereinlegen wurde dann beim nächsten Update über 40 angezeigt, danach aber wieder unter 10. Das hat natürlich nichts mit dem Modul zu tun, aber in fhem muss ich im Gegensatz zur Android App natürlich irgendwie damit umgehen. Außerdem stand hier im Forum schon mal, dass der Dünger-Wert unzuverlässig ist, bei der Helligkeit konnte ich das selbst feststellen (bei uns ist es demnach nachts manchmal heller als tagsüber).  Die Feuchtigkeit wäre mir das wichtigste, aber Frage ist halt, ob dieser Wert als einziger zuverlässig ist.

Dazu 2 Fragen:
- Habt ihr dieses Problem auch? Wie geht Ihr damit um? Ich könnte den Batteriestatus einfach ignorieren und die Sensoren Beispielsweise mit readingsWatcher überwachen. Optimal ist das aber halt nicht, besonders weil man dann erst bei komplett leerer Batterie etwas davon mitbekommt.
- Und wie oft fragt Ihr die Sensoren ab bzw. welche Erfahrungen habt Ihr in diesem Zusammenhang mit der Laufzeit der Batterien gemacht?
FHEM: 5.9 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick
Gateways: FRITZ!Box 6591 (OS: 7.12), HomeMatic LAN, Trädfri
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 3098
    • Homepage
Kann ich so nicht bestätigen. Batterien müssen aber gut sein, sonst brechen die zusammen. Nährstoffwerte sind fürn A. aber gut braucht kein Mensch. Helligkeit passt einigermaßen nur da der Sensor eh unter Blättern ist.... In der Nacht heller, neeee nur wenn der Mond drauf scheint. Der Rest passt bei mir. Einzig, dass die Bodenfeuchtigkeit bei 40% auf 20% springt finde ich nicht so toll. Nach einem Batteriewechsel geht es eine Zeit lang und dann wieder nicht.

Also das gelbe vom Ei sind die Dinger nicht aber im Prinzip machen sie was sie sollen.
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline tomcat.x

  • Full Member
  • ***
  • Beiträge: 101
@ext23:

Danke für die Antwort. Meine Batterien sind von Varta, bei anderen Geräten habe ich kein Problem damit. Ich bekomme jetzt noch weitere Sensoren und vergleiche dann mal. Ja, die Helligkeit macht wegen der Verdeckung durch die Blätter keinen Sinn, wie Du schon schreibst. Dünger (Leitfähigkeit) verändert sich mit der Feuchtigkeit beim Gießen, was ja richtig ist, aber eine Auswertung der Werte schon mal prinzipbedingt erschwert, selbst wenn sie korrekt wären. Die Sprünge bei der Feuchtigkeit habe ich auch, allerdings von ca. 50 auf 30. Nach oben beim Gießen sind die ja klar, aber nach unten schon komisch. Da hätte ich eher einen kontinuierliche Verlauf erwartet.

Hast Du das "interval" vergrößert oder fragst Du wirklich ganz häufig ab?

Edit:
Die Theorie "Dünger (Leitfähigkeit) verändert sich mit der Feuchtigkeit" stimmt auch nur beim Gießen. Bei den Sprüngen nach unten bei der Feuchtigkeit, ändert sich da nichts.
« Letzte Änderung: 10 Juni 2020, 13:52:06 von tomcat.x »
FHEM: 5.9 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick
Gateways: FRITZ!Box 6591 (OS: 7.12), HomeMatic LAN, Trädfri
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 3098
    • Homepage
Bei mir sieht das so aus:

https://forum.fhem.de/index.php/topic,82572.msg949434.html#msg949434

Und abfragen tu ich glaube alle 15 min.

/Daniel
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Online MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 7970
  • NIVEAu ist keine Creme...
Also ich hab meine ja schon eine Weile...

Und (noch) keinen FW-Update gemacht.
Habe irgendwas 2.6.2 bzw. 2.7.0

Ich kann weder Sprünge feststellen noch bei den Batteriewerten klagen.

Sprünge habe ich aber evtl. verm. wegen meinem "kontinuierlichen" Bewässerungssystem.
Es ist "physiklaisch", fhem und die Sensoren nehme ich nur: weil's geht ;)
(und wegen Neugierde ;)  )

Ich nutze Blumat, das sind Tonkegel, die bei Trockenheit bzw. wenn sie trocken(er) werden per "Unterdruck" ein "Ventil" öffnen und dann eben Wasser "fließen" (eher tröpfeln) lassen, bis eben wieder feucht genug...

Wie feucht feucht genug ist kann man über eine "Einstellschraube" einstellen...
...Wasser kommt aus einem Tank auf dem Balkon, dessen Wasserstand "überwacht" wird und eine Nachricht schickt, wenn es Zeit wird nachzufüllen (150L ca. 2-3x pro Jahr [Sommer] füllen)...

Die Helligkeitswerte vom ext23 Plot kommen mir etwas (sehr) niedrig vor.
Sonnenlicht etc. ist norm. schon sehr hell ;)

Habe das System nun schon ca. 4 Jahre und die Sensoren jetzt das dritte Jahr...
...dieses Jahr (dank Corona) nocht nicht im Einsatz, bin ja da und kann gießen :)

Anbei Plots vom letzten Jahr...

EDIT: Abfrageintervall ist "Modul-Standard"...

Gruß, Joachim
FHEM PI3B+ Buster: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, KODI, alexa-fhem, ...
FHEM PI2 Stretch: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM PI3 Buster (Test)
FHEM PI3 Stretch (Test)

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 3098
    • Homepage
Das sind Zimmerpflanzen bei mir, Sonne ist da nicht ;-)

/Daniel
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Online MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 7970
  • NIVEAu ist keine Creme...
Das sind Zimmerpflanzen bei mir, Sonne ist da nicht ;-)

/Daniel

Ah, Höhlenbewohner  ;D ;)

Gruß, Joachim
FHEM PI3B+ Buster: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, KODI, alexa-fhem, ...
FHEM PI2 Stretch: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM PI3 Buster (Test)
FHEM PI3 Stretch (Test)

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 3098
    • Homepage
So zu sagen ja, Kellerkind ^^
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline Teamdrachen

  • Jr. Member
  • **
  • Beiträge: 72
Inzwischen gibt es ja eine neue Version der Temp/feuchte Sensoren.

Leider wollen die bei mir nicht. 
setstate Schlafz_Sensor write sensor data
setstate Schlafz_Sensor 2020-06-19 19:45:33 batteryPercent 5.6809773020555e+35
setstate Schlafz_Sensor 2020-06-19 19:45:33 batteryState ok
setstate Schlafz_Sensor 2020-06-19 19:40:51 firmware Time
setstate Schlafz_Sensor 2020-06-19 19:48:36 lastGattError Attribute can't be written
setstate Schlafz_Sensor 2020-06-19 19:48:36 state write sensor data

 

decade-submarginal