Vorstellung & Frage zu Temperatur- & Feuchtesensor

Begonnen von God-of-Games, 01 Juli 2020, 09:31:50

Vorheriges Thema - Nächstes Thema

God-of-Games

Hallo Zusammen,
ich hatte mir vor ein paar Jahren schon mal FHEM angeschaut, jedoch damals mangels zeit ist das ganze dan eingeschlafen. Nun ich der Plan in absehbarer zeit in die eigenen vier Wände zu ziehen und daher habe ich einen Grund mich wieder mit Smart Home zu beschäftigen. Nun habe ich mir überlegt mich schon mit dem System und der Hardware auseinander zu setzten um, wenn es dann "ernst" wird, nicht bei Null anfangen zu müssen.
Aktuell habe ich ein Setup auf einem Pi 3 + und dort ein paar Gosund SP111 mit Tasmota und MQTT angeschlossen. Das war aber auch schon ein kleiner Kampf, da das tasmota_pow Template damals noch einen Bug hatte...

Zur eigentlichen Frage:
Zunächst suche ich eine Möglichkeit die Temperatur- & Luftfeuchte in den einzelnen Räumen zu messen.
Was ich jetzt bisher im Forum gefunden hatte, wäre:

  • LaCrosse TX29 DTH-IT
  • Xiaomi Sensoren (rund und eckig)
  • FS20 / HomeMatic Wandthermostat
Jedoch gefallen mir alle drei Lösungen nicht wirklich, da ich den Pi in einem Serverrack verbaut habe und das für Funkwellen nicht besonders zuträglich ist.
Um trotzdem Funk zu verwenden wäre, wenn ich es richtig verstanden habe, ein CUNX von Busware oder ein weiterer Pi per FHEM2FHEM mit dem Modul. Wobei ich ehrlich noch nicht so richtig verstanden habe wie genau FHEM2FHEM funktioniert und was die Einschränkungen sind. FHEM2FHEM wäre dann auch für die Xiaomi-Lösung notwendig, da die ja per Bluetooth läuft.

Nun bin ich auf die Idee gekommen, mit einem ESP8266, einem BME280 (Sensor für Temperatur- & Feuchte und Druck) und einem e-Ink-Display selbst ein Thermometer zu bauen. Das wäre zwar in Summe bestimmt nicht günstiger als ein HomeMatic Wandthermostat, aber WLAN wäre überall verfügbar und MQTT2 läuft eh schon und scheint je ein etablierter Standard zu sein.
Nun ist mein Problem, dass ich das zum einen nie gemacht habe und ich daher mir aus verschiedenen Anleitungen im Netz was zusammensuchen müsste was am Ende möglicherweise zu einem lauffähigen System führt, zum anderen habe ich keine Idee wie lange beispielsweise ein 18650er Akku hält.

Alternativ wäre ich für weitere Ideen offen.

Viele Grüße aus dem sonnigen Baden,
Jochen

MadMax-FHEM

Also WLAN und Batterie/Akku: naja...

Der Shelly H&T (humidity and temperature) hält (angelich) 1,5 Jahre...
Ein knappes/gutes Jahr hat er bei mir funktioniert...

Bei WLAN kommt noch die WLAN-Infrastruktur ins Spiel: einige Sensoren (evtl. noch Aktoren) und dann nat. auch noch die "ganz normalen" WLAN-Geräte...

Da solltest/darfst du an der WLAN Infrastruktur nicht sparen und Fritzbox ist (nach allem was man [hier] so hört) raus...


Bei Homematic (bidCos!) gibt es noch die Möglichkeit ein Funkmodul per LAN oder WLAN "anzuschließen", dann sparst du dir einen 2ten PI und fhem2fhem...

https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

Bei Homematic IP geht wohl mit (speziellen) Dauerstromversorgten Geräten sowas wie "Mesh"...

Ansonsten (weil brauchst du eh! Für Homematic IP) eine CCU (kann auch ein PI sein) woanders hin und dann Einbindung (ganz normal) per HMCCU-Modul...


Andere Systeme (z.B. ZWave, ZigBee?) sind meshed...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Neubau? Grundlegende Renovierung? => nimm' ein Kabel! (Es gibt einige Lösungen, die z.B. RS485-basiert sind und auch zentrale Spannungsversorgungen möglich machen...)

WLAN ist keine gute Idee, aber wenn, kommt ggf. für die (runden) BT-Xiaomi-Sensoren auch ein OpenMQTTGateway in Frage...

Ansonsten würde ich mal ZigBee (ebenfalls v.a. Xiaomi) ansehen (zigbee2mqtt oder deconz), kann aber sein, dass du - je nach Fläche - netzbetriebene Geräte als Repeater brauchst.

Für reine IO-Lösungen gibt es neben dem CUNO noch MapleCUN/Maple-LAN-Signalduino, ser2net-basierte Lösungen, oder (W-)LAN2serial Bridges (gibt einen Wiki-Artikel dazu.

Kurzum: Informiere dich gründlicher, sonst ist das Risiko enorm hoch, dass du am Ende das Falsche tust oder was unnötig kompliziertes, störungsanfälliges... Und parallel zu Bau-Fragen noch in die Microcontrollerprogrammierung einsteigen zu wollen, ist mMn. "steil". Würde daher erst mal mit was günstigem anfangen (eine der genannten Xiaomi-Lösungen) UND Kabel verlegen, damit du später umrüsten kannst ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

enno

Zitat von: God-of-Games am 01 Juli 2020, 09:31:50
Zunächst suche ich eine Möglichkeit die Temperatur- & Luftfeuchte in den einzelnen Räumen zu messen.

Moin Jochen,

wenn du sowieso ein wenig renovierst, dann schau dir doch 1-wire mal an. Ich hatte als ich noch zur Miete wohnte einen "Probeaufbau" gemacht, Erfahrungen gesammelt und dann als ich das eigene Haus renoviert habe die Kabel unter der Tapete im Haus verteilt:-)

https://wiki.fhem.de/wiki/Kategorie:1-Wire

Gruss
  Enno

Einfacher FHEM Anwender auf Intel®NUC mit Proxmox und Debian

God-of-Games

Hallo Zusammen,
danke für die schnellen Antworten.
Zitat von: MadMax-FHEM am 01 Juli 2020, 09:43:16
Da solltest/darfst du an der WLAN Infrastruktur nicht sparen und Fritzbox ist (nach allem was man [hier] so hört) raus...
Aktuell ist zwar noch eine Fritzbox im Einsatz, soll dann aber gegen Unifi-Geräte getauscht werden.

Zitat von: MadMax-FHEM am 01 Juli 2020, 09:43:16
Bei Homematic (bidCos!) gibt es noch die Möglichkeit ein Funkmodul per LAN oder WLAN "anzuschließen", dann sparst du dir einen 2ten PI und fhem2fhem...
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Das wäre auch eine schöne Möglichkeit, war mir nicht klar, dass das auch so geht.

Zitat von: Beta-User am 01 Juli 2020, 10:10:56
Neubau? Grundlegende Renovierung? => nimm' ein Kabel! (Es gibt einige Lösungen, die z.B. RS485-basiert sind und auch zentrale Spannungsversorgungen möglich machen...)
Generell tendiere ich auch für die Anbindung per Kabel, so wäre es auch meine Intension für weitere (wichtige) Geräte wie Licht und Rolladen gewesen. Bei den Thermometer hätte es den Charme gehabt, dass man sie ohne Probleme im Nachhinein dort hin machen kann wo man will..

Zitat von: Beta-User am 01 Juli 2020, 10:10:56
WLAN ist keine gute Idee, aber wenn, kommt ggf. für die (runden) BT-Xiaomi-Sensoren auch ein OpenMQTTGateway in Frage...
Die Version würde mir auch sehr gefallen und für "lernen" wäre auch der Invest überschaubar.

Zitat von: Beta-User am 01 Juli 2020, 10:10:56
Kurzum: Informiere dich gründlicher, sonst ist das Risiko enorm hoch, dass du am Ende das Falsche tust oder was unnötig kompliziertes, störungsanfälliges... Und parallel zu Bau-Fragen noch in die Microcontrollerprogrammierung einsteigen zu wollen, ist mMn. "steil". Würde daher erst mal mit was günstigem anfangen (eine der genannten Xiaomi-Lösungen) UND Kabel verlegen, damit du später umrüsten kannst ;) .
Das war hiermit auch meine Intension. Leider weiß ich noch nicht so richtig an welcher "Baustelle" ich hier anfangen soll. Die Ansteuerung der Rollläden, Licht, etc habe ich erst mal in die Zukunft geschoben, da ich hier auch noch nicht so richtig weiß ob etwas an KNX vorbei geht, wenn es zukunftssicher sein soll.
Aktuell ist die Lernkurve schon steil genug ;-)

Zitat von: enno am 01 Juli 2020, 10:22:16
wenn du sowieso ein wenig renovierst, dann schau dir doch 1-wire mal an. Ich hatte als ich noch zur Miete wohnte einen "Probeaufbau" gemacht, Erfahrungen gesammelt und dann als ich das eigene Haus renoviert habe die Kabel unter der Tapete im Haus verteilt:-)
https://wiki.fhem.de/wiki/Kategorie:1-Wire
1-Wire hatte ich mir auch schon angeschaut, würde zwar mein Problem mit dem Akku eliminieren, es wäre aber so wie ich es verstanden habe auch eine "Bastellösung" bei der ich die das Endgerät selbst "entwickeln" muss. Oder sehe ich das falsch.
Ich hätte im Eingangsposting extra erwähnen sollen, dass ich gerne auf den Endgerät eine Anzeige mit Temperatur- & Luftfeuchte hätte.

enno

Zitat1-Wire hatte ich mir auch schon angeschaut, würde zwar mein Problem mit dem Akku eliminieren, es wäre aber so wie ich es verstanden habe auch eine "Bastellösung" bei der ich die das Endgerät selbst "entwickeln" muss. Oder sehe ich das falsch.
Kann man machen wie man möchte ;) Ich bin auch nicht der große Künstler am Lötkolben, habe mit Fertiglösungen gestartet (z.B. https://www.esera.de/produkte/) und bin inzwischen mutiger geworden und habe auch ein paar "Bastellösungen" eingebaut.

Wenn du dir noch nicht sicher bist, dann plan auf jedenfall ganz viele Meter Leerrohr ein. dann kannst du später immer noch wechseln. Oder wie ich es gemacht habe, eben jetzt schon mal im kleinen testen.

Funk würde ich versuchen zu vermeiden wo immer es geht! Ich nutze auch HM, Shelly, Hue, und Somfy, stabil  von Anfang an ist aber bei mir 1-Wire

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC mit Proxmox und Debian

Beta-User

Zitat von: God-of-Games am 01 Juli 2020, 11:33:56Generell tendiere ich auch für die Anbindung per Kabel, so wäre es auch meine Intension für weitere (wichtige) Geräte wie Licht und Rolladen gewesen.
[...] KNX
Das ist auf alle Fälle eine gute Idee, und neben KNX gibt es wenige Bus-Systeme, mit denen sich auch der "gemeine Elektriker von um die Ecke" auskennt. Weiß nur nicht, ob das bei der Lichtsteuerung (Dimmer, Farben) mit ZigBee&Co mithalten kann (mit HomeMatic(-IP) ziemlich sicher).

ZitatBei den Thermometer hätte es den Charme gehabt, dass man sie ohne Probleme im Nachhinein dort hin machen kann wo man will..
Bzgl. einfacher Meßgeräte sehe ich das auch relativ unkritisch. Da muß man "nur" aufpassen, dass man überwacht, dass tatsächlich auch halbwegs aktuelle Meßwerte vorliegen, falls man irgendwelche Steuerungslogik dranknüpft. Das ist aber sowieso ein allgemein relevantes und nicht von einem bestimmten System abhängiges Thema.

ZitatDie Version würde mir auch sehr gefallen und für "lernen" wäre auch der Invest überschaubar.
Mit "lernen" ist da nicht wirklich viel: ESP32 bestellen, etwas Software installieren, flashen, passende attrTemplate in der richtigen Reihenfolge anwenden und verstehen, done...

ZitatIch hätte im Eingangsposting extra erwähnen sollen, dass ich gerne auf den Endgerät eine Anzeige mit Temperatur- & Luftfeuchte hätte.
Dann gibt es neben den (mMn. uncoolen LaCrosse) nur die BT-Vertreter oder Eigenbau.

Daher nochmal: Schnelle BT-Lösung (kann man auch vorher austesten, falls das Material rechtzeitig kommt) iVm. Kabeln an die vermutlich richtige Stelle (mit ausreichend Adern) dürfte für deinen Anwendungsfall die "richtige" Vorgehensweise sein ;) . Egal, ob es dann am Ende 1-wire, RS485 oder was anderes wird (oder eine Kombination: 8 Adern reichen für mind. RS485 und 1-wire parallel...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

God-of-Games

#7
Zitat von: enno am 01 Juli 2020, 12:10:56
... mit Fertiglösungen gestartet (z.B. https://www.esera.de/produkte/) ...
Schau ich mir Mal an, wenn der Shop die Wartungsarbeiten beendet hat.

Zitat von: Beta-User am 01 Juli 2020, 12:19:14
Das ist auf alle Fälle eine gute Idee, und neben KNX gibt es wenige Bus-Systeme, mit denen sich auch der "gemeine Elektriker von um die Ecke" auskennt. Weiß nur nicht, ob das bei der Lichtsteuerung (Dimmer, Farben) mit ZigBee&Co mithalten kann (mit HomeMatic(-IP) ziemlich sicher).
Was kannst du sonst noch als (Basis-)Bussystem empfehlen?
Dimmer wäre mir schon wichtig, Für Farben und anderen "Schnikschank" tut es auch ein nicht so "etabliertes" System.

Zitat von: Beta-User am 01 Juli 2020, 12:19:14
Mit "lernen" ist da nicht wirklich viel: ESP32 bestellen, etwas Software installieren, flashen, passende attrTemplate in der richtigen Reihenfolge anwenden und verstehen, done...
Dann gibt es neben den (mMn. uncoolen LaCrosse) nur die BT-Vertreter oder Eigenbau.
Nachdem ich mir die Website von OpenMQTTGateway genauer Angeschaut habe, bin ich auf den Olimex ESP32-GATEWAY-EA gekommen. Das wäre von der Sache her mit den Xiaomi Sensoren genau das was ich gesucht habe.
Bzgl. attrTemplate, du hättest nicht zufällig einen Tipp für mich welches das richtige ist?

Edit: Ich habe auf der Website gerade noch den Olimex ESP32-POE-EA gefunden. der wäre für meinen Anwendungszweck sogar noch besser geeignet...

Zitat von: Beta-User am 01 Juli 2020, 12:19:14
Daher nochmal: Schnelle BT-Lösung (kann man auch vorher austesten, falls das Material rechtzeitig kommt) iVm. Kabeln an die vermutlich richtige Stelle (mit ausreichend Adern) dürfte für deinen Anwendungsfall die "richtige" Vorgehensweise sein ;) . Egal, ob es dann am Ende 1-wire, RS485 oder was anderes wird (oder eine Kombination: 8 Adern reichen für mind. RS485 und 1-wire parallel...).
Da die eigenen vier Wände aus steuerlichen Gründen noch etwas dauern, habe ich noch genug Zeit Hardware zu bestellen und alles zu testen.
Nach meiner bisherigen Erfahrung enden die Leerrohre aber immer genau an der falschen Stelle. Daher wäre meine Tendenz bei nicht statischen Geräten in eine etwas mobilere Richtung gegangen.

Beta-User

Zitat von: God-of-Games am 01 Juli 2020, 13:18:34
Was kannst du sonst noch als (Basis-)Bussystem empfehlen?
Was ich (vom Hörensagen her) kenne, ist im Wiki zu finden: https://wiki.fhem.de/wiki/System%C3%BCbersicht

ZitatDimmer wäre mir schon wichtig, Für Farben und anderen "Schnikschank" tut es auch ein nicht so "etabliertes" System.
Was Beleuchtung angeht, gibt es mit DALI (?) afaik ein etabliertes Profi-System (ist RS485-basiert, afaik). Dürfte aber nicht günstig sein, und Einbindung in FHEM: k.A.
Von daher würde ich wichtige Leuchten/Dimmer in KNX ausführen, und für Effektbeleuchtung usw. dann ggf. ZigBee verwenden.

ZitatNachdem ich mir die Website von OpenMQTTGateway genauer Angeschaut habe, bin ich auf den Olimex ESP32-GATEWAY-EA gekommen. Das wäre von der Sache her mit den Xiaomi Sensoren genau das was ich gesucht habe.
Bzgl. attrTemplate, du hättest nicht zufällig einen Tipp für mich welches das richtige ist?
Ich habe noname-ESP32 am Start, bisher keine Auffälligkeiten (läuft seit ca. 8 Monaten). Bzgl. attrTemplate mal mit OpenMQTTGateway_MCU einsteigen (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L2990), da ist dann auch ein Link drin zum Thread bzgl. der Entwicklung der weiteren attrTemplate. (Sieht mehr nach Baustelle aus, als es ist ;) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

God-of-Games

Zitat von: Beta-User am 01 Juli 2020, 13:38:16
Was ich (vom Hörensagen her) kenne, ist im Wiki zu finden: https://wiki.fhem.de/wiki/System%C3%BCbersicht
Was Beleuchtung angeht, gibt es mit DALI (?) afaik ein etabliertes Profi-System (ist RS485-basiert, afaik). Dürfte aber nicht günstig sein, und Einbindung in FHEM: k.A.
Von daher würde ich wichtige Leuchten/Dimmer in KNX ausführen, und für Effektbeleuchtung usw. dann ggf. ZigBee verwenden.
Genau so wäre mein Plan.

Zitat von: Beta-User am 01 Juli 2020, 13:38:16
Ich habe noname-ESP32 am Start, bisher keine Auffälligkeiten (läuft seit ca. 8 Monaten). Bzgl. attrTemplate mal mit OpenMQTTGateway_MCU einsteigen (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L2990), da ist dann auch ein Link drin zum Thread bzgl. der Entwicklung der weiteren attrTemplate. (Sieht mehr nach Baustelle aus, als es ist ;) ).
Da bin ich mal gespannt. Wobei ich jetzt beim durchlesen der Seite von OMG nicht so ganz schlau daraus geworden bin ob das Olimex ESP32-GATEWAY-EA bereits unterstützt wird und was die passende Firmware ist...

Beta-User

Zitat von: God-of-Games am 01 Juli 2020, 13:55:44
Wobei ich jetzt beim durchlesen der Seite von OMG nicht so ganz schlau daraus geworden bin ob das Olimex ESP32-GATEWAY-EA bereits unterstützt wird und was die passende Firmware ist...
Vermutlich wird der LAN-Teil nicht ootb unterstützt, das board ist jedenfalls nicht unter https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.4 fertig compiled gelistet.

Würde für den Anfang eher ein "normales" dev-Board empfehlen, wie gesagt, ich habe "irgendwelche" aus China im Einsatz, die eher wie dieses hier aussehen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

God-of-Games

Ah, wer lesen kann ist klar im Vorteil... Ich habe hier das TODO jedes mal überlesen.
Wenn ich es richtig verstanden habe , benötige ich für das von dir verlinkte Board das "esp32dev-ble"-Paket?

Beta-User

Jep! (Die kombinierten funktionieren teils nicht bzw. jedenfalls nicht ältere "all"-binaries). Aber der BT-Teil ist solo schon super...

(Dann brauchst du aber zu dem ble-bin noch die weiteren drei bin-files wie unter https://docs.openmqttgateway.com/upload/binaries.html beschrieben; das muß alles auf einen Rutsch vorhanden sein, später kann man auch nur die ble aktualisieren).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

God-of-Games

So, jetzt ist alles da, geflasht und eingebunden. Gibt ed für die ClerGlass Sensoren ein passenden Template oder muss ich den selbst nach meinen Wünschen einrichten?

Beta-User

Zu den ClearGlass kann ich (noch) nichts sagen, vermute aber, dass das OpenMQTTGateway_BT_temp_hum_sensor passen müßte.

Ansonsten bitte eine RAW-Definition einstellen (tendenziell aber besser in dem "OpenMQTTGateway-Thread"). Der Aufbau der Device-Struktur in FHEM ist klar? (Erst das "MCU"-template, dann den BT-Scanner, zuletzt das für den eigentlichen Sensor.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors