Im Artikel Experimente mit ESP8266, WS2812B und MQTT habe ich vor einiger Zeit über meine ersten Schritte mit dem WLAN-Microcontroller ESP8266 geschrieben.
Mittlerweile bin ich hier aus dem Versuchsstadium hinaus und habe mein „HomeStatusDisplay“ im Betrieb. Mit diesem Gerät visualisiere ich den Status meines Smart Home via LEDs- beispielsweise kann ich so offene Fenster, brennende Lichter, aber auch den Zeitpunkt wann die Mülltonnen auf die Straße gestellt werden müssen visualisieren. In diesem Tutorial zeige ich, wie ich beim Bau vorgegangen bin.
Zielsetzung
Zunächst einmal ein paar Worte zum „Sinn“ dieses Projekts.
Ich habe festgestellt, dass es immer wieder enorm hilfreich ist, wenn man sich schnell und einfach einen Überblick über die Zustände im Haus verschaffen möchte. Sind alle Licher ausgeschaltet? Sind alle Fenster zu? Werden irgendwelche Probleme gemeldet? Bisher war es zur Beantwortung dieser Fragen notwendig, entweder in jedem Raum nachzusehen, oder per Handy oder PC die Smart Home Visualisierung aufzurufen und dort nachzusehen. Beides ist aber unpraktisch, wenn man beispielsweise gerade das Haus verlassen möchte. Daher wollte ich eine immer verfügbare und sichtbare Anzeige, die einen Überblick mit einem Blick ermöglicht. Genau dies soll hier realisiert werden: Mit Hilfe verschiedener LEDs sollen diese Dinge auf einem zentral platzierten Gerät angezeigt werden.
Die LEDs können in verschiedenen Farben leuchten, und in unterschiedlichen Frequenzen blinken, um so auch aus der Ferne schnell zu sehen was für ein Status angezeigt wird.
Hinweis: Ich habe versucht, die notwendigen Schritte zur Realisierung so genau wie möglich zu beschreiben. Leider ist es nicht möglich auf jedes Detail einzugehen. Grundvoraussetzung ist ein lauffähiges Smart Home System, welches in der Lage ist, via MQTT (hierüber habe ich im vorherigen Artikel schon kurz geschrieben) zu kommunizieren. Hier bietet sich FHEM natürlich an, allerdings unterstützen viele andere Systeme dies auch- ich kann allerdings nur Unterstützung im Zusammenhang mit FHEM geben.
Weiterhin sind Grundkenntnisse von Mikrocontrollern, insbesondere der Umgang mit der Arduino IDE hilfreich. Ich habe allerdings versucht die wichtigsten Schritte zu dokumentieren.
Falls jemand Informationen in diesem Tutorial fehlen, bitte in den Kommentaren fragen. Ich werde dann versuchen das Tutorial entsprechend zu erweitern.
Hardware
Die Hardware, die für dieses Gerät benötigt wird, ist wirklich minimal:
- ESP8266 als Mikrocontroller mit WLAN Unterstützung (in meinem Fall ein wemos D1 Mini Klon)
- ein WS2812B LED Stripe, in meinem Fall kommen 33 LEDs in drei Reihen zum Einsatz
- minimale Beschaltung (ein 1000uF Elektrolyt Kondensator und ein Widerstand von ca. 470 Ohm, Standard-Beschaltung für die WS2812B Stripes)
- USB-Netzteil, Leistung ca. 1-2A, je nach Anzahl der LEDs
- ein Bilderrahmen mit ausreichender Tiefe (in meinem Fall aus einem schwedischen Möbelhaus)
- eine Holzplatte als Trägerrahmen für die LEDs und den Rest der Elektronik
- zwei Holzleisten als Klemmbefestigung
Vor dem Aufbau habe ich mir eine kleine Skizze gemacht, die den ungefähren Aufbau zeigen soll. In der fertigen Version hat das Format von Querformat auf Hochformat gewechselt, aber ansonsten bin ich dem Entwurf relativ treu geblieben..
Der Schaltplan für die Elektronik ist wie schon angesprochen sehr übersichtlich. Außer dem Controller, dem LED Stripe sowie einem Kondensator und einem Widerstand wird nichts weiter benötigt. Der Elko wird möglichst nah am Mikrocontroller zwischen Masse und 5V (Polung beachten!) eingebaut.
Zur Ansteuerung des LED Stripe wird lediglich ein Datenpin des Mikrocontrollers benötigt. Dies ist das besondere an den WS2812B LED Stripes gegenüber herkömmlichen LED Stripes- jede LED lässt sich getrennt in Farbe und Helligkeit ansteuern. Nachteil ist natürlich, dass zwingend ein Mikrocontroller mit entsprechender Software benötigt wird. Ich habe zur Ansteuerung den GPIO 4 benutzt, auf dem wemos D1 ist dieser mit „D2“ beschriftet.
Damit der LED Stripe nicht fest mit dem Controller verbunden ist, habe ich als Steckverbindung den Stecker von einem alten PC-Lüfter genommen. Natürlich braucht man nicht unbedingt einen Stecker, man kann die Leitungen zum LED-Stripe auch direkt verbinden- aber mit Stecker kann mit die Elektronik auch leicht herausnehmen. Den Kondensator habe ich liegend montiert und ein Loch in die Platine gesägt, weil der Aufbau sonst zu hoch für den Bilderrahmen gewesen wäre.
Ein IKEA Bilderrahmen bildet die Basis zur Aufnahme der Komponenten. Die auf dem folgenden Bild noch vorhandene Rückwand des Bilderrahmens mit dem Aufsteller habe ich entfernt.
Vom LED-Stripe habe ich mir drei Stücke a 11 LEDs abgeschnitten (die meisten WS2812B Stripes lassen sich nach jeder LED trennen). Die drei Stücke habe ich dann auf einem zurecht gesägten Stück Holz (von der Größe her so, dass es genau in den Bilderrahmen passt) aufgeklebt. Vorher habe ich noch Löcher zur Kabel-Durchführung gebohrt. Die Elektronik wurde dann auf der Rückseite befestigt und die Kabel angeschlossen. Wichtig ist, dass die Stripes eine Richtung haben- auf dem Stripe ist IN und OUT immer beschriftet. Der ESP muss mit dem IN verbunden werden, und das OUT Ende des Stripes dann mit dem IN des nächsten Stripes.
Die Holzplatte wird durch zwei passend zurecht gesägte Holzleisten, welche dann seitlich am Rahmen verschraubt wurden, gehalten. Damit es optisch schöner aussieht, habe ich Holzplatte und Leisten noch schwarz lackiert (dazu habe ich natürlich noch einmal alles zerlegt).
Als Stromversorgung dient ein einfaches Netzteil mit micro-USB Stecker. Hierbei ist zu beachten, dass pro LED maximal 60mA benötigt werden. Dies gilt aber nur bei voller Helligkeit und wenn alle drei Farben gleichzeitig an sind (also weiß dargestellt wird). Ich betreibe die LEDs mit ca. 10% Helligkeit, dies reicht völlig aus. Man muss also nicht unbedingt mit dem maximalen Strom rechnen, da ja auch selten alle LEDs gleichzeitig an sind.
Was nun noch fehlte, war eine passende Beschriftung der LEDs. In der ersten Version habe ich die Namen der jeweiligen LEDs einfach auf ein weißes Stück Papier ausgedruckt. Dies war mir dann aber zu schlicht, und so habe ich noch ein farbiges Stück Tonkarton darüber gelegt, in das ich entsprechende Ausschnitte geschnitten habe.
Der Zusammenbau der Hardware ist hiermit abgeschlossen.
MQTT Broker
Für die Kommunikation mit FHEM setze ich wie schon geschrieben auf MQTT. Hierüber lassen sich Nachrichten zwischen verschiedenen Geräten einfach austauschen. Da MQTT ein standardisiertes Protokoll ist, kann man auf eine breite Softwareunterstützung und definiertes Verhalten setzen. Der große Vorteil ist, dass wenn MQTT einmal eingerichtet ist, kann man es für eine Vielzahl weiterer Funktionen nutzen. Ich habe noch einige weitere Projekte realisiert, diese werde ich im Laufe der Zeit ebenfalls hier dokumentieren.
Um ein Grundverständnis für die Funktionsweise von MQTT zu bekommen, empfehle ich die entsprechenden Wiki-Artikel im FHEM-Wiki zu lesen. Bitte auch die am Ende des Artikel aufgeführten Links beachten. Es ist zum Verständnis dieses Tutorials enorm hilfreich, wenn man ein gutes Verständnis von MQTT hat.
MQTT nutzt zur Verteilung der Nachrichten eine Zentrale, einen sog. Broker. Ich habe mich hier für den Broker mosquitto entschieden. Da mein FHEM auf einem Raspberry Pi läuft, bietet es sich an den Broker auf demselben Gerät zu installieren. In der Paketverwaltung von Raspbian ist nicht die aktuellste Version enthalten, diese kann man aber folgendermaßen installieren:.
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
#für raspian wheezy:
sudo wget http://repo.mosquitto.org/debian/mosquitto-wheezy.list
# oder für raspian jessie:
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
sudo apt-get install mosquitto
Anschließend kann man testen ob der Broker läuft:
sudo service mosquitto status
Starten und stoppen des Brokers geht so:
sudo service mosquitto stop
sudo service mosquitto start
Zuletzt noch benötigte Module nachinstallierten, dies dauert ein wenig:
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
MQTT Einrichtung in FHEM
Wie eingangs erwähnt, lässt sich das HomeStatusDisplay mit allen Systemen verwenden, die MQTT „sprechen“. Die entsprechenden Topics auf die das Display hört, müssen vom System versendet werden. Ich erläutere dies hier anhand eines Beispiels in FHEM.
FHEM bietet für die MQTT Anbindung drei Gerätetypen: MQTT, MQTT_BRIDGE und MQTT_DEVICE. Ich empfehle, zunächst die Dokumentation hierzu in der Commandref zu lesen.
Zunächst ist es notwendig, ein MQTT Device anzulegen. Dieses verbindet FHEM mit dem Broker und ist damit die Grundvoraussetzung für alles weitere. Wie in der Commandref zu lesen ist die Syntax zum anlegen die folgende:
define <name> MQTT <ip:port> [<username>] [<password>]
Da bei mir der Broker auf demselben Raspberry wie FHEM läuft und ich kein Passwort verwende, sieht die Einrichtung bei mir folgendermaßen aus (1883 ist der Standard Port für MQTT):
define mqtt MQTT 127.0.0.1:1883
Wenn die Verbindung zum Broker steht, zeigt das angelegte MQTT Device den Status „opened“.
Für jedes Gerät, welches auf dem StatusDisplay visualisiert werden soll, muss nun ein MQTT_BRIDGE Device angelegt werden. Dieses ist dazu da, bei Statuswechsel des Geräts ein bestimmtes MQTT Topic zu verschicken.
Ich zeige die Konfiguration für einen 1-Kanal Homematic Unterputz Schaltaktor HM-LC-SW1-FM. Diesen Typ verwende ich für die meisten Deckenlampen bei mir im Haus. Der nachfolgend verwendete Schaltaktor hat den Namen Bad.Deckenlampe (dies ist der Name des Homematic Geräts, wie er in FHEM konfiguriert ist).
Das MQTT_BRIDGE Device legt man nun beispielsweise so an:
define mqtt_status_light_bath_ceiling MQTT_BRIDGE Bad.Deckenlampe
Nun hört die MQTT_BRIDGE mqtt_status_light_bath_ceiling auf Statusänderungen des Homematic-Geräts Bad.Deckenlampe. Es muss noch noch konfiguriert werden, welches Topic bei einer Statusänderung aktualisiert werden soll:
attr mqtt_status_light_bath_ceiling publishState fhem/status/light/bath_ceiling
Dieses Attribut sorgt dafür, dass bei Statusänderung der Status in das Topic fhem/status/light/bath_ceiling gepostet wird, also z.B. wird wenn das Licht angeschaltet wird die Nachricht „fhem/status/light/bath_ceiling on“ gepostet, bzw. beim Ausschalten entsprechend „fhem/status/light/bath_ceiling off„.
Wichtig und sinnvoll ist auch noch die Messages „retained“ zu schicken. Dadurch bekommt das StatusDisplay immer den aktuellen Status vom Broker zugestellt, auch wenn es zum Zeitpunkt der Statusänderung nicht online war:
attr mqtt_status_light_bath_ceiling retain 1
Ich empfehle, während ihr die Konfiguration vornehmt, immer die Commandref geöffnet zu haben und jeden Schritt nachzuvollziehen anstatt einfach die Befehle abzutippen. So bekommt ihr ein genaues Verständnis was ihr tut und könnt die weiteren Geräte ohne Probleme entsprechend konfigurieren.
Firmware
Als nächstes muss die Firmware auf den ESP8266 gespielt werden. Hierzu installiert man zunächst die Arduino IDE. Die Firmware kann von meinem GitHub-Repository geladen werden. Nach dem Entpacken öffnet man in der Arduino IDE die Hauptdatei (HomeStatusDisplay.ino) und kompiliert diese durch einen Klick auf den „Haken“ Button ganz links oben in der IDE, siehe nachfolgenden Screenshot.
Wenn die IDE frisch installiert wurde, wird es zu Fehlermeldungen wegen fehlenden Abhängigkeiten zu anderen Libraries kommen. Die folgenden Libraries werden benötigt und müssen daher installiert werden:
Adafruit_NeoPixel: https://github.com/adafruit/Adafruit_NeoPixel
PubSubClient: https://github.com/knolleary/pubsubclient
ArduinoJson: https://github.com/bblanchon/ArduinoJson
Alle Libraries können über den Library Manager der Arduino IDE installiert werden (Sketch->Include Library->Manage Libraries, dann im Suchfeld den Namen der Library eingeben).
Weiterhin muss das Package für die Unterstützung des ESP8266 in der Arduino IDE installiert werden. Dies geht über Tools->Board->Boards Manager. Hier gibt man im Suchfeld „ESP8266“ und installiert das gefundene Package. Wenn kein Package gefunden wird, muss folgende URL unter Datei -> Voreinstellungen -> Zusätzliche Boardverwalter-URLs hinzugefügt werden:
http://arduino.esp8266.com/stable/package_esp8266com_index.json
Unter Tools müssen noch die korrekten Board-Einstellungen für den wemos D1 Mini gemacht werden:
Unter „Port“ müsst ihr den USB Port auswählen, an dem der Controller angeschlossen ist. In der Regel gibt es hier nur eine Auswahlmöglichkeit. Nun kann der Code kompiliert werden, und nachdem dies erfolgreich abgeschlossen ist, wird der ESP8266 mit einem Micro-USB auf USB Kabel mit dem PC verbunden. Danach kann der Code mit dem Upload Button (zweiter Button von links, ganz oben in der IDE) auf den ESP8266 geladen werden.
Dies dauert eine Weile und wird am Ende von einer Erfolgsmeldung abgeschlossen. Falls eine Fehlermeldung auftaucht, einfach noch mal probieren- manchmal verhält sich der ESP8266 ein wenig eigenartig.
Inbetriebnahme
Die Firmware verhält sich beim ersten Booten so, dass ein WLAN Access Point aufgespannt wird. Dieser hat den Namen StatusDisplay und das Passwort statusdisplay. Mit dem PC oder Smartphone kann man diesen Access Point auswählen und sich damit verbinden. Danach ist unter der Adresse 192.168.4.1 die Konfigurationsseite des Geräts verfügbar.
Hier kann man nun die Basiskonfiguration vornehmen, wichtig ist zunächst WiFi SSID und Passwort. Sinvollerweise kann man auch schon LED-Anzahl und LED-Datenpin eingeben. Nach einem Klick auf Reboot sollte sich das Gerät mit dem WLAN verbinden (Hinweis: auch hier hat der ESP8266 ein seltsames Verhalten. Der erste Boot nach dem Flashen der Firmware via USB funktioniert meistens nicht; daher kann es sein dass kurz die Spannungsversorgung abgezogen und wieder angeschlossen werden muss, damit er wieder hochfährt).
Visualisiert wird das Hochfahren -sofern korrekt eingegeben- schon über die LEDs:
- alle LEDs rot bedeutet: Keine WLAN Verbindung vorhanden
- alle LEDs gelb bedeutet: WLAN Verbindung vorhanden, MQTT Verbindung steht noch nicht
Man sollte nun die Konfigurationsseite erneut aufrufen (diesmal über die IP, die das Gerät vom lokalen DHCP-Server bekommen hat, dazu im Router nachsehen), und die restlichen Einstellungen machen. Auf der Statusseite sieht man eine Übersicht über den Zustand des Geräts:
Weiter geht es auf der „General“ Seite mit den restlichen Einstellungen:
- MQTT Server: Servername oder IP des MQTT-Servers
- Status Topic: Topic, über das die Statusmeldungen übermittelt werden, auf die die LEDs reagieren sollen. Dieses MUSS eine Wildcard enthalten in der Form, dass auf alle gewünschten Nachrichten reagiert wird. Beispiel „fhem/status/#“ -> Alle Nachrichten die mit fhem/status beginnen, werden für die Statusanzeige hergenommen. Das Topic muss natürlich zu den vorher angelegten MQTT_ BRIDGE Devices passen.
- Es wird davon ausgegangen, dass im Topic danach einer der unterstützten Gerätetypen im String folgt (derzeit „door“, „window“, „light“ und „alarm“), sowie der Name des Geräts, Beispiel: fhem/status/light/bath_ceiling, siehe ebenso oben die Konfiguration der MQTT_BRIDGE
- Test Topic: Ein Topic zu Testzwecken. Dieses wird nur komplett erkannt, also keine Wildcards. Als Message können die Werte 1-5 übermittelt werden, diese schalten verschiedene LEDs dauerhaft an, um die Funktion der LEDs testen zu können. Mit Message „0“ wird in den normalen Betrieb zurück geschaltet.
- Will Topic: Dieses Topic wird beim Startup des Geräts mit der Message „on“ gepublished. Wenn die Verbindung zum Gerät abbricht (z.B. weil stromlos), schickt der MQTT Broker dieses Topic mit der Message „off“. Hiermit kann man überwachen, ob das Gerät einsatzbereit ist
Nach Klick auf „Save“ und „Reboot“ sollten nun nicht mehr alle LEDs in rot oder gelb an sein, sondern aus (normaler Betrieb).
Nun muss noch das „Color Mapping“ konfiguriert werden.
Hier müssen Message, Type, Color und Behavior gewählt werden.
Zum Verständnis hier ein Beispiel, wie ein Statustopic aussehen soll: „fhem/status/window/kitchen open“. -> Konfiguration z.B.:
open, Window, Blue, On -> Wenn im Topic „fhem/status/window/DEVICENAME“ die Message „open“ empfangen wird, soll dies mit einer dauerhaft leuchtenden blauen LED signalisiert werden.
Allgemein gesprochen konfiguriert man hier „Wenn eine Message X für den Gerätetyp Y empfangen wird, wie soll sich eine LED verhalten“.
Was alles in DEVICENAME stehen darf, wird im Device Mapping eingestellt:
Hier müssen Device, Type und LedNummer gewählt werden.
Beispiel:
kitchen, Window, 2
Im Zusammenhang mit dem Color Mapping bedeutet dies:
Wenn die message „fhem/status/window/kitchen open“ empfangen wird, soll dies an der LED 2 signalisiert werden, diese würde dann blau leuchten (Zusammenspiel mit Color Mapping).
Wenn man im Device Mapping noch hinzufügt z.B. „eating, Window, 3“, dann wird auch die Message „fhem/status/window/eating open“ erkannt, hier würde die LED 3 blau leuchten.
Allgemein gesprochen konfiguriert man hier „Wenn eine Message für Device X vom Typ Y eintrifft, welche LED soll reagieren“.
Ausblick
Auf den ersten Blick sieht dieses Tutorial sehr kompliziert aus. Dies liegt aber vor allem daran, dass ich viele grundlegende Dinge ebenso versucht habe zu erläutern. Wer Erfahrung mit FHEM hat, für den erleichtert sich schon vieles. Wer auch schon die Arduino IDE kennt und benutzt hat, wird sich auch mit der Firmware sehr leicht tun- es bleibt in diesem Fall nur noch die Konfiguration von MQTT. Da dies prinzipiell ein sehr leicht zu verstehendes System ist, denke ich dass man mit Hilfe der Beispiele und der genannten Links gut ein Verständnis aufbauen kann.
Als letztes bleibt mir nur noch viel Spaß bei Aufbau und Inbetriebnahme eures eigenen HomeStatusDisplay zu wünschen. Die von mir gewählte Optik ist natürlich nur eine von vielen Möglichkeiten. Wer möchte kann mir gerne Fotos von seinem eigenen Display schicken, es würde mich sehr interessieren.
Im übrigen ist es auch problemlos möglich, mehrere HomeStatusDisplays gleichzeitig zu betreiben- durch den zentralen Broker bekommen alle Geräte die auf das Status Topic subscribed sind den Status automatisch zugestellt.
Wenn Probleme beim nachvollziehen und durchführen dieses Tutorial auftauchen, bitte in den Kommentaren fragen- ich werde wie gesagt versuchen, alle Fragen zu beantworten und bei Bedarf das Tutorial zu ergänzen. Solltet ihr Fehler in diesem Tutorial feststellen, könnt ihr mir diese ebenso gerne melden.
Nachtrag 05.06.2017: Der User stenumer aus dem we-mod-it.com Forum hat mir folgendes Foto seines Nachbaus geschickt:
Hallo Bernd,
ein ziemlich geniales Projekt hast du dir da aufgebaut. Da ich momenten mit Openhab und Hausautomatisierung experimentiere habe ich mir deine Software mal angeschaut.
Leider bekomme ich diese nicht so richtig zum Laufen. Genauer gesagt funktioniert des Flashen des Wemos D1 Mini mit RGB-Shield sehr gut. Der StatusDisplay-AP erscheint auch wie von dir beschrieben. Eine Anpassung der Konfiguration habe ich durchgeführt.
Der Reboot wird auch ausgeführt, nur danach erhalte ich folgende Aussagen im Serial Monitor:
Initializing config.
Mounted file system.
Reading config file /config.json
File does not exist
Creating default main config file.
Writing config file /config.json
File does not exist
Failed to write file, formatting file system.
Done.
Reading config file /colormapping.json
File does not exist
Creating default color mapping config file.
Deleting color mapping config data.
Writing config file /colormapping.json
File does not exist
Failed to write file, formatting file system.
Done.
Reading config file /devicemapping.json
File does not exist
Creating default device mapping config file.
Deleting device mapping config data.
Writing device mapping config file.
Writing config file /devicemapping.json
File does not exist
Failed to write file, formatting file system.
Done.
Starting WebServer.
Initializing MQTT connection to
Free RAM: 32904
Starting Wifi connection to
Failed to connect WiFi.
Starting access point.
AccessPoint SSID is StatusDisplay
IP: 192.168.4.1
Er findet also wohl die config.json und formatiert den Speicher. Danach ist alles weg und er springt wieder in den unkonfigurierten Zustand.
Bei genauerem Hinsehen ist mir aufgefallen, dass eine Speicherung der Konfiguration schon nicht richtig funktionierte.
Starting access point.
AccessPoint SSID is StatusDisplay
IP: 192.168.4.1
Page size: 1058
Page size: 1058
Page size: 2727
Free RAM: 29472
Page size: 2750
Main config has changed, storing it.
Writing config file /config.json
File does not exist
Failed to write file, formatting file system.
Done.
Free RAM: 28952
Page size: 1058
Page size: 2750
Free RAM: 29472
Page size: 2750
Rebooting ESP.
Hast du eine Idee, was da bei mir schiefläuft? Ich habe es mit der Version 0.4 getestet.
Viele Grüße
Tim
Hi,
das Problem scheint bei dir zu sein dass er es nicht schafft die Konfigurationsdateien ins Flash zu schreiben.
Benutzt du einen Original wemos D1 mini oder einen Klon?
Du sagst du hast schon einmal eine Konfiguration vorgenommen. Bitte mache das nochmal, und poste die Log-Ausgabe vom Booten bis zu der Stelle wo du in die Konfiguration was eingetragen hast und „Save“ gedrückt hast. Ich vermute schon hier klappt das Abspeichern nicht.
Achja, wenn du das Log postest wird darin deine WIFI SSID und Passwort auftauchen. Die kannst du natürlich unkenntlich machen 😉
/Edit: Ich sehe gerade, genau das hast du schon gemacht. Komisch ist allerdings, dass die Werte die du eingetragen hast gar nicht im Log auftauchen? Ich werde morgen mal nachsehen was es noch für Möglichkeiten gibt
Als kleine Ergänzung mit dem aktuellen Master-Branch funktioniert es problemlos.
Sehr cooles Projekt. Vielen Dank für die Veröffentlichung.
Ah, alles klar.
Ja das stimmt, die Version 0.4 hat hier noch einen Bug, den ich erst nach dem Release gefixt habe. War mir so nicht mehr bewußt. Ich schaue dass ich schnellstmöglich ein Release vom aktuellen Master mache, damit andere nicht in das gleiche Problem laufen.
Freut mich jedenfalls dass es klappt!
Hallo Bernd,
vielen Dank für das ausführliche Tutorium und die geniale Firmware. Der Nachbau hat super geklappt und solange der LED-Rahmen online ist werden auch alle Meldungen angezeigt.
Wenn dieser allerdings stromlos ist und wieder Online geht sind nach dem Booten (und kurzen Roten aufleuchten aller LEDs) alle LEDs aus obwohl beim Brooker Statusmeldungen hinterlegt sind (MQTT QoS 2) ich kann diese z.B. mit MQTT-Spy sehen.
Erst wenn sich ein Status ändert oder erneuert wird leuchtet die entsprechende LED. Ist es nicht möglich, dass alle Statusmeldungen beim starten angefordert werden?
Dann habe ich noch ein Problem mit der Last Will Message, beim starten wird diese nicht auf „On“ gesetzt.
Gruß Andre
Hi Andre,
freut mich dass der Nachbau gut geklappt hat.
Damit der letzte Status erneut übertragen wird wenn das Display online geht, ist es notwendig dass die Meldungen von den jeweiligen Geräten mit „retained“ Flag gepublished werden. Ist dies bei dir der Fall? Der QoS spielt da keine Rolle.
Beim Last Will Topic habe ich gerade noch keine Idee warum das bei dir nicht klappt. Wird nie „on“ gepublished oder nicht immer?
Grüße,
Bernd
Hallo Bernd,
da muss ich mich wohl noch tiefer mit MQTT beschäftigen… QoS 2 bedeutet ja, dass die Nachricht mindestens 1x zugestellt wird ich dachte dann auch noch mal wenn der Client wieder Online ist.
Habe jetzt überall noch den retain Flag gesetzt und jetzt funktioniert es wie erwartet, danke für deine Hilfe.
Heute habe ich auch noch 3x den LTW „On“ getestet, habe dafür in Node-Red eine Texfeld angelegt welches das Topic anzeigt.
2x wurde „On“ angezeigt 1x „Off“ obwohl der LED-Rahmen online war.
Vielleicht solltest du den „On“ Status später verschicken oder periodisch wiederholen,
Gruß Andre
Hallo, ich wollte für mein Status Display 96leds verwenden. Ist das ohne Probleme möglich oder muss man am Code etwas anpassen? Strom-/Spannungsversorgung ist logisch, dass die ausreichend sein muss.
Hi, sorry für die späte Antwort.
Aufgrund des limitierten Speichers des ESP sind mit dem Konfigurationskonzept per Webseite derzeit maximal 35 LEDs möglich. Das zu erweitern würde größere Umbauarbeiten bedeuten.
hi.
wollte das Projekt nachbauen.
Komme aber über das kompilieren nicht drüber weg!
Hast du eine Idee was ich falsch mache?
Danke
Sascha
—————————-
Fehler:
Arduino: 1.8.4 (Windows 7), Board: „Generic ESP8266 Module, 80 MHz, 80MHz, DIO, 115200, 512K (64K SPIFFS), ck, Disabled, None“
C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\DSL\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\DSL\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\DSL\Documents\Arduino\libraries -fqbn=esp8266:esp8266:generic:CpuFrequency=80,FlashFreq=80,FlashMode=dio,UploadSpeed=115200,FlashSize=512K64,ResetMethod=ck,Debug=Disabled,DebugLevel=None____ -ide-version=10804 -build-path C:\Users\DSL\AppData\Local\Temp\arduino_build_104314 -warnings=none -build-cache C:\Users\DSL\AppData\Local\Temp\arduino_cache_281698 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.esptool.path=C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\esptool\0.4.9 -prefs=runtime.tools.mkspiffs.path=C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\0.1.2 -prefs=runtime.tools.xtensa-lx106-elf-gcc.path=C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26-gb404fb9-2 -verbose C:\TEMP_Adrino\HomeStatusDisplay-0.5-beta\HomeStatusDisplay-0.5-beta\HomeStatusDisplay\HomeStatusDisplay.ino
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\DSL\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\DSL\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\DSL\Documents\Arduino\libraries -fqbn=esp8266:esp8266:generic:CpuFrequency=80,FlashFreq=80,FlashMode=dio,UploadSpeed=115200,FlashSize=512K64,ResetMethod=ck,Debug=Disabled,DebugLevel=None____ -ide-version=10804 -build-path C:\Users\DSL\AppData\Local\Temp\arduino_build_104314 -warnings=none -build-cache C:\Users\DSL\AppData\Local\Temp\arduino_cache_281698 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.esptool.path=C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\esptool\0.4.9 -prefs=runtime.tools.mkspiffs.path=C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\0.1.2 -prefs=runtime.tools.xtensa-lx106-elf-gcc.path=C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26-gb404fb9-2 -verbose C:\TEMP_Adrino\HomeStatusDisplay-0.5-beta\HomeStatusDisplay-0.5-beta\HomeStatusDisplay\HomeStatusDisplay.ino
Using board ‚generic‘ from platform in folder: C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0
Using core ‚esp8266‘ from platform in folder: C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0
Detecting libraries used…
„C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-g++“ -D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0/tools/sdk/include“ „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0/tools/sdk/lwip/include“ „-IC:\Users\DSL\AppData\Local\Temp\arduino_build_104314/core“ -c -w -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -ffunction-sections -fdata-sections -w -x c++ -E -CC -DF_CPU=80000000L -DLWIP_OPEN_SRC -DARDUINO=10804 -DARDUINO_ESP8266_ESP01 -DARDUINO_ARCH_ESP8266 -DARDUINO_BOARD=“ESP8266_ESP01″ -DESP8266 „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\cores\esp8266“ „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\variants\generic“ „C:\Users\DSL\AppData\Local\Temp\arduino_build_104314\sketch\HomeStatusDisplay.ino.cpp“ -o „nul“
„C:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-g++“ -D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0/tools/sdk/include“ „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0/tools/sdk/lwip/include“ „-IC:\Users\DSL\AppData\Local\Temp\arduino_build_104314/core“ -c -w -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -ffunction-sections -fdata-sections -w -x c++ -E -CC -DF_CPU=80000000L -DLWIP_OPEN_SRC -DARDUINO=10804 -DARDUINO_ESP8266_ESP01 -DARDUINO_ARCH_ESP8266 -DARDUINO_BOARD=“ESP8266_ESP01″ -DESP8266 „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\cores\esp8266“ „-IC:\Users\DSL\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\variants\generic“ „C:\Users\DSL\AppData\Local\Temp\arduino_build_104314\sketch\HomeStatusDisplay.ino.cpp“ -o „C:\Users\DSL\AppData\Local\Temp\arduino_build_104314\preproc\ctags_target_for_gcc_minus_e.cpp“
C:\TEMP_Adrino\HomeStatusDisplay-0.5-beta\HomeStatusDisplay-0.5-beta\HomeStatusDisplay\HomeStatusDisplay.ino:1:31: fatal error: HomeStatusDisplay.h: No such file or directory
#include „HomeStatusDisplay.h“
^
compilation terminated.
exit status 1
Fehler beim Kompilieren für das Board Generic ESP8266 Module.
Hi,
das Problem steht ganz am Ende: HomeStatusDisplay.h: No such file or directory
Hast du alle Dateien in dem Verzeichnis liegen, in dem sich die ino befindet?
Am besten auf Github auf der Release-Seite (https://github.com/MTJoker/HomeStatusDisplay/releases) das neueste Release runter laden und alles in ein Verzeichnis entpacken. Dann die ino öffnen und kompilieren.
Du kannst natürlich auch von der Hauptseite herunterladen (https://github.com/MTJoker/HomeStatusDisplay), dort bekommst du die neueste Entwicklungsversion – aber in jedem Fall brauchst du alle Dateien.
Hi,
ist es auch möglich dies in IOBroker mir einzubinden?
Hi,
mit IOBroker kenne ich mich nicht aus. Aber das Gerät lässt sich in alle System einbinden, die MQTT sprechen.
Moin,
ich finde das Projekt schick und will das gerne nachbauen. Flasche etc sind problemlos, ist auch ins WLan eingebunden. Aber ich bekomme keine MQTT Verbindung zustande (MQTT an sich läuft, steuere damit Sonoff Schalter mit Tasmota). Monitor liefert mir
Starting WebServer.
Free RAM: 34608
Starting Wifi connection to Tedious_Home…
WiFi connected with IP 192.168.192.83.
Connecting to MQTT broker 192.168.192.60 with client id ESP8266Client-359a… failed, rc = -4
DEBUG: Reconnect unsuccessful, m_numConnectRetriesDone = 1
Connecting to MQTT broker 192.168.192.60 with client id ESP8266Client-1613… failed, rc = -4
DEBUG: Reconnect unsuccessful, m_numConnectRetriesDone = 2
Connecting to MQTT broker 192.168.192.60 with client id ESP8266Client-7110… failed, rc = -4
DEBUG: Reconnect unsuccessful, m_numConnectRetriesDone = 3
Failed to connect Mqtt.
Hast Du einen Tip wo ich ansetzen könnte?
Hi,
der Rückgabewert -4 bedeutet „MQTT_CONNECTION_TIMEOUT“, d.h. der Mqtt Server hat nicht innerhalb der KeepAlive Zeit geantwortet. Stimmt die IP-Adresse sicher?
Hallo Bernd, auch von mir ein großes Lob.
Es ist mir gelungen alles ohne größere Probleme nachzubauen. Das Problem ist, das die Verbindung zum Mosqitto_Server vom ESP nach dessen Naustart nur sproradisch auf dessen Statusseite angezeigt wird. Der Mosqitto_Server hingegen meldet „connection active“ und aktalisiert dies jede Minute. Der Mosquitto läuft genau wie Fhem auf einem Rasperry 3 (Port 1883).
Was kann ich da machen?
MFG
Bernd C
Meinst du auf der Webseite die von der HomeStatusDisplay Firmware bereitgestellt wird? Also wenn dort nichts steht, dann kann eigentlich auch keine Verbindung bestehen. Funktioniert das Display denn, wenn dort nichts steht?
Hallo Bernd,
ich habe deinen „Bilderrahmen“ nachgebaut, vielen Dank erstmal für die tolle Idee und die Bereitstellung der Bauanleitung/Software. Da der Wemos ja etwas unterfordert ist hatte ich die Idee noch 3 bis 4 Taster auf dem Bilderrahmen zu platzieren die beim Drücken bestimmte Aktionen auslösen, natürlich per MQTT Message. Hättest du eine Idee wie ich das am besten in deine Firmware einbaue? Bin da leider nicht so der Fachmann drin 😉
Danke schonmal und Grüße aus dem Ruhrpott!!!
Hi Klaus,
danke fürs Lob erstmal.
Ich weiß nicht welche Kenntnisse du hast, aber prinzipiell ist das sehr einfach:
– jeden Taster an einen freien Pin des Wemos anschließen
– Pins als INPUT_PULLUP definieren
– Pin-Zustand in der main loop abfragen (Entprellen nicht vergessen, gibts aber fertige Libs dazu wie z.b. „Bounce2“)
– bei Wechsel auf LOW eine MQTT-Message absetzen, z.B. „statusdisplay/switch1/status“, z.B. mit der Funktion HSDMqtt::publish (siehe MSDMqtt.cpp); idealerweise noch vorher checken ob überhaupt eine Verbindung zum MQTT Server besteht
Die Idee ist jedenfalls interessant, ich habe auch schon mal drüber nachgedacht aber im Moment keine Zeit für eine Implementierung. Wenn du da was funktionsfähiges hinbekommst nehme ich es gerne offiziell in die Firmware auf!
Hallo Bernd,
ich habe da noch ein Problem festgestellt. Bin mir aber nicht sicher ob es an deinem Code oder am NeoPixel Plugin liegt.
Und zwar habe ich die Helligkeit auf 10% gesetzt und man kann sehr gut erkennen, dass regelmäßig (ca.1x pro Stunde) kurz alle LEDs mit voller Helligkeit aufblitzen.
Gruß Andre
Hallo Andre,
Den Fehler konnte ich bei mir noch nie sehen. Sind es alle Leds die hell aufleuchten oder nur die, die sowieso schon an waren? Und in welcher Farbe leuchten sie auf, in der wie sie waren oder alle in der selben Farbe (und in welcher, wenn letzteres)?
Hallo Bernd,
leider kann ich deine Fragen nicht beantworten. Das Status Display hängt im Flur und man sieht es dann daran, dass es einen Art Lichtblitz dort gibt.
Wenn du das Problem nicht hast, liegt es vielleicht an meinem LED-Streifen es ist ein WS2812B mit 144 LEDs pro Meter.
Gruß Andre
Hallo Andre,
ok. Meine Vermutung ist, dass das Display komplett neu bootet und der „Lichtblitz“ daher kommt, dass beim Booten kurz alle LEDs an sind während der Verbindung mit dem WLAN. Schau doch mal auf die Webseite des Displays kurz nachdem dieser Lichtblitz passiert ist. Unter „Status“ steht eine Device uptime. Wenn das Gerät neu gebootet hat, geht diese wieder auf 0. Ist das vielleicht das Problem?
Hallo Bernd,
jetzt stand ich mal direkt daneben als es wieder Aufblitzte. Es leuchten nicht alle LEDs (also kein Neuboot) sondern die welche gerade etwas Anzeigen waren für ca. 1s auf voller Helligkeit bevor diese wieder auf 10% gedimmt wurden.
Kurios. Dafür habe ich aktuell keine Erklärung. In der Software gibt es nichts, was die LEDs kurz auf volle Helligkeit stellen würde. Ich kann leider nur mutmaßen: Vielleicht ein Problem mit dem Netzteil? Kannst du mal ein anderes ausprobieren?
Hallo Bernd, ich habe dein HomestatusDisplay Projekt eher zufällig gefunden. Obwohl ich genau nach soetwas gesucht hatte. Daher versuche ich nun es nach zu bauen.
Leider scheitere ich schon ganz am Anfang an der Übertragung der Firmware.
Ich benutze aktuell Arduino IDE 1.6.12.
Die Firmware soll auf eine NodeMcu.
Die beschriebenen Einstellungen habe ich vorgenommen.
Der ESP ist im FlashMode.
Leider funktioniert das Übertragen nicht.
Muss ich eine bestimmte Version von Arduino IDE benutzen?
Gruss Ingo
Lei
Hi, nein es ist keine bestimmte Version der IDE erforderlich. Was genau funktioniert nicht, das kompilieren oder das Übertragen? Poste bitte mal die Fehlermeldung die kommt.
Hallo habe das statusdisplay nachgebaut alles funktioniert soweit allerdings ist das LED beahviour „on“ auch blinkend ist das so gewollt? ich dachte es soll einfach dauer an sein
Nein, das ist natürlich nicht so gewollt, „on“ heißt dauerhaft an. Zwei Sachen:
1) hast du für die betroffene LED sowohl „on“ als auch „blink“ aktiviert?
2) kommt auch ganz sicher die MQTT-Message, die für das Behavior „on“ definiert wurde? Am besten mal mit einem Tool wie z.B. MQTT.fx kontrollieren
Poste oder schick mir vielleicht mal deine Konfiguration, die wird beim Booten über die serielle Schnittstelle ausgegeben. Zur Not ginge auch ein Screenshot von allen Konfigurations-Seiten. Kannst du auch gerne an meine Email (siehe Impressum schicken).
Hallo Email gesendet
Hallo,
schaffe es leider nicht ein notify auszulösen in fhem:
Mit folgenden Anweisungen kann ich eine Temperatur in FHEM übergeben die dann unter Status angezeigt wird:
define Mosquitto_Broker MQTT 192.168.1.66:1883
define WeMos_WZ MQTT_DEVICE
attr WeMos_WZ room MQTT
attr WeMos_WZ IODev Mosquitto_Broker
attr WeMos_WZ subscribeReading_Temperatur /Temperatur/set
attr WeMos_WZ stateFormat Temperatur
Möchte nun mit einer If Abfrage oder einem notify das Ventil ausschalten wenn die Temperatur größer 24 Grad ist.
Wie kann ich den Status (Temperatur) abfragen und das Ventil aus oder einschalten?
Hallo Jakob, ich würde dich bitten diese Fragen im FHEM Forum zu stellen. Ich kann es zeitlich und auch vom Wissen her nicht schaffen, allgemeine FHEM-Fragen zu beantworten. Da gibt es zu viele Nebenbedingungen je nachdem was genau an Hardware vorhanden ist und was genau gewünscht ist.
Hallo Bernd,
bin gerade dabei mich Stück um Stück durch die Anleitung zu arbeiten und mir sind zwei Punkte aufgefallen. Waren keine große Probleme, Google bzw. Hirn einschalten half mir recht schnell weiter, aber der Vollständigkeit halber kann man das evtl. hier auch direkt mit einbauen.
1. „Weiterhin muss das Package für die Unterstützung des ESP8266 in der Arduino IDE installiert werden. Dies geht über Tools->Board->Boards Manager. Hier gibt man im Suchfeld „ESP8266“ und installiert das gefundene Package.“ Das klappt bei einer jungfräulichen Arduino IDE nicht, da findet man unter ESP8266 nichts. Erst nachdem ich unter Datei -> Voreinstellungen -> Zusätzliche Boardverwalter-URL’s die http://arduino.esp8266.com/stable/package_esp8266com_index.json eingetragen hatte wurde ich im Boardverwalter mit ESP8266 fündig und konnte die Boards installieren.
2. „Nachdem der Code erfolgreich kompiliert wurde, wird der ESP8266 mit einem Micro-USB auf USB Kabel mit dem PC verbunden. Unter Tools müssen noch die korrekten Board-Einstellungen für den wemos D1 Mini gemacht werden:“ Ich konnte den Code erst erfolgreich kompilieren NACHDEM ich die korrekten Board-Einstellungen vorgenommen hatte. Vorher hat der den immer noch versucht für das Voreingestellte Arduino Board zu kompilieren und das lief schief. Hier müsste also in der Anleitung die Reihenfolge angepasst werden – erst Boardeinstellungen setzen, dann kompilieren.
Ansonsten muss ich sagen – Respekt und Danke!
MfG
Marco
Hallo Marco, danke fürs Lob und für die Anmerkungen, welche natürlich völlig richtig sind! Ich habe den Artikel entsprechend aktualisiert.
Hi Bernd,
in Deinen Texten erläuterst Du die Arduino IDE Einstellungen anhand der englischen Version und hast jetzt meine Angaben mit eingearbeitet die von der deutschen Version stammen. Ggf. sollte man das noch Vereinheitlichen – der Schönheit wegen. 😉
Eine andere Kleinigkeit fiel mir noch auf, einfach nur weil ich da für mich gleich beim Einrichten ein paar Anpassungen an mein System vorgenommen habe und später feststellte, dass ich mich an die Vorgaben halten muss.
Es gibt den Punkt „Es muss noch noch konfiguriert werden, welches Topic bei einer Statusänderung aktualisiert werden soll:
attr mqtt_status_light_bath_ceiling publishState fhem/status/light/bath_ceiling“
Hier hatte ich mir Anpassungen vorgenommen weil ich meine Konfiguration immer noch weitestgehend auf Deutsch halte. Später in der Einrichtung stolperte ich und dann kam auch der Hinweis „Es wird davon ausgegangen, dass im Topic danach einer der unterstützten Gerätetypen im String folgt (derzeit „door“, „window“, „light“ und „alarm“)“ Da kam ich natürlich mit meinen deutschen Bezeichnungen nicht mehr weit. Ggf. kann man den Hinweis schon oben mit einbauen.
MfG,
Marco
Hallo,
danke für das Tutorial, ich versuche das ganze mit iobroker zum laufen zu bringen?
Bis jetzt ohne Erfolg.
Das sind z.b die Meldungen beim schalten der Sonoffs die mit Tasmota geflasht sind.
17:08:49 MQT: stat/light-Sonoff-Rote-Lampe/RESULT = {„POWER“:“OFF“}
17:08:49 MQT: stat/light-Sonoff-Rote-Lampe/POWER = OFF
Hat jemand eine Idee was wo in der Konfiguration eingetragen werden sollte, habe schon einige Kombinationen probiert.
Vielen Dank Dirk
Hi,
auf direktem Weg funktioniert das leider nicht. Der Aufbau der Topics in sonoff-tasmota und im HomeStatusDisplay sind jeweils fix.
Man müsste ein Mapping zwischen den Topics durchführen. In FHEM könnte man sich mit Devices vom Typ Dummy, MQTT_BRIDGE und readingsProxy was passendes bauen, so dass bei Empfang eines bestimmten Topics (Aufbau entsprechend Tasmota) ein anderes Topic gesendet wird (Aufbau entsprechend HomeStatusDisplay). In ioBroker kenne ich mich leider nicht aus…
Danke für die schnelle Antwort.
Schade das es nicht so einfach geht , wäre genau das was ich suche.
Trotzdem danke für deine Arbeit, vielleicht bekomm ich es noch irgendwie hin.
Hallo, auch von mir ein großes Dankeschön!
Tolles Projekt, und super nachvollziehbar erklärt. Danke!
Bei mir steht im Seriellen Monitor, dass eine MQTT Nachricht ON empfangen wird, aber im Style4, hab ein wenig rumprobiert und festgestellt, dass die voreingestellten (Window, Door, Alarm, Light) Style 0-3 sind.
Im Seriellen Monitor steht dann Sinngemäß, dass die Message ON empfangen wurde, aber ignoriert wird, da es im Style4 konfiguriert ist.
Ich vermute, dass ich bei den MQTT Meldungen unbedingt …/…/light oder window oder door stehen haben muss.
Ist das so?
Bisher hab ich nur ne Mqtt Topic in der Form …./…./RESULT# ( da dass die Sonoff MQTT Message vorgibt.
Ich konnte es noch nicht weiter probieren (werde ich heute Abend machen).
Was ich schon vorbereitet hab, da ich OH2 nutze, ist ein Switch, der den Sonoff Status empfängt und dann eine von mir gestaltbare MQTT Nachricht versendet. (mit einer Regel konfiguriert). Die werd ich dann in Form von home/Kellerlicht/light:ON:1 versenden.
Somit hoffe ich auf dem richtigen Weg zu sein.
Wenn es funktioniert, stell ich hier gerne mal den Weg ein.
Grüße Auke
Hi,
ja das siehst du genau richtig. Der Aufbau der MQTT-Messages ist fest vorgegeben. Im Kapitel „Inbetriebnahme“ im Artikel steht das mit Beispiel beschrieben. In FHEM kann man mit den MQTT_BRIDGE Devices ganz gut auch so ein Mapping durchführen, sollte man Geräte mit ebenso fest vorgegebenem Message Aufbau haben. Wege für andere Systeme sind natürlich immer gern gesehen.
Hallo
Guten Projekt habe es nachgebaut aber,
bekomme aus Fhem kein LED zu leuchten, mit der Konsole und den
den Befehl: mosquitto_pub -t fhem/light/mqtt_2 -m on geht es.
In Fhem alles nach Anleitung eingerichten, Monitoring bringt auch:
MQTT_BRIDGE mqtt_2 transmission-state: outgoing publish sent
Gibts noch einen Tipp was ich falsch mache
LG
Hi,
d.h. beim HomeStatusDisplay geht die entsprechende LED an wenn du es über die Konsole eingibst, und über FHEM nicht? Dann kann es eigentlich nur daran liegen dass FHEM entweder nicht auf das richtige Topic oder nicht die richtige Message schickt. Was sagt denn die Konsole vom HomeStatusDisplay wenn die Nachricht vom FHEM gesendet wird?
Hallo Bernd,
erstmal einfach nur RESPEKT, richtig geiles Projekt. Kinderleicht zum nachbauen. Habe nur ein kleines Problem mit meinen EQ3 Fensterkontakten.
Da sie mehrere Readings senden, geht beim aufmachen des Fensters die LED kurz an, und dann wird sie durch das nächte reading (z.B. battery) wieder ausgeschalten.
Gibt es eine möglichkeit MQTT nur auch das reading „state“ zu begrenzen?
Vielen dank im Voraus
Gruß Jan
Hi,
das geht natürlich (nutze ich ja auch so). Allerdings bräuchte ich da ein paar Infos mehr- z.B. verwendest du FHEM zum senden der MQTT Nachrichten? Wie sendest du, über ein MQTT_BRIDGE Device? Dann bitte mal ein „list“ von dem Device posten. Weiterhin wäre noch die Einstellungen im HomeStatusDisplay selbst interessant (v.a. das Device Mapping).
Vielen Dank zunächst für die tolle Arbeit! Ich konnte die Installation und General-Konfiguration problemlos durchführen. Auch derTest an /fhem/status/light/test mit den Test-Topics funktioniert; demnach müsste die Hardware in Ordnung sein.
Mein Problem: Nach Definition eines Device und Color-Mappings werden keinerlei Aktionen auf dem LED-Stripe sichtbar, sprich keine Reaktion.
Die Kommandos on bzw. off kommen am mosquitto-Server an, habe ich über MQTT.fx kontrolliert und auch gepublisht. Wo kann ich den Fehler suchen?
Color-Mapping(s): (0 zur Sicherheit, falls FHEM ’set_on‘ statt ‚on‘ sendet)
Nr Message Type Color Behavior
0 set_on Light green On
1 on Light green On
Device-Mapping:
Nr Device Type Led
0 /fhem/status/light/wz Light 5
1 /fhem/status/light/wz/ Light 3
Ich habe max. 30 LEDs konfiguriert. Pin stimmt auch.
Hi,
da wäre es am einfachsten wenn du das HomeStatusDisplay am Rechner anschließt und die Ausgaben auf der Konsole beobachtest wenn du die Nachrichten sendest. Dann kann man sehen ob sie überhaupt am Display ankommen, und wenn ja, warum das Display sich entscheidet sie zu ignorieren 🙂
Hast du beim Device Mapping wirklich das komplette Topic so eingegeben wie gepostet? Wenn ja passt das so nicht, da muss nur der Name vom Gerät hin, müsste in deinem Fall „wz“ sein (siehe die Screenshots in der Anleitung). Weiterhin- warum hast du dasselbe Geräte zweimal im Device Mapping? Möchtest du dass zwei LEDs (5 und 3) angehen? Da bin ich mir nicht sicher ob das geht 🙂
Hallo Bernd,
vielen Dank für den schnellen Tipp. Ich erhalte auf dem seriellem Monitor:
Received an MQTT message for topic /fhem/status/light/wz: off
No LED defined for device wz of type 2, ignoring it
Ich habe aber doch im Device Mapping die LED 3 definiert (5 hatte ich zum Test, habe ich rausgenommen).
Sorry: eine Neudefinition des Device und ein Reboot haben geholfen. Es scheint jetzt zu funktionieren! Nochmals vielen Dank!
Bestens, freut mich dass es nun klappt.
Moin Bernd,
nachdem ich die Bibliotheken eingebunden hatte, begann das Übersetzen der Sourcen. Nach einer Weile bekam ich folgende Fehlermeldung:
—————————-
Arduino: 1.8.5 (Mac OS X), Board: „NodeMCU 1.0 (ESP-12E Module), 80 MHz, 4M (1M SPIFFS), v2 Prebuilt (MSS=536), Disabled, None, 115200“
sketch/HSDConfig.cpp: In member function ‚bool HSDConfig::readMainConfigFile()‘:
HSDConfig.cpp:95: error: ‚DynamicJsonBuffer‘ was not declared in this scope
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_MAIN_CONFIG_FILE);
^
sketch/HSDConfig.cpp:95:5: note: suggested alternative:
In file included from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/DynamicJsonDocument.hpp:10:0,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.hpp:9,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.h:9,
from sketch/HSDConfigFile.h:4,
from sketch/HSDConfig.h:3,
from sketch/HSDConfig.cpp:1:
/Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/Memory/DynamicJsonBuffer.hpp:159:5: note: ‚ArduinoJson::Internals::DynamicJsonBuffer‘
DynamicJsonBuffer;
^
HSDConfig.cpp:95: error: expected ‚;‘ before ‚jsonBuffer‘
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_MAIN_CONFIG_FILE);
^
HSDConfig.cpp:96: error: ‚jsonBuffer‘ was not declared in this scope
JsonObject& json = jsonBuffer.parseObject(fileBuffer);
^
HSDConfig.cpp:101: error: ‚class ArduinoJson::JsonObject‘ has no member named ‚measureLength‘
Serial.print(F(„JSON length is „)); Serial.println(json.measureLength());
^
HSDConfig.cpp:102: error: ‚class ArduinoJson::JsonObject‘ has no member named ‚prettyPrintTo‘
json.prettyPrintTo(Serial);
^
sketch/HSDConfig.cpp: In member function ‚bool HSDConfig::readColorMappingConfigFile()‘:
HSDConfig.cpp:148: error: ‚DynamicJsonBuffer‘ was not declared in this scope
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_COLOR_MAPPING_CONFIG_FILE);
^
sketch/HSDConfig.cpp:148:5: note: suggested alternative:
In file included from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/DynamicJsonDocument.hpp:10:0,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.hpp:9,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.h:9,
from sketch/HSDConfigFile.h:4,
from sketch/HSDConfig.h:3,
from sketch/HSDConfig.cpp:1:
/Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/Memory/DynamicJsonBuffer.hpp:159:5: note: ‚ArduinoJson::Internals::DynamicJsonBuffer‘
DynamicJsonBuffer;
^
HSDConfig.cpp:148: error: expected ‚;‘ before ‚jsonBuffer‘
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_COLOR_MAPPING_CONFIG_FILE);
^
HSDConfig.cpp:149: error: ‚jsonBuffer‘ was not declared in this scope
JsonObject& json = jsonBuffer.parseObject(fileBuffer);
^
HSDConfig.cpp:154: error: ‚class ArduinoJson::JsonObject‘ has no member named ‚measureLength‘
Serial.print(F(„JSON length is „)); Serial.println(json.measureLength());
^
HSDConfig.cpp:155: error: ‚class ArduinoJson::JsonObject‘ has no member named ‚prettyPrintTo‘
json.prettyPrintTo(Serial);
^
sketch/HSDConfig.cpp: In member function ‚bool HSDConfig::readDeviceMappingConfigFile()‘:
HSDConfig.cpp:195: error: ‚DynamicJsonBuffer‘ was not declared in this scope
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE);
^
sketch/HSDConfig.cpp:195:5: note: suggested alternative:
In file included from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/DynamicJsonDocument.hpp:10:0,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.hpp:9,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.h:9,
from sketch/HSDConfigFile.h:4,
from sketch/HSDConfig.h:3,
from sketch/HSDConfig.cpp:1:
/Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/Memory/DynamicJsonBuffer.hpp:159:5: note: ‚ArduinoJson::Internals::DynamicJsonBuffer‘
DynamicJsonBuffer;
^
HSDConfig.cpp:195: error: expected ‚;‘ before ‚jsonBuffer‘
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE);
^
HSDConfig.cpp:196: error: ‚jsonBuffer‘ was not declared in this scope
JsonObject& json = jsonBuffer.parseObject(fileBuffer);
^
HSDConfig.cpp:201: error: ‚class ArduinoJson::JsonObject‘ has no member named ‚measureLength‘
Serial.print(F(„JSON length is „)); Serial.println(json.measureLength());
^
HSDConfig.cpp:202: error: ‚class ArduinoJson::JsonObject‘ has no member named ‚prettyPrintTo‘
json.prettyPrintTo(Serial);
^
sketch/HSDConfig.cpp: In member function ‚void HSDConfig::writeMainConfigFile()‘:
HSDConfig.cpp:235: error: ‚DynamicJsonBuffer‘ was not declared in this scope
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_MAIN_CONFIG_FILE);
^
sketch/HSDConfig.cpp:235:3: note: suggested alternative:
In file included from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/DynamicJsonDocument.hpp:10:0,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.hpp:9,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.h:9,
from sketch/HSDConfigFile.h:4,
from sketch/HSDConfig.h:3,
from sketch/HSDConfig.cpp:1:
/Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/Memory/DynamicJsonBuffer.hpp:159:5: note: ‚ArduinoJson::Internals::DynamicJsonBuffer‘
DynamicJsonBuffer;
^
HSDConfig.cpp:235: error: expected ‚;‘ before ‚jsonBuffer‘
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_MAIN_CONFIG_FILE);
^
HSDConfig.cpp:236: error: ‚jsonBuffer‘ was not declared in this scope
JsonObject& json = jsonBuffer.createObject();
^
sketch/HSDConfig.cpp: In member function ‚void HSDConfig::writeColorMappingConfigFile()‘:
HSDConfig.cpp:257: error: ‚DynamicJsonBuffer‘ was not declared in this scope
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_COLOR_MAPPING_CONFIG_FILE);
^
sketch/HSDConfig.cpp:257:3: note: suggested alternative:
In file included from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/DynamicJsonDocument.hpp:10:0,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.hpp:9,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.h:9,
from sketch/HSDConfigFile.h:4,
from sketch/HSDConfig.h:3,
from sketch/HSDConfig.cpp:1:
/Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/Memory/DynamicJsonBuffer.hpp:159:5: note: ‚ArduinoJson::Internals::DynamicJsonBuffer‘
DynamicJsonBuffer;
^
HSDConfig.cpp:257: error: expected ‚;‘ before ‚jsonBuffer‘
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_COLOR_MAPPING_CONFIG_FILE);
^
HSDConfig.cpp:258: error: ‚jsonBuffer‘ was not declared in this scope
JsonObject& json = jsonBuffer.createObject();
^
sketch/HSDConfig.cpp: In member function ‚void HSDConfig::writeDeviceMappingConfigFile()‘:
HSDConfig.cpp:283: error: ‚DynamicJsonBuffer‘ was not declared in this scope
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE);
^
sketch/HSDConfig.cpp:283:3: note: suggested alternative:
In file included from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/DynamicJsonDocument.hpp:10:0,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.hpp:9,
from /Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson.h:9,
from sketch/HSDConfigFile.h:4,
from sketch/HSDConfig.h:3,
from sketch/HSDConfig.cpp:1:
/Users/rode/Documents/Arduino/libraries/ArduinoJson/src/ArduinoJson/Memory/DynamicJsonBuffer.hpp:159:5: note: ‚ArduinoJson::Internals::DynamicJsonBuffer‘
DynamicJsonBuffer;
^
HSDConfig.cpp:283: error: expected ‚;‘ before ‚jsonBuffer‘
DynamicJsonBuffer jsonBuffer(JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE);
^
HSDConfig.cpp:284: error: ‚jsonBuffer‘ was not declared in this scope
JsonObject& json = jsonBuffer.createObject();
^
exit status 1
‚DynamicJsonBuffer‘ was not declared in this scope
—————————-
Da komme ich nicht weiter.
Gruß Heiner
Hi,
das klingt als wird die ArduinoJson Library nicht gefunden. Hast du diese in der Arduino IDE installiert?
Grüße
Moin Bernd,
die Bibliothek fehlte. Jetzt ist die Kompilierung glatt durchgelaufen. Komisch, ich bin mir sicher, daß ich die Arduino.Json Library am Anfang mit den anderen beiden in der Arduino-Umgebung eingebunden hatte.
Aber jetzt hat es ja geklappt. Danke für den Tipp.
Gruß Heiner
Hallo !
Erst mal danke für dieses dolle Projekt ! Ich habe es sofort umgesetzt und es läuft !°
Nur habe ich leider folgendes Problem:
Das Display verliert alle 2-3 Stunden den Kontakt zum Broker und alle LED leuchten yellow.
Nach reset bzw Neustart läuft es wieder .
Woran könnte das liegen ? Evtl wird nicht oft genug per Broker eine Statusänderung geschickt, da alle meine geräze 5-8 Stunden ihren Status beibehalten.
Gibts hierfür einen Lösungsvorschlag ?
Hi und sorry erstmal für die späte Antwort.
An der Anzahl der Statusänderungen zum Broker kann es nicht liegen. Tritt das Problem nur mit dem Statusdisplay auf oder auch mit anderen MQTT-Clients?
Im FHEM Forum haben einige das Problem (siehe https://forum.fhem.de/index.php/topic,68948.75.html) mit einer verlorenen Wifi-Verbindung. Probleme mit verlorener MQTT-Verbindung kenne ich bisher noch nicht. Vielleicht hängt das aber irgendwie mit der Wifi-Verbindung zusammen.
Aktuell ist die Vermutung, dass es an einer bestimmten Version der ESP8266 Arduino Bibliothek liegt. Schau mal bei dir in der Arduino IDE im Boards Manager nach, welche Version du verwendest. Ich verwende eine relativ alte (2.3.0) und ich habe das Problem mit dem Wifi nicht. Laut Google gab es speziell mit der 2.4.0 hier einen Bug.
Ich werde bei mir testweise mal auf die aktuelle 2.4.2 gehen und es weiter beobachten.
Melde dich gerne wieder wenn das irgendwie hilft, oder natürlich auch wenn nicht- dann müssen wir mal sehen, eine konkrete Idee habe ich da noch nicht.
Hallo Bernd,
vielen Dank für dieses super Projekt. Ich habe alles problemlos mit wenigen Änderungen einsetzen können (für MQTT brauchte ich Authentifizierung, meine OpenHAB item names sind länger als 25 Zeichen). Das war aber durch den gut strukturierten Quellcode überhaupt kein Problem.
Marcel
Hallo Marcel,
prima dass alles klappt!
Ich wurde schon öfter gefragt (auf GitHub ist auch eine Issue dazu offen), ob ich Authentifizierung für MQTT einbauen kann. Aus Zeitgründen bin ich bisher dazu nicht gekommen. Wenn du möchtest kannst du mir gerne deine Codeänderung zukommen lassen (entweder per Pull-Request auf Github oder per Email, siehe Impressum). Ich würde das dann in den normalen Code übernehmen. Würde mich sehr freuen!
Viele Grüße,
Bernd
Danke für die Anleitung.
Anfangs etwas schwierig durchzusteigen, nachdem man aber das Prinzip von dem MQTT Broker verstanden hat, geht es immer leichter von der Hand.
Gruß
Hallo Bernd,
das ist ein sehr tolles Projekt und ich wollte das Ganze nachbauen und in FHEM integrieren. Leider scheitere ich schon beim kompilieren.
Arbeite mit Arduino IDE Version 1.8.6
Habe mein WeMOS d1 mini Clone an USB COM6 vom WIN10 PC angeschlossen. Wird auch erkannt.
Alle erwähnten Bibliotheken integriert und upgedatetet.
Boardeinstellungen nach Vorgabe eingestellt.
Habe das ZipFile HomeStatusDisplay-master von Github downgeloadet und entpackt. Anschließend alles in ein Verzeichnis gelegt.
Drücke ich den Haken in der Arduino IDE kommt nach einer gewissen Zeit die Fehlermeldung ‚IPAddress‘ has not been declared. Es scheint so als das er bis zum 7ten Reiter HSDHtmlHelper.hpp kommt und dann scheitert.
Hast du einen Tip für mich?
Gruß Uwe
Hi Uwe,
bitte poste mal die komplette Ausgabe des Kompiliervorgangs. Gerne auch über das Kontaktformular falls es hier zu unübersichtlich wird.
Gruß,
Bernd
Hi Bernd,
habe dir gestern meinen Kompiliervorgang per Kontaktformular gesendet. Ich hoffe du kannst damit was anfangen und mir einen Tip geben. 🙂
Gruß Uwe
Hallo Bernd,
das Projekt ist echt super. Tolle Idee um FHEM etwas mehr WAF zu geben 🙂
Ich bastle es gerade nach. Die ArduinoJSON Library gibt es mittlerweile als v6 Beta… vielleicht kommen daher gelegentliche „Library nicht gefunden“ Meldungen (der Quellcode kompiliert nur mit der stable 5er Version, nicht mit einer Beta 6er).
Kompiliert und geflashed habe ich meinen Kontroller also schon.
Ich kann dann auch die Weboberfläche per WLAN erreichen… das WLAN aber zu ändern und so das Device im eigenen Heimnetz einzubinden, will mir aber einfach nicht gelingen…
… gibt es hier eventuelle Beschränkungen (die ich dann überlesen hätte :-)). Ich würde dabei gerne WPA2 verwenden…
Kann ich ansonsten irgendwie die WLAN Einstellungen setzen, wenn es Probleme bei der Verwendung der Weboberfläche gibt (wieso auch immer)? Eventuell im Quellcode oder kann ich mich sonst irgendwie mit dem ESP8266 verbinden, um dort eine Konfiguration zu hinterlegen?
Liebe Grüße und „Danke“ für dein Projekt und dessen Bereitstellung,
Niko
Einen kleinen Fortschritt kann ich mittlerweile vermelden. Die Verbindung übers WLAN funktioniert. Allerdings nur, wenn die SSID des Netzwerks sichtbar ist. Bei versteckter SSID funktioniert die Verbindung nicht.
Liegt das an der Library oder kann man da im Quellcode des Projekts was verbessern?
Hallo Niko,
das habe ich leider nicht probiert. Ich nutze die Standard ESP8266 Bibliothek, also ich selbst kann da nichts dran ändern. Was genau kommt für eine Fehlermeldung wenn die SSID versteckt ist?
Hallo Niko,
danke!
Des gibt prinzipiell die Möglichkeit die Konfiguration per Sketch-Data-Upload zu hinterlegen, aber dazu müsstest du händisch ein Config-File im korrekten Format erzeugen.
Was genau kommt denn für eine Fehlermeldung auf der seriellen Konsole, wenn du die Daten hinterlegt hast? WPA2 ist kein Problem.
Hallo Bernd,
Kompliment – ein Super-Projekt!
Für alle, die sich über blitzende Displays wundern, hier ein Tipp:
Hier gehen Daten verloren aufgrund der unterschiedlichen Betriebsspannungen. Ein High-Level darf nicht unter 70% der anliegenden Spannung sein. Das sind bei 5 Volt genau 3.5 Volt, die der LED-Strip braucht, um ein High zu erkennen. WEMOS D1 liefert aber max. 3.3 Volt.
Soweit die Theorie.
In der Praxis funktioniert die Schaltung trotzdem (meistens), weil die 5 Volt gar nicht am LED-Strip ankommen. Denn wenn die Spannung an den LEDs nur schon auf 4.7 Volt abfällt, passt es wieder. Aber es bleibt bei einem Betrieb ganz hart am unteren Limit.
Mit einem Logic Level Converter (3.3V to 5V) in der Datenleitungen am Ausgang des WEMOS kommt man einfach und günstig in einen stabilen Arbeitsbereich.
Hallo Herbert,
danke fürs Lob. Warum sollte der wemos nur 3.3V liefern? Der LED Strip wird mit dem 5V Pin verbunden, und dieser ist 1:1 mit den 5V vom USB Stecker verbunden. Die 3.3V die der wemos intern und für seine GPIOs verwendet, werden erst danach erzeugt.
Zur „Blitz-„Problematik: Wie Herbert schreibt, erreicht der WEMOS am Ausgang nicht sicher die 70%-Schwelle für einen sauberen Pegel am Eingang der WS8218. Ich nutze nun die erste LED als Levelshifter: +5V zwischen erster und zweiter LED auftrennen, dann die zweite LED (und den Res) mit 5V versorgen, die erste LED über eine Si-Diode. So erhält die erste LED nur ca 4,3V – der Eingangspegel reicht hier dann sicher und wird sauber genug weitergegeben. Da die LED etwas dunkler ist, bleibt sie dauerhaft unbenutzt – verschmerzlich bei den Preisen für einen Streifen.
Hallo Bernd,
dank der guten Anleitung konnte ich dein Projekt erfolgreich nachbauen und problemlos in meine FHEM Hausautomation integrieren.
Ein großes Lob auch für die super Software!
Wenn man jetzt noch Taster an die freien GPIOs anschließen könnte, deren Status dann mittels MQTT-Message an den Broker gesendet würden, wäre das Projekt perfekt.
Am 23.10.2017 schriebst Du, dass das prinzipiell ganz einfach sei:
– jeden Taster an einen freien Pin des Wemos anschließen
– Pins als INPUT_PULLUP definieren
– Pin-Zustand in der main loop abfragen
(Entprellen nicht vergessen, gibts aber fertige Libs dazu
wie z.b. Bounce2“)
– bei Wechsel auf LOW eine MQTT-Message absetzen,
z.B. „statusdisplay/switch1/status“,
z.B. mit der Funktion HSDMqtt::publish (siehe MSDMqtt.cpp);
idealerweise noch vorher checken ob überhaupt eine Verbindung
zum MQTT Server besteht
Hast Du inzwischen Zeit gefunden dieses Feature in deine Software einzubauen?
Viele Grüße
Norbert
Hallo Norbert,
danke fürs Lob.
Ich habe leider aktuell keine Zeit um neue Features in das Projekt einzubauen. Von daher- nein, das Taster Feature ist noch nicht implementiert.
Hallo, ich erreiche den Wemos über die 192.268.4.1 und geben mein WLAN ein. Save und reboot.
Leider öffnet er wieder sein eigenen WLAN. Schon vom Netz gezogen. Hat auch nicht geholfen. Mein WLAN Signal ist in dem Raum schwach. Kann es daran liegen?
Hallo Alex,
kann natürlich daran liegen. Versuche es doch mal in einem anderen Raum. Um genauere Informationen zu kommen kannst du den Wemos auch an der Position an der es Probleme gibt mit der seriellen Kontrolle verbinden (Laptop z.B.). Dann kann man am Log-Output besser sehen woran es genau liegt.
Hallo Bernd,
vielen Dank für das tolle Projekt und die Beschreibung ! Für mich war das der Einstieg in das Smarthome. Bei mir läuft nun alles wunderbar auf openhab und raspi.
Das einzige was mir in dem esp8266 Sketch fehlt ist die Möglichkeit einen MQTT User und Passwort zu definieren um etwas mehr Sicherheit in die Steuerungen zu bekommen. Leider reichen mein Programmierkenntnisse dazu nicht aus.
Könntest du mir hier weiterhelfen wo der MQTT_user und passwort eingefügt werden muss ? Es würde auch ausreichen dies nur im Code einzugeben, im WebUI wäre nice-to-have.
Grüße
Andreas
Hallo Andreas,
ich habe leider noch keine Zeit gefunden über die Weboberfläche eine Möglichkeit für User und Passwort einzubauen.
Im Code fix codiert müsste es so gehen, dass du in der Datei HSDMqtt.cpp folgende Zeilen ersetzt:
connected = m_pubSubClient.connect(clientId.c_str(), willTopic, 0, true, „off“);
ersetzen durch:
connected = m_pubSubClient.connect(clientId.c_str(), „USERNAME“, „PASSWORT“, willTopic, 0, true, „off“);
Außerdem
connected = m_pubSubClient.connect(clientId.c_str());
ersetzen durch:
connected = m_pubSubClient.connect(clientId.c_str(), „USERNAME“, „PASSWORT“);
Getestet habe ich das nicht. Gib gerne mal Feedback ob es funktioniert.
Hallo Bernd
erst mal vielen Dank für den Code! Werde das diese Woche gleich einbauen und Rückmeldung geben.
Bei Kompilieren in der Arduino IDE hat er sich über die Anführungsstriche „off“, „USERNAME“, „PASSWORT“ beschwert (stray/342). Habe sie durch Hochkommata ersetzt, dann gings.
(in Ubuntu 18.04)
Grüße
Andreas
Hallo Bernd
habe das ESP8266-Skript mit dem mqtt-user und password getestet. Es funktioniert einwandfrei.
Vielen Dank nochmal
Grüße
Andreas
Hallo Bernd,
danke für dieses Projekt.
Mein Bilderrahmen kann sich jetzt auch mit meinem WLAN verbinden, nachdem ich die Größe des PSK auf 64 erweitert habe. Das entspricht dann auch der maximalen Länge laut Spezifikation.
Leider klappt die Verbindung zum MQTT Broker nicht. Hast du einen Link für ein brauchbares Mosquitto Howto?
Hier noch die Ausgabe des ESP:
Initializing config.
Mounted file system.
Reading config file /config.json
File size is 329 bytes
Main config data successfully parsed.
JSON length is 329
• host : HomeStatusDisplay
• wifiSSID : **************
• wifiPSK : not shown
• mqttServer : 192.168.64.36
• mqttStatusTopic : fhem/status/#
• mqttTestTopic : fhem/cmd/statusdisplay_01/test
• mqttWillTopic : fhem/status/statusdisplay_01
• ledCount : 20
• ledPin : 4
• ledBrightness : 20
Config data is complete.
Deleting color mapping config data.
Reading config file /colormapping.json
File size is 2 bytes
Color mapping config data successfully parsed.
JSON length is 2
Deleting device mapping config data.
Reading config file /devicemapping.json
File size is 2 bytes
Device mapping config data successfully parsed.
JSON length is 2
Starting WebServer.
Free RAM: 40792
Starting Wifi connection to Dien7490…
WiFi connected with IP 192.168.64.142.
Connecting to MQTT broker 192.168.64.36 with client id ESP8266Client-6531… failed, rc = -4
DEBUG: Reconnect unsuccessful, m_numConnectRetriesDone = 1
Connecting to MQTT broker 192.168.64.36 with client id ESP8266Client-8563… failed, rc = -4
DEBUG: Reconnect unsuccessful, m_numConnectRetriesDone = 2
Connecting to MQTT broker 192.168.64.36 with client id ESP8266Client-446… failed, rc = -4
DEBUG: Reconnect unsuccessful, m_numConnectRetriesDone = 3
Failed to connect Mqtt.
Uptime: 1min
LG Arne
Hallo Arne,
der Wert -4 bedeutet „MQTT_CONNECTION_TIMEOUT“. Das heißt, der MQTT Server ist nicht erreichbar. Kannst du mit anderen Clients dich verbinden? Du kannst es z.B. mit dem Tool MQTT.fx mal versuchen wenn du kein anderes Gerät hast. Wenn das auch nicht geht, liegt es an deinem Server. Wie hast du diesen denn installiert? Prinzipiell gibt es da nichts weiter zu beachten.
Hallo Bernb
danke für die Infos.
Meinen Server habe ich mit MQTT.fy untersucht und er macht was er soll.
Gibt es die Möglichkeit die Timeout-Zeit einzustellen?
Laut Paketmittschnitt bricht der ESP knapp 13ms nach Start des Connect Versuchs die Verbindung ab. Es wäre evtl. ein Versuch wert, die Zeit zu verlängern…
LG
Arne
Was meinst du mit Paketmitschnitt, Wireshark? Bis du mit den 13ms sicher? Der Timeout für die Socketverbindung ist in der PubSubClient Library auf 15s (Sekunden, nicht Millisekunden) eingestellt.
Du kannst natürlich in der Library mal den Wert verändern, aber ich glaube nicht dass das das Problem ist. Du könntest mal im mosquitto den Parameter log_type auf „all“ stellen (mosquitto.conf), dann kann man sehen ob der Connect ankommt und ob der mosquitto einen Grund sieht, keine Antwort zu schicken bzw. die Verbindung abzulehnen.
Hallo Bernd,
ja, es war ein Wireshark Mitschnitt.
Mein Mosquitto kennt den log_type all nicht. Damit startet der Broker nicht mehr.
Ich habe alle andere log_types enabled.
Dann bekomme ich im syslog folgende Meldung:
Oct 26 20:50:29 FHEM-Raspberry mosquitto[2142]: Invalid protocol „MQTT“ in CONNECT from 192.168.64.142.
Oct 26 20:50:29 FHEM-Raspberry mosquitto[2142]: Socket read error on client (null), disconnecting.
Oct 26 20:50:50 FHEM-Raspberry mosquitto[2142]: Received PINGREQ from NetMQTTpm2318
Oct 26 20:50:50 FHEM-Raspberry mosquitto[2142]: Sending PINGRESP to NetMQTTpm2318
Die …142 er IP ist das Display…
Invalid protocol „MQTT“
Der Mosquitto Broker ist die Version 0.15
Der Raspberry läuft mit Raspbian wheezy
LG
Arne
Hallo nochmal,
ich glaube, ich habe den Fehler gefunden.
Der Broker ist zu alt.
Ich bin da nicht alleine mit dem Fehler…
Ich werde weiter berichten…
Danke trotzdem und LG
Arne
So, jetzt aber…
Ich habe in der PubSubClient.h die MQTT Version auf 3.1 geändert und jetzt klappt die Verbindung…
Hallo Arne,
ja das geht zwar auch, würde ich dir aber nicht empfehlen. Die Version 0.15 ist ja etliche Jahre alt! Installiere dir lieber eine aktuelle Version von mosquitto z.B. nach dieser Anleitung:
https://www.instructables.com/id/Installing-MQTT-BrokerMosquitto-on-Raspberry-Pi/
Dann spricht er auch die aktuelle Version von MQTT, und enthält natürlich auch etliche Bugfixes und Erweiterungen.
Bzw. fällt mir gerade ein, ich habe ja eigentlich im Tutorial beschrieben wie man eine aktuelle Version bekommt 😉
Hallo Bernd,
es gibt da aber keine neue Version für wheezy (mehr).
Bei Gelegenheit werde ich einen neuen Raspberry mit der aktuellen Raspbian Distri aufsetzen…
Bis dahin lasse ich das mal so…
Vielen Dank trotzdem…
LG
Arne
Hallo Bernd
Super Projekt, sieht echt gut aus. Will es jetzt auch nachbauen, doch leider bekomme ich beim kompilieren eine Fehlermeldung und kann nichts damit anfangen.
Kannst du mit bitte helfen?
Arduino: 1.8.9 (Windows Store 1.8.21.0) (Windows 10), Board: „LOLIN(WEMOS) D1 R2 & mini, 80 MHz, Flash, Disabled, 4M (3M SPIFFS), v2 Lower Memory, Disabled, None, Only Sketch, 115200“
In file included from sketch\HSDWebserver.h:6:0,
from sketch\HomeStatusDisplay.h:5,
from C:\Users\Bastian\Documents\Arduino\HomeStatusDisplay-0.5-beta\HomeStatusDisplay\HomeStatusDisplay.ino:1:
HSDLeds.h:4:31: error: Adafruit_NeoPixel.h: No such file or directory
#include
^
compilation terminated.
exit status 1
Adafruit_NeoPixel.h: No such file or directory
MfG Bastian
Hi
du hast vermutlich die Adafruit_NeoPixel Library nicht installiert. Schaue bitte im Blogbeitrag unter „Firmware“, ob du die drei dort genannten Libraries installiert hast.
Hallo Bernd,
ein tolles Projekt. Das will ich auch 🙂
Durch Deine ausführliche Anleitung funktioniert es auch fast. Beim Booten werden die 10 LED rot, dann grün, dann aus. Auf MQTT Messages werden Nachrichten auf dem COM-Port ausgegeben.
Aber die LED gehen nicht an, weil irgendwas nicht richtig ist:
<– Platzhalter
Adding color mapping entry at index 0 with name on, type 2, color 3840, behavior 0
Adding color mapping entry at index 1 with name off, type 2, color 983040, behavior 0
Adding device mapping entry at index 0 with name lamp, type 2, LED number 0
Adding device mapping entry at index 1 with name lamp2, type 2, LED number 1
Adding device mapping entry at index 2 with name lamp3, type 2, LED number 2
Adding device mapping entry at index 9 with name lampA, type 2, LED number 9
Starting WebServer.
Free RAM: 35016
Starting Wifi connection to WLAN1234…
WiFi connected with IP 192.168.100.36.
Connecting to MQTT broker 192.168.100.52 with client id ESP8266Client-e87e… connected
Published msg on for topic fhem/will
Subscribing to topic fhem/status/#
Subscribing to topic fhem/test
Received an MQTT message for topic fhem/status/light/lamp2 on:
No LED defined for device lamp2 on of type 2, ignoring it
Ich habe schon alles nochmal gelöscht, rebootet … gleiches Ergebnis.
MfG Ulf
Hi Ulf,
ich bin mir gerade nicht ganz sicher, aber ich glaube dass das „on“ bei dir nicht in der Payload der MQTT Message steht, sondern im Topic selbst.
Die Konfiguration sieht soweit OK aus.
Wie schickst du die Message? Versuche am besten mal ein Tool wie MQTT.fx, da kann man gut damit rumprobieren:
In dem kleinen Feld unter „Publish“ gibst du das Topic ein (fhem/status/light/lamp2) und in dem großen Feld die Payload (on). Ich bin mir recht sicher dass es so dann klappt. Wenn ja, musst du nur noch dafür sorgen dass dein eigentliches Home Automation System das auch so schickt :-).
Wenns nicht klappt, einfach nochmal melden.
Hallo, ich benutze 2 HomeStatusDisplays schon über 1 Jahr mit guter Funktion.
Vielen Dank dafür.
Was mich etwas unsicher macht, ist die Anzeige des Wlan-Kennworts im Status im Klartext.
Jeder Benutzer im Wlan kann dieses beim Aufruf der Webseite doch sehen !? Kann ich das absichern?
Viele Grüße
Verstehe ich gerade nicht, im Status sieht man lediglich den WLAN-Namen, aber doch nicht das Passwort?
sorry,
unter General – General configuration ist das Passwort zu sehen …
Welchen Browser benutzt du? Das Eingabefeld ist als Typ „Password“ konfiguriert und der Inhalt wird bei mir unter Firefox, Chrome und Safari entsprechend nur mit Sternchen angezeigt.
Ich habe jetzt alle 3 Browser durchprobiert und Passwort geändert, auf PC , Tablet u Handy, es kommen keine Sternchen, alles im Klartext. Ist das denn nur bei mir so?
Version ist HomeStatusDisplayV0.5. Gibt es eine Neuere?
Ah jetzt verstehe ich.
Ja du hast leider recht, in der 0.5 wurde das auf der Webseite tatsächlich angezeigt (was ich nicht als riesiges Problem sehe, da ja jedes Gerät was im WLAN ist, sowieso das Passwort schon kennt – geändert habe ich es aber natürlich trotzdem).
Lade dir die Develop-Version 0.6_dev herunter. Dazu einfach über die Startseite https://github.com/MTJoker/HomeStatusDisplay gehen und dort „Clone or Download“ -> „Download ZIP“ auswählen.
Hallo, ich habe auf Version 6 aktualisiert, jetzt werden Sternchen angezeigt.
Danke für die Hilfe.
Hallo Bernd, ich nutze die Idee von deinem Projekt inzwischen seit fast zwei Jahren. Allerdings habe ich bisher nur die Hardware Idee genutzt. Auch dem (bei mir NodeMCU) lief so lange tasmota als Software. Jedenfalls habe ich mit meinem Aufbau immer wieder Probleme mit dem LED Stip. Es leuchten einzelne LEDs immer mal wieder unkontrolliert auf. Ohne eine Regelmäßigkeit zu erkennen. Teilweise geht es einige Wochen ohne Probleme. Wie auch immer, um das Display weiter nutzen zu können muss ich etwas ändern. Nun will ich das ganze mit der Software von dir ausprobieren.
Ich habe in deiner Beschreibung leider nirgends lesen können wie man den LEDs eine bestimmte Farbe zuweist. Ich habe bisher den Farbwert an die NodeMCU gesendet, zb „000800“ für grün. Dadurch leuchtet die Farbe nicht so hell. Ist es, und wenn ja wie ist es möglich solche Farbwerte mit deiner Software einzustellen? Weiterhin würde ich gern wissen ob es möglich ist eine Gruppe von LEDs mit einem Befehl eine Farbe zuzuordnen? Das gehört aber zu einem anderes Projekt von mir. Ich kann dir demnächst mal Bilder davon senden.
Gruß Ingo
Hallo Ingo,
also das Phänomen dass du beschreibst klingt eigentlich nicht nach einem Software Problem, eher nach einer schlechten Spannungsversorgung oder schlechter Masseverbindung etc. Aber natürlich macht es Sinn meine Software auszuprobieren 😉
Bei der Software lassen sich die Farben nicht frei wählen, sondern es sind sieben Farben vordefiniert. Die Helligkeit lässt sich darüber hinaus global einstellen. Die Software ist so gedacht, dasss man ein Event schickt (z.B. „Fenster offen“), und in der Software ist dann hinterlegt was passieren soll (z.B. „Led Nr. 5 auf Rot blinkend“). Ich hoffe das hilft dir weiter.
Hi!
Das Projekt ist zwar schon lange her, aber ich hab´s vor kurzem nachgebaut und in einen Lichtschalter inkl. 4 Taster integriert.
Klappte alles top, allerdings zeigen die LEDs jetzt nichts mehr an, obwohl MQTT Server korrekt läuft und updated.
Taster werden ausgelsen und in MQTT gespeichert, beim booten leuchten die LEDs wie gehabt.
Habe schon neu aufgespielt, nix geändert. Ich vermute, dass mein Loxberry MQTT Gateway irgendwie die Konfig geändert haben könnte? MQTT Server ist Mosquitto auf Synology.
Ein Tip wäre top! Danke.
Hi,
wird denn auf der Haupt-Webseite vom Display angezeigt dass LEDs leuchten, oder nicht? Wenn nicht, dann wurden keine passenden MQTT-Messages empfangen.
D.h. entweder dein MQTT-Server verschickt die erwarteten Messages gar nicht, oder sie sind vom Topic und/oder Payload nicht so, wie im Display konfiguriert (siehe die Konfiguration vom Status-Topic auf der „General“ Seite und die entsprechenden Einträge im Device/Color Mapping).
Am besten du nimmst dir ein MQTT-Tool (z.B. Mqtt.fx) und schaust dir an was dein MQTT-Server für Nachrichten schickt. Dann sollte es relativ schnell rauszufinden sein, wo das Problem liegt.