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

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

Vorheriges Thema - Nächstes Thema

ToKa

Hallo Cooltux,

Bluetooth 4.0 sollte doch ausreichen oder?

Beta-User hat mir in einem anderen Thread diesen Hinweis gegeben:
Zitat
Würde empfehlen, mal einen von den eckigen mit alternativer firmware zu betanken - geht OTA, wenn man ein Handy+Browser, der Zugriff auf die BT-Schnittstelle hat (bei mir funktionierte es mit Chrome + https://atc1441.github.io/TelinkFlasher.html; über den link kommt man auch an die firmware). Kann sein, dass CoolTux dann ein Log braucht, um den "neuen" Sensor dann auch einzubinden, aber mit der firmware sind die Dinger wenigstens eindeutig benannt (Teile der BT-MAC werden im Namen verwurstelt) und es entfällt die Anmelde-/Ausleseprozedur, was sich auch positiv auf die Batterielebensdauer auswirken sollte...

Bevor ich das aber ausprobiere, wollte ich Dich fragen, ob Dein Modul dann noch funktioniert bzw. ein Log genügt, um die andere firmware zu unterstützen.

Viele Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

CoolTux

Zitat von: ToKa am 05 Januar 2021, 20:38:28
Hallo Cooltux,

Bluetooth 4.0 sollte doch ausreichen oder?

Beta-User hat mir in einem anderen Thread diesen Hinweis gegeben:
Bevor ich das aber ausprobiere, wollte ich Dich fragen, ob Dein Modul dann noch funktioniert bzw. ein Log genügt, um die andere firmware zu unterstützen.

Viele Grüße
Torsten

Das kann ich Dir nicht sagen. Ich kenne weder die Sensoren noch die Firmware. Ich habe lediglich die Pflanzensensoren.
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

ToKa

OK, das war mir nicht bewusst. Vielleicht liest ja sonst jemand mit...
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

tomcat.x

Bei den "eckigen" Sensoren geht es um die LYWSD03MMC oder?

Die funktionieren ja mit dem Modul, nur der Name lässt sich nicht setzen und anscheinend (bei mir hängt keiner richtig draußen, nur einer in der Garage) gibt es noch ein Problem mit negativen Temperaturen.

Empfänger ist bei mir der integrierte Adapter eines Raspberry Pi Zero W, der näher an den Sensoren ist als mein Raspi mit fhem drauf. Das funktioniert ganz gut, außer dass ich den Bluetooth Adapter regelmäßig wegen Fehler "Device or resource busy (16)" neu starten muss ("sudo hciconfig hci0 reset"). Das versuche ich gerade zu automatisieren. Fehler, die ich zuerst auf Empfangsprobleme am Rand der Reichweite geschoben hatte, ließen sich bisher immer damit beseitigen. Ein weiterer Zero an anderer Stelle wäre bei unter 20 Euro (plus meist vorhandenem Netzteil) auch keine so große Investition. Wenn man noch warten kann, dürfte der Preis auch wieder fallen.

Die alternative Firmware hatte ich mal getestet, konnte dann aber mit dem fhem Modul keine Verbindung mehr herstellen und hatte im Zusammenspiel mit dem Modul auch keine theoretischen Vorteile gesehen.

Generell hatte ich mir in dem Zusammenhang aber die Frage gestellt, warum das Modul die Daten aktiv pollt, statt einfach auf die Advertisments zu lauschen. Das kostet zusätzliche Energie, hat aber sicher einen Grund.

Über die Feiertage habe ich zur Anwesenheitserkennung (und später vielleicht mehr) "ein paar" ESP32 in der Wohnung verteilt. Die bekommen die Advertisments auch mit und melden sie per MQTT an fhem. Aber da müsste man dann die Daten selbst extrahieren. Bei den ESP32 gibt es aktuell 3 für den Preis eines Zero.
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

Beta-User

...eigentlich wollte ich hier nicht direkt auch noch was schreiben, ist hier eigentlich nicht meine Baustelle...

Also: die LYWSD03MMC geben ihre Daten mit der Original-firmware nur preis, wenn man sich darauf einloggt. Das sperrt aber offenkundig die Schnittstelle für die Zeit, womit praktisch alle Lösungen ein Problem haben (das Modul hier kann (derzeit) nur einen gleichzeitig und  OpenMQTTGateway auf ESP32 kommt damit uU. auch aus dem Tritt, wobei das auch andere Gründe haben kann).
Diese Art des Auslesens mit login ist für beide Seiten deutlich Energie-intensiver, langfristig spart das also mind. Batterie (wobei die echt auch so ok sind, was das Thema angeht)...

Die alternative firmware ändert das Verhalten, es wird einfach offen versendet, was gemessen wird, ähnlich dem, wie es die älteren "runden" machen.

Vermutlich wäre es überhaupt kein Ding, diese alternative firmware in das Modul zu integrieren, ich nehme an, CoolTux müsste halt wissen, was die so versenden...

Die Daten muss man via MQTT schon "extrahieren", aber eigentlich ist das kein Hexenwerk, und im OpenMQTTGateway-attrTemplate-Set ist auch ein template für die Dinger enthalten. Das fragt dann die BT-Adresse ab; die muss man halt wissen (auch dafür gibt es Hilfsmittel). Ich hatte erst die Original-firmware im Einsatz, und musste nach dem Umflashen NICHTS ändern, die BT-Adresse ändert sich dadurch nicht, nur der Name (den man aber auch afaik mit der neuen firmware nicht ändern kann, der aber dann individuell ist, weil er Teile der BT-Adresse enthält).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ToKa

Hallo Tomcat,

danke für die Informationen und ja es handelt sich um die LYWSD03MMC.

Ich werde es jetzt mal mit einem USB Bluetooth Empfänger probieren und damit vom lepresenced, was ich mit G-Tags für die Anwesenheitserkennung nutze, trennen. Das onboard Bluetooth der Raspis ist nicht besonders stabil. Ich muss auch für die G-Tags ab und an einen "Reset" machen.

Das flashen mit der alternativen Firmware spare ich mir dann, wenn damit keine Verbindung mehr zum Modul möglich ist. Deine Frage zum Advertisment ist hinsichtlich Batterie sehr spannend und vielleicht kann CoolTux uns da ja eine Antwort geben.

Hast Du denn mehrere im Einsatz, nachdem Beta-User schreibt, es funktioniert nur mit einem?

Viele Grüße
Torsten 
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

tomcat.x

#1056
Hallo Torsten,

ich habe aktuell 3 im Einsatz. Die müssen ja nicht gleichzeitig abgefragt werden. Bei Thermometern ist das ok, bei Beacon zur Anwesenheitserkennung wäre es wirklich ein Problem.

Viele Grüße
Thomas

[Edit]
Mir ist gerade noch aufgefallen, dass ich die Aktualisierungsintervalle so eingestellt habe, dass die sich möglichst nicht "treffen".
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

ToKa

Hallo Tomcat,

habe jetzt zwei eingebunden und auch mit unterschiedlichen Intervallen, wobei ich den Eindruck habe, dass das mit den Intervallen nicht wirklich greift. Es kommt trotzdem zu "Aussetzern" z.B. wird einer seit 3 Stunden nicht aktualisiert und es kommt die Fehlermeldung:

Device or resource busy (16)

@CoolTux: Ist es grundsätzlich ein Problem mit mehreren Sensoren? Kannst Du da etwas machen anhand der Fehlermeldung oder benötigst Du ein Log dazu?

Viele Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

CoolTux

Zitat von: ToKa am 08 Januar 2021, 14:26:13
Hallo Tomcat,

habe jetzt zwei eingebunden und auch mit unterschiedlichen Intervallen, wobei ich den Eindruck habe, dass das mit den Intervallen nicht wirklich greift. Es kommt trotzdem zu "Aussetzern" z.B. wird einer seit 3 Stunden nicht aktualisiert und es kommt die Fehlermeldung:

Device or resource busy (16)

@CoolTux: Ist es grundsätzlich ein Problem mit mehreren Sensoren? Kannst Du da etwas machen anhand der Fehlermeldung oder benötigst Du ein Log dazu?

Viele Grüße
Torsten

Mehrere Devices sind kein Problem, aber wenn mehrere Programme auf den Bluetoothstack zugreifen kann es zu Problemen kommen. Zum Beispiel Das Modul hier und lpresented
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

ToKa

Hallo CoolTux,

habe ja einen zweiten Bluetooth Empfänger (hci1) gekauft und über den laufen nur die Xiaomi Sensoren. Die G-Tags mit leprecenced über hci0.

Im Syslog finden sich auch keine Auffälligkeiten und die Intervalle für die beiden Sensoren sind entzerrt. Macht es Sinn verbose auf einen bestimmten Wert einzustellen und mitzuloggen?

VG
Torsten

RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

CoolTux

Zitat von: ToKa am 08 Januar 2021, 16:57:50
Hallo CoolTux,

habe ja einen zweiten Bluetooth Empfänger (hci1) gekauft und über den laufen nur die Xiaomi Sensoren. Die G-Tags mit leprecenced über hci0.

Im Syslog finden sich auch keine Auffälligkeiten und die Intervalle für die beiden Sensoren sind entzerrt. Macht es Sinn verbose auf einen bestimmten Wert einzustellen und mitzuloggen?

VG
Torsten

Bekommst Du gar keine Daten? Zeig mal bitte ein list von einem Device
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

ToKa

Hallo CoolTux,

doch Werte kommen, aber eben zwischendurch auch mal mit längeren Unterbrechungen und Fehlern unter lastGattError.

Internals:
   BTMAC      A4:C1:38:56:4D:A1
   DEF        A4:C1:38:56:4D:A1
   FUUID      5ff36603-f33f-2e5f-f813-bd879db8acd53cbb
   FVERSION   74_XiaomiBTLESens.pm:v3.0.0-s22474/2020-07-26
   INTERVAL   855
   NAME       E1_wz_THHY_Wand
   NOTIFYDEV  global,E1_wz_THHY_Wand
   NR         340
   NTFY_ORDER 50-E1_wz_THHY_Wand
   STATE      Temperatur: 21.09 °C </br>
Feuchtigkeit: 55 % </br>
Stand: 2021-01-08 19:23:00
   TYPE       XiaomiBTLESens
   VERSION    v3.0.0
   loglevel   4
   Helper:
     DBLOG:
       humidity:
         logdb:
           TIME       1610130180.90625
           VALUE      55
       temperature:
         logdb:
           TIME       1610130180.90625
           VALUE      21.09
   READINGS:
     2021-01-08 08:52:12   batteryPercent  63
     2021-01-08 08:52:12   batteryState    ok
     2021-01-07 17:46:24   devicename      LYWSD03MMC
     2021-01-04 20:05:22   firmware        1.0.0_0106
     2021-01-08 19:23:00   humidity        55
     2021-01-08 19:41:04   lastActivity    2021-01-08 19:23:00
     2021-01-08 19:41:04   lastGattError   no data response
     2021-01-08 19:41:04   state           error
     2021-01-08 19:23:00   temperature     21.09
   helper:
     CallBattery 0
     CallSensDataCounter 0
     updateTimeCallBattery 1610092332.59243
     updateTimestampCallBattery 2021-01-08 08:52:12
Attributes:
   DbLogInclude batteryPercent,batteryState,humidity,temperature
   alias      Thermometer Wohnzimmer
   event-min-interval humidity:1800,temperature:1800
   event-on-change-reading humidity,temperature,batteryPercent,batteryState,batteryState
   group      Heizungssteuerung
   hciDevice  hci1
   interval   855
   model      mijiaLYWSD03MMC
   room       XiaomiBTLESens
   sortby     1
   stateFormat Temperatur: temperature °C </br>
Feuchtigkeit: humidity % </br>
Stand: lastActivity
   userReadings lastActivity {ReadingsTimestamp ($name,"temperature","--")}
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

CoolTux

Da wurde mir nur einfallen das Intervall niedriger zu setzen. Sagen wir so 300 zum Beispiel und dann mal schauen wie oft es zu Problemen kommt.
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

ToKa

Kann ich machen.
Komischerweise ist seit gestern Abend 21 Uhr nur bei einem ein Ausfall festszustellen, beim anderen kommen munter die Werte rein.

Vielleicht binde ich den einfach noch einmal neu ein.
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

tomcat.x

Bei mir stehen die Intervalle übrigens alle über 300 (zwischen 350 und 400). Gestern hätte ich fast schon geantwortet, dass es damit und einem täglichen Restart des Adapters ohne Probleme funktioniert. Jetzt hatte ich aber gerade wieder bei 2 den "Device or resource busy (16)" Fehler.

Da ich auf einem meiner ESP32 mittlerweile OpenMQTTGateway installiert habe und es da sowohl für die LYWSD03MMC als auch meine Pflanzensensoren fertige Templates zur Auswertung gibt, werde ich wohl eher den Weg weiterverfolgen. Nur mit der Verbindung zu dem am weitesten entfernten LYWSD03MMC (Garage) habe ich noch Probleme. Da ist der Raspi Zero wohl besser. Aber am Montag kommen 3 weitere (andere) ESP32, die besser empfangen sollen.
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