Hallo,
ich habe einen Satz von den Xiaomi Aqara Sensoren am Laufen, die Temperatur, Luftfeuchtigkeit und Luftdruck messen. Ich verwende die Xiaomis mit Koenkk's zigbee2mqtt und einem CC2531.
Allerdings bin ich mit deren Sendebereitschaft nicht sonderlich zufrieden. Die Sensoren arbeiten nach dem Verbinden recht solide für ein paar Tage, stellen dann aber in der Regel das Senden der Updates ein - und zwar durch die Bank alle.
Hat da jemand ähnliche Erfahrungen gemacht, bzw kann mir einen Tipp geben, wie man das Verbindungsverhalten verbessern kann?
Habe die Aquara in Betrieb, allerdings direkt am Xiaomi Gateway (mit gekappter Cloud) und hab bzgl. Update von Werten kein Problem...
Wie sind denn die Entfernungen?
Bei mir (Wohnung) max. 10m zum Gateway durch max. 2 Wände...
Habe da eher wenig(er) Vertrauen in die Messwerte... ;)
Gruß, Joachim
Hatte einige Sensoren (Aqara Fenstersensoren) die beim Positionieren einwandfrei gefunkt haben aber bereits am nächsten Tag kein Signal mehr ankam. Abhilfe schafften dann nur Repeater (z.B. Osram Smart+ oder HUE/Ikea Birnen.
Der einzige Aqara Temperatursensor zeigt sehr unterschiedliche Werte zu dem Messgerät daneben an. Frage ist, welcher der beiden Sachen liegt mehr daneben ;)
Zitat von: MadMax-FHEM am 10 Januar 2019, 07:52:17
Wie sind denn die Entfernungen?
Bei mir (Wohnung) max. 10m zum Gateway durch max. 2 Wände...
ich habe den ZigBee ein Stockwerk über den eigentlichen Sensoren. In der Nähe der Sensoren habe ich auch noch ein Osram Smart+ Plug am laufen - das lässt sich eigentlich gut schalten, die Zeitschaltfunktion läuft derzeit aber nur noch in "Aus"-Richtung - "An" muss ich händisch schalten. Das muss ich mir nochmal anschauen.
Entfernung habe ich auch schon in Verdacht - ich habe mir jetzt mal eine stärkere Antenne für den Stick bestellt, mal sehen ob das eine Verbesserung bringt.
Zitat von: Xell1984 am 10 Januar 2019, 10:38:20
Hatte einige Sensoren (Aqara Fenstersensoren) die beim Positionieren einwandfrei gefunkt haben aber bereits am nächsten Tag kein Signal mehr ankam. Abhilfe schafften dann nur Repeater (z.B. Osram Smart+ oder HUE/Ikea Birnen.
Der einzige Aqara Temperatursensor zeigt sehr unterschiedliche Werte zu dem Messgerät daneben an. Frage ist, welcher der beiden Sachen liegt mehr daneben ;)
Ich denke das mit den Messwerten gilt für die meisten Sensoren. Ich habe bis jetzt nur Sensoren von Xiaomi und die Thermostate/Wandthermostate von Max! im Einsatz - die scheinen die Temperaturen alle irgendwie nur zu raten. Bei den Max! kann man ja noch einen Offset reinsetzen, was jetzt aber bei mir auch nicht wirklich zuverlässig funktioniert. Dann habe ich noch eine Wetterstation von TFA-Dostmann mit einem 868MHz Aussensensor - sowohl Innen- als auch Aussentemperatur werden da wenigstens 2° zu hoch angezeigt.
Seit Ende November '18 nutze ich eine breite Palette von ZigBee-Geräten (derzeit 21 Stück verschiedener Hersteller: Hue,Osram,Xiaomi); erfreulicherweise gibt es bislang keine Probleme.
Infrastuktur bildet dabei ein CC2531-USB-Stick sowie ein Osram Smart+ Plug. Diese beiden Geräte reichen aus, die komplette Wohnung "auszuleuchten" - die linkquality reicht dabei von 31 bis 157.
Die Messwerte der Xiaomi-thp-Sensoren sind vergleichbar mit denen von Hue und Homematic - ohne Korrekturwert liefern alle keine wirklich brauchbaren Werte.
kann man bei den Xiaomi's denn einen Offset setzen?
Nein, nicht direkt im Gerät.
Ich nutze für das Auslesen der Temperatur nicht das originäre Reading temperature, sondern ein über alle Temperatur-Geräte (Sensor,Steckdose,Bewegungsmelder,...) normiertes userReading. Bei der Gelegenheit filtere ich ungeliebte Zeichen heraus, wende einen zum jeweiligen Gerät passenden Korrekturwert an, usw.
ich habe jetzt mal testweise eine externe Antenne von meinem CUL an dem CC2531 angesteckt und bekomme auch prompt wieder readings gesendet. Allerdings ist mir aufgefallen, dass die Batterien der Xiaomis schon ziemlich leergenudelt sind - und das, obwohl ich die erst kurz vor Weihnachten in Betrieb genommen hatte :o
Scheint also wirklich auf Empfangsprobleme hinauszulaufen...
Auch ich kenne das Problem mit der Reichweite bei dem AQARA. Abhilfe hat nur eine verringerung des Abstandes gebracht. Erst dann haben sie wieder nach etwas Zeit angefangen zu funken.
Ich habe im Haus mehrer Zigbee Geräte (Lightify Gateway, Birnen und Plugs, Huhe Gateway für den Garten (draußen)) verteilt, jedoch erfüllen die nicht das geforderte Repeaten. Der CC2531 Stick ist leider im Keller angebracht.
Die leere Batterie kenne ich auch von dem Tmperatursensor, auch ein Tausch hat nur kurzfristig für Erfolg gebracht, jetzt meldet er schon wieder das die Batterie am Ende ist.
Die 2032 nicht im 5-er-Pack (?) im Billigstladen holen.
Die sind meistens schneller leer, als eingebaut.
die 2032 gibts relativ günstig im 10er oder 20er Satz in der Bucht.
Ich habe jetzt an meinen 2531 eine externe WLAN-Antenne mit 13dbi gehängt. Die Antenne hatte ich noch von meinen Linksys-Zeien über - die Antenne hängt jetzt über einen Sockel-Adapter am Stick. Am Anfang wollte das nicht so recht - als ich den ganzen Rechner aber neu gebootet hatte lief das Zigbee los und in 2 Tagen hatte ich jetzt auch keine Ausfälle.
Ich meine auch, dass sich der batter_level nicht weiter reduziert hat - das kann aber auch Einbildung sein ;)
Ich würde aktuell nicht zuviel auf die Batterieanzeige geben. Dachte am Anfang auch ich muss die Batterie wechseln und hatte nach kurzer Zeit wieder "nur" 42%.
Wenn ich es allerdings richtig verstanden habe, "berechnet" zigbee2mqtt die Batterieanzeige aufgrund der gemessenen Spannung. Und so wie ich das sehe ist hier sehr sehr viel Luft. Ich lasse die Batterien jetzt erst mal drin bis ich wirklich Probleme sehe. Bisher gehen alle Devices noch ohne Probleme.
Viele Grüße,
mthome
Zitat von: MadMax-FHEM am 10 Januar 2019, 07:52:17
Habe die Aquara in Betrieb, allerdings direkt am Xiaomi Gateway (mit gekappter Cloud) und hab bzgl. Update von Werten kein Problem...
Hallo Joachim
Wie hast Du den Xiaomi Gateway ins FHEM verbunden?
Ist aber schon wirklich lange her... ;)
Hab das nicht mehr in Betrieb.
Waren mir gerade bzgl. Luftfeuchte (deutlich) zu ungenau und nach einem Umzug (neuer PI bzw. neues OS oder doch beides ;) ) hab ich den Gateway rausgeworfen...
Aber war hierüber (soweit ich das noch im Kopf hab):
https://forum.fhem.de/index.php/topic,78418.0.html
Bzw.:
https://forum.fhem.de/index.php/topic,63212.0.html
Und:
https://github.com/T0RST3N/fhem-XiaomiSmartHome/wiki
Allerdings hab ich im Kopf, dass das jetzt auch ohne Xiaomi-Gateway gehen soll...
Hab ich aber nicht ausprobiert...
Gruß, Joachim
Vielen Dank Joachim,
Hab den Hub aufgrund der Beiträge und dem Xiaomi Modul einbinden können, sehe aber dort keine Sensoren (wie auch schon im anderen Tread von Superposchi schon erkannt). Werde in dortigen Beitrag weiterfragen ;-)
https://forum.fhem.de/index.php/topic,78418.240.html#ratethis (https://forum.fhem.de/index.php/topic,78418.240.html#ratethis)
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
Und hier der Anhang ;-)
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
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
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.
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...
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
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.
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.
Ah, ok, dann ist das bei MAX! (etwas) anders... ;)
Aber dann sollte das at (wenn auch "unschön") helfen...
Gruß, Joachim
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.
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
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.
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
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 (https://compatible.openmqttgateway.com/index.php/product/xiaomi-mi-jia-ble-lywsd03mmc-indoor-mini-weather-station/) und den "runden (https://compatible.openmqttgateway.com/index.php/product/xiaomi-mi-jia-ble-indoor-weather-station/)", 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...
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.
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...!
Mach ich natürlich.
Hier gehts weiter
https://forum.fhem.de/index.php/topic,68961.msg1111118.html#msg1111118
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...
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
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 ;) .
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 (https://compatible.openmqttgateway.com/index.php/product/xiaomi-mi-jia-ble-lywsd03mmc-indoor-mini-weather-station/) und den "runden (https://compatible.openmqttgateway.com/index.php/product/xiaomi-mi-jia-ble-indoor-weather-station/)", 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.