OpenMQTTGateway -> MQTT und RollingCode .... mal wieder

Begonnen von Dattel01, 15 September 2019, 21:13:13

Vorheriges Thema - Nächstes Thema

andre07

Du schreibst 1440 sind alle 24 Stunden ? ich dachte die zweite Variable ist angabe in Minuten

Beta-User

Hallo zusammen,

wollte nur mal vermelden, dass es neues bei OpenMQTTGateway gibt: 0.9.5-beta bringt einige Neuerungen im BT-Bereich, u.A. Unterstützung für LYWSD03MMC. Kann noch nicht besonders viel sagen, aber immerhin bekomme ich Daten von dem einem dieser Teile, das hier grade rumsteht.

Geändert/Ergänzt wurde allerdings auch das JSON-Element zum Senden der Temperaturen, da gibt's jetzt tempc und tempf. Entsprechender Update des temp/hum-templates folgt bei Gelegenheit.

Grüße, Beta-User
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

andre07

Habe die Teile schon einige Wochen hier rumliegen automatisch wird da aber nichts angelegt
muss man wohl per Hand machen aber danke für den Tip

Beta-User

Hat jemand behauptet, es würde was automatisch angelegt?
Es ging nur darum, dass die Teile jetzt überhaupt ausgelesen werden können. Ansonsten ist das immer noch dasselbe: Um "Einzel-Geräte" für eine BT-ID zu generieren muss man die ID nehmen und dann mit dem passenden attrTemplate (OpenMQTTGateway_BT_temp_hum_sensor) ein zusätzliches FHEM-Device erstellen.

Was den LYWSD03MMC angeht: Mein Testgerät sendet munter vor sich hin, allerdings sind mir beide GW's mit der 0.9.5-beta und auch mit der jetzt verfügbaren 0.9.5 schon mal hängen geblieben. Dauert ein paar Tage, bis das passiert, und ich kann auch nicht sagen, woran es genau hängt, und die letzten Tage ist es auch nicht vorgekommen...
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

andre07

Bei mir laufen die Teile auch mit 0.9.5  bis jetzt stabil (2 wochen) Abstürze habe ich aber auch schon gehabt mit früheren Versionen. Die LYWSD03MMC sind bei mir eingebunden funktionieren tadellos

Beta-User

Klingt gut.

@0.9.5 (ohne beta) hatte ich auch nur den einen Hänger, das war aber zur Zeit des Schreibens auch schon länger her. Bis dato alles chick...
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

sinus61

Hab gerade mal einen MHO-C401 (https://compatible.openmqttgateway.com/index.php/product/mmc-indoor-weather-station-with-e-ink-display/) mit dem OpenMQTTGateway in Betrieb genommen, ist intern kompatibel zum LYWSD03MMC hat aber ein eInk Display und ist ca. doppelt so groß.

Im Gegensatz zum LYWSD03MMC gibt es aber wohl noch keine alternative Firmware, nutzt daher die "alle-10-Minuten-connect" Methode vom OpenMQTTGateway. Irgendeine App zum Konfigurieren benötigt man nicht, läuft so out-of-the-box.

Macht sich ganz gut wenn man auf die Temperatur leicht ablesen will, da das Display schon deutlicher und größer ist als beim LYWSD03MMC. Abzuwarten bleibt jetzt noch die Batterielaufzeit.


defmod all_MHOC401 MQTT2_DEVICE
attr all_MHOC401 IODev MQTT2s
attr all_MHOC401 event-on-change-reading .*
attr all_MHOC401 group Temperatur
attr all_MHOC401 jsonMap batt:batteryPercent\
hum:humidity\
tempc:temperature\
tempf:0\
volt:batteryVoltage\

attr all_MHOC401 readingList home/(.*)/BTtoMQTT/A4C138BD4569:.* { json2nameValue($EVENT,'',$JSONMAP) }\

attr all_MHOC401 stateFormat T: temperature H: humidity

Beta-User

Danke für die Info, sollte mit "OpenMQTTGateway_BT_temp_hum_sensor" auch direkt via attrTemplate konfigurierbar sein.

Meine LYWSD03MMC (5 oder 6 St. neben 2 runden) laufen seit kurzem alle mit der alternativen firmware. Diese "alle 10 Min"-Connect-Methode habe ich in Verdacht, "schuld" daran zu sein, dass hin und wieder eines der GW's hängen bleibt (ich habe 2 rumfliegen, und gefühlt hängt alle 2-3 Wochen eines der beiden).
Leider ist auch die BT-Reichweite nicht berühmt, so dass zwei, die Luftlinie keine 3m weg sind, allerdings ein Stockwerk höher, nicht oder sehr selten empfangen werden. Jetzt bin ich am Überlegen, ob ich die Antenne umlöten soll (es wird angeblich dieselbe Antenne wie für WLAN genutzt), bei meinem Wasserzähler-ESP32 war das eine deutliche Verbesserung...
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

sinus61

Ich habe 3 Gateways, hin und wieder hängt da auch einer. Die Reichweite ist aber bei mir relativ gut, da übernimmt immer ein anderes Gateway die Sensoren. Bisher hat mich das aber davon abgehalten überall LYWSD03MMC produktiv einzusetzen. Eigentlich hätte ich dafür auch gerne mindestens einen ESP mit LAN Anschluss zum sich nicht vollkommen auf WLAN zu verlassen, die Unterstützung ist aber wohl noch nicht so richtig da.

OpenMQTTGateway ist ja ansonsten schon eine ziemlich gute Lösung, einfach erweiterbar und leicht einzurichten.

Der MHO-C401 ist übrigens von gestern etwa 3V auf heute 2,9V runter. Im Gegensatz dazu ist der LYWSD03MMC mit alternativer Firmware seit 2 Wochen konstant bei 3V. Die Connect Methode ist wohl nicht so optimal. Wäre schade um den MHO-C401, das eInk Display sieht schon viel cooler aus.

xavier

Hallo,

ich versuche, das Vorhandensein von drei G-Tags mit ESP32 anstelle von rPi zu verwalten, aber nachdem ich den gesamten Thread unzählige Male gelesen habe, verstehe ich immer noch nicht, wie man die Räume verwaltet.

Das Modul lepresenced-0.93 generiert bereits die richtigen Readings, die an ROOMMATE übergeben werden sollen, während ich nicht verstehe, wie man mit OpenMQTTGateway dasselbe erreicht.

Ich habe die Struktur erstellt, die am Ende des Wikis vorgestellt wurde, aber ich bekomme nur den gegenwärtigen/abwesenden Zustand, nicht den Raum, in dem ich mich befinde.

Hinweis: Ich habe nirgendwo gefunden, wie eine weiße Liste in MQTT2_oMQTTgw_BT gespeichert werden kann. Es gelang mir erst nach vielen Versuchen (und einigen ESP32-Blitzen). Schreiben Sie in der Gerätekonfiguration nach dem Setzen des Elements "BT_whitelist" neben der Schaltfläche "set" in das Feld an der Seite (z. B. für drei MAC-Adressen):


"AA:BB:CC:DD:EE:FF","GG:HH:II:JJ:KK:LL","MM:NN:OO:PP:QQ:RR"


Hochgestellte Zeichen, Doppelpunkte und Kommas sind erforderlich.

Schöne Grüße,

Xavier


Beta-User

Hmm, ich kenne jetzt wiederum lepresenced nicht (bzw. dieser Dienst wohl als "Methode" unter PRESENCE?), von daher kann ich nicht sagen, wie da irgendwas mit "Räumen" ist.

Um etwas über den Ort zu erfahren, an dem sich jemand befindet, hatte ich mal Code gepostet, um das "beste letzte Gateway" anhand des RSSI-Werts zu ermitteln; darüber könnte man dann ggf. auch den Raum für einen RESIDENT bestimmen. Soweit ich das aber im Kopf habe, hat das bislang niemand aufgegriffen.



Da wir grade beim Sammeln sind, zu dem Whitelist-Thema bzw. zum Wiki:
Ich habe den bekannten Zwischenstand nur von jemandem zugespielt bekommen und das dann ins Wiki gepackt (siehe auch die Info hier: https://forum.fhem.de/index.php/topic,101549.msg1110529.html#msg1110529), aber eigentlich wäre es gut, es würde sich jemand (anderes als ich!) der Sache annehmen und dann auch weitere Erkenntnisse dazu posten.

Mein letzter Stand:
die alternative Firmware zum LYWSD03MMC kann man sehr einfach via https://atc1441.github.io/TelinkFlasher.html OTA auf die Dinger flashen; ich hatte das vor einigen Tagen mal gemacht und kann zur Batterielaufzeit wenig sagen, aber das in Verbindung mit dem Anlöten einer externen Antenne an den ESP32 führte dazu, dass ich im Prinzip alle Sensoren auch mit einem GW empfangen könnte.
Bin nicht ganz sicher, ob sich nicht 2 GW's in die Quere kommen, v.a., wenn man sich auf die Standard-firmware connecten muss...
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

sinus61

Zitat von: Beta-User am 12 Januar 2021, 13:11:38
die alternative Firmware zum LYWSD03MMC kann man sehr einfach via https://atc1441.github.io/TelinkFlasher.html OTA auf die Dinger flashen;

Gibt jetzt unter https://github.com/pvvx/ATC_MiThermometer auch noch eine weiter entwickelte Firmware für die LYWSD03MMC, die soll noch sparsamer im Verbrauch sein und die Einstellung im LYWSD03MMC speichern können, bei der anderen ist nach Batteriewechsel ja eine eventuelle Änderung der defaults weg. Hab schon einen damit geflasht, funktioniert alles gut.  Man kann wohl auch einen Pin vergeben um das Gerät zu schützen.

Für den MHO-C401 mit eInk Display gibt es da jetzt auch eine Version, funktioniert genauso gut. Jetzt muss kein Connect mehr auf das Gerät gemacht werden, damit dürfte der wegen dem eInk Display ja relativ sparsam laufen. Ich werde mir für die Stellen wo man auch leicht mal das Display sehen möchte noch welche davon bestellen, das Display ist selbst im halbdunklen ziemlich gut abzulesen und das Gerät sieht ganz schick aus.

Die Einstellungen im Web Flasher von pvvx sind etwas komplexer, man kann aber fast alles auf Default lassen. Ich hab nur das Advertising Format auf "atc1441" gestellt und 5% Offset für Humidity. Letzteres war aber ja vorher auch schon nötig, da das in der Originalfirmware auch so drin war.

Der MHO-C401 meldet sich nach dem flashen jetzt auch als model LYWSD03MMC_ATC. Ich hab jetzt mal angefangen die zu beschriften, sonst kann man die nicht mehr auseinanderhalten :)

Wenn ich alle meine Temperatursensoren betrachte ist das im Moment die beste Lösung. Kostengünstig, schicker als die LaCrosse Sensoren und melden sich häufiger als die Aqara Zigbee Sensoren.

Meine Gateways laufen derzeit auch störungsfrei, mal sehen ob es da möglicherweise eine Zusammenhang mit den Ausfällen und der Connect Methode gab.