[74_XiaomiBTLESens.pm] Xiaomi Bluetooth Sensoren FlowerSens/Thermometer

Begonnen von CoolTux, 11 Januar 2018, 15:42:45

Vorheriges Thema - Nächstes Thema

myrave

Zitat von: Jamo am 12 August 2020, 09:01:21
Ich habe 13 Flower sense am laufen. Ohne Probleme.

Sehr gut, so hatte ich es eigentlich erwartet, dann besteht auf jeden Fall Hoffnung.

Ich habe es auf RPI 4 aufgesetzt mit dem integrierten BT.

Welchen RPI hast du und mit dem integrierten BT Modul oder einem BT USB Stick?
Vielleicht kann es sonst an der Software, also Bluez Version liegen? Welche hast du?

Eventuell reicht hier ja eine Änderung an der Stelle, dass es dann funktioniert.
Ich hatte am Anfang beim Aufsetzen mit Bluez und Gattool einige Probleme,
würde daher nicht ausschließen, dass andere SW / Version daran Schuld ist.

mi.ke

Zitat von: mi.ke am 13 Januar 2019, 18:36:08
Ich tippe auch auf Reichweitenproblemen und/oder zu kurze Abfrage-Intervalle

Bei Reichweitenproblemen zusätzlichen RPiZ über SSH verwenden !

Hier laufen z.Z. (Winter)  17 Stk.
Im Sommer sind es dann wieder ca. 30.
Bluetooth ist auf diesem RPi auch noch mit Anwesenheitskennung und Batterieüberwachung beschäftigt.
Allerdings auf einem anderen hcidevice.

Bei mehrere Sensoren muss/darf der interval nicht zu kurz sein, sonst versuchen doch mehrere Devices/Sensoren gleichzeitig Daten zu bekommen. Cooltux hatte seinerzeit schon eine zufällige Verzögerungszeit eingebaut, die das kompensiert.
Aber mal ehrlich. Pflanzen sind nicht wirklich "plötzlich" trocken und müssen nicht alle 10 Minuten abgefragt werden. 8)

Das einzige "Problem" ist, dass nach dem fhem-Start alle Devices zur gleichen Zeit starten wollen.
Hier hab ich mir ein Script geschrieben, dass nach starten des Hostes alle Devices deaktiviert und dann im Zeitversatz von einigen Minuten nacheinander aktiviert. Das funktioniert dann sehr gut.

Da die Sensoren aber mehr können als "Erde Trocken||Nass" setze ich sie auch z.B. zur Beschattung ein.
Diese haben eine dann einen kürzeren Interval und dafür auch eine höhere Prio beim automatisierten Startvorgang.

Cheers
mi.ke

Oben die Info könnte helfen.

Desweiteren:
Ich nutz einen externen BT-USB Stick, da der RPi auf dem die Pflanzen angefragt werden, noch ein älteres Modell ist.
Zur Abfrage per SSH ist es ein zusätzlicher RPi ZW platziert. Auch hier gehe ich auf externen BT-USB Stick, weil der interne zu wenig Reichweite hatte.

Nutzt Du bzw. Dein RPi den integrierten BT noch für andere Abfragen z.B. presence. Das funktioniert nämlich nicht.
Steck doch einfach mal den 2.ten dazu,
Du kannst mit mit
attr <device> hciDevice hci0 (oder hci1)
die BTs zuordnen und so vielleicht Unterschiede erkennen.

cheers
mi.ke
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

Jamo

Ich habe 3 externe BT Sticks, mit dem internene BT funktioniert das nicht.

1 x für LEpresenced
1 x für Presenced
1 x für was anderes.

Falls Du lepresenced und presenced gleichzeitig verwendest, kann das evtl auch daran liegen.
Du kannst mal mit "sudo service presenced status" und "sudo service lepresenced status" checken, welches hci interface verwendet wird.
Da die sich in die quere kommen, lepresenced aber immer hci1 will, habe ich im /usr/bin/presenced in der Zeile $return = qx(hcitool -i hci2 name $address 2>/dev/null); den hci auf hci2 gestellt (bei 3 externen BT Sticks). Normalerweise steht in der Zeile auch hci1. Kannst Du mit "grep hci /usr/bin/presenced" checken.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

revres

Zitat von: myrave am 12 August 2020, 09:48:03
Sehr gut, so hatte ich es eigentlich erwartet, dann besteht auf jeden Fall Hoffnung.

Ich habe es auf RPI 4 aufgesetzt mit dem integrierten BT.

Welchen RPI hast du und mit dem integrierten BT Modul oder einem BT USB Stick?
Vielleicht kann es sonst an der Software, also Bluez Version liegen? Welche hast du?

Eventuell reicht hier ja eine Änderung an der Stelle, dass es dann funktioniert.
Ich hatte am Anfang beim Aufsetzen mit Bluez und Gattool einige Probleme,
würde daher nicht ausschließen, dass andere SW / Version daran Schuld ist.

Ich habe mittlerweile ein Firmware update gemacht. Seit dem scheint es über das interne modul stabil zu laufen (über 24h.). Mal schauen ob das so bleibt. Ansonsten versuche ich auch mal einen externen stick.


revres

Zitat von: revres am 13 August 2020, 16:42:32
Ich habe mittlerweile ein Firmware update gemacht. Seit dem scheint es über das interne modul stabil zu laufen (über 24h.). Mal schauen ob das so bleibt. Ansonsten versuche ich auch mal einen externen stick.

Leider ist das Problem nicht behoben - auch nicht mit einem externen Dongle... Vll liegt es ja an der neuen Generation?

Headhunter667

Gleiches Verhalten bei mir: Fhem läuft auf einem Raspi3+ egal ob internes Bluetooth oder externer Stick, WLAN habe ich auch schon ausgeschaltet (per config.txt). Die  bei mir derzeit 2 LYWSD03MMC liefern immer nach spätestens 48h, meist viel früher (ein paar Stunden) einen Fehler zurück. Meistens Device or resource busy (16)
Ab und zu Transport endpoint is not connected (107) Letzteres schiebe ich auf Empfangsprobleme, weil sich das meistens von selbst wieder gibt.
Ich denke nicht, dass ich noch einen konzeptionellen Fehler habe, da "verklemmt" einfach immer mal wieder etwas.
Abhilfe schafft immer, sich auf dem Raspi per SSH einzuloggen und diese beiden Befehle ein zu geben:sudo invoke-rc.d bluetooth restart
sudo hciconfig hci0 reset

Wenn ich Zeit habe suche ich mal nach einem weg, auf das Device or resource busy (16) zu triggern und dann ein Shellscript mit den beiden reset-Befehlen auszuführen. Kann eigentlich nicht schwierig sein, schüttele ich nur nicht aus dem Handgelenk.
Vielleicht liest ja jemand mit, dem das leicht fällt und er teilt seine Weisheit mit uns  ;)
Das ist natürlich keine Lösung, sondern ein Workaround. Für mich würde das aber wohl reichen, weil ich eigentlich nur die Temperatur aufzeichnen will.

Holger S

Ich habe es so gelöst

define Restart_Bluetooth notify TempLuft.*:lastGattError:.Device.or.resource.busy.\(16\) {qx(sudo /usr/sbin/service bluetooth restart)}

Headhunter667

Danke für das notify - das hatte ich gesucht. Ich breche mir mit den ganzen Punkten,Sternen und Slashes immer Einen ab. Da kostet mich jede Zeile Stunden. ;)

Leider bringt es bei mir nichts den service neu zu starten. Der bringt aber auch einen Fehler wenn ich den Status abfrage. Wahrscheinlich habe ich zu viel herumgespielt. Aber deswegen setzte ich den FHEM jetzt nicht auf ein sauberes und frisch installiertes raspberry OS.   ;D
Ich werde mal damit experimentieren statt den service neu zu starten ein Script mit meinen beiden Befehlen zu starten - das müsste doch auch gehen.
Wenn's funktioniert poste ich es hier.

Pati_Alpha

Hey, ich habe jetzt schon zum 3. mal festgestellt, dass das XiaomiBTLESens-Modul mein komplettes FHEM lahmgelegt hat!
Diesmal war die Logmeldung die folgende:
2020.08.23 22:25:54 1: Timeout for FHEM::XiaomiBTLESens::ExecGatttool_Run reached, terminated process 755
Connection to 10.0.0.211 closed by remote host.

(10.0.0.211 ist mein RasPi)
Daraufhin ist FHEM komplett nicht mehr ansprechbar. Laut htop hat der FHEM-Rechner aber auch keine Last in der Zeit. Der Raspberry ist auch ansprechbar. Starte ich den Raspberry dann neu, ist FHEM nach ca. 5 Sekunden wieder normal am Start.

Was kann es damit auf sich haben?

Pati_Alpha


CoolTux

Zitat von: Pati_Alpha am 23 August 2020, 23:06:07
Hey, ich habe jetzt schon zum 3. mal festgestellt, dass das XiaomiBTLESens-Modul mein komplettes FHEM lahmgelegt hat!
Diesmal war die Logmeldung die folgende:
2020.08.23 22:25:54 1: Timeout for FHEM::XiaomiBTLESens::ExecGatttool_Run reached, terminated process 755
Connection to 10.0.0.211 closed by remote host.

(10.0.0.211 ist mein RasPi)
Daraufhin ist FHEM komplett nicht mehr ansprechbar. Laut htop hat der FHEM-Rechner aber auch keine Last in der Zeit. Der Raspberry ist auch ansprechbar. Starte ich den Raspberry dann neu, ist FHEM nach ca. 5 Sekunden wieder normal am Start.

Was kann es damit auf sich haben?

Ohne genauere Logausgaben kann man dazu schwer was sagen.
Da die Abfrage der Sensoren nonBlocking passiert sollte FHEM nicht blockiert werden.
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://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tomcat.x

Nachdem ich mit dem Modul einige Pflanzensensoren angebunden hatte und mal wieder einen Temperatursensor brauchte, ist mir eingefallen, dass es da ja auch welche gibt, die mit dem Modul funktionieren. Leider war mir nicht ganz klar, welche das genau sind. Ganz am Anfang im Thema steht was von "runden", die funktionieren und von "eckigen", die das nicht tun. Mehr habe ich auf die Schnelle nicht gefunden.

Da es einen eckigen Sensor für die Hälfte gab und das noch zu einem sehr niedrigen Preis (7,90 bei ebay), habe ich gestern einfach mal einen bestellt. Der wird als "Second Generation" beworben. Eine AAA Batterie (bei den runden) wäre mir lieber gewesen, die CR2032 (in den eckigen) soll aber genauso lang halten und ich wollte auch keine "alten" kaufen.

Jetzt, nachdem der Sensor geliefert wurde, habe ich beim Auslesen der MAC gesehen, dass es ein Modell "LYWSD03MMC" ist und das findet man in den Geräten vom Typ XiaomiBTLESens im Attribut "model" wieder. Aber auch wenn ich damit im Forum suche, finde ich zumindest einen Hinweis unter "FHEM Code changes". Trotzdem wollte ich in einem Beitrag in diesem Thema noch mal darauf hinweisen, dass die Dinger mit dem Modul funktionieren, falls mal jemand anders nach "eckig" sucht, weil er die genaue Modellbezeichnung nicht kennt ;-)
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Invers

Ich hatte die runde Version des BT Thermometers. Die Reichweite ist aber grottig. Wie ist denn die Reichweite bei den neuen LYWSD03MMC ?
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

tomcat.x

Die Reichweite ist zumindest besser als die von einem HMS100TF. Das habe ich vorher dafür genutzt, hatte aber immer Aussetzer. Es ist eine Hausaußenwand und die Wand der Garage dazwischen, Entfernung ungefähr 15m. Wobei beide Wände schräg zur direkten Verbindungslinie stehen. Es gibt auch Fenster, allerdings nicht auf direktem Weg. Aber keine Ahnung, wie sich die Funkwellen verbreiten.

Wenn ich die zusätzlich bestellten bekomme, teste ich mal innerhalb des Hauses. Von den HMS100 habe ich aber ein paar im Haus verteilt und der in der Garage hatte den schlechtesten RSSI-Wert. Wobei das durch die andere Frequenz natürlich nichts aussagt.
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo