Zuverlässigkeit Xiaomi Aqara Temperatur-Sensoren

dfk · 24 November 2020, 11:01:09

Zitat von: MadMax-FHEM am 18 November 2020, 14:05:13

Waren mir gerade bzgl. Luftfeuchte (deutlich) zu ungenau ...

Hallo,

Ich habe seit ein paar Tagen zwei xianomi temp/hum/press Sensoren via Zigbee und conbee2 angebunden. Anbei ein Vergleich der Temperatur und Feuchtigkeitswerte mit einem ZWave Everspring ST814, den ich schon seit Jahren benutze und früher einmal mit einem professionellen Hygrometer 'kalibriert' habe. Der Aquara ist nicht ganz so empfindlich aber die Werte stimmen viel besser überein als ich das von so einem kleinen Ding mit einer CR2032 Stromquelle erwartet hatte. Die relativ steilen Stellen in der Feuchte kommen von einem Luftentfeuchter. Der Everspring schickt öfter Werte, aber das kann er sich mit 3AA Batterien auch leisten ....

Nur mein Datenpunkt ...

Daniel

dfk · 24 November 2020, 11:04:43

Und hier der Anhang

dfk · 24 November 2020, 12:20:37

Der Vollständigkeit halber hier noch der Vergleich des zweiten Aquara Sensors mit einem Netatmo Innensensor. Am 22.11 waren wenig Schwankungen, daher ist die Y-Achse nur 3 Grad C bzw. 8% relative Feuchte. Habe wirklich nichts auszusetzen an den kleinen Aquara Dingerchen.

Wieder nur meine Datenpunkte ...

Daniel

Thyraz · 24 November 2020, 20:07:47

Die Dinger sind super und zumindest alle die ich bestellt habe auch für ein Consumer Produkt sehr genau.

Vergleichbar mit den Technoline was Genauigkeit angeht, weit besser bei der Luftfeuchtigkeit als so manches teures Spielzeug wie z.B. Netatmo.

Hatte meine Erfahrungen hier mal zusammengetragen:
https://forum.fhem.de/index.php/topic,98183.msg1016549.html#msg1016549

neyzen · 16 Dezember 2020, 10:17:09

Hallo,
ich teste gerade auch den xiaomi Temperatursensor mit deCONZ. Nutze den als externe Temperatursensor für mein MAX Heizthermostat. Ich hab bemerkt das der sensor leider nur jede Stunde einen Wert Temperatur sendet. Das führt dazu das der MAX dan keine neuen Werte bekommt und vermutlich abschaltet deswegen. Der deCONZ ist etwa 3 Meter entfernt vom Sensor. Kann man den sensor dazu bringen das er öfters sendet.

MadMax-FHEM · 16 Dezember 2020, 10:23:57

Zitat von: neyzen am 16 Dezember 2020, 10:17:09
Hallo,
ich teste gerade auch den xiaomi Temperatursensor mit deCONZ. Nutze den als externe Temperatursensor für mein MAX Heizthermostat. Ich hab bemerkt das der sensor leider nur jede Stunde einen Wert Temperatur sendet. Das führt dazu das der MAX dan keine neuen Werte bekommt und vermutlich abschaltet deswegen. Der deCONZ ist etwa 3 Meter entfernt vom Sensor. Kann man den sensor dazu bringen das er öfters sendet.

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...

Code Auswählen


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

neyzen · 16 Dezember 2020, 10:33:52

Hallo Joachim,

das mit dem at befehl ist eine gute idee. Werd ich mal testen.
Eine Anfrage im MAX Unterforum läuft bereits. Im Wiki steht eben dass wenn keine neuen Werte bis 30 minuten kommen, kann es sein das der Thermostat eben in sein ursprungsmodus geht.

Code Auswählen

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten "fakeWT" aktiviert wird.

MadMax-FHEM · 16 Dezember 2020, 10:35:34

Ah, ok, dann ist das bei MAX! (etwas) anders...

Aber dann sollte das at (wenn auch "unschön") helfen...

Gruß, Joachim

Beta-User · 16 Dezember 2020, 11:06:34

Bei der at-Lösung solltet man aber mAn. noch ReadingAge() checken; ist das älter als 1h, sollte lieber der interne Sensor verwendet werden als ein ggf. völlig veralteter Wert.

MadMax-FHEM · 16 Dezember 2020, 11:32:51

Zitat von: Beta-User am 16 Dezember 2020, 11:06:34
Bei der at-Lösung solltet man aber mAn. noch ReadingAge() checken; ist das älter als 1h, sollte lieber der interne Sensor verwendet werden als ein ggf. völlig veralteter Wert.

Verstehe ich nicht.

Ist doch egal, wenn ich genau den aktuellen Wert des Sensors noch mal in den Sensor schreibe?

Weil es kann ja in fhem (single Thread) nicht/kaum passieren, dass das at den aktuellen Wert (im Sensor-Device) abfrägt und bevor der setreading ("in" dasselbe Sensor-Device) folgt ein neuerer Wert vom Sensor kommt?

EDIT: ah, ok. Interner Sensor des Thermostats... Aber das ist ja genau was passiert (wenn ich das richtig verstanden habe)!? Und das ist doch genau das was nicht gewünscht ist?

Gruß, Joachim

Beta-User · 16 Dezember 2020, 11:43:17

Es geht gar nicht darum, dass sich irgendwas überschneidet, und bei dem vorgeschlagenen einmaligen at ist das auch nicht so das Problem.

Eine "at-Lösung" war auch mal im Wiki zu HM gestanden, daher bin ich etwas "sensibilisiert" für das "Problem", dass so ein Sensor auch mal ausfallen kann und dann _längere Zeit gar keine_ Werte mehr liefert.
Im Wiki war das dann so gelöst, dass ein zyklisches at immer nur stumpf den eben vorhandenen Wert in den virtuellen Thermostat geschrieben hatte (oder bei MAX, wo das vermutlich ursprünglich herkam: erneut versendet?). Macht man das so, hat man irgendwann nicht nur einen "leicht angegrauen" Wert, sondern ggf. einen völlig falschen! Da finde ich persönlich den aktuellen Messert am Thermostaten den besseren Wert...

Die ZigBee-Teile liefern übrigens bei signifikanten Änderungen der Temperatur ggf. auch schneller als 1h Werte, von daher ist es m.E. völlig ok, den nicht mehr zu versenden, wenn die Stunde wesentlich überschritten ist.

Aber du hast recht, wenn man nur (via watchdog, z.B.) ein einmaliges at definiert, das nach (optimalerweise wohl etwas weniger als) 30 Minuten den Wert nochmal sendet, ist das kein größeres Problem.

MadMax-FHEM · 16 Dezember 2020, 11:49:33

Ok, ja das ist nat. logisch, dass man das dann nicht mitkriegt (auf diesem Weg), dass der Sensor u.U. "tot" ist...

Kombination mit watchdog ist eine Möglichkeit...

Man kann auch prüfen (ob der Wert neu "gesetzt" werden "muss": ReadingsAge etc.) und mitzählen (beides z.B. im at) wie oft man denn schon per at aktualisieren "musste"...
...und dann gegebenenfalls eben eine Meldung absetzen.

Aber wie so oft: es gibt viele Möglichkeiten (mit fhem)

Und wie so oft: der Anwender darf entscheiden wie er es machen will

Aber eigentlich war (Fehler meinerseits

) schon ein zyklisches at gemeint (und ich hab's jetzt trotzdem mal "korrigiert", es wurde ja hier auf die "Risiken" hingewiesen)...

Gruß, Joachim

Beta-User · 16 Dezember 2020, 12:27:43

Um wieder in Richtung des eigentlichen Topics zu kommen:

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.

Läuft auch recht gut (hin und wieder muss ich einen der ESP32 neu starten), und auch da sind die Messwerte dem Gefühl nach in etwa auf einer Linie mit dem, was die Aqara liefern. Wenn meine nächste Lieferung kommt, hänge ich evtl. mal einen eine Zeitlang zum direkten Vergleich neben einen Aqara...

neyzen · 16 Dezember 2020, 13:00:36

Ich danke euch beiden für eure Infos.
Prinzipiell ging es mir darum vom internen Thermostat Sensor weg zu kommen und die tatsächliche Temperatur auch am Tatsächlichen Ort zu Regeln. Aber da muss ich noch etwas Feinarbeit reinstecken und das ganze noch beobachten. Deswegen hab ich das auch nur mal an einem Heizkörper getestet, der nicht so Wichtig ist.
Der Sensor hat jetzt auch gerade nochmal gesendet, auch wenn noch nicht die Stunde um war, aber er eine Temperaturänderung hatte.
Ich hab aber bedenken wenn der dann mal die Temperatur vom Sensor nimmt und dann rausgeht in den interne Sensor, das der Regler dann Probleme hat die Wunschtemperatur zu regeln. Der Interne weicht schon um fast 1,5°C ab. Das wäre ja dann ein auf und ab. Dann ist das auch nicht mehr hilfreich.

Beta-User · 16 Dezember 2020, 13:08:47

Zitat von: neyzen am 16 Dezember 2020, 13:00:36
Dann ist das auch nicht mehr hilfreich.

Es ist auch wenig hilfreich, Themen nicht am richtigen Ort zu besprechen (wenn auch verständlich). Das ist ein Thread für Aqara, und damit haben diese Beiträge nur sehr am Rande was zu tun. Würdest du das in dem anderen Thread mit Wzut diskutieren, könnte der ggf. - falls es allgemein Bedarf dafür gibt - eine "automatische Maximal-Wiederholung des alten Werts" ins Modul einbauen und auch was zum Verhalten der MAXe sagen, aber hier ist es einfach nicht relevant...!