Zuverlässigkeit Xiaomi Aqara Temperatur-Sensoren

Begonnen von NEA, 10 Januar 2019, 07:11:23

Vorheriges Thema - Nächstes Thema

neyzen

#30

Beta-User

Danke.

Trotzdem war diese Frage ja valide (und nur die Diskusion über das "at" [OT]):
Zitat von: neyzen am 16 Dezember 2020, 10:17:09
Kann man den sensor dazu bringen das er öfters sendet.
Vielleicht hat jemand einen unmittelbaren Tipp dazu, manche Sensoren lassen sich ja via deconz konfigurieren, und falls jemand weiß ob bzw. wie es über zigbee2mqtt (&Co) geht, interessiert das ggf. auch jemanden...
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

neyzen

Zitat von: MadMax-FHEM am 16 Dezember 2020, 10:23:57
Du kannst ja auch ein at mit kürzerer Zeit definieren und den aktuellen Wert einfach noch mal setzen, dann sollte ein Event kommen und das ganze gehen...
Bzw. glaube ich nicht, dass es daran liegt...


defmod atTemp at +*00:03:00 {my $value=ReadingsNum("XiaomiTemp","temp",0);;fhem("setreading XiaomiTemp temp $value")}

EDIT: at "korrigiert" auf "wiederkehrend und zyklisch" ;)

EDIT: gut ist halt noch der "alte" Wert... Bzw. was stört? Dass kein Event kommt (da hilft das at normalerweise, außer du hast event-on-change-reading) oder dass nicht schnell/oft genug ein aktuellerer Wert kommt?

Schon mal bei MAX! (also Unterforum) nachgefragt?

Gruß, Joachim

Ich hab jetzt nochmal geschaut. Ich kann ja mit event-min-interval genau das erzeugen was ich hier bräuchte. Ein event bei der es kein update gibt. Würde das hier funktionieren oder denk ich da falsch. Alternative zu deinem at

Beta-User

Jein. event-min-interval erzeugt eine triggernde Aktualisierung des Werts und würde daher auch den Verbindungsabbruch zum Thermostaten verhindern.

ABER: Das erzeugt genau dasselbe Problem, wie wenn man "nur" ein zyklisches at hat und den Wert stumpf übernimmt. Der echte Wert ist irgendwas anderes, und eventuell völlig veraltet, ohne dass es einer merkt... MAn. ein ziemlich mieser Würgaround. Wenn, dann ein zyklisches at, das aber nur ein "trigger"-Kommando (KEIN setreading!) raushaut, wenn der Wert nicht "zu jung" oder "zu alt" ist.

Und das ist jetzt schon wieder an der Grenze zu OT, weil es ziemlich wenig mit der konkreten Hardware zu tun hat! (Ich lese auch an dem anderen Thread mit, ggf. helfe ich dir da auf's Pferd, wenn du dort irgendwas erfolgloses postet, das "if", "ReadingsAge" und "trigger" 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

sinus61

Zitat von: Beta-User am 16 Dezember 2020, 12:27:43
Mit den Aqara bin ich auch recht zufrieden, und auch die Messwerte scheinen soweit zu passen. Die haben aber einen Nachteil: Sie haben kein Display.

Daher hatte ich est mal testweise, und - nachdem das Decodieren der "eckigen" jetzt auch klappt - jetzt in größerer Zahl die BTLE-Konkurrenz von derselben Firma im Einsatz:Den "eckigen" XIAOMI Mi Jia BLE LYWSD03MMC und den "runden", das ganze über OpenMQTTGateway/MQTT2_DEVICE.

Guter Hinweis, davon hatte ich ja auch noch einen liegen der damals noch nicht ging. Eben ein Update für OpenMQTTGateway gemacht und den Sensor mit dem Telink-Flasher umgeflasht und läuft. Das mit dem Web-Flasher ist ja schon ziemlich cool.

OpenMQTTGateway ist natürlich wieder ein extra Gerät dazwischen. Die einzigen Zigbee Temperatursensoren mit Display die ich bis jetzt gesehen habe sind aber die von Blitzwolf, leider recht enttäuschend. Batteriefresser und senden sehr selten.