(gelöst) OpenMQTTGateway XiaomiBTLESens

Begonnen von traders-banquet, 25 März 2022, 09:16:52

Vorheriges Thema - Nächstes Thema

traders-banquet

Hallo,

ich habe mir das openmqttgateway v0.9.11 auf einem ESP32 mit Bluetooth installiert und gestartet.

In Fhem mit :
defmod OpenMQTTGateway_ESP32_BLE  MQTT2_DEVICE OpenMQTTGateway_ESP32_BLE

Das resultierende Device mit attrTemplate auf  openMQTTGateway_MCU eingestellt und das austomatisch entstandene
Device :  MQTT2_oMQTTgw_BT   mit attrTemplate auf openMQTTGateway_BT_scanner eingestellt.

Ich bekomme viele Readings, doch mein Ziel ist es die XiaomiBTLESens  die im Wohnzimmer von  74_XiaomiBTLESens.pm
nicht erreicht werden mit OpenMQTTGateway wieder einzubinden.

Für einen der XiaomiBTLESens kommen folgende Readings an :


C47C8D662ADA_id                           C4:7C:8D:66:2A:DA
C47C8D662ADA_mac_type             0
C47C8D662ADA_name                    Flower care
C47C8D662ADA_rssi                       -91
C47C8D662ADA_servicedata         310298002eda2a668d7cc40d


Keine Temperatur, Fertility, Moisture,Lux, das gilt für alle XiaomiBTLESens Sensoren, mit Ausnahm eines neuen


C47C8D6CA3DC_batt       39
C47C8D6CA3DC_brand    Xiaomi
C47C8D6CA3DC_fer         423
C47C8D6CA3DC_id          C4:7C:8D:6C:A3:DC
C47C8D6CA3DC_lux        29616
C47C8D6CA3DC_mac_type       0
C47C8D6CA3DC_model             Miflora
C47C8D6CA3DC_model_id        HHCCJCY01HHCC
C47C8D6CA3DC_moi                 43
C47C8D6CA3DC_name              Flower care
C47C8D6CA3DC_rssi                  -93
C47C8D6CA3DC_tempc            22.3
C47C8D6CA3DC_tempf             72.14


Werden die ersten nicht unterstützt ?
Mache ich etwas falsch ?
Ich hatte große Hoffnungen auf das openMQTTGateway, doch bin erst einmal sehr ernüchtert.

Beta-User

ZitatWerden die ersten nicht unterstützt ?
Das kann ich zwar nicht direkt beantworten, aber wenn man eine Suchmaschine mit "miflora firmware update" füttert, kommen ein paar Treffer, die (unabhängig) von FHEM und/oder OpenMQTTGateway darauf hindeuten, dass nicht alle gleich sind.

Der RSSI-Wert (bzw. alle gezeigten) sind jedenfalls auch nicht berauschend (bzw. sehr grenzwertig), vielleicht liegt es auch daran?

ZitatMache ich etwas falsch ?
"falsch" ist ein großes Wort...
Der attrTemplate-Satz ist jedenfalls nicht ganz aktuell, eigentlich sollten die BT-Daten neuerdings direkt beim "MCU"-Device verbleiben.

Eventuell ist/wäre es möglich, die Sensoren auch durch aktive Anfragen auszuwerten (wie mit dem Batterie-Reading bei den gtags), allerdings müßtest du dann erst mal rausfinden, welche Datenpunkte vorhanden sind, wie man sie abfragt, und wie sie dann letztendlich zu interpretieren sind. Dazu mal in den "support"-Thread schauen und ggf. einen Link hierher setzen kann nicht schaden, damit sich die BT-Experten das ggf. näher ansehen können.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

tomcat.x

Habe gerade keine Zeit, mich länger damit zu beschäftigen. Aber ich habe auf jeden Fall verschiedene Sensoren im Einsatz (Gehäuse Farbe hat sich irgendwann leicht geändert und es sind auch verschiedene Herstellernamen aufgedruckt), über die Zeit auch verschiedene Firmware Versionen. Alle funktionieren. Die MAC Adressen beginnen bei denen unterschiedlich, C4:7C:8D wie bei Dir ist aber auch dabei.

Der Batteriestand wir seit ein paar Versionen auch schon aktiv abgefragt. Ich wollte schon länger mal ein Update für das Template (OpenMQTTGateway_BT_mi_flora_sensor) schicken ... Aber soweit bist Du ja noch gar nicht. Im MQTT2_oMQTTgw_BT Device sollte die Werte schon sichtbar sein.

Die RSSI Werte sind bei mir einen Hauch besser. Aktuell habe ich aber nur 2 im Einsatz (Terrasse muss erst wieder betückt werden), da ist es -87 und -79.
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

MadMax-FHEM

#3
Ich habe auch welche von der "allerersten" Sorte, die laufen prima mit dem Fhem-Modul (74_XiaomiBTLESens.pm) und einem abgesetzten PI ZeroW...

Habe auch versucht den loszuwerden und einen BTLE-Gateway genommen, bekam die aber auch nicht zum Laufen.

Denke es liegt (bei mir) an der (sehr) alten FW, siehe auch: https://docs.openmqttgateway.com/use/ble.html#receiving-signals-from-ble-devices-mi-flora-mi-jia-lywds02-lywsd03mmc-cleargrass-mi-scale-and-many-more

EDIT: meine FW
firmware 2.6.2
firmware 2.7.0
-> (wohl) zu "alt" laut dem Link...

Welche FW haben denn deine?

Hab schon überlegt mal ein FW-Update zu machen aber deswegen wieder irgendeine App (hatte die ja noch nie in einer App angelernt 8) ) installieren, sich auf einem (China) Xiaomi Server anmelden, die Dinger "anlernen", updaten und dann wieder raus und zurück...

Da kann ich (aktuell) auch noch mit meinem ZeroW leben :)

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

traders-banquet

Mir ist aufgefallen, dass die XiaomiBTLESens auch von dem 74_XiaomiBTLESens.pm nichgt mehr erreicht werden, bzw, keine Daten ausgelesen werdem, ich hatte im Zusammenhang mit den 74_XiaomiBTLESens.pm gelesen, dass man die Grenzwerte sehr gut aus der XIAOMI App heraus holen kann, daraufhin habe ich mir die App installiert und die jeweiligen Pflanzen eingetragen. Dabei wurde wohl die Firmware upgedatet und seit dem bekomme ich keine Werte. Das ist etwa genau einen Monat her ...

Beta-User

Na ja, wenn du die aktuellste firmware hast, würde es ggf. Sinn machen, bei OMG einen neuen Thread dazu aufzumachen und gleich (über den zero-W abgefragt) die Infos zu liefern, welche BT-"Eigenschaften" vorhanden sind. Das ganze betrifft dann nämlich potentiell künftig noch sehr viel mehr Anwender...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

tomcat.x

Meine Firmware ist 3.3.5. Das Update ist einige Zeit her und es wird auch aktuell nichts angeboten.

@Beta-User: Ich bin da auch vorsichtig, aber für die Registrierung wird nur eine (Einmal-) Mailadresse benötigt und die Sensoren sind danach nicht mit irgendeiner Cloud verbunden. Wenn man also nach dem Firmware-Upgrade die App nicht mehr benutzt oder wieder löscht, sollte alles gut sein. Ich habe für so was auch immer mal ein altes Handy rumliegen, wo sonst keine Daten drauf sind.
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

traders-banquet

Vielen Dank für alle Hinweise, es funktioniert nun.
Es ist interressant wie schnell sich die Dinge ändern. Ich hatte auch zuletzt vor 4 etwa Wochen mein FHEW upgedatet. Nachdem ich gelesen hatte, das die Readings wieder auf dem ersten Device landen sollten habe ich wieder alles gelöscht, ein update all gefahren und anschließend das Gateway neu angelegt.
Parallel die App gestartet und musste feststellen, dass ich noch die alte Firmware auf allen Mii Flora's hatte. Es stimmt die Aktuelle ist immer noch 3.3.5. diese habe ich dann auch jeweils eingespielt und sowohl 74_XiaomiBTLESens.pm empfängt wieder Daten als auch das OpenMQTTGateway.
Das stateFormat muss jeweils angepasst werden, da als Reading keine temperature vorliegt aber tempc oder alternativ tempf. Ich muss sagen, so funktioniert es wirklich fein, vielen Dank für alle Hnweise und ich hoffe ich habe nicht zu viel Verwirrung gestiftet.

Beta-User

 :) Danke für die Rückmeldung.
Habe eben das attrTemplate noch angepaßt, damit "temperature" auch wieder unter diesem Namen verfügbar ist, hoffe, der Rest paßt noch...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors