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 (https://forum.fhem.de/index.php/topic,111779.0.html) 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
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
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 ;) .
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
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.
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
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...).
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 (https://docs.openmqttgateway.com/) genauer Angeschaut habe, bin ich auf den Olimex ESP32-GATEWAY-EA (https://www.olimex.com/Products/IoT/ESP32/ESP32-GATEWAY/open-source-hardware) 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 (https://www.olimex.com/Products/IoT/ESP32/ESP32-POE/open-source-hardware) 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.
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 (https://docs.openmqttgateway.com/) genauer Angeschaut habe, bin ich auf den Olimex ESP32-GATEWAY-EA (https://www.olimex.com/Products/IoT/ESP32/ESP32-GATEWAY/open-source-hardware) 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 ;) ).
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...
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 (https://www.ebay.de/itm/Espressif-ESP32-WLAN-Dev-Kit-Board-Development-Bluetooth-Wifi-v1-WROOM32-NodeMCU/253059783728?_trkparms=ispr%3D1&hash=item3aeb89dc30:g:5-8AAOSwAThb3MaZ&enc=AQAFAAACYBaobrjLl8XobRIiIML1V4Imu%2Fn%2BzU5L90Z278x5ickkrDx%2B2NLp21dg6hHbHAkGMSBk8ENaUyWOaMOz6JBZHDYef4ZPE34MVD7xDw4yim%2BvYqL4E7i3VF%2FhSQqyzlkiKd1b5nCxGKyqak2bV0gEFKDPR9IZKS5SDNU4cEi6zWe3yah2oBJOvbh3Jazd8w01Ag85EhjBRGb5RFcKlKmz66b0Kbc2IH62Zh4vbNOnZCHNIVDOVI4Zi7pDNhyy2k6ifVgJqeXxgPqPtzfbJ16yFPOyzHlBZHAwziLOyUefeMtwTQcPp0O1Rk4HlBjEsbmX5gp%2FSOsQ%2FAhcFT9qWJyNroiMyDsBQYHsykG6Ur9WsgxjoVzziUi18G6Uk29dUQibtqnzMzGzLjahzLdPEVUwTBFE944lWRQ%2F3BV9SqLBxD7jb4%2FuZpl6IvhwFJOY1Io7O%2BSBVV921fy9%2FAUB6ti5%2BMODlVk2ceLsLDWTtrMe2Iha3wphNW0ngVB08zS9BihvknRknf8ZVlOuOBMuZeWkISoBZGwMwP4CU4oQzRgXA91MOiin2wYCtcTvML%2FTF9Q6xnVxLVSLULZGZsBswB09SLjJ8ELGE52IvKlRqa8I1xo2S0Yzq7iCi7RIvJk1fImBmPmN%2FHP8KblPR%2B4v9EgDbFGZHeMqff0N%2BPFFiTy9HB57dYQVEbWT04fejs0y0QHvWEnW5ykbXVtOPH%2FcHHlz2gVwDLwaQjmMSZfNks1oq8PVlItp2eQyTiBKOYOYXOD483zWdj4oP8TDX6mmAr27gl6Uh946yF54F3I49qzVAKtP&checksum=253059783728f098edfb63e54220b64a1f5a9918c2f8) aussehen.
Ah, wer lesen kann ist klar im Vorteil... Ich habe hier (https://github.com/1technophile/OpenMQTTGateway/pull/642) 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?
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).
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?
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.)
Dann würde ich das mit dem Template heute Abend mal ausprobieren.
Der Aufbau der Device-Struktur in FHEM ist mir nicht klar. Nach dem einrichten des OpenMQTTGateway ist dieser in FHEM erschienen und ich habe das OpenMQTTGateway template angewendet. Nach starten des ClearGrass ist ein neues Device erstellt worden, welches im Reading die gleichen Werte hatte wie dieses.
Jetzt wollte hatte ich mir noch die Logik zum anzeigen der Werte aus einem anderen Gerät mit Template "nachgebaut", dachte aber dass es vielleicht schon was fertiges gibt.
Würdest du mir den Aufbau erklären oder gibt es hierzu eine Seite im Wiki?
Zitat von: God-of-Games am 16 Juli 2020, 13:55:51
Dann würde ich das mit dem Template heute Abend mal ausprobieren.
Vermutlich sind "Trockenübungen" etwas abstrakt, und du solltest auch bitte bei Fragen genau mitteilen, welches template du jeweils angewendet hast (das ergibt sich für mich am einfachsten aus einer RAW-Definition).
Daher erst mal noch vorab, wie die Device-Struktur sein sollte. Das ist vermutlich v.a. dann etwas schwer nachzuvollziehen, wenn man nur ein entsprechendes Device hat...
Zitat
Der Aufbau der Device-Struktur in FHEM ist mir nicht klar. Nach dem einrichten des OpenMQTTGateway ist dieser in FHEM erschienen und ich habe das OpenMQTTGateway template angewendet.
Das sollte genauer gesagt das hier sein: OpenMQTTGateway_MCU. Das repräsentiert zukünftig dann nur noch den ESP(32|8266), also ob dieser mit dem MQTT-Server verbunden ist, und erlaubt das Absetzen von Kommandos, die an den Microcontroller selbst gerichtet sind. Das ist ganz so, wie du es evtl. auch von anderen .*2mqtt-Lösungen kennst (zigbee2mqtt, z.B.).
Dabei werden alle Readings gelöscht und nur wenige neue dann wieder (über der Zeit) angelegt).
ZitatNach starten des ClearGrass ist ein neues Device erstellt worden, welches im Reading die gleichen Werte hatte wie dieses.
Es können auch mehrere Devices angelegt werden, das hängt u.a. auch davon ab, was das betreffende Gateway eigentlich so alles "kann" bzw. an Schnittstellen hat. Bei einem reinen BT-Betrieb, düfte es ein Device mit der CID "oMQTTgw_BT" sein. In dem landet "alles", was irgendwie über den BT-Zweig an Infos kommt, ganz egal, von welcher Hardware das eigentlich kommt. Daher kann man mit diesem Device eigentlich m.E. nur eines tun: Man wendet darauf das OpenMQTTGateway_BT_scanner-template an...
Das bereitet dann alle über BT eingehenden Infos etwas anders auf und ist eigentlich v.a. als "Übersichtsdevice" konzipiert, was etwas schwierig nachzuvollziehen ist, wenn man das nicht etwas länger am laufen hat - z.B. werden auch alle BT-Signale von sämtlichen Handys empfangen, was besonders dann "lustig" ist, wenn es sich um angebissene Äpfel handelt: die wechseln nämlich alle Naselang ihre ID, so dass man dann irgendwann eine irre lange Liste mit unnützen Daten hat.
Dieses template sorgt daher dafür, dass die Readings auch wieder regelmäßig gelöscht werden.
ZitatJetzt wollte hatte ich mir noch die Logik zum anzeigen der Werte aus einem anderen Gerät mit Template "nachgebaut", dachte aber dass es vielleicht schon was fertiges gibt.
Würdest du mir den Aufbau erklären oder gibt es hierzu eine Seite im Wiki?
Was BT-Geräte angeht, die Temperatur und Humidity senden, gibt es ein template: OpenMQTTGateway_BT_temp_hum_sensor
(Ich sehe grade, dass da noch die CID falsch vergeben wird, muß ich nacharbeiten...)
Das template erstellt ein neues Device (BT-Adresse bekommt man aus dem "scanner"), das sollte es dann (ähnlich wie OpenMQTTGateway_BT_gtag für GTags uä.) möglich machen, einfach nur die Werte "ganz normal" (wie von anderen Sensoren her auch bekannt) darzustellen.
Kurzfassung ist daher: Man braucht bei OMG-BT m.E. eigentlich immer mind. drei Geräte: Das "MCU" für den ESP, das "scanner" als "Infogerät" und die eigentlichen "Hardware"-Geräte für jedes BT-Endgerät, das man separat sehen will.
(Ich packe das mal bei Gelegenheit etwas ausführlicher ins Wiki; da hat zwar jemand mal in https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway angefangen, aber was da steht, greift m.E. etwas zu kurz).
Perfekt, danke dir für die Erklärung, jetzt ist mir auch klar, wie das ganze abläuft und das einrichten hat auch geklappt.
Wenn ich es richtig verstanden habe, wäre es in diesem Fall auch kein Problem, wenn sich ein BT-Sender im Empfangsbereich von mehren Gateways befindet bzw. wechselt, da er über die MAC eindeutig identifiziert wird.
Zitat von: God-of-Games am 17 Juli 2020, 13:06:18
Perfekt, danke dir für die Erklärung, jetzt ist mir auch klar, wie das ganze abläuft und das einrichten hat auch geklappt.
Danke für die Rückmeldung. Falls ich die Beschreibung in den templates selbst bzw. im Wiki noch optimieren kann/soll: bin für Vorschläge zu haben...
ZitatWenn ich es richtig verstanden habe, wäre es in diesem Fall auch kein Problem, wenn sich ein BT-Sender im Empfangsbereich von mehren Gateways befindet bzw. wechselt, da er über die MAC eindeutig identifiziert wird.
Korrekt, mehrere GW's sind kein Problem, außer, dass eben ggf. mehrere Events mit demselben Trigger generiert werden - da kann man dann aber z.B. bei notify mit disableAfterTrigger abhelfen (oder entsprechenden event-on-Attributen).
Das hat teilweise aber auch Vorteile - allerdings weniger bei deiner Art Sensor, sondern eher bei mobilen wie Handys oder G-Tags: Da kann man den ungefähren Standort über den besten RSSI-Wert ermitteln (gibt ein eigenes Template dafür).
Da das (bei den einfachen Sensoren) afaik auch "broadcasts" sind, braucht das auch nicht extra Batterie-Leistung, wenn man mit mehreren GW's empfängt.
Hi,
sorry, dass ich mirch jetzt erst melde, wir hatte am Wochenende Besuch...
Zitat von: Beta-User am 17 Juli 2020, 13:14:34
Danke für die Rückmeldung. Falls ich die Beschreibung in den templates selbst bzw. im Wiki noch optimieren kann/soll: bin für Vorschläge zu haben...
Meinst du diese Seite im Wiki (https://wiki.fhem.de/wiki/Template)?
bei meiner Suche ist mir aufgefallen, dass viele User Probleme haben zu unterscheiden, dass es für Tasmota "gerätespeztifische" und bei FHEM "funktionsspezifische" Templates gibt. Mein Problem war am Anfang aber eher herauszufinden, was das passende Template für mein Gerät ist. Verstärkt wurde es damals dadurch, dass damals scheinbar ein Bug im Template war, ich finde aber den Thread dazu nicht mehr.
Insgesamt hätte ich mir eine Seite gewünscht, die etwas übersichtlicher wäre, was mein passendes Template wäre. Also ein Bereiche schaltbare Steckdosen und dort alle möglich Templates gelistet (einfach, doppelt etc. mit und ohne Leistungsmessung).
Zum OMQTTG hatte ich keine Wiki-Seite gefunden, wobei ich ohne deine Hilfe nie darauf gekommen wäre wie die Geräte angelegt werden müssen.
Bei quer lesen im Forum bin ich noch auf einen anderen Thread (https://forum.fhem.de/index.php/topic,112864.0.html) gestoßen bei dem das ganze über Tasmota läuft. Wenn ich es richtig verstanden habe, würde dass dann, wenn SetOption89 funktioniert, auf die gleiche weise laufen?
Also:
Im Wiki gibt es (allg.) https://wiki.fhem.de/wiki/AttrTemplate, speziell, was MQTT2_DEVICE angeht https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele, die Ultrakurzfassun gäbe es hier https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate und hier hat dann noch jemand was zu OpenMQTTGateway geschrieben: https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway. Das verlinkte "template" ist dagegen was ganz anderes...
Das mit gerätespezifisch vs. funktionsspezifisch ist ein Dauerthema, zu dem ich auch keine definitive Lösung habe. Für zigbee2mqtt-Leuchtmittel gäbe es z.B. was hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#IKEA-Tradfri-Birne; sowas könnte man auch für die diversen Tasmota-Vertreter basteln. Oder eben in die desc: -Abschnitte typische Hardware-Verteter auflisten - da wäre ich aber auf entsprechende Zuarbeit angewiesen.
Was tasmota2bt angeht, könnte das auch in diese Richtung gehen, es fehlen aber Erfahrungen (für den Parallelfall tasmota2zigbee habe ich zwar ein paar attrTemplates bereitgestellt, aber die sind im wesentlichen bisher auch ungetestet...). Einen gößeren Vorteil für tasmota kann ich nicht erkennen (außer, dass es einfacher ist, updates auf den ESP zu bringen) - dafür ist die json-Datenstruktur in der Regel noch verschachtelter, die Tasmota liefert... (ich werde eher bei OMG bleiben).
Danke für die Klarstellung.
Wie schon gesagt war es zum Beginn recht schwierig das passende Template zu finden und nachdem ich bei Tasmota für jedes Endgerät ein spezifisches brauche, bin ich auch nicht auf die Idee gekommen, dass alle Steckdosen das gleiche verwenden, wenn man den MQTT-Server der Steckdosen passend konfiguriert. So war die Suche am Anfang etwas mühsam.
Leider ist der verlinkte Abschnitt zum OpenMQTTGateway (https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway) sehr kurz gehalten und enthält für mich zum einen unrelevante Infos ("Ich habe es noch in den Raum MQTT2 geschoben."). Zum Anderen fehlt der Zwischenschritt mit dem korrekten anlegen des BT-Scanners.
Was aber für mich persönlich ser verwirrend war ist die Logik wie ich das BT-Gerät anlege.
Zum einen setzte ich mit dem Befehl
set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU
das Template für den Gateway, zum andern mit dem "gleichen" Befehl
set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor
definiere ich die Endgeräte, welche jedoch nicht unbedingt etwas mit gerade diesem Gateway zu tun haben.
Was meinst du mit "desc: -Abschnitte"?
Bzgl. tasmota2bt sehe ich für mich neben dem erwähnten einfacheren Update die Vorteile des Webinterfaces falls man im Nachgang noch etwas anpassen möchte (bei OMG nur beim ersten Verbinden vorhanden) und das im andere Thread erwähnte auslesen der Batterie.
Würdest du mir noch erklären was eine MQTT-Bridge ist und für was ich die benötige oder ist das vor relevant, wenn FHEM nicht der MQTT2-Server ist?
Zu desc: bzw. zur Frage, wie man was findet. Du kennst hoffentlich
set <device> attrTemplate ?Wenn nein: Bitte ausprobieren!
Was man da sieht, ist eine Liste mit den _geladenen_ templates (ohne Filterung) sowie entsprechenden weiteren Infos, links zu Forenthreads, Projektseiten, ... Das kommt in der Regel aus "desc:" in der Source-file (zu finden beispielsweise in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template). Derselbe Text kommt auch, wenn man in FHEMWEB eines der templates auswählt (ohne set).
Die Liste hat halt den Vorteil, dass man z.B. auch im Browser nach einer Gerätebezeichnung suchen kann (die aber eher selten dasteht).
Was den Ablauf für das "mi_flora" (und ein paar andere) angeht, ist es in der Tat etwas anders als üblich, eben weil ein weiteres Device benötigt wird. Bisher habe ich allerdings noch keine bessere Idee gehabt, wie man das sonst lösen könnte, erst manuell ein Device erstellen zu lassen, ist auch nicht wirklich besser, oder? Vielleicht könnte man den Hinweis, dass ein neues Device erstellt wird etwas deutlicher machen, aber wenn keiner eine Idee hat, was "desc:" denn sein könnte, liest das vermutlich auch keiner, wenn es in rot oder orange dasteht?
Das mit der Batterie@OMG kann ich übrigens so nicht bestätigen; ich habe auch einen "runden", da kommt auch der Batterie-Prozentwert und der sieht auch einigermaßen plausibel aus; ist evtl. auch eine Frage der Version, da tut sich auch @OMG einiges. Ohne eigenen Zweig je Hardware ist es jedenfalls mit Tasmota m.E. nicht wirklich nutzbar (soll aber kommen, und dann ist anzunehmen, dass da auch viele kompetente Mitentwickler an Bord sind, was evtl. mittelfristig hilfreich sein kann, wenn mehr Geräte verschlüsseln).
Was MQTT-Bridge sein soll, kann ich nur raten. Falls du das Modul 10_MQTT_BRIDGE.pm meinst: einfach vergessen, dass es das gibt, ab dem 2. Gerät ist es sehr viel einfacher, MQTT_GENERIC_BRIDGE zu nutzen, das im übrigen auch mit MQTT2-Interfacemodulen kann (MQTT_BRIDGE geht nur mit 00_MQTT.pm). Siehe auch hier: https://wiki.fhem.de/wiki/MQTT#MQTT_BRIDGE.
Zu beiden steht im Wiki (https://wiki.fhem.de/wiki/MQTT#Kommunikation_zu_sonstigen_FHEM-Ger.C3.A4ten_.C3.BCber_MQTT) als Einleitungssatz:
ZitatMöchte man Daten von einem Gerät (https://wiki.fhem.de/wiki/Ger%C3%A4t) (im FHEM-Sinn), das nicht vom Typ MQTT2_DEVICE oder MQTT_DEVICE (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:
Falls ich das hier in dem Zusammenhang gebraucht hatte: Es gibt neben OMG und Tasmota2zigbee noch einige andere Dienste und firmwares, die einfach nur "irgendwas2mqtt" machen. Dann war wohl ein FHEM-Device gemeint, das irgendwie diese Art Dienst oder MCU+firmware repäsentiert.
set <device> attrTemplate ?
ist mir bekannt, habe ich auch schon damals für die tasmota-Steckdosen verwendet um zu sehen, wie das tempalte genau heißt (in dem Thread war damals nur von POW-Template die Rede).
Ich würde mir im Wiki oder in den Foren öfters diese abstrahierte Schreibweise wünschen. Leider habe ich öfters (das die Syntax noch nicht so richtig sitzt) das Problem zu wissen, was das Gerät und was der Befehl ist.
Ich konnte jetzt mit der Abkürzung nichts anfangen, jetzt ist mir klar, dass es description also Beschreibung bedeutet. Hierfür müsste ich aber schon das passende Template gefunden haben. Ich dachte eher an eine Art Ablaufplan:
Art: Steckdose => Leistungsmessung ja/Nein => Anzahl Anschlüsse => Zu verwendentes Template
Bzgl. dem Ablauf bei solchen Geräten gebe ich dir Recht. Von der Logik her müsste man zuert ein neues Gerät anlegen und im Anschluss auf dieses das Template anlegen. Das wäre aber ein Schritt mehr, wobei mich es doch verwundert hatte das Gerät so anzulegen.
Ist es eigentlich auch möglich die Adresse des BT-Geräts gleiche beim
set <device> attrTemplate <template>
mitzugeben?
Bzgl. der aktuellen Vorgehensweise: Ist es egal von welchem OMG aus ich ein BT-Device anlege oder wird es dann nur mit diesem verknüpft?
Ich habe diese ClearGrass-Modell von Amazon (https://www.amazon.de/gp/product/B07X1YDCNS/), habe jetzt aber in den Reading keine Baterieanzeige gefunden, oder muss hierfür noch etwas gemacht werden?
Ok, wenn ich das mit der MQTT-Bridge richtig verstanden habe "generiert" diese ein MQTT-Gerät, welches ich per MQTT-Befehle ansprechen kann um damit in FHEM Schaltbefehle auszulösen. Da ganze natürlich auch andersherum mit Readings.
Die "irgendwas2mqtt" Geräte (Hard+Software) setzten wiederum ein anderes Protokoll auf MQTT um, so dass ich beispielsweise die Funkmodule besser positionieren oder mehrere Module verwenden kann um die USB-Sticks nicht verwenden zu müssen.
Zitat von: God-of-Games am 21 Juli 2020, 13:33:14
set <device> attrTemplate ?
ist mir bekannt, habe ich auch schon damals für die tasmota-Steckdosen verwendet um zu sehen, wie das tempalte genau heißt (in dem Thread war damals nur von POW-Template die Rede).
Na ja, manchmal ist "klar", um welches template es geht, und dann werden eben ggf. Abkürzungen verwendet, was für "uneingeweihte" oder "vorsichtig suchende" User manchmal nicht optimal ist.
Genauso mit "verkürzten" Schreibweisen für Befehle usw.. Gibt ermutlich keine optimale Lösung dafür, meistens hilft es, einfach ein wenig rumzuraten und FHEMWEB intensiver anzusehen; so lernt man mMn. auch relativ schnell viel, ist also eigentlich nicht verkehrt.
Zitat
Ich dachte eher an eine Art Ablaufplan:
Art: Steckdose => Leistungsmessung ja/Nein => Anzahl Anschlüsse => Zu verwendentes Template
Sowas kann man machen, ABER: jemand muß es a) machen und b) aktuell halten. Letzteres ist bei firmware-updates schon schwierig, wenn dann die Variantenvielfalt dazukommt, kann man eigentlich nur kapitulieren und versuchen, halbwegs sprechende Benennungen zu wählen und eine eher abstrahierende Struktur und Sortierung (so eben der aktuelle Versuch; wie gesagt: ich bin für zielführende Vorschläge zu haben)...
ZitatIst es eigentlich auch möglich die Adresse des BT-Geräts gleiche beim
set <device> attrTemplate <template>
mitzugeben?
Prinzipiell ja
set <device> attrTemplate OpenMQTTGateway_BT_mi_flora_sensor <BT_ID>sollte funktionieren, denn BT_ID ist die erste par:-Anweisung, etwas "zielgenauer" ginge
set <device> attrTemplate OpenMQTTGateway_BT_mi_flora_sensor BT_ID=<BT_ID>Ist nur etwas erklärungsbedürftig, von daher schadet es nicht, wenn wenigstens hin und wieder auch mal ein Parameter via Dialogfeld abgefragt wird...
ZitatBzgl. der aktuellen Vorgehensweise: Ist es egal von welchem OMG aus ich ein BT-Device anlege oder wird es dann nur mit diesem verknüpft?
Also: das attrTemplate löscht sowohl die CID-Angaben (von welchem Device kam das?) aus der readingList und ersetzt den konkreten Topic-Pfad durch eine regex-Variante, die auch auf mehrere OMG-Bridges passen sollte. Von daher gibt es danach keinen konkreten Bezug mehr zu einem bestimmten OMG. Das hat nur einen Haken: vergibt man Namen für das OMG, das nicht mit der regex kompatibel ist, geht es gar nicht...
ZitatIch habe diese ClearGrass-Modell von Amazon (https://www.amazon.de/gp/product/B07X1YDCNS/), habe jetzt aber in den Reading keine Baterieanzeige gefunden, oder muss hierfür noch etwas gemacht werden?
Afaik kann man beim OMG nichts einstellen; von daher: entweder das Reading ist da, oder eben nicht; ich kenne nur die LCD-Variante von dem Ding, und da geht es...
ZitatOk, wenn ich das mit der MQTT-Bridge richtig verstanden habe "generiert" diese ein MQTT-Gerät, welches ich per MQTT-Befehle ansprechen kann um damit in FHEM Schaltbefehle auszulösen. Da ganze natürlich auch andersherum mit Readings.
Im Prinzip richtig, aber solange du keine exakteren Bezeichnungen verwendest, fühle ich mich mit der Antwort nicht so recht wohl, weil ich nicht sicher weiß, ob wir wirklich über dasselbe reden.
Zitat
Die "irgendwas2mqtt" Geräte (Hard+Software) setzten wiederum ein anderes Protokoll auf MQTT um, so dass ich beispielsweise die Funkmodule besser positionieren oder mehrere Module verwenden kann um die USB-Sticks nicht verwenden zu müssen.
"Anderes Protokoll auf MQTT" paßt im Prinzip, allerdings ist das nicht beschränkt auf spezielle Funklösungen (siehe sonos2mqtt, da ist es afaik ein TCP/IP-Protokoll)). Was den "begründenden" Rest angeht, ist das für mich mehrfach schief: zum einen ist es so, dass man z.B. auch ser2net oder ein ser2LAN-Modul (oder einen ESP866 usw.) nutzen kann, um Funkschnittstellen besser zu positionieren, zum anderen bin ich ganz froh, dass ich alles, was mir wichtig ist, direkt an meinen (FHEM-)Server anstöpseln kann. Auf dem läuft z.B. auch deconz für zigbee. Darüber hinaus bin ich besonders froh, wenn ich sowas dann auch noch direkt von FHEM aus ansprechen kann; von daher ist selbst das lokal parallel laufende deconz in meiner Wahrnehmung nur eine (akzeptable) Notlösung ;) . Sobald irgendwo LAN (ohne localhost) im Spiel ist, ist es nicht mehr super, und WLAN kommt in meiner Wahrnehmung knapp oberhalb von 433MHz-"Gedöns" (just my2ct...)
Zitat von: Beta-User am 21 Juli 2020, 14:25:28
Afaik kann man beim OMG nichts einstellen; von daher: entweder das Reading ist da, oder eben nicht; ich kenne nur die LCD-Variante von dem Ding, und da geht es...
Ok, schade.
Zitat von: Beta-User am 21 Juli 2020, 14:25:28
Im Prinzip richtig, aber solange du keine exakteren Bezeichnungen verwendest, fühle ich mich mit der Antwort nicht so recht wohl, weil ich nicht sicher weiß, ob wir wirklich über dasselbe reden.
Die Ausführung so weit reicht mir bereits. Ich bin nicht so wirklich darauf gekommen, was es ist und ob ich es brauche, aber nachdem ich diese Info nun habe ist es für meinen aktuelle Stand nicht nötig.
Zitat von: Beta-User am 21 Juli 2020, 14:25:28
"Anderes Protokoll auf MQTT" paßt im Prinzip, allerdings ist das nicht beschränkt auf spezielle Funklösungen (siehe sonos2mqtt, da ist es afaik ein TCP/IP-Protokoll)). Was den "begründenden" Rest angeht, ist das für mich mehrfach schief: zum einen ist es so, dass man z.B. auch ser2net oder ein ser2LAN-Modul (oder einen ESP866 usw.) nutzen kann, um Funkschnittstellen besser zu positionieren, zum anderen bin ich ganz froh, dass ich alles, was mir wichtig ist, direkt an meinen (FHEM-)Server anstöpseln kann. Auf dem läuft z.B. auch deconz für zigbee. Darüber hinaus bin ich besonders froh, wenn ich sowas dann auch noch direkt von FHEM aus ansprechen kann; von daher ist selbst das lokal parallel laufende deconz in meiner Wahrnehmung nur eine (akzeptable) Notlösung ;) . Sobald irgendwo LAN (ohne localhost) im Spiel ist, ist es nicht mehr super, und WLAN kommt in meiner Wahrnehmung knapp oberhalb von 433MHz-"Gedöns" (just my2ct...)
Danke für die Ausführung.
Ich bin wiederum von den USB Lösungen nicht so wirklich angetan, aber daher gibt es ja auch mehrere Varianten.
Du hast jetzt noch ser2net und ser2LAN ins Spiel gebracht. Wenn damit das Linux-Tool gemeint ist und ich die Doku richtig verstanden habe, kann ich mich damit per Telnet auf den Server verbinden und dort einen seriellen Port simulieren.
Wie sieht in diesem Fall die Hardware der Gegenseite aus?
Zitat von: God-of-Games am 21 Juli 2020, 16:54:57
Du hast jetzt noch ser2net und ser2LAN ins Spiel gebracht. Wenn damit das Linux-Tool gemeint ist und ich die Doku richtig verstanden habe, kann ich mich damit per Telnet auf den Server verbinden und dort einen seriellen Port simulieren.
Wie sieht in diesem Fall die Hardware der Gegenseite aus?
ser2net ist ein Linux-dienst, korrekt. ser2LAN ist eine spontane Wortschöpfung, gemeint sind diverse Hardware-Optionen, um eine serielle Schnittstelle über einen fertigen oder selbsgebauten Microcontroller+LAN-Modul im Netz verfügbar zu machen. Das hat mWn. beides nicht wirklich was mit Telnet zu tun, selbst wenn man sich ggf. (auch) mit telnet da einwählen können sollte. Du findest die verschiedenen Varianten und links zum Weiterlesen am einfachsten über https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Verwendung; was da steht, kann im Prinzip fast universell mit allen möglichen Interfaces genutzt werden, die seriell angesprochen werden (mind. noch Signalduino, MySensors-GW, ...), Probleme kann es allerdings wegen Latenzen geben.