Zitat von: Beta-User am 14 September 2020, 11:45:35
habe ich gestern angefangen, meine gesamte (indirekte) Steuerung der Homematic-Raumthermostate darauf umzubauen;
WLAN, DU ?
Ein oder mehrere Gateways, du deckst doch nicht mit nur einem OpenMQTTGateway das ganze Haus (unvorstellbar/durch die Betondecke) ab oder nur 1-2 Räume/ein Stockwerk ?
IR machst du damit vmtl. auch, Anwesenheit (BT) fürs Smartphone ginge ( wenn man das möchte) auch, gibts noch einen weiteren Verwendungszweck bei dir ?
Gruß
Thomas
Ja, WLAN :P ...
Ist aber ausfallsicher, die Thermostate schalten auf den internen Sensor um, wenn im gepeerten Sensor keine Werte mehr stehen (das Löschen ggf. veralteter Werte macht bei mir ein at, siehe https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren)), von daher bringt diese Lösung (die in Variante 1 über ZigBee-Xiaomis läuft, was ich übrigens für die bessere Variante* halte, wenn man ZigBee hat) nur eine Verbesserung des Komforts (die Messwerte sehen bei den Xiaomis insgesamt eigentlich relativ gut aus, von daher dürfte das auch unter diesem Gesichtspunkt keine Verschlechterung sein; neben der ZigBee-Variante habe ich auch zwei LYWSDCGO und eben jetzt den LYWSD03MMC im Einsatz).
Derzeit habe ich ein GW pro Stockwerk, die Reichweite ist relativ begrenzt (bzw. der Empfang), und ich mache im Moment damit tatsächlich nur BT, die firmware war früher bei den "Multi-Varianten" buggy und die selber zu backen war mir erst mal noch too much bzw. meine Versuche bei 0.9.2 waren nicht so erfolgreich, dass ich da viel Mühe reininvestiert hätte. Und mein Receiver spricht seit einiger Zeit Netzwerk, so dass IR nicht mehr besonders wichtig ist).
Anwesenheit (samt Ortung, wo der bessere RSSI ist) ginge damit, aber ich bin über das Experimentierstadium noch nicht so wirklich rausgekommen; WLAN ist für die Androiden tendenziell auch ok, von daher habe ich da auch nicht den großen Druck (und immer gehofft, dass das Thema mal jemand aufgreift, bei dem ich abkupfern kann...).
Grundsätzlich muss ich sagen, dass die OMG's sehr stabil laufen, von daher habe ich beschlossen, diesen Versuch mit der indirekten Steuerung etwas auszuweiten, mal sehen, wie die Resonanz der family ausfällt.
Andererseits habe ich wenig Lust auf weitere WLAN-Geräte, denn sonst müßte ich tatsächlich meine Infrastruktur überarbeiten, habe schon jetzt manche Effekte, die komisch sind (aber gerade noch erträglich)...
Von daher gilt für WLAN in der Hausautomatisierung weiter: Obacht! :-*
EDIT: * besser, wenn man kein Display braucht; ich wollte aber Sensoren mit Display haben, deswegen bin ich überhaupt erst auf die "runden" gekommen. Für die "eckigen" war dann der Spieltrieb iVm. Geiz verantwortlich: die kann man besser ins Regal stellen und kleiner sind die auch, von daher dachte ich, das wäre den Versuch wert (kosteten irgendwas unter 10 Euro, auf die schnelle verfügbare Doku gabs wie bei sowas üblich damals noch nicht so recht)...
Da das Thema ja auf alles passt, packe ich meine Frage auch mal hier rein.
Beta-User hatte geschrieben, "dass die OMG's sehr stabil laufen". Bei mir leider nicht. Nach ein paar Tagen oder manchmal auch nur Stunden sind sie im fhem offline. Es gibt dann auch keine WLAN-Verbindung mehr, ich komme also nicht mehr drauf und kann nichts mehr prüfen.
Bisher nutze ich nur BLE (zur Anwesenheitserkennung und für Mi Thermometer). Es läuft besser, seit ich für die bekannten Geräte eine Whitelist definiert habe.
Zusätzlich habe ich die OMGs einmal am Tag neu gestartet, per Kommando "restart", was auch immer da genau passiert. Allerdings waren heute dann 2 ausgerechnet seit dem Restart offline. Also lasse ich das erst mal.
Ich nutze insgesamt 6 ESP32 NodeMCUs von AZDelivery und dabei 2 verschiedene Type. Aus den Bewertungen kann ich keine Probleme wie bei mir raus lesen.
Haben andere ähnliche Erfahrungen oder Tipps?
Nach meinen aktuellen Erfahrungen scheint zum einen die Zahl der Geräte einen Einfluss zu haben, und zum anderen eventuell auch (betr. die "eckigen Mijia") deren firmware.
Nachdem ich ein paar mehr von den LYWSD03MMC mit der Original-firmware im Einsatz hatte, hat sich hin und wieder (gefühlt alle paar Wochen) mal eines der beiden GW's aufgehängt. Jetzt läuft seit einiger Zeit (~2Wochen oder so?) auf denen ein Mix aus der ATC-firmware und der weiteren gemoddeten firmware (müßte den Link raussuchen), und seitdem ist mir das nicht wieder passiert.
Allerdings habe ich auch an dem einen eine externe Antenne angebracht, kann auch sein, das hängt (auch) damit zusammen.
Danke für die schnelle Antwort. Den Firmware-Link brauchst Du nicht raus suchen, ich benutze vermutlich den gleichen Mix. Die Original-Firmware hatte ich dafür nie im Einsatz, bis vorgestern nur die ATC auf dreien und jetzt die "pvvx"auf 3 weiteren.
Hmm, schade, wäre auch zu einfach gewesen... Dann kommen sich bei dir möglicherweise die bridges selbst gegenseitig ins Gehege?
Evtl. hilft es, die jeweils zu blacklisten?
Ansonsten wäre wohl mal die issue-Liste beim OMG zu durchsuchen und ggf. zu erweitern...?
Zitat von: tomcat.x am 01 Februar 2021, 12:11:55
Beta-User hatte geschrieben, "dass die OMG's sehr stabil laufen". Bei mir leider nicht.
Mit OpenMQTTGateway v0.9.6 bei mir jetzt auch, seit Wochen ohne Aussetzer und Neustart.
Danke für die Rückmeldung, freut mich, dass das jetzt auch bei dir stabiler ist!
In 0.9.6 scheint man den BT-Stack ziemlich überarbeitet zu haben, in https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.6 tauchen jedenfalls 3 oder 4 "under the hood"-Änderungen zu BT auf, und ich meine, dass da jetzt ein anderes Framework im Hintergrund eingesetzt wird.
Scheinbar nimmt das Thema BT auch bei Tasmota Fahrt auf, aber für den Moment habe ich den Eindruck, dass OMG für BT-Zeug (abgesehen von Thermostaten) die einfachste (stabile) Integrationsmöglichkeit bietet. Mal sehen, für's erste bin ich jedenfalls sehr zufrieden mit der Implementierung, und auch die Batterielebensdauer ist ok (die runden@1xAA machen ~ 1 Jahr, die eckigen@1xCR2032 vermutlich länger).
Zitatund auch die Batterielebensdauer ist ok (die runden@1xAA machen ~ 1 Jahr, die eckigen@1xCR2032 vermutlich länger).
Ich hab mich mit dem ESP32 ehrlich gesagt noch nicht beschäftigt, hab gar keinen, war letzte Woche kurz davor einen zu bestellen aber dann doch wieder gelassen. Was versteh ich nicht an 1xAA (1,5-6V) ? (du meinst zwei) und 1xCR2032 (3,irgendwas V), halten die Batterien wirklich ein Jahr oder gehts um die Thermostate ?
Der ESP32 ist vermutlich eher energiehungrig und nicht mit "ein bißchen Batterie" zufrieden. Es ging um die Batterie der BT-Sensoren; der "runde" Xiaomi (mein erster) läuft mit einer AA-Batterie (? oder AAA? Na jedenfalls 1x1,5V), und die habe ich jüngst mal getauscht, also nach über einem Jahr (eher geschätzt 16 Monate). Bei den "eckigen" (LYWSD03MMC) habe ich noch keine Batterie getauscht, soweit ich mich entsinne; die laufen aber auch noch nicht ganz so lange, und ob das Umflashen (effektiv) Auswirkungen in die eine oder andere Richtung hat, kann ich noch nicht abschließend sagen. Aber auch da ist (deutlich) mehr wie 1 Jahr Standard.
(OT: Im Gegensatz zu den besch... Sonoff-ZigBee-Bewegungsmeldern! Da sind die "alten" Xiaomi-ZigBee-Bewegungsmelder eine ganz andere Nummer, die laufen bereits irgendwas über 2 Jahre).
ZitatDa sind die "alten" Xiaomi-ZigBee-Bewegungsmelder eine ganz andere Nummer, die laufen bereits irgendwas über 2 Jahre).
OT weiter ergänzend: das ist bei mir auch so, hab zwei davon (die ohne Lichtsensor) auch schon geschätzt etwas mehr als 1 1/2 Jahre in Betrieb.
Einen seit 04.03.2020 mit der Brücke zwischen den Testpunkten, damit reagiert er alle 6-8 Sekunden, anfangs im Bad, später/jetzt in einem Flur und hat jetzt 86 %, der andere ohne Hack schickt immer noch 100 %.
Hab noch einen mit Lichtsensor (ein,zwei Monate nach den anderen gekauft), ohne Hack, immer noch 100%.