Hallo,
hier möchte ich mein Projekt "HomeStatusDisplay" vorstellen.
Hierbei handelt es sich um eine Anzeigemöglichkeit von verschiedenen Zuständen aus FHEM (aber prinzipiell auch anderen System, dazu weiter unten mehr) via LEDs.
Zur Anzeige werden RGB (WS2812B) LEDs verwendet. Der Gedanke ist, mit einem Blick auf die Anzeige schnell einen Überblick über das System zu bekommen, ähnlich der Homematic LED-Statusanzeige. Ich nutze es, um mir z.B. die Zustände von Fenstern (getriggert von Homematic Fensterkontakten), Lichtern (getriggert von Homemematic Schaltaktoren) und anderen Dingen wie z.B. der Müllabfuhr zu visualiseren. Verbaut ist das ganze aktuell in einem zweckentfremdeten Bilderrahmen. Siehe Bild "01_hardware.jpg" , als Einstieg wie das ganze aussieht.
Die Idee ist zugegebenermaßen nicht neu, auch hier im Forum gab es schon entsprechende Ansätze und auf anderen Seiten ebenso. Ich habe allerdings -meiner Meinung nach- mein System etwas universeller und vor allem auch "kompletter" gestaltet.
Was wurde verbaut?
- 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 Kondensator und ein Widerstand, Standard-Beschaltung für die WS2812B Stripes)
- ein Bilderrahmen aus einem schwedischen Möbelhaus
- eine Holzplatte als Trägerrahmen für die LEDs und den Rest
- zwei Holzleisten als Klemmbefestigung
Siehe Bilder, "02_hardware.jpg", "03_hardware.jpg", "04_hardware.jpg".
Wie man sieht, wirklich minimaler Aufwand auf der Hardware-Seite, siehe auch "10_schematic.png"
Was braucht man noch?
- ein laufendes FHEM System (oder ein anderes System das MQTT-Nachrichten verschicken kann)
- einen MQTT-Broker, z.B. mosquitto. Dieser kann z.B. auf dem selben Gerät laufen wie FHEM, beispielsweise einem Raspberry Pi
Was kann das System?
- der ESP8266 kommuniziert mit FHEM per WLAN
- als Protokoll kommt MQTT zum Einsatz
- auf FHEM-Seite werden die Module MQTT_BRIDGE und MQTT_DEVICE verwendet, diese senden konfigurierte Topics an das Display, und dieses schaltet entsprechend der Konfiguration bestimmte LEDs
- über eine Konfigurations-Webseite kann man sämtliche Parameter festlegen, wie z.B. die MQTT Topics, Anzahl der LEDs, WLAN Zugangsdaten, MQTT-Zugangsdaten etc.
- ebenso frei konfigurierbar per Webseite ist das Mapping von MQTT-Nachrichten auf LED-Verhalten
- als LED-Verhalten gibt es (aktuell) die Möglichkeit An, Aus, Blinken (500ms an, 500ms aus), Blitzen (200ms an, 2s aus) sowie Flackern (100ms an, 100ms aus) zu wählen
- die Software für den ESP8266 wurde in der Arduino-IDE geschrieben
- es muss nichts in der Software verändert werden, um das Gerät ans eigene System anzupassen- alle Einstellungen können per Webseite gemacht werden
- OTA Firmware Update
Die Inbetriebnahme des Geräts kann wie folgt erfolgen:
- beim ersten Start wird versucht eine WLAN-Verbindung aufzubauen, da noch keine Zugangsdaten bekannt sind, schlägt dies fehl und es wird ein Access Point aufgemacht
- der Access Point heißt "StatusDisplay", Passwort "statusdisplay". Mit diesem kann man sich verbinden und danach gelangt man über die Seite 192.168.4.1 auf die Konfigurationsseite (Bild "06_software_general.png")
-- Hier kann man nun Basiskonfiguration vornehmen, wichtig ist zunächst WiFi SSID und Passwort. Sinvollerweise kann man auch schon LED-Anzahl und LED-Datenpin eingeben. Nach einem Reboot sollte sich das Gerät mit dem WLAN verbinden. Visualisiert wird dies -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), und die restlichen Einstellungen machen. Auf der Statusseite (Bild "05_software_status.png") sieht man eine Übersicht über den Zustand des Geräts.
Weiter geht es auf der "General" Seite mit den 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. Es wird davon ausgegangen, dass 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/kitchen.
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 (Bild "07_software_colormapping.jpg")
Hier müssen Message, Type, Color und Behavior gewählt werden.
Zum Verständnis hier ein Beispiel, wie ein Statustopic aussehen soll: "fhem/status/light/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 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 (Bild 08_software_devicemapping.png).
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/light/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".
Ich hoffe das ist so einigermaßen verständlich, wenn nicht bitte nachfragen :-) Meine eigene Konfiguration seht ihr in den Screenshots.
Vielleicht könnte man das auch noch ein wenig einfacher machen, für Vorschläge bin ich offen.
Ach ja, den Code gibt es zum Download natürlich auf gitHub:
https://github.com/MTJoker/HomeStatusDisplay (https://github.com/MTJoker/HomeStatusDisplay)
Bitte als work-in-progress betrachten- ich habe das System schon länger produktiv im Einsatz, aber es ist sicherlich noch einiges zu verbessern. Auch dafür bin ich offen, entweder hier im Thread oder gern per pull-Request.
Interessantes Projekt.
Vielen Dank für die Veröffentlichung! :)
Sobald ich wieder mehr Zeit habe werde ich mich an die Umsetzung machen und meine Homematic LED-Statusanzeige deren Anzeigemöglichkeiten begrenzt sind ersetzen.
Billy
Cooles Teil Danke dafür.
Gruß
Jörg
Hallo Joker
wenn ich den Sketch auf den ESP hochlade und neu starte wird kein AP erzeugt.
Mache ich etwas falsch oder ist im Code noch ein Fehler?
Viele Grüße
Der Serielle Monitor zeigt folgendes:
##########################
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: 34384
Connecting to MQTT broker with client id ESP8266Client-3d4f... failed, rc=-2
Connecting to MQTT broker with client id ESP8266Client-49c0... failed, rc=-2
Connecting to MQTT broker with client id ESP8266Client-5a51... failed, rc=-2
Connecting to MQTT broker with client id ESP8266Client-e2ed... failed, rc=-2
usw.
Hi ckbln,
da kommen mehrere Dinge zusammen, konnte es mir gerade nur kurz ansehen:
1. Es gibt einen Bug, wenn die Konfigurationsdateien noch nicht vorhanden sind. Dadurch werden die Files initial nicht erzeugt. Das werde ich beheben, schaue ich mir die Tage an, evtl komme ich heute abend schon dazu.
2. Ich vermute, der ESP war schon einmal mit deinem WLAN verbunden oder? Der ESP hat die Eigenheit dass er die Zugangsinformationen zum letztgenutzen WLAN intern wohl irgendwo speichert und mit diesen versucht eine Verbindung in dieses WLAN aufzubauen. Schau mal in deinen Router, ich vermute der ESP ist schon in deinem WLAN und deswegen baut er keinen AP auf. Daher versucht er als nächsten Schritt den MQTT Broker zu erreichen, welcher aber noch nicht hinterlegt ist. Das geht auch noch nicht solange der Punkt 1. nicht behoben ist.
Als Info für mich: Hast du schon den kompletten Hardware Aufbau, also inklusive LEDs? Benutzt du ein wemos D1 oder ein anderes Board?
Hallo Joker,
danke für die schnelle Antwort.
zu 2. Ja du hast die richtige Vermutung gehabt. Der ESP hatte vorher ESPEASY drauf und er ist unter der alten IP Adresse erreichbar.
Nach ändern der Basiskonfiguration gibt der serielle Monitor folgendes aus
Main config has changed, storing it.
Writing config file /config.json
File does not exist
Failed to write file, formatting file system.
Done.
Das dauert dann ein wenig aber jetzt sind die geänderten Daten zu sehen.
Hardwareaufbau kommt noch. Ich nutze einen Wemos D1 mini. Nicht original aber sieht so aus.
Grüße
Zitat von: ckbln am 05 April 2017, 12:59:58
Main config has changed, storing it.
Writing config file /config.json
File does not exist
Failed to write file, formatting file system.
Done.
Das dauert dann ein wenig aber jetzt sind die geänderten Daten zu sehen.
Hm, wundert mich aktuell ein wenig, denn wenn ich es richtig gesehen habe führt der Bug dazu dass die Config-Dateien gar nicht erzeugt werden können. Ich vermute die Einstellungen sind nach einem PowerOff wieder weg :) Aber ich sehe es mir noch genauer an.
ZitatHardwareaufbau kommt noch. Ich nutze einen Wemos D1 mini. Nicht original aber sieht so aus.
Ich nutze auch einen Klon, also das passt schon.
Hallo,
gefällt mir sehr gut. Das werde ich als nächsten Umbau für https://forum.fhem.de/index.php/topic,33979.0.html (https://forum.fhem.de/index.php/topic,33979.0.html) ins Auge fassen. Muss mich dazu noch mit dem zusätzlichen OLED beschäftigen und irgendwie integrieren. Dann kann der RasPi endlich in Rente gehen.
MfG
Hallo Joker,
du hast Recht. Der ESP verliert seine Einstellungen nach einen Reboot oder PowerOff.
Und bei jedem Save dauert es eine knappe Minute bis der ESP wieder erreichbar ist
Leider habe ich es bisher nicht geschafft eine oder mehrere LED´s ans Leuchten zu bekommen. Der LED Pin ist doch die Nummer des GPIO vom ESP, oder?
Also D6 ist dann GPIO 12 somt LED Pin 12
Grüße
Zitat von: Ralf W. am 05 April 2017, 18:30:21
Das werde ich als nächsten Umbau für https://forum.fhem.de/index.php/topic,33979.0.html (https://forum.fhem.de/index.php/topic,33979.0.html) ins Auge fassen. Muss mich dazu noch mit dem zusätzlichen OLED beschäftigen und irgendwie integrieren. Dann kann der RasPi endlich in Rente gehen.
Auch sehr schöne Variante! Muss zugeben dass ich deins bisher noch gar nicht gesehen hatte. Das OLED ist ne nette Sache. Wie wird es angesteuert? Sollte eigentlich kein Thema sein das mit dem ESP zu nutzen.
Zitat von: ckbln
du hast Recht. Der ESP verliert seine Einstellungen nach einen Reboot oder PowerOff.
Und bei jedem Save dauert es eine knappe Minute bis der ESP wieder erreichbar ist
Ich habe gerade den Bug mit den Config-Files und noch ein paar weitere Kleinigkeiten gefixed. Bitte probiere es damit mal. Auf jeden Fall sollte der ESP jetzt seine Einstellungen nicht mehr verlieren.
Das mit der langen Wartezeit nach Save habe ich auch gesehen. Es tritt dann auf, wenn eine WiFi Verbindung besteht, aber noch keine Verbindung zum MQTT Broker, z.B. weil er noch nicht konfiguriert ist oder nicht erreichbar ist. Der Grund ist mir noch unklar da ich nirgends längere Delays verwende.
Achtung: Aktuell muss beim MQTT Broker der DNS Name des Brokers eingetragen werden, IP geht aktuell nicht. Wenn das ein Problem ist werde ich da demnächst was einbauen.
Zitat von: ckbln
Leider habe ich es bisher nicht geschafft eine oder mehrere LED´s ans Leuchten zu bekommen. Der LED Pin ist doch die Nummer des GPIO vom ESP, oder?
Also D6 ist dann GPIO 12 somt LED Pin 12
Ja, so ist es. Folgendes:
Lade bitte mal die neuen Files runter (am besten alle, da ich zwischenzeitlich auch noch ein paar andere Dinge verbessert hatte), und dann schaue dass das Editieren der General config soweit klappt und die Verbindung zum WiFi und MQTT Broker besteht.
Dann schauen wir weiter. Ich vermute dann wird es mit den LEDs auch klappen, denn der Pin wird aus dem Config File geholt, aber wenn das nicht geschrieben werden kann, dann geht es auch nicht.
Gib mal Feedback wie es aussieht ;)
Hallo Joker,
deine Änderungen waren erfolgreich. Aus meiner Sicht läuft es jetzt so wie du es beschrieben hast.
Jetzt mache ich mich an die Einbindung in FHEM ran.
Noch eine Frage: Wäre es möglich über ein Eingabefeld die Helligkeit der LED´s anzupassen?
Vielen Dank für die schnelle Anpassung und Unterstützung
Zitat von: ckbln am 06 April 2017, 00:46:08
deine Änderungen waren erfolgreich. Aus meiner Sicht läuft es jetzt so wie du es beschrieben hast.
Jetzt mache ich mich an die Einbindung in FHEM ran.
Super, freut mich dass es klappt!
ZitatNoch eine Frage: Wäre es möglich über ein Eingabefeld die Helligkeit der LED´s anzupassen?
Ja, darüber habe ich auch schon nachgedacht. Prinzipiell geht es, aber ich muss ein paar Sachen umbauen, da ich aktuell mit fix codierten Farbwerten (die ja die Helligkeit beinhalten) arbeite. Aber es macht absolut Sinn, von daher werde ich das einbauen, geht aber nicht ganz so schnell ;)
Wenn sonst noch irgendwas auffällt... gerne melden, ich sehe das ganze noch immer als work-in-progress...
Hallo
das Bild hier macht dann schnell einiges klarer,
https://github.com/MTJoker/HomeStatusDisplay
ev wäre es sinnvoll im 1. Post es noch einzufügen.
Kann man jede Mehrfarben LED Stripe da anschließen, oder was muss man dann beachten?
Aufbau scheint ja wirklcih sehr einfach im Nachbau zu sein,
Haben am WE einen FHEM Workshop in Waltrop wo wir das nachbauen wollen
das hier, dann wird Verdrahtung sofort klar
Welches Bild meinst du, das vom Anschlussschema? Kann ich einfügen ja. Das andere ist ja im 1. Post.
Es muss natürlich ein digitaler LED Streifen sein, also einer wo jede LED seperat angesteuert werden kann. Und da geht jeder den die Adafruit Neopixel Library ansteuern kann. WS2812B oder z.B. auch SK6812 (habe ich nicht getestet, ich habe nur WS2812B verwendet).
Hallo Franz,
Zitatoder was muss man dann beachten?
Auf jeden Fall bitte die Stromversorgung für die LED's beachten.
Eine einzelne LED ist pro Farbe mit max 20mA agegeben. Das macht bei drei Farben max. 60mA pro LED.
Da kommt der ESP ganz schnell in Schwitzen.
P.S.: Ich komme vorr. auch am Sonntag. Dann können wir uns ja darüber unterhalten.
Hier noch ein Link zu diesem Thema: https://learn.adafruit.com/adafruit-neopixel-uberguide/power
Das ist richtig, je nach Anzahl der LEDs kommt da schon einiges zusammen.
Beim wemos D1 mini ist es aber so, dass die 5V die über den USB Anschluss hereinkommen, durchgeschleift sind auf den Pin am Breakout Board. D.h. wenn man am USB Port ein Netzteil mit entsprechender Leistung anschließt, dann hat man da kein Problem und muss nicht z.B. ein zweites Netzteil extra für die LEDs nehmen.
Wie im Guide von Adafruit auch steht kann man "grob" mit 20mA pro Pixel rechnen anstatt mit 60, da der Anwendungsfall dass alle LEDs auf voller Helligkeit an sind (also weiß) so gut wie nie vorkommt und die meisten Netzteile auch "kurz" mal etwas mehr Strom liefern können als angegeben.
In meinem Fall habe ich 33 LEDs und versorge diese mit diesem Netzteil:
https://www.amazon.de/gp/product/B00WLI5E3M/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1 (https://www.amazon.de/gp/product/B00WLI5E3M/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1)
Das ist finde ich relativ günstig und von sehr guter Qualität - leistungsärmere Netzteile sind zumindest nicht sehr viel günstiger. Die 2.4A pro Port reichen auch dicke aus (33 LEDs * 60mA = 1,98A, also würde sogar den worst case abdecken). Aber ich habe den Aufbau auch ohne Probleme an einem 1A Netzteil betrieben.
Zitat von: Joker am 05 April 2017, 20:36:36
Auch sehr schöne Variante! Muss zugeben dass ich deins bisher noch gar nicht gesehen hatte. Das OLED ist ne nette Sache. Wie wird es angesteuert? Sollte eigentlich kein Thema sein das mit dem ESP zu nutzen.
Hallo,
OLED wird mit Adafruit_Python_SSD1306 angesteuert. Steuerung mit ESP sollte keine Problem sein. Das Problem ist halt immer die Zeit ...
MfG
ZitatOLED wird mit Adafruit_Python_SSD1306 angesteuert. Steuerung mit ESP sollte keine Problem sein. Das Problem ist halt immer die Zeit ...
Ist ja ziemlich cool muss ich sagen. Es gibt auch eine Library für Arduino die mit dem ESP geht für diese Displays.
Bin fast am überlegen ob ich sowas auch einbauen soll ;D
Am ESP hat man natürlich das Problem dass dieser erstmal keine Daten wie die Uhrzeit hat aber das kriegt man hin.
Eine Frage noch zu deinem Aufbau: Wie hast du die Front gestaltet? Sind es ein schwarzes und ein weißes Papier hintereinander? Oder ist es bedruckt? Ich bin mit der Optik meines Displays noch nicht so 100% zufrieden...
cooler Bilderrahmen,
zur Ansteuerung würde ich aber das LedStripe Modul empfehlen.
das macht das ganze imho einfacher ansprechbar. :-)
https://forum.fhem.de/index.php/topic,50174.0.html
Ich mache damit gerade noch Versuche mit einem 18650 gespeisten ESP:
https://www.tindie.com/products/lspoplove/pocket-8266-esp826618650-battery/
Zitat von: Frank_Huber am 06 April 2017, 11:27:21
cooler Bilderrahmen,
zur Ansteuerung würde ich aber das LedStripe Modul empfehlen.
das macht das ganze imho einfacher ansprechbar. :-)
https://forum.fhem.de/index.php/topic,50174.0.html
Hm, ich glaube das ist eher weniger gut für den Anwendungsfall geeignet. Ich möchte ja gerade die Intelligenz wie und welche LED angesteuert wird dem Display überlassen. Ich schicke dem Display nur eine Message z.B. "Fenster Küche ist offen", und was damit passiert entscheidet das Display. Die Benutzung von MQTT hat außerdem den Vorteil, dass ich mir im Prinzip das gleiche Display nochmal bauen kann, an den Strom anschließe und sofort zeigt es ohne irgendeine Änderung in FHEM dasselbe an wie das andere, da es automatisch die Messages ebenso bekommt. Wenn ich jetzt möchte dass das zweite Display bestimmte Messages anders anzeigt kann ich das sehr leicht am entpsprechenden Display ändern und muss in FHEM gar nichts machen.
Weiterhin, wenn ich das richtig sehe kann ich mit dem LEDStripe Modul eine LED auch nicht dauerhaft blinken lassen oder? Das kann ich bei meiner Variante einfach einstellen, dass die Reaktion kein dauerhaftes "ein" einer LED sein soll sondern ein Blinken oder auch "Flackern".
ZitatIch mache damit gerade noch Versuche mit einem 18650 gespeisten ESP:
https://www.tindie.com/products/lspoplove/pocket-8266-esp826618650-battery/
Ja das mit der Stromversorgung ist so ein Thema. Natürlich wärs am besten wenn ich so einen Bilderrahmen einfach irgendwo an die Wand hängen könnte, aber ich brauche immer eine Stromversorgung. Löse ich aktuell so dass das Display in einem Regal steht wo das Kabel unsichtbar zugeführt werden kann.
Den ESP per Batterie zu versorgen wäre zwar schön, aber ist wegen dem WLAN schon schwierig... die 17h die mit der Batterie möglich sind, sind ja viel zu wenig... da müsste man mit DeepSleep etc arbeiten, aber bei dem Statusdisplay geht das auch nicht, weil ich will ja dass ein Status immer sofort angezeigt wird...
Zitat von: Joker am 06 April 2017, 11:17:38
... Eine Frage noch zu deinem Aufbau: Wie hast du die Front gestaltet? Sind es ein schwarzes und ein weißes Papier hintereinander? Oder ist es bedruckt? ...
Die Front ist gedruckt. Der Platz für OLED ist mit einem Cuttermesser ausgeschnitten. Ich hänge meine aktuelle Version als jpg und xcf an.
MfG
Zitat von: Joker am 06 April 2017, 11:55:16
Hm, ich glaube das ist eher weniger gut für den Anwendungsfall geeignet. Ich möchte ja gerade die Intelligenz wie und welche LED angesteuert wird dem Display überlassen. Ich schicke dem Display nur eine Message z.B. "Fenster Küche ist offen", und was damit passiert entscheidet das Display. Die Benutzung von MQTT hat außerdem den Vorteil, dass ich mir im Prinzip das gleiche Display nochmal bauen kann, an den Strom anschließe und sofort zeigt es ohne irgendeine Änderung in FHEM dasselbe an wie das andere, da es automatisch die Messages ebenso bekommt. Wenn ich jetzt möchte dass das zweite Display bestimmte Messages anders anzeigt kann ich das sehr leicht am entpsprechenden Display ändern und muss in FHEM gar nichts machen.
Weiterhin, wenn ich das richtig sehe kann ich mit dem LEDStripe Modul eine LED auch nicht dauerhaft blinken lassen oder? Das kann ich bei meiner Variante einfach einstellen, dass die Reaktion kein dauerhaftes "ein" einer LED sein soll sondern ein Blinken oder auch "Flackern".
OK, in dem Fall macht das so Sinn. Ich überlassedie Steuerung gerne FHEM so dass das zentral abäuft. ein zweites Display kann ich auch einfach in den DOIFs mit reinpacken.
Ich sehe für mich mit dem Modul den Vorteil das alles in FHEM ist und ich noch dazu kein MQTT benötige.
Aber bekanntlich führen ja viele Wege nach Rom. :-)
Zitat von: Joker am 06 April 2017, 11:55:16
Ja das mit der Stromversorgung ist so ein Thema. Natürlich wärs am besten wenn ich so einen Bilderrahmen einfach irgendwo an die Wand hängen könnte, aber ich brauche immer eine Stromversorgung. Löse ich aktuell so dass das Display in einem Regal steht wo das Kabel unsichtbar zugeführt werden kann.
Den ESP per Batterie zu versorgen wäre zwar schön, aber ist wegen dem WLAN schon schwierig... die 17h die mit der Batterie möglich sind, sind ja viel zu wenig... da müsste man mit DeepSleep etc arbeiten, aber bei dem Statusdisplay geht das auch nicht, weil ich will ja dass ein Status immer sofort angezeigt wird...
Ja, 17h ist nicht viel, aber um ein Statusdisplay mal am Abend mit auf die Terrasse zu nehmen oder wie bei mir abends am Kaminofen den Füllstand vom Pufferspeicher anzuzeigen, dazu reichen die 17h locker.
wenn die LEDs noch drüber gehen sind es wahrscheinlich eh nur noch 5 bis 6 h. aber auch das reicht für meinen Zweck.
Zitat von: Ralf W. am 06 April 2017, 12:00:28
Die Front ist gedruckt. Der Platz für OLED ist mit einem Cuttermesser ausgeschnitten. Ich hänge meine aktuelle Version als jpg und xcf an.
Danke. Ich hatte mir auch schon mal überlegt das mit schwarzem Hintergrund zu machen, aber mit meinem Tintenstrahler habe ich das erst gar nicht probiert. Denke das geht nur mit einem Laserdrucker gut.
Daher habe ich dann einen farbigen Karton vor das gedruckte Papier gelegt und die "Löcher" ausgeschnitten als Test. Hat mir dann zumindest so gut gefallen dass ich es mit einem Laserdrucker nicht mehr probiert habe. Aber so filigranere Ausschnitte kann ich dann natürlich nicht machen.
ZitatOK, in dem Fall macht das so Sinn. Ich überlassedie Steuerung gerne FHEM so dass das zentral abäuft. ein zweites Display kann ich auch einfach in den DOIFs mit reinpacken.
Ich sehe für mich mit dem Modul den Vorteil das alles in FHEM ist und ich noch dazu kein MQTT benötige.
Aber bekanntlich führen ja viele Wege nach Rom. :-)
Hehe, so ist es. Ich will MQTT noch für andere Dinge nutzen, von daher war es quasi "schon da".
ZitatJa, 17h ist nicht viel, aber um ein Statusdisplay mal am Abend mit auf die Terrasse zu nehmen oder wie bei mir abends am Kaminofen den Füllstand vom Pufferspeicher anzuzeigen, dazu reichen die 17h locker.
wenn die LEDs noch drüber gehen sind es wahrscheinlich eh nur noch 5 bis 6 h. aber auch das reicht für meinen Zweck.
Ok, das stimmt dafür ist es in Ordnung.
Zitat von: Joker am 06 April 2017, 14:54:56
Danke. Ich hatte mir auch schon mal überlegt das mit schwarzem Hintergrund zu machen, aber mit meinem Tintenstrahler habe ich das erst gar nicht probiert. Denke das geht nur mit einem Laserdrucker gut ...
Ich habe es mit einem Tintenstrahtdrucker erstellt (Fotomodus) und bin zufrieden. Falls das Papier zu stark wellt, kurz warten und in ein großes Buch legen. Papier war 90 g oder 120 g, da bin ich mir nicht mehr ganz sicher.
MfG
Hallo Joker,
mir ist aufgefallen das nach einer gewissen Zeit (Dauer kann ich nicht sagen) alle gesetzten LED´s aus sind. Kann es sein, dass der ESP selbst einen Reboot macht und damit alle gesetzten LED´s aus sind?
Viele Grüße
Ich habe gerade noch ein paar Aktualisierungen hochgeladen:
- MQTT Broker Adresse kann nun wahlweise als IP oder Hostname übergeben werden
- Es wird maximal 10s lang versucht sich am MQTT Broker anzumelden, danach wird abgebrochen. Nur noch während dieser Zeit ist das Webinterface sehr langsam, da der PubSubClient sehr lange in der connect() Routine verbleibt und in der Zeit der Webserver nicht bedient wird
Zitat von: ckbln am 08 April 2017, 11:41:11
mir ist aufgefallen das nach einer gewissen Zeit (Dauer kann ich nicht sagen) alle gesetzten LED´s aus sind. Kann es sein, dass der ESP selbst einen Reboot macht und damit alle gesetzten LED´s aus sind?
Das ist jetzt nicht ganz einfach zu sagen. Bei einem Reboot des ESP müsstest du im Logfile vom MQTT Broker sehen dass der Client verschwunden ist (KeepAlive Mechanismus). Weiterhin würde der Broker wenn du ein Will Topic angegeben hast, dieses in dem Fall verschicken.
Prinzipiell wäre dann aber die Frage was den Reboot auslöst (hatte ich selber noch nie, mein Display ist schon mehrere Wochen durchgelaufen. Aber ausschließen kann man es natürlich nicht). Was ich für das Gerät sinnvoll halte ist, die MQTT Messages immer mit retain Flag zu schicken. Dann würde der Broker wenn das Gerät weg ist und wieder auftaucht, die letzten Nachrichten zu jedem Topic neu schicken und die LEDs würden wieder an gehen.
Ich habe der Status-Webseite nun eine Uptime hinzugefügt (ist im git), siehe Anhang.
Wenn der ESP tatsächlich rebooten sollte, würde die Uptime zurückgesetzt werden. Falls das tatsächlich auftritt wären weitere Infos gut (wie lange lief der ESP, ist zum Absturzzeitpunkt evtl. etwas besonderes passiert z.B. sehr viele Nachrichten eingetroffen etc). Bei mir habe ich das nach wie vor nicht gesehen.
Wenn sonst noch jemand Probleme oder Anregungen hat, immer her damit.
Weitere Aktualisierungen:
Zitat von: Franz Tenbrock am 06 April 2017, 09:30:43
das Bild hier macht dann schnell einiges klarer,
https://github.com/MTJoker/HomeStatusDisplay
ev wäre es sinnvoll im 1. Post es noch einzufügen.
Ist jetzt im ersten Post drin.
Zitat von: ckbln am 06 April 2017, 00:46:08
Noch eine Frage: Wäre es möglich über ein Eingabefeld die Helligkeit der LED´s anzupassen?
Ist jetzt ebenfalls möglich, es gibt ein weiteres Eingabefeld bei der "General config".
ACHTUNG: Da sich dadurch eine Konfigurationsdatei ändert, geht durch ein Update mindestens die General config verloren und muss neu eingegeben werden!Bitte vorher Screenshot machen etc. um die Konfiguration leicht neu eingeben zu können. Bei einem Test hatte ich auch einmal den Fall dass alle drei Konfigurationen verloren gingen (General, Color mapping, Device mapping), aber das konnte ich nicht mehr reproduzieren. Sicherheitshalber von allen Screenshots machen o.ä.
Zur Funktionsweise: Der Helligkeitswert ist einstellbar von 0 (aus, macht natürlich keinen Sinn) und 255 (maximale Helligkeit). Ich verwende bei mir
15, das reicht völlig aus und ist ungefähr so wie in der alten Version. Wer es heller oder dunkler haben möchte, hat jetzt die Möglichkeit.
Zitat von: ckbln am 08 April 2017, 11:41:11
mir ist aufgefallen das nach einer gewissen Zeit (Dauer kann ich nicht sagen) alle gesetzten LED´s aus sind. Kann es sein, dass der ESP selbst einen Reboot macht und damit alle gesetzten LED´s aus sind?
Ich hatte in den ganzen Wochen in denen das Gerät bei mir läuft jetzt auch scheinbar zwei mal einen Neustart. Über den Grund bin ich nicht 100% sicher, aber habe eine Idee woran es liegt. In der aktualisierten Version ist schonmal was eingebaut was dies beheben
könnte. Ich teste noch, aber wenn jemand noch das Problem hat, kann er es ja mal mit der neuen Version probieren.
Hallo
hatte bisher das Teil von ELV, das habe ich über einen Bewegungsmelder aktiviert, dh wenn vor der Garderobe Bewegung ist wird es eingeschaltet, nach 10-15 Sekunden hat es dann alles angezeigt.
Ist es möglich das Ganze ebenso mit einem Bewegungsmelder zu kombinieren, um den Gesamtstromverbrauhc von dem Teil zu redudieren, neben den dimmen sollte es dann ja halbwegs gehen mit dem Stromverbrauch.
Ich weiß grade nicht wovon du sprichst :)
Was für ein Teil von ELV?
Was heißt "neben dem dimmen"...?
Zitat von: Joker am 06 April 2017, 11:17:38
...
Es gibt auch eine Library für Arduino die mit dem ESP geht für diese Displays.
Bin fast am überlegen ob ich sowas auch einbauen soll ;D
...
Ist da was in Planung? Das wäre ein Träumchen :)
MfG
"Ich weiß grade nicht wovon du sprichst :)
Was für ein Teil von ELV?
Was heißt "neben dem dimmen".."
HomeMatic 104798 Funk-Statusanzeige LED 16 Helligkeitsstufen HM-OU-LED16
Hier ist das weit unten mit dem Bewegungsmelder beschrieben
https://wiki.fhem.de/wiki/HM-OU-LED16_Funk-Statusanzeige_LED16
Die LEDs des Status Display sollen nur leuchten wenn im Flur Bewegung ist,wieviel Strom ziehen die wenn alle LEDs rund um die Uhr leuchten.....
Der ESP braucht sicher 30 Sekunden um sich im Netz anzumelden. das wird zu langsam sein, da wird meine Frau nicht begeistert sein ...
Zitat von: Franz Tenbrock am 20 April 2017, 13:00:10
hatte bisher das Teil von ELV, das habe ich über einen Bewegungsmelder aktiviert, dh wenn vor der Garderobe Bewegung ist wird es eingeschaltet, nach 10-15 Sekunden hat es dann alles angezeigt.
Ist es möglich das Ganze ebenso mit einem Bewegungsmelder zu kombinieren, um den Gesamtstromverbrauhc von dem Teil zu redudieren, neben den dimmen sollte es dann ja halbwegs gehen mit dem Stromverbrauch.
Zitat von: Franz Tenbrock am 20 April 2017, 13:00:10
HomeMatic 104798 Funk-Statusanzeige LED 16 Helligkeitsstufen HM-OU-LED16
Hier ist das weit unten mit dem Bewegungsmelder beschrieben
https://wiki.fhem.de/wiki/HM-OU-LED16_Funk-Statusanzeige_LED16
Die LEDs des Status Display sollen nur leuchten wenn im Flur Bewegung ist,wieviel Strom ziehen die wenn alle LEDs rund um die Uhr leuchten.....
Der ESP braucht sicher 30 Sekunden um sich im Netz anzumelden. das wird zu langsam sein, da wird meine Frau nicht begeistert sein ...
Machen kann man viel, aber ob das sinnvoll ist? Also von meiner Seite aus gibts da keine Planung für, der Grund ist ganz einfach- das lohnt sich nicht:
Der ESP braucht ca. 80mA. Eine LED braucht pro Farbe in voller Helligkeit (!) 20mA. Der Normalfall ist aber, dass wenige bis gar keine LEDs an sind, zumindest bei mir, und volle Helligkeit kommt gar nicht vor- wie oben geschrieben verwende ich einen Helligkeitswert von 15 wobei maximal 255 möglich ist.
Also nehmen wir mal an es wären tatsächlich rund um die Uhr 10 LEDs an, dann würde ich bei der Helligkeit schätzen dass das nicht mehr als 100mA sind. Dann hätten wir insgesamt 180mA bei 5V, das sind 0,9W. Bei 8640 Stunden im Jahr sind das ca. 7,8kWh pro Jahr. Das kostet dann bei 20ct pro kWh 1,56€ pro Jahr. Und wie gesagt- ich denke das ist eher viel weniger da -zumindest bei mir- z.B. nachts wenn alle Fenster zu und alle Lichter aus sind, keine einzige LED an ist (was nicht bedeutet dass die LED dann gar keinen Strom verbraucht, aber zumindest nicht in der Größenordnung). Sollte ich da einen groben Denkfehler haben, dann lasst es mich wissen ;)
Wenn man das jetzt in irgendeiner Form optimiert reden wir von einer Ersparnis von maximal 1€ pro Jahr, und dafür -sorry- fange ich nicht an da eine Softwarelösung zu basteln, zumal das wie du schon erkannt hast mit einer Funktionseinschränkung einher ginge, dass es eine gewisse Zeit dauert bis man was sieht. Aber der Sourcecode liegt ja offen, wenn jemand was baut was funktioniert kann ich das gerne einpflegen und ggf. behilflich sein.
Eine Hardwarelösung in der Form dass dem ESP einfach hart der Strom abgeschaltet wird und per Bewegungsmelder wieder ein, wäre eine einfachere Lösung, aber das ist dann sowieso außerhalb dieses Projekts. 30s braucht der ESP nicht um sich einzuwählen, bei mir dauert es vom Stecker einstecken bis alle LEDs den Status anzeigen ca. 10s. Der Vorteil ist, wenn man mit MQTT retained Messages arbeitet, bekommt das Gerät beim Power On immer den letzten Status zugestellt- man muss keine notify o.ä. basteln um den Status wieder herzustellen.
Zitat von: Ralf W. am 20 April 2017, 14:10:36
Ist da was in Planung? Das wäre ein Träumchen :)
Was das OLED Display angeht, von Planung würde ich nicht sprechen. Ich finde die Idee interessant und würde das prinzipiell umsetzen, aber meine Zeit ist im Moment sehr begrenzt. Ich habe bisher noch nicht mal so ein Display, also kann ich da aktuell gar keine zusagen machen. Ich würde mir mal ein paar Displays in China bestellen und dann bei Gelegenheit damit experimentieren, aber ob und wann das was wird, kann ich im Moment nicht sagen.
Aber auch hier ist jeder eingeladen selbst mitzumachen, ich helfe wo ich kann.
Hallo Joker,
ich würde Dein Projekt mit IOBroker nutzen.
In der Theorie sollte das kein Problem sein, eine Frage hätte ich aber.
Mein MQTT Server braucht noch ein Benutzername und Passwort, damit sich der Client verbinden kann. Dies habe ich in der Konfiguration nicht gesehen.
Sind die Bilder zu alt oder existiert die Eingabe nicht für Benutzername und Passwort?
Hat jemand eine xcf (Gimp) für einen passenden Bilderrahmen mindestens 13x18?
ICh habe den Aufbaue noch nicht verstanden, die Front per Gimp zusammengestellt, an den LEDs jeweils ein passenden Loch ausgestanzt, dann ein weißes Blatt papier und dahinter dann die LEDs?
siehe hier: https://we-mod-it.com/board258-diy-do-it-yourself/board260-elektronik/3380-home-statusdisplay-mit-ws2812b-leds-esp8266-und-mqtt-by-joker/
da ist es etwas genauer beschrieben.
Zitat von: knopers1 am 28 Dezember 2017, 13:30:37
Mein MQTT Server braucht noch ein Benutzername und Passwort, damit sich der Client verbinden kann. Dies habe ich in der Konfiguration nicht gesehen.
Sind die Bilder zu alt oder existiert die Eingabe nicht für Benutzername und Passwort?
Aktuell gibt es noch keine Version mit MQTT Benutzername und Passwort. Es sollte kein Problem sein das einzubauen, aber ich kann noch nicht versprechen wann ich dazu komme.. Eventuell schaffe ich es in der ersten Januarwoche es zumindest mal auszuprobieren.
Zitat von: Tobias am 28 Dezember 2017, 13:50:51
Hat jemand eine xcf (Gimp) für einen passenden Bilderrahmen mindestens 13x18?
ICh habe den Aufbaue noch nicht verstanden, die Front per Gimp zusammengestellt, an den LEDs jeweils ein passenden Loch ausgestanzt, dann ein weißes Blatt papier und dahinter dann die LEDs?
Zitat von: knopers1 am 28 Dezember 2017, 13:58:32
siehe hier: https://we-mod-it.com/board258-diy-do-it-yourself/board260-elektronik/3380-home-statusdisplay-mit-ws2812b-leds-esp8266-und-mqtt-by-joker/
da ist es etwas genauer beschrieben.
Genau, dort habe ich den Aufbau genauer beschrieben. Wenn noch Fragen sind melde dich, aber es sollte eigentlich damit klar sein. Mal am Ende des Threads schauen, denn am Anfang sind noch Bilder der ursprünglichen Version.
Noch ganz wichtig: Aktuell ist die letzte Version mit allen Bugfixes und Features nicht offiziell released. Daher bitte auf https://github.com/MTJoker/HomeStatusDisplay auf "Clone or Download" gehen und dort die Dateien runterladen. Nicht über "Releases".
Zitat von: Joker am 29 Dezember 2017, 07:13:58
Aktuell gibt es noch keine Version mit MQTT Benutzername und Passwort. Es sollte kein Problem sein das einzubauen, aber ich kann noch nicht versprechen wann ich dazu komme.. Eventuell schaffe ich es in der ersten Januarwoche es zumindest mal auszuprobieren.
ich drücke die Daumen dass Du etwas Zeit dazu findest. Zwischendurch versuche ich evtl. selbst etwas auf die Beine zu stellen. Muß mich aber vorerst mit der Ansteuerung der WS2812B Led Bänder vertraut machen.
Kann man in dem Sketch auch die LEDs dimmen? Bei dunkler Umgebung möchte ich die leuchtstärke gerne herunter regeln.
Bin gerade dabei mir 1m des 60er LED Bandes zu besorgen. Damit soll ein A4 Rahmen in 3 senkrechten Reihen bestückt werden.
Ich bin noch am schauen, ob es etwas derartiges auch mit intelligenten SMD tastern gibt. Dann könnte ich neben jeder LED auch ein Taster setzen
Gesendet von meinem Leap mit Tapatalk
Zitat von: Joker am 29 Dezember 2017, 07:13:58
Noch ganz wichtig: Aktuell ist die letzte Version mit allen Bugfixes und Features nicht offiziell released. Daher bitte auf https://github.com/MTJoker/HomeStatusDisplay auf "Clone or Download" gehen und dort die Dateien runterladen. Nicht über "Releases".
Im Github steht, die letzten änderungen sind 7 MOnate her. Tut sich da noch etwas dran? Ist das der letzte finale Stand? Oder bist du ev. umgezogen?
NOchmal die FRage, kann man (in 0-100%) dimmen? Oder zumindest alle LEDs ausschalten und wieder einschalten mit einem einzigen Topic?
Brauche ich bei einem Schaltnetzteil mit exakt 5V den großen Elko? Wie gross muss der Widerstand sein?
den Widerstand würde ich zwischen 200-400 Ohm nehmen. Und der Elko ist nur für die Glättung der Spannung. Hierbei würde ich zwischen 500 und 1000uF nehmen.
Ist aber nicht zwingend notwendig. Ich würde aber einen einbauen. Dies sorgt für eine konstante Spannungsguelle für den Wemo.
hab jetzt weiter oben auch endlich kapiert, das ein Zustandsabhängiges dimmen in der jetzigen Form nicht möglich ist, damit ist meine Frage beantwortet ;)
Aktuell habe ich auch so eine Homematic Statusanzeige an Laufen. Bei mir brennen immer ALLE LEDs und die Farbe zeigt den Zustand an. Ggf. werde ich dann deinen Sketch anpassen- Muss ich sehen.
Zitat von: Tobias am 02 Januar 2018, 13:22:31
Im Github steht, die letzten änderungen sind 7 MOnate her. Tut sich da noch etwas dran? Ist das der letzte finale Stand? Oder bist du ev. umgezogen?
Final sicher nicht, ich mache immer mal wieder etwas dran, aber ich habe noch nichts was eine Qualität hat die ich ruhigen Gewissens veröffentlichen könnte :-)
Die letzten Änderungen die Online sind, sind in der Tat 7 Monate her, aber es sind trotzdem eine ganze Reihe an Commits seit dem letzten Release (auf der Release-Seite), daher der Hinweis lieber über "Download" auf der Hauptseite zu gehen, denn dann hat man auch die Änderungen seit dem letzten Release.
Mein kleiner Beitrag zu diesem Projekt. Eine Vorlage nach Ralfs LCARS Vorbild für einen 21x30 Bilderrahmen. Ich habe mich für einen 21x30 Alurahmen LOMVIKEN eines schwedischen Möbelhauses entschieden
ich versuche gerade den Sketch zu kompilieren, Libraries sind alle installiert. Leider wird die HomeStatusDisplay.hpp nicht gefunden obwohl diese im Sketchfolder enthalten ist.
Sie wird merkwürdigerweise im BuildOrder erwartet. Ich bin etwas ratlos....
Arduino: 1.6.5 (Windows 7), Platine: "WeMos D1 mini Pro, 80 MHz, 16M (15M SPIFFS), v2 Prebuilt (MSS=536), Disabled, None, 921600"
Build-Optionen wurden verändert, alles wird neu gebaut
C:\Users\Tobias\AppData\Roaming\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\Tobias\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\2.4.0/tools/sdk/include -IC:\Users\Tobias\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\2.4.0/tools/sdk/lwip2/include -IC:\Users\Tobias\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\2.4.0/tools/sdk/libc/xtensa-lx106-elf/include -IC:\Users\Tobias\AppData\Local\Temp\build2717470748974038980.tmp/core -c -w -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections -DF_CPU=80000000L -DLWIP_OPEN_SRC -DTCP_MSS=536 -DARDUINO=10605 -DARDUINO_ESP8266_WEMOS_D1MINIPRO -DARDUINO_ARCH_ESP8266 -DARDUINO_BOARD="ESP8266_WEMOS_D1MINIPRO" -DESP8266 -IC:\Users\Tobias\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\2.4.0\cores\esp8266 -IC:\Users\Tobias\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\2.4.0\variants\d1_mini C:\Users\Tobias\AppData\Local\Temp\build2717470748974038980.tmp\HomeStatusDisplay.cpp -o C:\Users\Tobias\AppData\Local\Temp\build2717470748974038980.tmp\HomeStatusDisplay.cpp.o
C:\Users\Tobias\AppData\Local\Temp\build2717470748974038980.tmp\HomeStatusDisplay.cpp:1:33: fatal error: HomeStatusDisplay.hpp: No such file or directory
#include "HomeStatusDisplay.hpp"
^
compilation terminated.
Fehler beim Kompilieren.
Edit: Problem gelöst, mit der Arduino IDE 1.6.5 gibt es Probleme, erst ab Version 1.6.6. werden hpp files unterstützt. Mit der aktuellen 1.8.5 Version kompiliert es sauber durch.
Wäre ev. ein Hinweis im GitHub ReadMe und auf deiner Webseite wert :)
stehe vor einem merkwürdigem Verhalten, nach dem Flashen verbinde ich mich mit dem AP und gebe alle möglichen Daten ein. Nach einem Reboot verbindet sich der ESP leider nicht mit meinem WIFI, das Pass habe ich per Copy und Paste eingegeben. Mag sein - ev hat sich ein Leerzeichen eingeschlichen.
Nach ca 60sek erfolglosem Connect wird der AP aufgemacht. Jetzt Kann ich wieder dort connecten ABER jetzt bricht der AP zusammen sobald ich versuche mich mit der SID "StatusDisplay" zu verbinden. Ich kann mich ab jetzt bis zu einem Reboot nicht mehr verbinden bzw die SID ist "weg", im Serial Log steht nix dazu
Wie kann ich die vorher eingegebene und gespeicherte Config manuell wieder löschen?
Edit: mit einem anderen ESP klappt der erneute AP-Connect
Hi,
anscheinend habe ich jetzt einen wirklichen, echten kleinen Bug entdeckt. Mein Paswort ist 64 Zeichen lang.
In der WebForm werden nur 40 Zeichen angenommen, bzw per nach dem SaveButton nur die ersten 40 Zeichen des Passwortes in der URL übertragen. Im ESP werden nur 30 Zeichen gespeichert. Hatte mir dazu in der PrintMainConfigFile Prozedur das gespeicherte Passwort audgeben lassen.
Könntest du dir das mal bitte anschauen ob ich richtig liege?
Edit: Habe angepasst:
HSDConfig.cpp, Zeile 253:
static const int MAX_WIFI_PSK_LEN = 64;
HSDWebserver.cpp, zeile 73:
html += F("' size='64' maxlength='64' placeholder='Password'></td></tr>");
Kannst du das bei dir ins Github einpflegen? Nach diesen beiden Änderungen klappt es auch mit dem WiFi Connect ;)
Zitat von: Tobias am 03 Januar 2018, 20:26:38
Edit: Problem gelöst, mit der Arduino IDE 1.6.5 gibt es Probleme, erst ab Version 1.6.6. werden hpp files unterstützt. Mit der aktuellen 1.8.5 Version kompiliert es sauber durch.
Wäre ev. ein Hinweis im GitHub ReadMe und auf deiner Webseite wert :)
Danke, werde ich so aufnehmen.
Zitat von: Tobias am 05 Januar 2018, 19:53:55
Könntest du dir das mal bitte anschauen ob ich richtig liege?
Edit: Habe angepasst:
HSDConfig.cpp, Zeile 253:
static const int MAX_WIFI_PSK_LEN = 64;
HSDWebserver.cpp, zeile 73:
html += F("' size='64' maxlength='64' placeholder='Password'></td></tr>");
Kannst du das bei dir ins Github einpflegen? Nach diesen beiden Änderungen klappt es auch mit dem WiFi Connect ;)
Ja das passt so, ich werde es übernehmen. Kann ein paar Tage dauern da ich im Moment einiges anderes um die Ohren habe. Ich muss nochmal checken dass man dann da nicht in Probleme läuft da auch die maximale Größe eines Config-Files festgelegt ist.
Ich hatte das so streng limitiert da ich am Anfang enorme Speicherprobleme hatte wenn die Webseiten aufgebaut werden. Aber der Hauptspeicherfresser ist hier die Anzahl an LEDs und Behaviors und die MQTT-Strings.
Danke dir. Ich habe zb. 54 Led´s.
Alternativ macht es ev. Sinn den Sketch auf einen ESP32 zu portieren.
Mal was anderes: hat schonmal jemand einen Rolladenstatus darüber angezeigt?
Meine Idee wäre bisher nur diesen über den windows type zu visualisieren (zu=off, offen=on, irgendetwas dazwischen=tilted)
Gibts eine bessere idee?
SO sieht mein Statusdisplay aus. Das Ganze ist ca 15mm dick. Der ESP verschwindet in einer dahinterliegenden UNterputzdose. Aber auch ohne diese dose würde er von der höhe noch dahinterpassen da ohne die Stiftleiste dieser selbst auch nur 5mm dick ist
Zitat von: Tobias am 12 Januar 2018, 09:58:52
SO sieht mein Statusdisplay aus. Das Ganze ist ca 15mm dick. Der ESP verschwindet in einer dahinterliegenden UNterputzdose. Aber auch ohne diese dose würde er von der höhe noch dahinterpassen da ohne die Stiftleiste dieser selbst auch nur 5mm dick ist
Sieht super aus! Ist das ein fertiger Rahmen oder sind das selber zugeschnittene Aluprofile?
Zitat von: Tobias am 09 Januar 2018, 14:08:30
Danke dir. Ich habe zb. 54 Led´s.
Alternativ macht es ev. Sinn den Sketch auf einen ESP32 zu portieren.
Hm, was mir dazu noch einfällt: Aktuell ist aufgrund der Speicherprobleme die Anzahl der Einträge im Color Mapping auf 30 beschränkt, und die Anzahl der Einträge im Device Mapping auf 35. D.h. du wirst da vermutlich Probleme bekommen alles so einzurichten wie du willst. Hierzu sei noch gesagt, das Speicherproblem ist hauptsächlich wegen der Konfiguration über die Webseite, d.h. die Webseite wird aufgrund der vielen Einträge so groß dass der Speicher ausgeht. Würde man das Config-File z.B. offline editieren und direkt ins Flash legen, könnte man auch wesentlich mehr Einträge zulassen- verliert dadurch aber die komfortable Editiermöglichkeit und kann Probleme bekommen wenn die Syntax im editierten Config-File nicht stimmt.
Wenn jemand einen Weg kennt den Speicherverbrauch mit der Webseite zu limitieren oder andere Lösungsmöglichkeiten für dieses Problem, bin ich für Vorschläge, am liebsten direkt in Form von Pull-Requests sehr dankbar.
Ich kann aufgrund sehr wenig verfügbarer Zeit allerdings da leider nicht maßgeblich dran mitwirken. Ich habe aktuell auch kein Testsystem mit entsprechend großen Konfigurationen (größer als meine eigene meine ich damit).
ZitatMal was anderes: hat schonmal jemand einen Rolladenstatus darüber angezeigt?
Meine Idee wäre bisher nur diesen über den windows type zu visualisieren (zu=off, offen=on, irgendetwas dazwischen=tilted)
Gibts eine bessere idee?
Wäre so möglich, habe ich selber aber noch nicht gemacht. Prinzipiell könnte man auch einen Device Type "Generic" oder sowas einführen, damit das nicht so seltsam aussieht. Vielleicht ist diese ganze Aufteilung wie ich das gemacht habe auch nicht so gut (Color/Device Map Konfiguration). Wenn hier jemand bessere Ideen hat bin ich da durchaus offen ;)
Das ist ein fertiger Bilderrahmen, siehe ein paar Postings von mir weiter oben
Meine Ideee ist als erstes, das Ganze auf ESP32 zu portieren, der hat bei weitem mehr Speicher.
Erstes Problem ist, das ESP8266WebServer und ESP8266HTTPUpdateServer im ESP32 nicht mehr gibt. Dort wird alles über WiFi.h abgewickelt.
Als Alternative oder QuickWin / Workaround wäre ev. ein Export und Import der jeweiligen Datei möglich.
Leider bekomme ich das nicht selbst hin.
Mein Problem ist, dass ich außer dem HomeStatusDisplay auch noch keine "größeren" Projekte auf dem ESP8266 selbst entwickelt habe, und auf dem ESP32 noch gar nichts.
Daher kann ich z.B. nicht einschätzen ob man den Speicherverbrauch vielleicht deutlich reduzieren könnte. Wenn ich mir andere Projekte wie ESPEasy, Sonoff-Tasmota oder das Sming Framework anschaue, können diese ja DEUTLICH mehr als das Projekt hier, also wäre die Frage wieso habe ich mit dem kleinen Projekt hier so große Speicherprobleme?
Was den ESP32 angeht, bestimmt kriegt man es hin das Projekt zu portieren, aber das muss dann so geschehen dass man den ESP8266 Support nicht abschneidet, denn die allermeisten nutzen diesen. Das könnte dann bedeuten, dass man auf dem ESP8266 z.B. nur 30 LEDs nutzen kann, auf dem ESP32 aber 100 oder sowas. In jedem Fall sollte man aber den Speicherverbrauch überprüfen, denn eventuell kann man sich dann die Portierung auch komplett sparen, oder hätte zumindest funktionell keine Unterschiede.
Hi,
ich habe mal den sketch so erweitert, dass man 55 Einträge im Devicemapping machen kann um einen Speicherfehler zu provozieren. Ich habe alle 54 Einträge angelegt, aber keinen ESP-Absturz oder sonstige Auffälligkeiten festgestellt.
@Joker: inwiefern hat sich die Speicherproblematik gezeigt??
Adding or editing device mapping entry at index 54 with name test24, type 0, LED number 0
Header size: 1297
Page size: 6977
Free RAM: 21104
Need to save device mapping config
Preparing to write device mapping config file index 0
Preparing to write device mapping config file index 1
Preparing to write device mapping config file index 2
Preparing to write device mapping config file index 3
Preparing to write device mapping config file index 4
Preparing to write device mapping config file index 5
Preparing to write device mapping config file index 6
Preparing to write device mapping config file index 7
Preparing to write device mapping config file index 8
Preparing to write device mapping config file index 9
Preparing to write device mapping config file index 10
Preparing to write device mapping config file index 11
Preparing to write device mapping config file index 12
Preparing to write device mapping config file index 13
Preparing to write device mapping config file index 14
Preparing to write device mapping config file index 15
Preparing to write device mapping config file index 16
Preparing to write device mapping config file index 17
Preparing to write device mapping config file index 18
Preparing to write device mapping config file index 19
Preparing to write device mapping config file index 20
Preparing to write device mapping config file index 21
Preparing to write device mapping config file index 22
Preparing to write device mapping config file index 23
Preparing to write device mapping config file index 24
Preparing to write device mapping config file index 25
Preparing to write device mapping config file index 26
Preparing to write device mapping config file index 27
Preparing to write device mapping config file index 28
Preparing to write device mapping config file index 29
Preparing to write device mapping config file index 30
Preparing to write device mapping config file index 31
Preparing to write device mapping config file index 32
Preparing to write device mapping config file index 33
Preparing to write device mapping config file index 34
Preparing to write device mapping config file index 35
Preparing to write device mapping config file index 36
Preparing to write device mapping config file index 37
Preparing to write device mapping config file index 38
Preparing to write device mapping config file index 39
Preparing to write device mapping config file index 40
Preparing to write device mapping config file index 41
Preparing to write device mapping config file index 42
Preparing to write device mapping config file index 43
Preparing to write device mapping config file index 44
Preparing to write device mapping config file index 45
Preparing to write device mapping config file index 46
Preparing to write device mapping config file index 47
Preparing to write device mapping config file index 48
Preparing to write device mapping config file index 49
Preparing to write device mapping config file index 50
Preparing to write device mapping config file index 51
Preparing to write device mapping config file index 52
Preparing to write device mapping config file index 53
Preparing to write device mapping config file index 54
Writing config file /devicemapping.json
Header size: 1297
Page size: 6701
Free RAM: 22064
Uptime: 17min
Uptime: 18min
machmal kommt es vor das alle definierten LEDs in allen mögliche Farben mit 100% Helligkeit aufblitzen. Wie ein Regenbogengewitter , alle LEDs gleichzeitig isn derselben Farbe.
Kennt das jemand? Ich habe keine Ahnung wo ich suchen soll.
Ich habe den Elko und den Widerstand (510 Ohm) drin.
Hallo,
ich habe mir das HomeStatusDisplay in den letzten Tagen mal vorgenommen und möchte ein ähnliches Display bauen.
Allerdings habe ich jetzt nach der Einrichtung von Wemos und MQTT ein Problem mit dem Verbindungsaufbau und weiß nicht, was ich falsch mache.
Wemos funktioniert und ich kann per Intranet darauf zugreifen. Die LED´s gehen von rot auf gelb.
Die Webpage des HomeStatusDisplay zeigt folgendes an:
Device is connected to WLAN JS
IP address is 192.168.178.74
Device is not connected to an MQTT broker
In FHEM sieht es so aus:
Das MQTT Device steht auf opened:
mqtt
opened
Die Readings:
connection
active
2018-01-20 16:30:24
state
opened
2018-01-20 16:21:24
Ein Tesdevice, dass ich angelegt habe zeigt folgendes Reading:
transmission-state
outgoing publish sent
2018-01-20 16:23:13
Allerdings tut sich am Wemos/RGB-Stripe nichts.
Ich weiß nicht, warum der Status
Device is not connected to an MQTT broker
lautet.
Es könnte sein, dass es an den Einstellungen unter "General" liegt, denn ich weiß nicht wirklich was ich unter "Server" eingeben soll?
Sorry, wenn die Frage doof ist:
Soll ich da die IP und das Passwort von FHEM eingeben?
Oder vom Raspberry?
Du musst die IP des Servers eintragen wo der mqtt Server läuft. User und password kannst du leer lassen wenn du dieses beim mqtt Server nicht explizit eingestellt hast
Gesendet von meinem Leap mit Tapatalk
Das ist genau meine Frage?
Muss ich die IP des Raspi eingeben, auf dem MQTT läuft, oder muss ich -das habe ich in entsprechenden Beiträgen gefunden- 127.0.0.1:1883 eingeben.
Beides funktioniert bei mir nicht. Ich bekomme keine Verbindung.
Ich suche seit Stunden.
Kann es evtl. daran liegen, dass ich auf meinem Raspi Pihole laufen habe?
Zitat von: Jogi am 20 Januar 2018, 17:56:48
Das ist genau meine Frage?
Muss ich die IP des Raspi eingeben, auf dem MQTT läuft, oder muss ich -das habe ich in entsprechenden Beiträgen gefunden- 127.0.0.1:1883 eingeben.
Beides funktioniert bei mir nicht. Ich bekomme keine Verbindung.
Ich suche seit Stunden.
Kann es evtl. daran liegen, dass ich auf meinem Raspi Pihole laufen habe?
Ich habe es jetzt gelöst.
Ich musste bei Server "raspberrypi" eingeben. Ob ich das vergeben habe und wann, weiß ich nicht mehr.
Über den Befehl "hostname" per SSH auf dem Pi ist das aber herauszufinden (für alle Anfänger wie mich!).
Die direkte IP mit dem Port hat nicht funktioniert. Keine Ahnung, ob das mit Pihole zusammen hängt.
@Joker:
Vielen Dank für diese coole Anwendung!!! Ich werde jetzt mit dem Einrichten all meiner Meldungen beginnen, aber es macht schon jetzt eine Menge Spaß!
Zitat von: Tobias am 14 Januar 2018, 15:41:50
Hi,
ich habe mal den sketch so erweitert, dass man 55 Einträge im Devicemapping machen kann um einen Speicherfehler zu provozieren. Ich habe alle 54 Einträge angelegt, aber keinen ESP-Absturz oder sonstige Auffälligkeiten festgestellt.
@Joker: inwiefern hat sich die Speicherproblematik gezeigt??
Die Speicherproblematik hat sich insbesondere beim Konfigurieren über die Webseite gezeigt. Also Einträge hinzufügen, Weglöschen, ändern, etc. und das öfter hintereinander. Irgendwann war es dann so, dass der Speicher (im Log "Free RAM") beim Aufrufen einer Seite weniger wurde. Der freie Speicher sollte eigentlich beim erneuten Aufrufen einer Seite immer gleich sein. Dann kommt es dazu dass die Webseite nicht mehr vollständig dargestellt werden kann und irgendwann das Config-File korrupt ist.
Zitat von: Tobias am 19 Januar 2018, 11:44:32
machmal kommt es vor das alle definierten LEDs in allen mögliche Farben mit 100% Helligkeit aufblitzen. Wie ein Regenbogengewitter , alle LEDs gleichzeitig isn derselben Farbe.
Kennt das jemand? Ich habe keine Ahnung wo ich suchen soll.
Ich habe den Elko und den Widerstand (510 Ohm) drin.
In einem Kommentar auf meiner Webseite hat ein User dieses Verhalten ebenso beschrieben, oder zumindest ähnlich: Er schrieb, es blitzen ca. 1x pro Stunde alle definierten LEDs einmal kurz mit voller Helligkeit auf. Wir hatten uns darüber eine Zeitlang per Mail ausgetauscht, aber ich habe leider keine Ahnung was die Ursache sein kann. Ich vermute ein elektrisches Problem, denn in der Software wüßte ich keinen Grund was dazu führen kann. Ich selber konnte das bei mir noch nie beobachten. Wenn es dazu irgendwelche Erkentnisse gibt bin ich sehr interessiert daran :)
Ist das Blitzen bei dir auch 1x oder dauerhaft?
@Jogi:
Freut mich dass es soweit funktioniert. Warum es in deinem Fall per IP nicht funktioniert, kann ich nicht sagen. Prinzipiell funktioniert beides. Es muss nur die IP-Adresse ohne Port eingegeben werden. Als Port wird immer 1883 genommen.
Das blitzen tritt mal gehäuft, mal immer nur einmal aus. Mal einmal pro Stunde, mal einmal pro 10 min.
Trenne ich den Daten Pin vom esp, leuchtet es stabil.
Es tritt auch mal auf, das auf einmal alle LEDs rot sind und rot bleiben, dann hilft nur noch ein Reset
Gesendet von meinem Leap mit Tapatalk
Hm. Gute Frage was da los ist. Was für ein Netzteil verwendest du? Ich kann mir da beim besten Willen kein Software Problem vorstellen.
Das andere, wenn alle LEDs rot sind bedeutet eigentlich dass die Verbindung zum WLAN nicht aufgebaut werden kann bzw. verloren ist. Das müsstest du dann aber in den Logausgaben sehen (sofern am PC angeschlossen) bzw. auch an deinem Router.
Ich glaube auch nicht das der efste Fall ein Software Problem ist, allerdings weiß ich no h nicht wo ich hardwareseitig du hin soll. Ich benutze ein 1,5A schaltnetzteil auf 5V, habe 54 LEDs die mit 20% Leistung laufen
Nur das der WLAN reconnect nicht funktioniert macht mich stutzig
Gesendet von meinem Leap mit Tapatalk
Das mit dem WLAN Reconnect ist merkwürdig. Bei mir eben nach ca 1h ist wieder alles rot, ein AP wurde aufgemacht. Natürlich hängt mein PC nicht an der seriellen SST um ds Log zu sehen :(
BEi Euch funktioniert grundsätzlich ein Reconnect? Steigt der ESP öfters mal aus dem WLAN aus?
Ja also bei mir funktioniert das Reconnect. Dass der ESP öfters mal aussteigt kann ich jetzt nicht sagen... wäre mir zumindest noch nie aufgefallen.
warscheinlich habe ich die Lösung gefunden, zumindest thoretisch, praktisch steht der test noch aus. Die WS2812b benötigen als Datenspannung mindestens 0.7*VCC, das sind 3.5V. Mit 3.3V wird es schon zu eng. Zumindest wurde in verschiedenen Beiträgen von meinen Flackerproblemem berichtet wenn kein LevelShifter dranhängt.
Warscheinlich scheint es nur von minimalen Faktoren abzuhängen dass eurer stripes zufällig funktionieren und andere nicht... Ich besorg mir jetzt einen Levelshifter und dann muss ich weiter testen
Interessant, das war mir tatsächlich so nicht bewußt. Leider findet man da ohne Ende Beispiele dafür wo das ohne Shifter gemacht wird und blöderweise auch noch funktioniert ;D
Also wenn es sich herausstellt dass dies das Problem behebt werde ich das mindestens in die Doku aufnehmen mit dringender Empfehlung Levelshifter einzubauen. Interessanterweise tritt das Problem nur bei sehr wenigen auf (mir sind aktuell nur du und noch ein User bekannt, ich habe dem gegenüber aber unzählige Rückmeldungen von Usern die keine Probleme haben).
Antwort: Der LevelShifter hilft 100%. ICh habe den von Adafruit empfohlenen Levelshifter verbaut: TXS0108E 8 Kanal Pegelwandler bidirektional Logic Level Converter I2C TTL SPI
Jetzt ist die Anzeige ENDLICH stabil!!
Coole Sache!
Danke für deinen Test und das Feedback.
Wie genau hast du den LevelShifter verbaut?
- Vcca = 3.3V vom wemos
- Vccb = 5V vom wemos
- A1 = output vom wemos
- B1 = data vom Stripe
- Oe = Vcca
?
Korrekt, plus GND natürlich.
Ich habe keinen Wemos sondern eine normalen ESP8266 NodeMCU. Hatte ich rumliegen von einem anderen Projekt als Ausschuss und konnte ich hier wiederverwenden
Ich habe jetzt nur noch das Problem das ca alle 6h alle LEDs rot leuchten - also WLAN Connect verloren. Nach ca 1,5h wird wieder automatisch in den normalen Modus zurück gewechselt. Schaue ich dann auf die Status-Page, wird mir eine Uptime ab dem Reconnect angezeigt.
Ich denke das ist nicht normal, oder?
Edit: so nach ca 160min uptime passierte es wieder :( hier mal das Log
WiFi connection lost.
Starting Wifi connection to MySSID...
Uptime: 164min
Uptime: 165min
Failed to connect WiFi.
Starting access point.
Error starting access point.
Starting access point.
AccessPoint SSID is StatusDisplay
IP: 192.168.4.1
Uptime: 166min
Uptime: 167min
Uptime: 168min
Uptime: 169min
Uptime: 170min
Uptime: 171min
Uptime: 172min
Uptime: 173min
Uptime: 174min
Uptime: 175min
Uptime: 176min
Uptime: 177min
Uptime: 178min
Uptime: 179min
Uptime: 180min
Uptime: 181min
Uptime: 182min
Uptime: 183min
Uptime: 184min
Uptime: 185min
Uptime: 186min
Uptime: 187min
Uptime: 188min
Exception (0):
epc1=0x2f7bf895 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: sys
sp: 3ffffb60 end: 3fffffb0 offset: 01a0
>>>stack>>>
3ffffd00: 0000002a 3fff1428 3fff1adc 401043d1
3ffffd10: 3fff58ec 40104456 3fff18b4 00000000
3ffffd20: 00000032 0000001c 3fff584c 3fff145d
3ffffd30: 3fff1428 3fff1428 3fff58ec 4010453d
3ffffd40: 4021c72f 3fff58ec 3fff5922 4021c738
3ffffd50: 00000608 3ffe9c2e 000000e4 02004010
3ffffd60: 00000000 3fff562c 00000050 3fff145d
3ffffd70: 3fff5930 00000000 3fff58ec 40222257
3ffffd80: 3fff1428 3fff145d 3ffe9c2e 3ffe9c28
3ffffd90: 00000001 3ffeda50 00000000 4000050c
3ffffda0: 00007fff 90b11b9c 3ffee460 3fff12cc
3ffffdb0: 3fff1428 00000001 3fff584c 40222442
3ffffdc0: 3fffff30 00000001 4024c370 3fff589c
3ffffdd0: 3fff1428 3fffff30 3fff584c 402225f5
3ffffde0: 00000002 00000000 00000001 3fff57c2
3ffffdf0: 00000000 00000000 40235907 3fff589c
3ffffe00: 3fff584c 3fffff30 3fff1428 402227c0
3ffffe10: 3ffe0000 401042c3 3ffeda78 3ffeaf4a
3ffffe20: 00000014 3fffff30 3fff584c 40223158
3ffffe30: 0000000c 00000000 00000020 40100ec6
3ffffe40: 3fff142c 000000ff 00000000 00000011
3ffffe50: 3fff13c8 00000004 40000f68 00000000
3ffffe60: 00000011 00000001 00000000 3fff584c
3ffffe70: 3fffff30 3fff58b0 3fff194c 402231e6
3ffffe80: 3fff1428 00000000 00000000 402238bb
3ffffe90: 00000000 00000000 0000001f 4021fdc7
3ffffea0: 3fff1428 3fff4c62 3ffea161 402237e0
3ffffeb0: 3fff584c 3fff1428 3fff142c 0000007b
3ffffec0: 0000005a 00000030 3fff13d4 401004d8
3ffffed0: 3fff191c 402012dc 00000000 3fff1084
3ffffee0: 3fffff30 0000007b 3fff194c 4021fe34
3ffffef0: fffffffc 3fffdcb0 3ffef2b0 4021fea8
3fffff00: 3fff584c 3fffff30 0000007e 3fff1084
3fffff10: 3fffff30 3fff58b8 3fff584c 4022360b
3fffff20: 40223640 3fff1088 3fff13d4 4022367c
3fffff30: 010aa8c0 3fff1088 3ffe9cb4 4021c7fa
3fffff40: 40104d8b d2639b26 0000001e 4021d844
3fffff50: 00000000 3ffe9e24 d2639b26 00000000
3fffff60: 4023bcb0 3ffef268 3ffef290 60000600
3fffff70: a1401723 3ffef290 3ffef268 4023bcbd
3fffff80: 4023bd02 3fffdab0 00000000 3fffdcb0
3fffff90: 3ffef2a0 3fffdad0 3ffeffd8 4021420f
3fffffa0: 40000f49 40000f49 3fffdab0 40000f49
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld
Initializing config.
Mounted file system.
Reading config file /config.json
File size is 331 bytes
Main config data successfully parsed.
JSON length is 331
[...]
Ich denke das Problem ist u.a., wenn der erste Reconnect fehlschlägt, warum auch immer, wird der accesspoint aufgemacht und nicht weiter versucht sich ans Wifi zu connecten. Warum dann eine Exeption auftritt und den ESP zum Reboot zwingt weiß ich auch nicht...
Habe jetzt in der wifi.cpp den Aufruf "createAccesspoint()" gegen ein ESP.restart() ausgetauscht. Damit hab ich zwar das Wifi-connectionLost Problem nicht gelöst, aber das Display arbeitet jetzt wie gewünscht :)
Hatte mal weiter geforscht, wenn die Wifi Connection verloren ging, hat der ESP es auch nach Stunden nicht hinbekomen die WLAN Verbindung neu aufzubauen. Da hilf nur ein Restart. Hatte testweise den createAP() Aufruf gelöscht damit er permanent versucht sich ins WLAN wieder neu einzuloggen - ohne Erfolg
Mich wundert es nur das es bei Euch funktioniert :(
Edit: Hatte das Phänomen bei meinen ESP32 auch, das musste aber ein Bug im core gewesen sein, habe die lib aktualisert und schon funktionierte ein reconnect. Hier beim ESP8266 hat ein update leider nicht geholfen....
Zitat von: Tobias am 05 Februar 2018, 19:47:32
Mich wundert es nur das es bei Euch funktioniert :(
Du bist nicht alleine.
Bei mir geht das Display auch unregelmäßig in den "roten" Zustand. Irgendwann fängt es sich dann wieder, oder ich muss es neu starten.
Ich weiß nicht genau, woran es liegt und teste mal einen anderen Wlan-Zugang.
Wenn das nicht funktioniert werde ich Deinen Tipp ausprobieren:
Zitat von: Tobias am 05 Februar 2018, 19:47:32
Habe jetzt in der wifi.cpp den Aufruf "createAccesspoint()" gegen ein ESP.restart() ausgetauscht.
Hi jogi, das "irgendwann fängt es sich wieder" war bei mir auch, das war aber ein restart des esp durch einen Kernel error hervorgerufen.
Habe ich auch nur rausbekommen weil ich mein Laptop mal einen Tag an der seriellen Schnittstelle hab mitlaufen lassen ;)
Mit welcher ESP code lib arbeitest du? Ich habe die 2.4.0
Mich würde es interessieren mit welcher Version der lib der Sketch kompiliert wurde der keine derartigen Probleme hat
Gesendet von meinem Leap mit Tapatalk
Hi Bernd,
neben den Anmerkungen zu Deiner tollen Anleitung auf deiner Homepage, die ich in den Kommentaren hinterlassen habe, habe ich noch weitere Anmerkungen und Fragen zum Display an sich. Aufgrund der besseren Interaktion komme ich mal damit hierher, ggf. kann ja den beschriebenen Fehler ja auch mal noch jemand anderes bei sich prüfen, nicht dass der aus irgendwelchen Gründen nur bei mir auftritt.
Mein Display zeigt in der Access Point Funktion ein Verhalten was ich so nicht erwarte und welches ich auch Nachvollziehen bzw. Nachstellen kann. Nach der "Erstinstallation" auf dem Wemos wird ja der AP aufgemacht, damit man sich einloggen und seine Einstellungen vornehmen kann. Zum Zeitpunkt meiner Erstinbetriebnahme hatte ich mein WiFi nicht in der Nähe, weswegen ich erstmal nur die LED Anzahl und den Datenpin eingerichtet habe, dann die Einstellungen abgespeichert habe und mich als ersten Erfolg daran erfreut habe, dass alle LEDs rot leuchten. Als ich dann bei meinem WiFi war, hab ich das Display wieder angesteckt, auf den AP gewartet, mich mit diesem verbunden, aber noch bevor ich die richtigen WiFi Einstellungen eintragen konnte war der AP nach wenigen Sekunden wieder zu und die Verbindung getrennt. Egal womit ich mich verbunden habe, Smartphone, Laptop, immer wurde der AP binnen weniger Sekunden nach dem Einloggen wieder geschlossen. In meiner Verzweiflung habe ich den ESP dann wieder komplett gelöscht und neu bespielt. Hier habe ich erstmal ohne jegliche Einstellungen einige Male neu gestartet, und immer konnte ich mich problemlos auf den AP einloggen und blieb auch drin. Sobald ich aber irgendwelche ,,General" Einstellungen abgespeichert habe, ohne dabei die Richtigen WiFi Einstellungen mit drin zu haben, trat bereits erwähntes Phänomen auf. Im dritten Anlauf habe ich dann gleich als Erstes die korrekten WiFi Einstellungen mit eingetragen und die Verbindung wurde korrekt aufgebaut. Wenn ich jetzt allerdings das Display testweise mal an einem Punkt starte, an dem mein eingerichtetes WiFi nicht erreichbar ist, habe ich wieder das Problem! Ich würde hier erwarten, dass in dem Fall dass immer wenn mit den abgespeicherten Daten keine WiFi Verbindung hergestellt werden kann, der AP sauber läuft.
So wie ich das Ganze derzeit interpretiere, sperrt man sich selbst aus wenn man beim ersten Save der General Configuration keine oder falsche SSID/Password Eingaben abspeichert. Ggf. sollte man hier mal Ursachenforschung betreiben, da falsche Eingaben schnell mal abgespeichert sind.
Ein anderes Thema betrifft meine eigene Netzwerkordnung. Ich habe meinen heimischen IP Bereich nach ,,Themengebieten" (Netzwerk Infrastruktur, feste PC's, Home Entertainment, Heimautomatisierung, Überwachungstechnik, DHCP) aufgeteilt und verteile bei mir, außer bei mobilen Endgeräten, grundsätzlich nur feste IPs. Aus diesem Grund, du kannst es Dir sicher denken, sollen auch die geplanten Displays alle ihre feste IP erhalten, und das Geräteseitig. Für's Erste hab ich mir schon selbst geholfen, in dem ich die HSDWifi.cpp entsprechend modifiziert habe.
if(m_numConnectRetriesDone == 0)
{
Serial.print(F("Starting Wifi connection to "));
Serial.print(m_config.getWifiSSID());
Serial.println(F("..."));
// NETWORK: Static IP details...
IPAddress ip(192, 168, x, x);
IPAddress gateway(192, 168, x, x);
IPAddress subnet(255, 255, x, x);
WiFi.config(ip, gateway, subnet);
WiFi.mode(WIFI_STA);
WiFi.begin(m_config.getWifiSSID(), m_config.getWifiPSK());
m_numConnectRetriesDone++;
}
Für die Ersteinrichtung ist das nur ein minimaler Aufwand, aber bei einem bei einem Upgrade auf eine neue Version wäre eine Möglichkeit in der General Configuration zwischen automatischer IP Vergabe und fester IP zu wählen die schönere Lösung. Meinst Du das wäre ggf. implementierbar?
Und noch ein Thema, womit ich aber sicher ziemlich allein dastehe, was aber sehr schön wäre, wäre das anlegen von zwei WiFi Zugängen. Ich hab bei mir zwei AP's und zwei SSIDs. Aktuell muss ich das Display je nach Einsaztzort auf eine SSID einrichten und vor dem Versetzen an einen anderen Ort anpassen. Ansonsten sperre ich mich ja wegen zuerst genanntem Problem wieder aus. Luxus wäre hier eine Grundeinrichtung auf beide SSIDs damit ich das Display jederzeit überall daheim in Betrieb setzen kann.
MfG
Marco
Hi Marco,
wow was für ein langer Text :D
Aber es ist wirklich sinnvoller dies hier zu besprechen, denn die Kommentarfunktion bei mir auf der Homepage ist sehr unübersichtlich.
1. Thema AP
Die Funktion soll so sein, dass nach einer bestimmten Zeit, in der das eingestellte Wifi nicht erreichbar ist, ein AP aufgemacht wird unter der das Display erreichbar ist. Das funktioniert bei mir soweit auch stabil. Dass der AP von selbst wieder zugemacht wird hatte ich bisher noch nicht, müsste man mal untersuchen. Leider kann ich das bei mir so nicht reproduzieren :-(
Generell hat das implementierte Verhalten folgenden Nachteil: Wenn das konfigurierte WLAN mal eine Zeitlang ausfällt, so dass der AP aufgemacht wird, dann erfolgt keine automatische Verbindung mehr zu dem WLAN wenn es wieder auftaucht. Ist mir neulich erst passiert als ich ein Firmwareupdate der Fritzbox gemacht habe. Man muss das Display dann vom Strom trennen. Vielleicht wäre es generell besser dies anders zu lösen. Man bräuchte aber immer eine Fallback-Strategie, wenn man falsche WLAN-Daten eingegeben hat, dass man die wieder korrigieren kann.
2. Thema IP-Adressen
Was ist der Grund dass du dies geräteseitig lösen möchtest? Ich habe bei mir in der Fritzbox bei fast allen Geräten "immer die gleiche IP-Adresse zuweisen" aktiviert. Das hat aus meiner Sicht den Vorteil, dass man keine Konflikte bekommen kann (da DHCP), und man zentral an der Fritzbox Änderungen vornehmen kann wenn man eine andere IP-Adresse nutzen möchte. Fest eingestellte IP-Adressen sehe ich persönlich als sehr unschön an. Implementieren könnte man das natürlich.
Generell ist es so (betrifft auch das Thema zwei Wifi-Zugänge): Implementieren kann man so ziemlich alles. Allerdings kann ich manche Dinge gar nicht ordentlich testen (z.B. habe ich keine zwei SSIDs), und kann daher nicht guten Gewissens eine Lösung liefern. Meine Zeit für das Thema ist, wie man auch hier im Verlauf des Threads sehen kann, ziemlich eingeschränkt. Prinzipiell habe ich das Display für mich entwickelt und es online gestellt mit der Hoffnung dass andere es ebenso brauchen können- was ja offensichtlich auch der Fall ist und mich sehr freut.
Ich versuche so gut es geht bei Problemen zu helfen, aber ich kann leider keine größere Entwicklungszeit in Dinge stecken, die ich selber nicht brauchen und/oder testen kann. Ich bin aber offen für jegliche Weiterentwicklungen die von jemand anders kommen, idealerweise in Form von Pull Requests. Wenn jemand was bestimmtes implementieren möchte kann ich auch gern Unterstützung in der Form leisten, Hilfe zu geben wo und wie im Code dies am besten umsetzbar wäre.
Das Problem mit dem AP hatte ich auch. Beim ersten mal kann man drauf, dann nicht mehr. Sobald man sich verbindet schließt sich der AP.
Habs mit 2x Flashen hinbekommen und so läuft es jetzt, muss nix mehr dran ändern. :)
Das mit dem nicht mehr funktionierendem Reconnect wenn Wifi mal länger weg ist habe ich mit einer Codeänderung hinbekommen, siehe ein paar postings voher. Einfach statt CreateAccesspoint() ein ESP.restart() eintragen. Funktioniert natürlich nur wenn das Wifi in einer endlichen ZEit wiederkommt, sonst hat man eine Bootschleife und es wird auch kein AP für neue WifiDaten aufgemacht.
Zitat von: Tobias am 23 Februar 2018, 13:40:55
Das mit dem nicht mehr funktionierendem Reconnect wenn Wifi mal länger weg ist habe ich mit einer Codeänderung hinbekommen, siehe ein paar postings voher. Einfach statt CreateAccesspoint() ein ESP.restart() eintragen. Funktioniert natürlich nur wenn das Wifi in einer endlichen ZEit wiederkommt, sonst hat man eine Bootschleife und es wird auch kein AP für neue WifiDaten aufgemacht.
Ja als Workaround geht das natürlich- aber auch nur wenn die Daten des Wifi korrekt sind. Hat man aus Versehen falsche Daten eingegeben, kommt man ohne neu Flashen so nicht mehr drauf...
Hi,
Zitat von: Joker am 23 Februar 2018, 12:33:021. Thema AP
Die Funktion soll so sein, dass nach einer bestimmten Zeit, in der das eingestellte Wifi nicht erreichbar ist, ein AP aufgemacht wird unter der das Display erreichbar ist. Das funktioniert bei mir soweit auch stabil. Dass der AP von selbst wieder zugemacht wird hatte ich bisher noch nicht, müsste man mal untersuchen. Leider kann ich das bei mir so nicht reproduzieren :-(
Wie gesagt, dass passiert erst nach einem connect. Solange man sich nicht verbindet sieht man ihn (hab nicht beobachtet ob da ein Timeout drin ist, aber 5-10 Min hab ich den mindestens gesehen vor dem Connect).
ZitatWas ist der Grund dass du dies geräteseitig lösen möchtest? Ich habe bei mir in der Fritzbox bei fast allen Geräten "immer die gleiche IP-Adresse zuweisen" aktiviert. Das hat aus meiner Sicht den Vorteil, dass man keine Konflikte bekommen kann (da DHCP), und man zentral an der Fritzbox Änderungen vornehmen kann wenn man eine andere IP-Adresse nutzen möchte. Fest eingestellte IP-Adressen sehe ich persönlich als sehr unschön an. Implementieren könnte man das natürlich.
Für nicht ortsveränderliche Hardware die fest in einem Netz ist kenne ich es nicht anders. Ich betreue dienstlich Anlagen mit teilweise mehreren Hundert IP Clients in einem Netz und da gibt es keinen DHCP. Da wird sich Gedanken gemacht welches Gerät welche IP bekommt und wenn man sich an die Vorgaben hält gibt es auch keine Adresskonflikte. Und das ziehe ich auch daheim durch. Da weiß ich anhand der IP sofort aus welchem Bereich ein Gerät stammt und kann mir auch leicher merken mit welcher IP ich welches Gerät erreiche. Und bei einem Hardwaretauch aufgrund defekt oder einfach Erneuerung bekommt das neue Gerät wieder die IP die für den Standort geplant ist, und sofort klappen wieder alle ohne dass noch irgendwas umkonfiguriert werden muss.
ZitatIch versuche so gut es geht bei Problemen zu helfen, aber ich kann leider keine größere Entwicklungszeit in Dinge stecken, die ich selber nicht brauchen und/oder testen kann. Ich bin aber offen für jegliche Weiterentwicklungen die von jemand anders kommen, idealerweise in Form von Pull Requests. Wenn jemand was bestimmtes implementieren möchte kann ich auch gern Unterstützung in der Form leisten, Hilfe zu geben wo und wie im Code dies am besten umsetzbar wäre.
Ja, daran habe ich auch schon gedacht, würde ich auch durchaus gern machen, nur muss ich dazu erstmal einen Einstieg in das Thema Arduino/ESP und co finden. Meine letzten, etwas erweiterten, Programmierarbeiten waren vor etwa 20 Jahren mit Object Pascal und dann vor einigen Jahren nochmal ein Programm in C++. Auf das erste drüber schauen kann ich mir zwar vieles zusammenreimen was in dem Code passiert, für die feste IP hat es dank Google auch gereicht, aber dann hört es im Moment leider auch schon auf. :-\
MfG,
Marco
Hi zusammen,
ich habe auch das Problem, dass nach unregelmäßiger Zeit meine Display LED's nur noch gelb blinken...
Habe deshalb versucht den Tipp von Tobias umzusetzen und den Aufruf "createAccesspoint()" gegen ein "ESP.restart()" zu tauschen. Leider habe ich irgendwie ein Brett vorm Kopf :-[
Ich finde schon die wifi.cpp Datei überhaupt nicht - hab nur die HSDWifi.cpp Datei :o
Kann mir jemand sagen wo mein Denkfehler liegt...
Danke und Gruß
Firetic
Mein Tipp nicht als copy&paste sehen, war aus dem Kopf heraus
Wifi.cpp = hsdwifi.cpp
Gesendet von meinem Leap mit Tapatalk
Hi,
wird hier noch entwickelt? Oder ist die Software jetzt rund? Bspw Erweitern auf ESP32 für mehr LEDs
Mit dem Reboot Fix läuft meine Anzeige jetzt stabil ohne das ich manuell eingreifen muss. :)
Zitat von: Tobias am 01 August 2018, 15:07:28
Hi,
wird hier noch entwickelt? Oder ist die Software jetzt rund? Bspw Erweitern auf ESP32 für mehr LEDs
Mit dem Reboot Fix läuft meine Anzeige jetzt stabil ohne das ich manuell eingreifen muss. :)
Hi,
also ich selbst arbeite aktuell nicht an der Firmware. Wie gesagt habe ich bei mir keinerlei Probleme mit einem Verlust der Verbindung- daher aktuell auch keine Idee woran das liegen könnte.
Wenn das mit dem ESP.restart soweit funktioniert ist das OK, aber das ist ja ein Workaround und kein Fix. Das Problem hatte ich ja oben schon mal beschrieben, wenn man die Wifi-Daten falsch eingibt, dann wird mit dieser Änderung kein AP mehr aufgemacht und man kommt nie mehr ins Netz (außer neu flashen natürlich). Daher kann ich das nicht "offiziell" so ändern.
Was sonstige Änderungen/Erweiterungen angeht wie schon oben gesagt- Pull Requests nehme ich gerne entgegen und kümmere mich um die Integration, aber selber plane ich aktuell keine Arbeiten an der Software (ich habe zwar noch einige Ideen, aber da ich nicht weiß ob und wann ich diese umsetzen kann, kündige ich da auch nichts an...).
Hi,
ich habe nun seit einigen Monaten zwei Displays mit komplett gleichem Aufbau im Einsatz und muss sagen, 100% stabil laufen sie bei mir nicht.
Zum Einen legen die Displays hier und da von allein Restarts hin, was ich nur daran erkenne dass ich im Augenwinkel sehe wie kurz mal alles gelb aufleuchtet. Auch anhand der Weboberfläche sehe ich, dass die Uptime seit dem letzten Reboot immer sehr übersichtlich ist. Manchmal sind diese Reboots schon nach wenigen Stunden, manchmal auch erst nach einigen Tage - ich glaube die höchste Uptime die ich jemals sah lag bei 15 Tagen. Ein System habe ich hierbei nicht entdecken können, zumal meine Displays bei den Uptimes auch völlig unterschiedlich laufen.
Des Weiteren passiert es immer mal wieder, dass die Displays ihre Verbindung zum MQTT verlieren und dann alles gelb leuchtet. Aus dem Zustand gibt es bisher auch nur einen Weg zurück - manueller Reboot. Da dies häufiger nur eines der Displays betrifft glaube ich nicht dass hier wirklich der MQTT Server weg war, denn dann wären ja beide betroffen.
Und wenn der MQTT mal wirklich weg war, z.B. weil ich den RasPi mal komplett neu durchgestartet habe, schaffen es die Displays aus nicht die Verbindung von allein herzustellen - hier muss auch immer ein manueller Reboot durchgeführt werden.
Leider fehlt mir bisher die Zeit mich mal zu versuchen in den Quellcode einzulesen. :'(
MfG
Marco
Das Problem wenn man das mit der Arduino IDE baut ist halt aus meiner Sicht auch das, dass man nicht vorschreiben kann, welche Version der abhängigen Bibliotheken benutzt werden soll.
Es gibt ja durchaus auch darin Bugs in Richtung Verbindungsabbrüche, siehe z.B. hier (https://github.com/esp8266/Arduino/issues/4166) oder hier (https://github.com/knolleary/pubsubclient/issues/395).
Damit will ich NICHT sagen dass das Problem nicht an meinem Code liegt, sondern jeder verwendet vermutlich eine andere Version der jeweiligen Libraries und somit ist auch ein unterschiedliches Verhalten möglich - und damit teilweise extrem schwer nachzuvollziehen.
Was die Verbindung zum MQTT angeht- ja, der Code ist da nicht optimal. Ich habe damals mit Absicht eingebaut, das der Verbindungsaufbau zum MQTT 3x im Abstand vom 5s probiert werden soll, dann nicht mehr. Soll heißen, ist der Server länger als 15s weg, bleibt es für alle Zeit auf "alles gelb". Der Grund war, wenn ich mich recht erinnere, dass es da Probleme gab, dass die MQTT-Library ansonsten den restlichen Sketch blockiert hat, d.h. z.B. auch die Webseite dann nicht mehr erreichbar war. So ganz nachvollziehen kann ich das aktuell leider nicht, müsste ich mich auch wieder reinfuchsen- wollte nur sagen, ja, das Problem kenne ich ;)
Wer da mal dran rumspielen will: HSDMqttt.cpp -> void HSDMqtt::handle()
Interessant ist aber natürlich auch die Frage, wieso wird die Verbindung zum MQTT überhaupt "einfach so" mal verloren (wenn man jetzt nicht gerade den Server durchstartet)...
Hi Joker,
falls du mal Zeit hast wäre es super wenn du den Sketch auf eine Anzahl maximaler Einträge auf 55 änderst und ein fertiges "bin" file bei dir im git ablegst. (mit 55 funktioniert es sauber bei mir)
Diese Wifi Abbrüche denke ich mal kommen von der eingesetzten ESP Git Version. Es gibt issues die berichten solches Verhalten. Du scheinst Glück zu haben eine VErsion abbekommen zu haben die keine Abbrüche hat :)
Da ich gerade am Bauen bin: Die Levelshifterproblematik kann man laut Hackaday (https://hackaday.com/2017/01/20/cheating-at-5v-ws2812-control-to-use-a-3-3v-data-line/) mit nur einer Diode lösen...
Aber das kapiere ich jetzt nicht:
Provisorisch nutze ich den in FHEM definierten MQTT-Broker zum Senden, bspw.
set myBroker publish fhem/cmd/statusdisplay_01/test 2
worauf tatsächlich die LEDs 11-21 grün geschaltet werden.
Ich habe in "General" als "Status topic" wie vorgeschlagen "fhem/status/#", als einen möglichen Kanal "fhemhealth Light 1" (also als Light-Gerät auf die LED 1) und als Colormapping "on Light (white) On" (statisch weißes Licht, wenn "on" für "Light"empfangen...?)
Nun interpretiere ich das so, dass ein gesendeter Befehl
set myBroker publish fhem/status/fhemhealth on
die LED 1 weiß einschalten sollte. Der Mosquitto auf Betriebssystem zeigt auf Betriebssystemebene
Client mosqsub|8538-raspberryp received PUBLISH (d0, q0, r0, m0, 'fhem/status/fhemhealth', ... (2 bytes))
fhem/status/fhemhealth on
Es tut sich aber ... nichts. Warum?
P.S.: meine OBI-Steckdose kann ich mit dem topic aus dem publishSet einwandfrei schalten: set myBroker publish cmnd/SmartHome/mobile/OBIplug1/POWER ON
Hi,
der Befehl muss in deinem Beispiel so aussehen:
set myBroker publish fhem/status/light/fhemhealth on
ach ... da kommt doch meine sig wieder zu Ehren. ;D
Erschließt sich nicht logisch. Würde gleichnamige Devices in unterschiedlichen Gruppen (light/alarm/door/window) ermöglichen, aber wozu?
Danke für die Augenöffnung. Dann kann's ja endlich losgehen...
ach noch ein Nachtrag: im Gegensatz zum ct-Projekt ist Dein Sketch ad hoc sauber durchkompiliert worden. Dennoch gefällt mir an der Konkurrenz, dass man die LEDs einzeln dimmen kann. Dafür ist die Definition der Anzeigezuordnung in der Anzeige hier selbst irgendwie brilliant ...
Zitat von: Pfriemler am 30 August 2018, 22:59:40
ach ... da kommt doch meine sig wieder zu Ehren. ;D
Erschließt sich nicht logisch. Würde gleichnamige Devices in unterschiedlichen Gruppen (light/alarm/door/window) ermöglichen, aber wozu?
Mein Gedanke war damals, dass man die Devices allgemeiner benennen kann, also z.B. "kitchen", und dann eben über die Topics "/light/kitchen" oder "/window/kitchen" bestimmen kann was man eigentlich meint. Im Prinzip das was du sagst, also gleichnamige Devices. Das hat sich tatsächlich als nicht so sinnvoll erwiesen, weil man ja mehrere Lichter in einem Raum haben kann und diese dann sowieso anders nennt, z.B. "kitchen_ceiling". Aber was mit der Gruppierung möglich ist, ist dass man z.B. mit dem Topic "/light/+" alle Lichter ansprechen kann.
Zitatach noch ein Nachtrag: im Gegensatz zum ct-Projekt ist Dein Sketch ad hoc sauber durchkompiliert worden. Dennoch gefällt mir an der Konkurrenz, dass man die LEDs einzeln dimmen kann. Dafür ist die Definition der Anzeigezuordnung in der Anzeige hier selbst irgendwie brilliant ...
Ja, also im Prinzip ist die Philosophie von dem ct-Projekt anders: Man sagt dem Display explizit was es tun soll, also "setze led 5 auf hellblau". In meiner Variante sage ich dem Display "fenster küche wurde geöffnet", und das Display weiß durch die Konfiguration wie es darauf reagieren soll. Hat beides sicher seine Vor- und Nachteile. In meiner Variante könnte sich auch jemand ganz anderes (ein anderer mqtt-client) noch für "fenster küche wurde geöffnet" interessieren und damit was ganz anderes machen (z.B. einen Alarm senden oder sonstiges).
Was ich charmant am Code von der ct finde, ist dass es mit mehreren Tasks umgesetzt wurde. Damit muss ich mich mal beschäftigen, das macht das ganze übersichtlicher.
Zum Thema Dimmen: Ich habe mich am Anfang explizit dafür entschieden, dass man nicht beliebige Farb- bzw. Helligkeitswerte setzen kann, sondern eine Handvoll gängiger Werte einfach im Display hinterlegt sind. Ich wollte eben nicht zig verschieden Farb- und Helligkeitsvarianten haben. Was wäre denn der Anwendungsfall für dieses dimmen, ich sehe aktuell nicht wozu man das brauchen könnte?
Zitat von: Joker am 31 August 2018, 09:58:19
1. ... und dann eben über die Topics "/light/kitchen" oder "/window/kitchen" bestimmen kann was man eigentlich meint.
2. ... Aber was mit der Gruppierung möglich ist, ist dass man z.B. mit dem Topic "/light/+" alle Lichter ansprechen kann.
3. ... Ja, also im Prinzip ist die Philosophie von dem ct-Projekt anders ... "setze led 5 auf hellblau" ... / In meiner Variante ... "fenster küche wurde geöffnet" ... Hat beides sicher seine Vor- und Nachteile.
4. Was ich charmant am Code von der ct finde, ist dass es mit mehreren Tasks umgesetzt wurde. Damit muss ich mich mal beschäftigen, das macht das ganze übersichtlicher.
5. ... nicht beliebige Farb- bzw. Helligkeitswerte setzen ... Was wäre denn der Anwendungsfall für dieses dimmen... ?
zu 1. Klingt erst mal sinnvoll. Aber aus FHEM ist es praktischer, die Geräte mehr oder weniger direkt zu mappen, und da heißen sie sowieso unterschiedlich. Das zusätzliche topic stört aber auch nicht - wenn ich etwa ein Notify auf alle meine "FK_.*" = Fensterkontakte baue, kann ich - wenn meine Kontakte in FHEM genauso wie in HomeStatusDisplay heißen - das 1:1 übermitteln - und auch "window/" davor schreiben. Anders sieht das aus, wenn ich die Regex für das Notify weiter fassen könnte, um etwa auch alle Lampen und den Alarmanlagenzustand zu erfassen - dafür bräuchte ich dann jeweils ein weiteres Notify, wenn ich nicht noch zusätzliche if-Schachteln da einbauen will. Geht aber auch.
Und wenn man diese neuere MQTT_Bridge einbaut (habe da erst kurz was quergelesen), hinterlegt man bei den Devices ohnehin den zu übermittelnden MQTT-Topic.
zu 2. die Sache mag attraktiv klingen, aber warum sollte ich alle Anzeigelampen einer Gruppe auf einmal in einen besondren Zustand bringen wollen? Und für eine andere Sache sehe ich wiederum keine Anwendung hier. Mag sein, dass man aus FHEM mit diesem Topic eine Reihe
Geräte schalten kann (etwa alles Licht aus oder so), aber die Anzeigelampen sollten sich doch bitte nach dem echten Status der Geräte richten, dafür braucht es eh andere Mechanismen. Alternativ könnte man den Topic auch direkt bei der Gerätedefinition in HomeStatusDisplay anfügen. Dann wäre man vor allem flexibler in der Namensgebung, denn - ehrlich gesagt - sind mir die vier Kategorien deutlich zu wenig. Ich sende manches im light-topic, was gar kein light-topic ist (etwa den Füllgrad der Tonnen, den Schaltzustand der Steckdosen oder Temperaturwarnungen). Und wenn man die Topics dort variabler ablegen kann, kann man sie doch trotzdem mit Wildcards bedienen.
zu 3. ich sagte schon, was mir da besser gefällt :-)
zu 4. War mir neu, klingt interessant. Derzeit krieg ich das Scheißding gar nicht kompiliert. Liegt aber wohl an meiner Unordnung hier auf dem Rechner. Meine verschiedenen Projekte brauchen leider recht verschiedene Versionen der Libs.
zu 5. Unterscheidung von "Warn-" und "alles ok"-Meldungen. Meine Schaltsteckdosen haben in FHEM etwa ein hellgrünes "AN" und ein dunkelgraues "AUS" - und ein dunkelrotes "HELP", wenn es ein Problem gibt (etwa wenn die Tasmotasteckdosen offline sind). So würde ich die Alarmanlage auch im Ruhezustand als eine dunkle dezente Farbe melden ("alles ok") - das hat einen anderen informatorischen Wert als wenn die LED ganz aus ist. Um alles glimmende muss ich mich dann nicht kümmern, alles helle erfordert Aufmerksamkeit. Das springt auch optisch intuitiver. Jetzt hilft die Unterscheidung zwischen statisch und blinkend/blitzend ja schon auf diesem Gebiet ziemlich weiter. Nur ist Blinken lieber mein Ding, wenn es wirklich dringend ist.
Mir würde dabei reichen, wenn ich zu jeder Farbe im Colormapping einfach noch eine Helligkeit hinterlegen kann.
Andererseits kann ich bei der c't-Variante dann allerdings auch ein freies Colormapping machen - Füllstandsanzeigen von rot über gelb nach grün in 100 Schritten etwa. Wenn da die Werte leicht fluktuieren, fällt das nicht so sehr auf wie ein hartes Umschalten an einer Triggergrenze (rot-gelb oder gelb-grün). Habe das Problem aktuell bei einer per Ultraschall überwachten Tonne. Da muss man dann erst eine Hysterese einbauen, damit es nicht dauert umschaltet... Könnte man ja auch einfach lösen, indem man einfach einen Farbskalenwert an die LED als Zahl schickt und damit das Mapping außer Kraft setzt.
Zitat von: Pfriemler am 31 August 2018, 14:28:05
zu 2. die Sache mag attraktiv klingen, aber warum sollte ich alle Anzeigelampen einer Gruppe auf einmal in einen besondren Zustand bringen wollen? Und für eine andere Sache sehe ich wiederum keine Anwendung hier. Mag sein, dass man aus FHEM mit diesem Topic eine Reihe Geräte schalten kann (etwa alles Licht aus oder so), aber die Anzeigelampen sollten sich doch bitte nach dem echten Status der Geräte richten, dafür braucht es eh andere Mechanismen.
Ja natürlich! So meinte ich das auch,
schalten von Geräten, nicht mehrere Anzeigelampen in einen Zustand bringen.
Kann aber sein dass das nicht vollständig durchdacht ist, das Projekt habe ich ungefähr ne Woche nachdem ich das erste mal genauer gelesen habe was MQTT überhaupt ist gestartet ;D
ZitatAlternativ könnte man den Topic auch direkt bei der Gerätedefinition in HomeStatusDisplay anfügen. Dann wäre man vor allem flexibler in der Namensgebung, denn - ehrlich gesagt - sind mir die vier Kategorien deutlich zu wenig.
Ja könnte man natürlich machen- macht halt das auswerten der empfangenen Topics deutlich aufwändiger (jetzt weiß ich genau wieviele Ebenen ein relevantes Topic hat und welchen Aufbau es hat). Ich stimme aber zu, dass das die flexibelste Lösung wäre.
ZitatIch sende manches im light-topic, was gar kein light-topic ist (etwa den Füllgrad der Tonnen, den Schaltzustand der Steckdosen oder Temperaturwarnungen).
Die Alarm-Gruppe passt eigentlich für sehr vieles, gerade für irgendwelche Warnungen. Ich sende alles was nicht in eine andere Gruppe passt als Alarm.
Zitatzu 5. Unterscheidung von "Warn-" und "alles ok"-Meldungen. Meine Schaltsteckdosen haben in FHEM etwa ein hellgrünes "AN" und ein dunkelgraues "AUS" - und ein dunkelrotes "HELP", wenn es ein Problem gibt (etwa wenn die Tasmotasteckdosen offline sind). So würde ich die Alarmanlage auch im Ruhezustand als eine dunkle dezente Farbe melden ("alles ok") - das hat einen anderen informatorischen Wert als wenn die LED ganz aus ist. Um alles glimmende muss ich mich dann nicht kümmern, alles helle erfordert Aufmerksamkeit. Das springt auch optisch intuitiver. Jetzt hilft die Unterscheidung zwischen statisch und blinkend/blitzend ja schon auf diesem Gebiet ziemlich weiter. Nur ist Blinken lieber mein Ding, wenn es wirklich dringend ist.
Mir würde dabei reichen, wenn ich zu jeder Farbe im Colormapping einfach noch eine Helligkeit hinterlegen kann.
Nun ja, also da kommen wir sehr in persönliche Vorlieben rein.
Ich habe es bei mir so, dass im Initialzustand - also keine Fenster offen, kein Licht an, kein Alarm - alle LEDs aus sind. Es ist meiner Meinung nach deutlich einfacher mit einem Blick zu erkennen ob gar keine LED an ist, oder ob eine LED hell oder dunkel ist - aber wie gesagt, das ist vermutlich Geschmackssache.
Der Vollständigkeit halber mal die Zusammenfassung wie ich es gedacht habe und nutze:
- LED aus: Das Gerät ist im "Grundzustand", also ein Zustand der z.B. der Normalfall sein sollte wenn man das Haus verlässt (Licht aus, Fenster zu...)
- LED an: Gerät ist nicht mehr im Grundzustand, aber erfordert normalerweise auch keine spezielle Beachtung (z.B. ein Licht ist an oder ein Fenster geöffnet, nur eine Information)
- LED blinkt: Gerät ist in einem Zustand, der "besonders" ist und ggf. beachtet werden sollte (z.B. Fenster ist seit mehr als einer halben Stunde geöffnet, Unwetterwarnung liegt vor etc.)
- LED flackert: Gerät ist in einem Zustand der sofortige Aufmerksamkeit erfordert (z.B. ein Wassermelder hat angeschlagen )
- zusätzlich habe ich fixe Farben für gleiche Informationen (z.B. Fenster geöffnet ist immer weiß, Fenster gekippt immer blau)
Damit kann man schon sehr viel Informationen darstellen und trotzdem noch schnell erfassen- dafür habe ich das Display eigentlich gemacht, schneller Überblick über den Gesamtzustand- für Detailinformation hat man ja immer noch eine Webvisualisierung- siehe auch nächster Punkt.
ZitatAndererseits kann ich bei der c't-Variante dann allerdings auch ein freies Colormapping machen - Füllstandsanzeigen von rot über gelb nach grün in 100 Schritten etwa. Wenn da die Werte leicht fluktuieren, fällt das nicht so sehr auf wie ein hartes Umschalten an einer Triggergrenze (rot-gelb oder gelb-grün).
Klar, machen kann man vieles. Aber ist eine LED dafür eine sinnvolle Anzeigemethode und bist du der Meinung du kannst 100 Schritte wirklich auseinanderhalten? Ich finde es da deutlich sinnvoller rot-gelb-grün zu verwenden um einen Überblick zu bekommen, und wenn man es genauer wissen will verwendet man ein vernünftiges Anzeigemedium (Browser mit Webvisu).
Hi,
wurde hier bestimmt schon angesprochen, aber der Gerätename ist derzeit auf 25 Zeichen begrenzt.
Aufgefallen ist mir dies bei einem meiner Homematic Rollladenaktoren, der derzeit aus 29 Zeichen besteht.
Greetz
Eldrik
25 für das Gerät, ohne Zusatztopic? Mappt man das nicht ohnehin zusätzlich irgendwie?
Keine Ahnung, ich habe gestern nur ein wenig herumexperimentiert und da ist es mir aufgefallen, das die Zeichen in der Weboberfläche abgeschnitten werden.
Wie habt ihr denn bisher die Adressierung und Abbildung des Statusdisplays in Fhem gelöst?
Greetz
Eldrik
Ich bin erst neu in MQTT. Ich schwanke noch: Den Status der Fenster und Türen könnte ich mit einem Notify publizieren (gleicher Name in FHEM und HSD, alle fangen mit "FK_" an), andererseits gibt es ja diesen MQTT-Bridge-Mechanismus, wo man das Topic als Attribut bei den Geräten hinterlegt und die ihren geänderten Status dann sozusagen selbst per MQTT publizieren. Ich werde aber die eine oder andere LED auch routinengesteuert nutzen.
Derzeit habe ich gerade mal 4 MQTT-Geräte und überlege damit noch jetzt zu MQTT2 zu wechseln, Akut fehlen mir Ruhe und Zeit, aber ich bin für Lösungen immer offen ...
@Joker:Ein spätes Danke für Deine Antwort. Ich werde mich dann mit dem Alarm-Topic arrangieren und bin inzwischen auch auf "aus=alles gut" umgeschwenkt - seit ich das auf dem 16-LED-Homematic-Display geändert habe, gefällt es allen besser.
Zur LED und 100 Schritten: Nein, natürlich kann ich die nicht auseinanderhalten an der Farbe. Aber der grobe Füllstand (in diesem Fall einer Regentonne) ist an dieser Stelle ausreichend - und die Fluktuaton der Anzeige ohnehin im einstelligen Prozentbereich. Wenn ich den Füllstand klassifiziere (voll, halb, leer), benötige ich dafür Grenzen und Hysteresen, wenn bei Fluktuation um eine Grenze die Farbe nicht ständig springen soll. So wechselt die LED dann eben kaum sichtbar ihre Farbe - aber ob rot, orange, gelb, gelbgrün etc. sieht man doch sofort. In TabletUI wäre das ein Balkendiagramm oder eine Torte. Die löst man ohne zusätzlich Zahl auch nicht genauer auf.
Deswegen fände ich eine Farbkreisdefinition (mit von-bis-Grenzen) schon nett. Alternativ würde eine Bypass-Ansteuerung mit direkten Farbwerten reichen - der Sketch rechnet die definierten Farben doch sicher in RGB-Stufen um. Schickt man statt eines definierten Zustands (also "on", "off", usw) einfach einen sechstelligen Hexwert, dann sollte die LED in dieser Farbe leuchten und fertig.
Das Studium des Sketches steht schon auf der ToDo - wenn ich eine Idee zur Umsetzung habe, melde ich mich.
Zitat von: eldrik am 12 September 2018, 21:21:50
Aufgefallen ist mir dies bei einem meiner Homematic Rollladenaktoren, der derzeit aus 29 Zeichen besteht.
Ja, es ist so dass der Name begrenzt ist. Kannst du -interessehalber- mal so einen langen Namen posten? Ich war eigentlich der Meinung das 25 Zeichen locker ausreichen. Beschränken muss ich es an irgendeiner Stelle.
Zitat von: eldrik am 13 September 2018, 12:18:38
Wie habt ihr denn bisher die Adressierung und Abbildung des Statusdisplays in Fhem gelöst?
Zitat von: Pfriemler am 13 September 2018, 12:47:01
Ich bin erst neu in MQTT. Ich schwanke noch: Den Status der Fenster und Türen könnte ich mit einem Notify publizieren (gleicher Name in FHEM und HSD, alle fangen mit "FK_" an), andererseits gibt es ja diesen MQTT-Bridge-Mechanismus, wo man das Topic als Attribut bei den Geräten hinterlegt und die ihren geänderten Status dann sozusagen selbst per MQTT publizieren. Ich werde aber die eine oder andere LED auch routinengesteuert nutzen.
Meine Empfehlung -und ausschließliche Nutzung meinerseits- ist die Verwendung des MQTT Bridge Mechanismus. Meine Anwendungsfälle sind immer so, dass es zu den LEDs auf dem Display auch irgendein physikalisch vorhandenes Gerät gibt, welches in FHEM schon existiert. Die MQTT Bridge übernimmt die Umsetzung auf MQTT Topics.
Prinzipiell könnte man das ohne physikalisches Gerät genauso machen: Routinegesteuert einen Dummy setzen, und auf diesen Dummy eine MQTT Bridge aufsetzen.
Zitat von: Pfriemler am 13 September 2018, 13:00:19
Zur LED und 100 Schritten: Nein, natürlich kann ich die nicht auseinanderhalten an der Farbe. Aber der grobe Füllstand (in diesem Fall einer Regentonne) ist an dieser Stelle ausreichend - und die Fluktuaton der Anzeige ohnehin im einstelligen Prozentbereich. Wenn ich den Füllstand klassifiziere (voll, halb, leer), benötige ich dafür Grenzen und Hysteresen, wenn bei Fluktuation um eine Grenze die Farbe nicht ständig springen soll. So wechselt die LED dann eben kaum sichtbar ihre Farbe - aber ob rot, orange, gelb, gelbgrün etc. sieht man doch sofort
Ja, ich sehe den Anwendungsfall schon. Wenn du Ideen zur Umsetzung hast, melde dich gerne. Behilflich sein kann ich vermutlich schon, aber für eine komplette Umsetzung fehlt mir die Zeit.
Zitat von: Joker am 13 September 2018, 14:48:20
Ja, es ist so dass der Name begrenzt ist. Kannst du -interessehalber- mal so einen langen Namen posten? Ich war eigentlich der Meinung das 25 Zeichen locker ausreichen. Beschränken muss ich es an irgendeiner Stelle.
Klar
CUL_HM_HM_LC_Bl1PBU_FM_298EDCist aber auch eine alte Autocreate Definition vom CUL_HM Modul wenn man heute den Rollladen definieren würde, dann kommt meine ich nur ein 8 Zeichen langer HM..... Name.
Zitat von: Joker am 13 September 2018, 14:48:20
Meine Empfehlung -und ausschließliche Nutzung meinerseits- ist die Verwendung des MQTT Bridge Mechanismus. Meine Anwendungsfälle sind immer so, dass es zu den LEDs auf dem Display auch irgendein physikalisch vorhandenes Gerät gibt, welches in FHEM schon existiert. Die MQTT Bridge übernimmt die Umsetzung auf MQTT Topics.
Prinzipiell könnte man das ohne physikalisches Gerät genauso machen: Routinegesteuert einen Dummy setzen, und auf diesen Dummy eine MQTT Bridge aufsetzen.
Ich habe mit der Bridge noch nicht wirklich gearbeitet aber in der Tat viele bis alle Geräte bereis in Fhem definiert, magst du vl. mal ein Codebeispiel liefern?
Edit: OK selbsterklärend funzt ;D
War es eigentlich beabsichtigt, dass man die LEDs nicht ausschalten kann? Im Code habe ich die Color None gefunden aber sie war in den betroffenen Dateien nicht weiter behandelt.
Ich habe heute als Versuch ein paar der Dateien entsprechend um die Farbe NONE erweitert und jetzt gehen die LEDs auch passend aus :)
Greetz
Eldrik
Zitat von: eldrik am 13 September 2018, 16:20:29
War es eigentlich beabsichtigt, dass man die LEDs nicht ausschalten kann? Im Code habe ich die Color None gefunden aber sie war in den betroffenen Dateien nicht weiter behandelt.
Ich habe heute als Versuch ein paar der Dateien entsprechend um die Farbe NONE erweitert und jetzt gehen die LEDs auch passend aus :)
Aus gehen die LEDs dann, wenn auf einem definierten Topic eine undefinierte Message empfangen wird :)
Also du hast beispielsweise definiert dass "fhem/status/light/kitchen on" eine Led auf blau schalten soll, dann wird bei Empfang einer Message "fhem/status/light/kitchen xx" (wobei xx irgendwas anderes als on ist) die LED ausgeschaltet.
Sollte so gehen.
Edit: Was die langen Namen angeht, man kann mit "rename" diese ja auch nachträglich umbenennen. Aufpassen muss man nur wenn die Namen in irgendeinem Stück Code verwendet werden, das wird natürlich nicht automatisch nachgezogen..
Zitat von: Joker am 13 September 2018, 16:57:58
Aus gehen die LEDs dann, wenn auf einem definierten Topic eine undefinierte Message empfangen wird :)
Also du hast beispielsweise definiert dass "fhem/status/light/kitchen on" eine Led auf blau schalten soll, dann wird bei Empfang einer Message "fhem/status/light/kitchen xx" (wobei xx irgendwas anderes als on ist) die LED ausgeschaltet.
Sollte so gehen.
Ah ok, darüber bin ich bisher nicht gestolpert bzw. hab es überlesen, dass das Verhalten so geplant ist. Ich finde es persönlich besser, direkt bei der Defintion von off, closed, locked etc. auswählen zu können, dass die LED ausgehen soll.
Zitat von: Joker am 13 September 2018, 16:57:58
Edit: Was die langen Namen angeht, man kann mit "rename" diese ja auch nachträglich umbenennen. Aufpassen muss man nur wenn die Namen in irgendeinem Stück Code verwendet werden, das wird natürlich nicht automatisch nachgezogen..
Ja mit rename kann man bestehende Definition umbennen, ich bin jetzt deinem Tipp mit der Bridge gefolgt und hab mir entsprechende Bridges angelegt :)
Greetz
Eldrik
Zitat von: eldrik am 14 September 2018, 07:04:44
Ah ok, darüber bin ich bisher nicht gestolpert bzw. hab es überlesen, dass das Verhalten so geplant ist. Ich finde es persönlich besser, direkt bei der Defintion von off, closed, locked etc. auswählen zu können, dass die LED ausgehen soll.
Am Anfang war die Implementierung so dass man das angeben musste. Ich habe dann nur festgestellt, dass ich dadurch quasi die doppelte Anzahl an Einträgen in der Konfiguration hatte - da man ja dann für jede LED die irgendwann eingeschaltet wird, auch den Trigger für aus angeben muss.
Aber was soll dann passieren, wenn eine unbekannte Nachricht auf das Topic kommt? Aus meiner Sicht muss man die LED dann auch ausschalten, da der Status ja dann nicht mehr dem Status entspricht, bei dem eingeschaltet werden soll. Also habe ich es dann so gemacht, dass JEDE unbekannte Nachricht die LED ausschaltet.
Hallo Joker,
dank der guten Anleitung konnte ich dein Projekt erfolgreich nachbauen und problemlos in FHEM 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.
Könntest du dir vorstellen dieses Feature in deine Software einzubauen?
Viele Grüße
Norbert
Hallo, ich bin ein Neuling.
Ich habe es geschaft die Sw auf einen Wemos zu flashen.
Aber ich schaffe es nicht aus Fhem Infos an das Display zu senden:
hier meine Konfig:
MQTT_BRIDGE
defmod MQTT_194 MQTT_BRIDGE Sonoff_194
attr MQTT_194 DbLogExclude .*
attr MQTT_194 IODev myBroker
attr MQTT_194 comment xxx
attr MQTT_194 publish-topic-base /fhem/status/Light/Sonoff_194/
attr MQTT_194 publishReading_POWER1 /fhem/status/Sonoff_194/POWER1
attr MQTT_194 publishReading_state /fhem/status/Sonoff_194/state
attr MQTT_194 publishReading_status /fhem/status/Sonoff_194/status
attr MQTT_194 publishState /fhem/status/light/Sonoff_194
attr MQTT_194 retain 1
attr MQTT_194 room Display
HomeStatusDisplayV0.6_dev:
Status topic :fhem/status/#
Device Mapping:
7 Sonoff_194 Light 7
Was mache ich falsch
wenn ich das hier aus mosquitto absetze :
mosquitto_pub -d -t fhem/cmd/statusdisplay/test -m 1 (2 3 4 5)
kann ich die Farben des Displays schalten.
Hi
also wenn du im Device Mapping das Gerät "Sonoff_194" genannt hast vom Typ "Light", dann muss das Topic das ans Display gehen muss so heißen:
fhem/status/light/Sonoff_194 mit entsprechender Payload wie im Color Mapping definiert (Color Mapping ist notwendig, hast du eins definiert?).
Sende mal diese Message mit mosquitto, das sollte dann gehen. Dann musst du noch dafür sorgen dass dein Gerät auch entsprechend das Topic sendet :)
@Joker
Nach über einem Jahr bin ich jetzt endlich dazu gekommen das Projekt umzusetzen!
Danke für dein tolles Projekt.
Ich habe mir das ganze mit 40 LED's in einem DIN A4 Rahmen aufgebaut. (4 Reihen a 10 LED 's)
Bei der Device mapping configuration habe ich das Problem, dass ich nicht mehr als 35 Devices anlegen kann. :'(
Edit entry (add not possible, entry limit reached):
Gibt es hierfür eine Erklärung?
Beim Test mit " fhem/cmd/statusdisplay_01/test 4 "werden werden alle 40 LED's angezeigt.
Gruß Billy
Habe die Antwort für die Limitierung der LED Anzahl hier gefunden!
https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/ (https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/)
ZitatBernd
15. SEPTEMBER 2017 UM 0:07 UHR
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.
Damit kann ich auch leben.
Billy
Zitat von: Billy am 07 Januar 2019, 18:55:22
@Joker
Nach über einem Jahr bin ich jetzt endlich dazu gekommen das Projekt umzusetzen!
Danke für dein tolles Projekt.
Ich habe mir das ganze mit 40 LED's in einem DIN A4 Rahmen aufgebaut. (4 Reihen a 10 LED 's)
Bei der Device mapping configuration habe ich das Problem, dass ich nicht mehr als 35 Devices anlegen kann. :'(
Edit entry (add not possible, entry limit reached):
Gibt es hierfür eine Erklärung?
Beim Test mit " fhem/cmd/statusdisplay_01/test 4 "werden werden alle 40 LED's angezeigt.
Gruß Billy
Hi,
die Anzahl lässt sich aber im Code aufbohren, irgendwo hier im Thread findet sich meine ich auch ein Hinweis darauf, ich betreibe mein Statusdisplay derzeit mit 47 Device Einträgen.
Greetz
Eldrik
Jupp, meins mit 54 läuft auch 1a
Gesendet von iPhone mit Tapatalk
Zitat von: Billy am 08 Januar 2019, 08:15:16
Habe die Antwort für die Limitierung der LED Anzahl hier gefunden!
https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/ (https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/)
Damit kann ich auch leben.
Genau, also das ist erstmal der Grund.
Natürlich kann man, wie beschrieben, das ganze Aufbohren. Die genaue Stelle ist in HSDConfig.hpp, die Konstante MAX_DEVICE_MAP_ENTRIES.
Der Hintergrund für die Limitierung ist, dass ich immer wieder Speicher Probleme hatte. Ich weiß leider nicht mehr genau, wie sich diese dargestellt haben. Jedenfalls habe ich mich dann entschieden, nichts mehr dynamisch zu allokieren, sondern das alles statisch ist. Daher muss man auch aufpassen wenn man die MAX_DEVICE_MAP_ENTRIES größer macht, wird das Config File ja größer und somit auch der benötigte Puffer für das JSON-Parsing.
D.h. man muss auch diese Werte in HSDConfig.cpp anpassen:
static const int MAX_SIZE_DEVICE_MAPPING_CONFIG_FILE = 1900; // 1801 exactly
static const int JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE = 4000; // 3908 exactlyAnsonsten kann es passieren, wenn man die maximale Topic Länge etc. ausnutzt, man sich beim ändern der Config über die Website alles zerschießt :), bedeutet: Die Config wird ungültig, kann nicht mehr geparsed werden und muss daher gelöscht werden, um neu aufsetzen zu können. Das ist extrem nervig wenn man gerade mühsam 50 Einträge erstellt hat :)
Danke an alle!
Zitat von: Joker am 08 Januar 2019, 11:12:38
Genau, also das ist erstmal der Grund.
D.h. man muss auch diese Werte in HSDConfig.cpp anpassen:
static const int MAX_SIZE_DEVICE_MAPPING_CONFIG_FILE = 1900; // 1801 exactly
static const int JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE = 4000; // 3908 exactly
Ansonsten kann es passieren, wenn man die maximale Topic Länge etc. ausnutzt, man sich beim ändern der Config über die Website alles zerschießt :), bedeutet: Die Config wird ungültig, kann nicht mehr geparsed werden und muss daher gelöscht werden, um neu aufsetzen zu können. Das ist extrem nervig wenn man gerade mühsam 50 Einträge erstellt hat :)
Hatte inzwischen schon die die Konstante MAX_DEVICE_MAP_ENTRIES angepasst und es läuft. :)
Welche Werte bei
static const int MAX_SIZE_DEVICE_MAPPING_CONFIG_FILE = 1900; // 1801 exactly
static const int JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE = 4000; // 3908 exactlysollte ich für 41 LED's nehmen ?
Billy
Da ich auch gerade (endlich) am Programmieren bin: Ich bräuchte auch sinnvolle Änderungen für 55 LEDs (50+5 in Reserve)
Genutzt werden tatsächlich etwa 45.
@Tobias: Hast Du noch an weiteren Stellschrauben für Deine 55 gedreht?
Wäre es hilreich, Längen für Topics anzupassen etc (ich brauche keine 50 Zeichen) usw...
Es wäre für mich ja kein Thema, immer nur 5 Einträge zu erstellen, save und reboot, um Speicherprobleme über die Webconfig zu vermeiden - wenn das hilfreich ist, und ich habe das so verstanden.
So ich habe jetzt mein HomeStatusDisplay mit 40 + 1 LED's am laufen.
MAX_DEVICE_MAP_ENTRIES auf 41 angepasst.
1x Opfer LED als Levelshifter + 40 leds als Anzeige auf DIN A4 Panel.
Die MQTT Anbindung habe ich in FHEM mit der MQTT-GENERIC-BRIDGE realisiert.
Meine anfänglichen Probleme mit sporadisch aufblitzenden LED's waren mit Tausch des Netzteils behoben.
Bin umfänglich zufrieden.
Billy
Hier mal ein Bild von meiner Version mit 49 LEDs.
Rahmen ist ein HOVSTA 13x18 eines bekannten Möbelhauses. Vom NodeMCU habe ich die Stiftleisten entlötet. Fast hätte ich mir die Mühe gemacht, einen meiner übrigen ESP8266 mit einem Linearregeler zu versehen, aber für den Node hatte ich eh keine Verwendung mehr. Stromversorgung erfolgt über den microUSB, mit allen LEDs zieht alles keine 250 mA. Passt alles locker in den Rahmen.
Helligkeit ist 25.
Ich habe den Sketch noch erweitert
a) um ein Topic "Uni" (für Universal). Ich mochte die Unterscheidung in window/door/light/alarm ja noch nie, zumal bei mir doppelte Namen für Stati eigentlich nicht vorkommen. Nun sind alle Geräte und Farben auf "Uni" gemappt und ich habe die volle Auswahl, etwa "redblink" an jedes meiner Lämpchen zu schicken, bzw. um Color-Einträge zu sparen, "recycle" ich manche Zustände einfach...
b) um die Farben "grey" (0F0F0F) und "darkgreen" (000F00). Diese kann ich als "Grundzustand" verwenden für diverse Anzeigelampen bzw. Fenster. Was dann irgendwann mal nicht leuchtet, hat einen undefinierten Status bekommen - oder die Anzeige ist nicht aktuell. So fiel mir bswp. auf, dass das Display heute morgen einen eigenmächtigen Reboot hingelegt hat, weil die meisten Lämpchen dunkel waren.
Der Überblick gewinnt auf diese Weise enorm. Was auffallen soll, fällt allein durch die Helligkeit auf, weitere Zustände werden passend signalisiert je nach Dringlichtkeit Flash/Blink/Flicker.
Ich sende Daten ausschließlich per publish über MQTT_SERVER und Mosquitto. Die Fensterkontakte aktualisieren ihren Zustand über ein Notify mit Regex ("FK_.*) direkt, für die übrigen wird eine Sub in myUtils bemüht, die in etwa 20 Unterblöcken verschiedene LEDs direkt ansteuert, auch hier sorgt ein Notify für einen entsprechenden Trigger. Grund hierfür ist, dass manche Anzeigezustände einfach nicht direkt den Wert des Dummys/Gerätes in FHEM widerspiegeln können. So bekommt "Garage" etwa "blau" mitgeteilt, sobald ein Funkbefehl an den Antrieb ergangen ist, und da dessen Rückmeldung leider immer mal wieder nicht ankommt, gibt es eine Warnung, wenn der Neigungssensor und der Antrieb widersprüchliche Werte liefern. Und das Badlicht-LED leuchtet, sobald eine der beiden dort verfügbaren Lampen irgendwie an ist. Das ließe sich mit MQTT_GENERIC_BRIDGE nie abbilden. So aber genügt ein Aufruf in der Art {Update_HSD("Garage")} und der Status ist aktuell.
Der Block "Fenster" aktualisiert etwa bei einer Batteriemeldung nicht nur den Status der Kontakte, sondern lässt - nur bei geschlossenem Fenster - die LED "flashen", wenn einer der Sensoren eine schwache Batterie hat, gleiches bei den Rauchmeldern. So weiß sogar die Frau ohne einen Blick in FHEM, welche Batterie sie wechseln müsste, wenn ich mal länger nicht da bin.
Und ein {Update_HSD("Alle")} löscht alle LEDs und bestückt sie neu. So kann ich das Display bei Bedarf komplett auf den aktuellen Stand bringen - und zwar mit den gleichen Routinen, die ich normalen Betrieb auch nutze. Nun muss ich nach einem Ausfall des Displays nur noch auf dessen "Wiedermeldung" in MQTT reagieren und kann das Display umgehend auf den neuesten Stand bringen.
Da noch nicht alle LEDs aktiv sind, sieht man, dass ich noch nicht ganz fertig bin mit Programmieren ...
Der Rahmen ist wie gesagt ein HOVSTA, leider brauche ich noch eine Glasscheibe, weil sich das Plastik zu sehr wölbt. Die Front ist auf Fotopapier gedruckt, direkt dahinter liegen die auf einem Hartfaserstück geklebten drei Streifen. Die Lichtoptik ist real nicht so gleichmäßig wie auf dem Foto, eher etwas bunt wie man an den "aus"en LEDs sehen kann, d.h. der jeweilige Chip "punktet" etwas hervor, aber das stört mich gar nicht.
Die Anordnung der LEDs links entspricht dem Grundriß der Reihenhausetagen, oben links ist die erste Levelshifter-LED gleichzeitig eine Regenmeldung. Die verpixelten Teile sind Namen der Bewohner, in der rechten Spalte widerspiegeln sie die Anwesenheit gemäß den Farben passend zum ersten Buchstaben - so weiß man auch im Dunkeln sofort wer "zuhause" ist oder gerade nach Hause gekommen ist (blinkt in den ersten 10 Minuten). Bei den Rauchmeldern blinkt es wenn "smoke" gemeldet wird - ein zweites Display kommt neben das Bett und im hoffentlich nie vorkommenden Falle eines Falles gewinne ich vielleicht schon im Halbschlaf eine Idee, in welcher Ecke des Hauses das Problem brennt...
Die Sketch-Änderungen kann ich gern zur Verfügung stellen, wenn das von Interesse ist.
Interessant, es führen halt immer noch mehrere Wege nach Rom. ;)
Kurze Anmerkung dazu:
ZitatIch sende Daten ausschließlich per publish über MQTT_SERVER und Mosquitto. Grund hierfür ist, dass manche Anzeigezustände einfach nicht direkt den Wert des Dummys/Gerätes in FHEM widerspiegeln können. Das ließe sich mit MQTT_GENERIC_BRIDGE nie abbilden.
Auch ich publishe einige Zustände über notifies direkt über MQTT_SERVER und Mosquitto.
Hauptsächlich da, wo die notifies schon angelegt waren.
Alles andere geht bei mir über die MQTT_GENERIC_BRIDGE die ja auch das value mapping ermöglicht.
Komplexe Anzeigezustände lassen sich, zumindest in meinem Fall über ein vorgeschaltetes DOIF darstellen.
An deinen Sketch Änderungen hätte ich durchaus Interesse. Man lernt ja nie aus.
Oh ... ist mir irgendwie durchgerutscht in der Benachrichtigung. Ich sollte die Änderungen also mal dokumentieren und hier bereitstellen.
Bitte ggf. nachtreten, ich hab zuviele Baustellen ...
Für ein einfaches Mapping (on/off -> closed/open oder so) hätte ich die GENERIC_BRIDGE schon bemüht, vor allem wenn mir die Color-Mapping-Einträge im Device ausgehen würden. Die DOIFs sind tatsächlich eine Alternative, wenn man sie bei (Aktualisierungs-)Bedarf von außen antriggert, stimmt. Das Display läuft übrigens seit vielen Tagen absolut stabil.
Aber für mein Homematic-LED-Display hatte ich das Konstrukt mit der {Update_...} in myUtils schon erfolgreich am Start und musste es nur "umschreiben".
So, hier die von mir in Post #113 (https://forum.fhem.de/index.php/topic,68948.msg886148.html#msg886148) angedeuteten Modifikationen für ein zusätzliches Topic und mehr Farben.
Teilweise habe ich vorhandene Zeilen mitkopiert, zum Wiederfinden im Kontext.
a) HSDConfig.cpp: Anzahl Farben erhöhen auf 10
16: const constexpr HSDConfig::ColorTranslator HSDConfig::colorTranslator[10];
b) a) HSDConfig.hpp: Zeile 43: Topic Uni einfügen, 66-67 und 239-240 Farben definieren usw:
42: TYPE_ALARM,
43: TYPE_UNI,
44: TYPE_UNKNOWN
...
64: BLUE = 0x0000FF,
65: WHITE = 0xFFFFFF,
66: GREY = 0x0F0F0F,
67: DGREEN = 0x000F00
...
205: for(uint32_t index = 0; index < 10; index++)
...
217: for(uint32_t index = 0; index < 10; index++)
...
229: for(uint32_t index = 0; index < 10; index++)
...
238: {WHITE, 7},
239: {GREY, 8},
240: {DGREEN, 9},
241: };
c) HSDHtmlHelper.cpp: Voreinstellung im Dropdown von WINDOW auf UNI ändern und weiteres:
111: html += getTypeOptions(HSDConfig::TYPE_UNI);
...
218: String whiteSelect = (selectedColor == HSDConfig::WHITE) ? SELECTED_STRING : EMPTY_STRING;
219: String greySelect = (selectedColor == HSDConfig::GREY) ? SELECTED_STRING : EMPTY_STRING;
220: String dgreenSelect = (selectedColor == HSDConfig::DGREEN) ? SELECTED_STRING : EMPTY_STRING;
230: html += F("<option "); html += whiteSelect; html += F(" value='"); html += HSDConfig::color2id(HSDConfig::WHITE); html += F("'>White</option>");
231: html += F("<option "); html += greySelect; html += F(" value='"); html += HSDConfig::color2id(HSDConfig::GREY); html += F("'>Grey</option>");
232: html += F("<option "); html += dgreenSelect; html += F(" value='"); html += HSDConfig::color2id(HSDConfig::DGREEN); html += F("'>DarkGreen</option>");
...
255: {
256: String uniSelect = (selectedType == HSDConfig::TYPE_UNI) ? SELECTED_STRING : EMPTY_STRING;
257: String windowSelect = (selectedType == HSDConfig::TYPE_WINDOW) ? SELECTED_STRING : EMPTY_STRING;
...
262: String html;
263:
264: html += F("<option "); html += uniSelect; html += F("value='"); html += HSDConfig::TYPE_UNI; html += F("'>Uni</option>");
265: html += F("<option "); html += windowSelect; html += F("value='"); html += HSDConfig::TYPE_WINDOW; html += F("'>Window</option>");
...
316: case HSDConfig::WHITE: htmlcolor = F("#FFFFFF"); break;
317: case HSDConfig::GREY: htmlcolor = F("#0F0F0F"); break; // fallen ein wenig dunkel aus, kann man heller machen
318: case HSDConfig::DGREEN: htmlcolor = F("#000F00"); break; // dito
319: default: break;
...
348: case HSDConfig::TYPE_DOOR: typeString = F("Door"); break;
349: case HSDConfig::TYPE_UNI: typeString = F("Uni"); break;
350: case HSDConfig::TYPE_LIGHT: typeString = F("Light"); break;
d) HomeStatusDisplay.cpp: UNI zwischen door und light einfügen usw.
6. #define DOOR_STRING (F("/door/"))
7: #define UNI_STRING (F("/uni/"))
8: #define LIGHT_STRING (F("/light/"))
...
130: else if(statusTopic.indexOf(UNI_STRING) != -1)
131: {
132: type = HSDConfig::TYPE_UNI;
133: }
134: else if(statusTopic.indexOf(ALARM_STRING) != -1)
Dann habe ich noch die MQTT-Wiederverbindung etwas verlängert, für den Fall dass FHEM mal länger als 30 Sekunden offline ist:
e) HSDMqtt.cpp: MQTT-Time
6: m_pubSubClient(m_wifiClient),
7: m_maxConnectRetries(10), // default 3 x 5 = 5 Sekunden
8: m_numConnectRetriesDone(0),
9: m_retryDelay(18000), // default 5000, 10x alle 18 sek = 3 Minuten
10: m_millisLastConnectTry(0),
Das dauert jetzt zwar ein bisschen länger mit dem Verbinden ...
Alle fünf Dateien auch im ZIP anbei
Dann:
Solange ich das Display im Testbetrieb hin und her trage, ist das sehr fein, wenn es sich nach dem Einstromen von selbst aktualisiert:
Auch noch etwas unschön, aber funktioniert, als Anregung:
defmod di_HomeStatusDisplay_PowerOn DOIF ([HomeStatusDisplay:"^statusdisplay_01:.on$"]) ({Update_HSD("Alle")})
attr di_HomeStatusDisplay_PowerOn cmdpause 30
attr di_HomeStatusDisplay_PowerOn do always
attr di_HomeStatusDisplay_PowerOn wait 10
Erklärung: Nach einem Neustart liefert das HomeStatusDisplay (das bei mir als gleichnamiges MQTT_DEVICE angeleggt ist) ein aktualisiertes Reading "statusdisplay_01" (Namen kann man im Webinterface einstellen, evtl. also anders).
Das triggert das DOIF. In der Update_HSD lösche ich bei "Alle" zunächst alle LEDs mit "set myBroker publish fhem/cmd/statusdisplay_01/test off" alle LEDs. Das löst eine erneute Aktualisierung des Readings aus, deswegen wird die Retriggerung mit "cmdpause 30" unterbunden. "wait 10" lässt dem Display ein wenig Verschaufpause nach der Meldung, kann man auch kürzen.
@Pfriemler
Vorab schon mal vielen Dank. Gibt ja einige Anregungen.
ZitatDann:
Solange ich das Display im Testbetrieb hin und her trage, ist das sehr fein, wenn es sich nach dem Einstromen von selbst aktualisiert:
Auch noch etwas unschön, aber funktioniert, als Anregung:
Ich publishe meine Stati alle mit gesetztem Retain-Flag an den Mosquitto damit habe ich nach Umzug meines Display exakt die gleiche Anzeige wie vorher. :)
Zitat von: Billy am 25 Januar 2019, 19:32:32
Ich publishe meine Stati alle mit gesetztem Retain-Flag an den Mosquitto damit habe ich nach Umzug meines Display exakt die gleiche Anzeige wie vorher. :)
Ja logisch eigentlich, das ist ja noch viel einfacher. Und für den gelegentlichen Umzug reicht es. Für jeden Neustart von FHEM oder gar dem Raspi bin ich dann doch dankbar, dass ich meine "Alle"-Routine habe.
Trotzdem danke für den Tipp, werde das mal umsetzen.
Im übrigen bastele ich gerade daran, weitere GPIOs im HSD nutzbar zu machen. Vermutlich werde ich dazu die mglw. nutzbaren GPIOs mit eigenen device-Namen belegbar machen abseits des Device- und Color-Mappings (etwa bei Global, oder zumindest anfänglich hart im Code verankern), als Befehle reichen mir on, off oder eine Sekundenzahl. Der Aufwand dürfte überschaubar bleiben: im "Empfangskomitee" für die MQTT-Messages die Befehle abfangen und speichern und in der allgemeinen Schleife, die derzeit ca 10x pro Sekunde das Display aktualisiert, auch die GPIOs mit ansprechen - Zeitangaben kann man da herunterzählen. Durch das variable Topic könnte man dann pro HSD entscheiden, ob es individuell oder auf "Rundruf" reagiert...
Oder hat da jemand in der Richtung schon was dazugebaut? Bei mir dauert es noch mindestens eine Woche bis ich anfangen kann...
Hi
sorry für die späte Rückmeldung, habe leider wenig Zeit aktuell (oder wie schon seit längerem...).
Generell ist es so, dass ich "sinnvolle" Erweiterungen für das HSD natürlich gerne in den Sourcecode aufnehmen würde. Ansonsten haben diejenigen, die eigene Erweiterungen nutzen das Problem, dass bei Updates des HSD Codes wieder alles neu nachgepflegt werden muss.
Voraussetzung wäre, dass keine bestehende Funktionalität "zerstört" wird und es sich um keine Spezial-Einzellösung handelt, sondern um etwas was potentiell interessant für alle ist.
Bei der Erweiterung von @Priemler wäre das aus meiner Sicht gegeben. Am sinnvollsten wäre es, das Repositiory über GitHub zu forken und die Erweiterung als PullRequest einzubringen. Das kann dann nämlich vollautomatisch per Knopfdruck passieren. Wenn die Erweiterung so gepostet wird wie hier muss alles händisch gemacht werden, was zeitaufwändig und fehleranfällig ist.
Gerade erst habe ich übrigens wieder ein Feedback von einem User erhalten der die Anzahl der LEDs erweitert hat und nun Probleme hat. Daher kann ich da aktuell noch keine allgemeine "Freigabe" für mehr LEDs als vorgesehen geben. Es scheint im Einzelfall tatsächlich von der Länge der Topics etc. abzuhängen ob es geht oder nicht.
Zitat von: Pfriemler am 26 Januar 2019, 09:48:11
Im übrigen bastele ich gerade daran, weitere GPIOs im HSD nutzbar zu machen. Vermutlich werde ich dazu die mglw. nutzbaren GPIOs mit eigenen device-Namen belegbar machen abseits des Device- und Color-Mappings (etwa bei Global, oder zumindest anfänglich hart im Code verankern), als Befehle reichen mir on, off oder eine Sekundenzahl.
Was genau meinst du mit "nutzbar" machen? Möchtest du GPIOs abhängig von eintreffenden Meldungen ein- und ausschalten? Was wäre da der UseCase?
ZitatJa logisch eigentlich, das ist ja noch viel einfacher. Und für den gelegentlichen Umzug reicht es. Für jeden Neustart von FHEM oder gar dem Raspi bin ich dann doch dankbar, dass ich meine "Alle"-Routine habe.
Trotzdem danke für den Tipp, werde das mal umsetzen.
Ja, bitte unbedingt die Retain-Funktion nutzen, denn das was du möchtest ist genau schon im MQTT Standard vorgesehen. Warum ist der Neustart von FHEM oder Raspberry ein Problem? Auch dafür funktioniert die Retain Funktion.
Keine Entschuldigung nötig. Danke für die Rückmeldung!
Github habe ich noch nie aktiv benutzt - wenn das der Sache dient, werde ich mich gern darin befleißigen. Die Änderungen händisch einzupflegen war auch nicht mein Auftrag, das geht mit dem eigenen Vergleich zu meinen angehängten Dateien ja viel einfacher - bzw. dann eben mit einem fork.
Die "Laufgesundheit" des HSD ist für mich keine Frage der LED-Anzahl, sondern der des Gesamtspeicherbedarfs, und weil ich meine Topics bewusst kurz halte, gibt es mit meinen 49 LEDs keine Probleme. Das ist mehr Glück, denke ich. Jokers Limits garantieren einen sicheren Betrieb - würde man die Topics weiter begrenzen könnte man sicher errechnen ob man mit seinem Bedarf unter einer kritischen Marke bleibt. Noch geiler wäre, wenn der Sketch anhand der vorliegenden eingegeben Daten einschätzen könnte, wieviele Datensätze er noch verträgt. Ist ein bisschen viel verlangt, aber Versuch macht ja auch kluch.
Da wäre ich bei einem weiteren Wunsch: Gibt es evtl. schon eine Hintertür, wie man die Konfiguration schon jetzt sichern und übertragen könnte? Jedes neue oder abgestürzte HSD vollständig zu bestücken dauert lange und ist fehlerträchtig. Sowas wie ein FTP-Server? Oder eine Export- und Importfunktion? Schon angedacht und des Aufwands wegen verworfen?
Und noch ein Wunsch: Helligkeit des gesamten Displays per MQTT-Message steuerbar (tageszeitabhängig).
Retain ist übrigens eingebaut und funktioniert (natürlich) prächtig. Legt Mosquitto die Messages dauerhaft in Files, so dass sie nach einem Neustart des Servers wieder präsent sind? Ich dachte, die wären dann verloren...
Zu den GPIO: Ja, es geht um das Ein- und Ausschalten weiterer GPIOs. Man könnte damit diverse Nicht-LED-Aktionen in der Nähe mitbedienen - einfachste sinnvollste Ergänzung wäre wohl ein Pieper direkt im HSD (mit eigenem Chip und Resonatorz, also keine Frequenansteuerung) oder ein kleines Relais, in meinem Fall eine versteckte Funkfernbedienung, die proprietäre Geräte steuert. Statt noch ein neues Gerät zu bauen, zu bestromen und ins WLAN zu hieven, dachte ich mir es böte sich an, vorhandene Ressourcen einfach mitzubenutzen.
4 freie GPIO gesucht - ein ESP8266-Projekt aufbohren - Idee? (https://forum.fhem.de/index.php/topic,96202.0.html).
Um den Aufwand gering zu halten, dachte ich an ein weiteres Topic "gpio". Vier oder fünf weitere GPIO gibt ein ESP8266 her. Anders als LEDs mit diversen Farben gäbe es hier allenfalls ein "Blinkmuster" - Flash, Blink, Flicker könnte man direkt übernehmen, aber wie gesagt eine (maximale) Laufzeit beim Einschalten vorzugeben wäre mir wichtig (mindestens als Sicherheit falls der Ausschaltbefehl auf der Strecke bleibt), macht aber bei Piepern oder "Ferntastereien" ohnehin Sinn.
Beispiel: Den Status der Unwetterwarnung für meinen Wohnort zeige ich derzeit mit "fhem/status/uni/DisUnwetter <farbe>" an (<farbe> je nach Warnstufe). Wenn ich jetzt einen kleinen Pieper dazubaue, der situationsabhängig (also nicht gerade nachts) mit "fhem/status/gpio/flurbeeper 5" ansteuern könnte ... "flurbeeper" wäre dann das Device und 5 die Einschaltdauer in Sekunden.
Oder gleich die SetExtensions übernehmen ... "on-for-timer x" etwa.
Und getreu dem HSD-Konzept: Versehe ich mehrere HSD mit Beepern und trage den Devicenamen überall ein (Bsp. "fhem/status/gpio/alarm"), dann könnte ich sie entsprechend alle einschalten...
Eine weitere aus meiner Sicht sinnvolle Idee wäre die Nutzung von Eingabetastern als Quittungssignal. Eine Betätigung würde ein entsprechendes Topic publishen ... richtig gesetzt sogar direkt vom eigenen Gerät verarbeitbar, etwa "fhem/status/gpio/flurbeeper off" ;)
Alternativ würe auch ein "pressed" bzw. "released" reichen, wie ich es von den Buttons meines EnOcean-Türgriffs kenne... Jede Änderung des Tasterstatus published eine einstellbare Meldung.
Viele Wüsche, aber noch keine konkreten Umsetzungsideen. Für mich wären die paar Einstellungen noch im "General" bestens aufgehoben. 5 neue Zeilen mit Feldern
Arduino-Pin-Nummer | in/out (Dropdown) | Device | closed| opened
Berücksichtigt wird dann nur das wo eine Pin-Nummer eingetragen ist, letztere beide gelten nur für Taster
Bsp.
"12"- "out" - "flurbeeper"
"13" - "in" - "flurtaste1" - "pressed" - "released"
"15" - "in" - "flurbeeper" - "off" - ""
Ankommende Messages würden natürlich nur auf "out"-Einträge gematched.
Die Taste an 13 würde beim Drücken "fhem/status/gpio/flurtaste1 pressed" und beim Loslassen ".... released" senden,
die Taste an 15 beim Drücken "fhem/status/gpio/flurbeeper off" senden (und damit einen eventuell eingeschalteten Beeper muten) und beim Loslassen nichts.
"fhem/status/" wäre entsprechend immer das "Status topic" des HSD.
Alle Änderungen zu GPIOs würde ich in eigene .cpp und .hpp auslagern und entsprechend includen nebst der entsprechenden Methoden begin und update und beim Start bzw. in der Haupt-Schleife zyklisch aufrufen. Evtl. könnte man dann noch das delay(100) der Hauptschleife in eine Konstante auslagern, die die Zeitberechnung für die GPIO mit berücksichtigt (hier dann 1 Sekunde = 10 Durchläufe bpw.)
Einwände/Gegenvorschläge?
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Legt Mosquitto die Messages dauerhaft in Files, so dass sie nach einem Neustart des Servers wieder präsent sind?
Ja, die werden gespeichert!
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Github habe ich noch nie aktiv benutzt - wenn das der Sache dient, werde ich mich gern darin befleißigen.
Wäre definitiv extrem hilfreich. Wie gesagt könnte ich dann Änderungen von anderen Leuten halbautomatisch einpflegen.
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Da wäre ich bei einem weiteren Wunsch: Gibt es evtl. schon eine Hintertür, wie man die Konfiguration schon jetzt sichern und übertragen könnte? Jedes neue oder abgestürzte HSD vollständig zu bestücken dauert lange und ist fehlerträchtig. Sowas wie ein FTP-Server? Oder eine Export- und Importfunktion? Schon angedacht und des Aufwands wegen verworfen?
Es gibt den Arduino Filesystem Uploader (https://github.com/esp8266/arduino-esp8266fs-plugin). Damit kann man beliebige Files in das Dateisystem des ESP hochladen, also auch Config Files. Ich habe das probiert, aber es hat nie vollständig funktioniert, ich glaube die Systemkonfiguration wurde geschrieben, die Mappings aber nicht. Den Grund habe ich bisher nicht weiter untersuchen können. Wenn jemand sich gerne damit auseinandersetzen möchte, sehr gerne! Es wäre für den angesprochenen Anwendungsfall natürlich sehr hilfreich...
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Und noch ein Wunsch: Helligkeit des gesamten Displays per MQTT-Message steuerbar (tageszeitabhängig).
Hm, schwierig. Da hat jeder eigene Anforderungen, wie er das gerne haben möchte. Ich z.B. würde helligkeitsabhängig viel sinnvoller finden als tagesabhängig, man hat ja auch Licht an :) Da dann die Konfigurierung so flexibel zu machen dass es für die meisten passt ist fast unmöglich. Man könnte darüber nachdenken dass das Display bestimmte Topics (z.b. brightness) subscribed, und auf diese reagiert. Dann kann jeder aus seinem Automatisierungssystem die Message senden wann er es für notwendig hält.
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Retain ist übrigens eingebaut und funktioniert (natürlich) prächtig. Legt Mosquitto die Messages dauerhaft in Files, so dass sie nach einem Neustart des Servers wieder präsent sind? Ich dachte, die wären dann verloren...
Zitat von: Billy am 28 Januar 2019, 19:38:33
Ja, die werden gespeichert!
Jain. Es hängt von der persistence-Einstellung in mosquitto.conf (https://mosquitto.org/man/mosquitto-conf-5.html)ab.
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Zu den GPIO: Ja, es geht um das Ein- und Ausschalten weiterer GPIOs. Man könnte damit diverse Nicht-LED-Aktionen in der Nähe mitbedienen - einfachste sinnvollste Ergänzung wäre wohl ein Pieper direkt im HSD (mit eigenem Chip und Resonatorz, also keine Frequenansteuerung) oder ein kleines Relais, in meinem Fall eine versteckte Funkfernbedienung, die proprietäre Geräte steuert. Statt noch ein neues Gerät zu bauen, zu bestromen und ins WLAN zu hieven, dachte ich mir es böte sich an, vorhandene Ressourcen einfach mitzubenutzen.
4 freie GPIO gesucht - ein ESP8266-Projekt aufbohren - Idee? (https://forum.fhem.de/index.php/topic,96202.0.html).
Klar, kann man schon machen. Ich würde zwei Dinge wichtig finden:
- das ganze sollte möglichst ohne zusätzliche Hardware funktionieren, denn sobald zusätzliche Hardware notwendig ist, muss diese optional sein, da das nicht jeder braucht. Und wenn sie optional ist, muss sie auch konfigurierbar sein, d.h. man braucht neue Optionen im Webinterface, muss schauen dass das auch alles richtig abgefragt wird etc... alles machbar, aber halt viel aufwändiger als einfach den ein oder anderen Pin einzuschalten, was man ohne Konfiguration der Zusatzhardware einbauen könnte. Da nur ein einziger Pin aktuell verwendet wird, sind definitiv auch welche frei.
- es sollte ein "StatusDisplay" bleiben. D.h. was immer da angeschlossen wird, sollte auch zur Anzeige eines Status dienen. Ich würde da keine weiteren Aktionen ableiten. Aber solang das außerhalb vom HSD geschieht, kann man natürlich anschließen was immer man möchte...
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Um den Aufwand gering zu halten, dachte ich an ein weiteres Topic "gpio". Vier oder fünf weitere GPIO gibt ein ESP8266 her. Anders als LEDs mit diversen Farben gäbe es hier allenfalls ein "Blinkmuster" - Flash, Blink, Flicker könnte man direkt übernehmen, aber wie gesagt eine (maximale) Laufzeit beim Einschalten vorzugeben wäre mir wichtig (mindestens als Sicherheit falls der Ausschaltbefehl auf der Strecke bleibt), macht aber bei Piepern oder "Ferntastereien" ohnehin Sinn.
Beispiel: Den Status der Unwetterwarnung für meinen Wohnort zeige ich derzeit mit "fhem/status/uni/DisUnwetter <farbe>" an (<farbe> je nach Warnstufe). Wenn ich jetzt einen kleinen Pieper dazubaue, der situationsabhängig (also nicht gerade nachts) mit "fhem/status/gpio/flurbeeper 5" ansteuern könnte ... "flurbeeper" wäre dann das Device und 5 die Einschaltdauer in Sekunden.
Oder gleich die SetExtensions übernehmen ... "on-for-timer x" etwa.
Und getreu dem HSD-Konzept: Versehe ich mehrere HSD mit Beepern und trage den Devicenamen überall ein (Bsp. "fhem/status/gpio/alarm"), dann könnte ich sie entsprechend alle einschalten...
Ich würde da den Aufwand vielleicht noch geringer halten: "statusdisplay_flur/gpio/1 on", "statusdisplay_flur/gpio/1 off". Dazu braucht man in der Software nichts weiter einbauen als diese Topics abzufangen und den Pin an oder auszuschalten. Das "Alle einschalten" geht auch, wenn man die Message mit Wildcard für den Namen schickt. Die Zeiten, wann die Messages geschickt werden, kann das Hausautomatisierungssystem bestimmen. Es macht wenig Sinn, Timer etc. im HSD zu implementieren, wenn es in FHEM dazu schon sehr ausgefeilte und funktionierende Lösungen gibt.
Zitat von: Pfriemler am 28 Januar 2019, 19:12:59
Eine weitere aus meiner Sicht sinnvolle Idee wäre die Nutzung von Eingabetastern als Quittungssignal. Eine Betätigung würde ein entsprechendes Topic publishen ... richtig gesetzt sogar direkt vom eigenen Gerät verarbeitbar, etwa "fhem/status/gpio/flurbeeper off" ;)
Alternativ würe auch ein "pressed" bzw. "released" reichen, wie ich es von den Buttons meines EnOcean-Türgriffs kenne... Jede Änderung des Tasterstatus published eine einstellbare Meldung.
Das macht vermutlich Sinn :D
Zitat
Viele Wüsche, aber noch keine konkreten Umsetzungsideen. Für mich wären die paar Einstellungen noch im "General" bestens aufgehoben. 5 neue Zeilen mit Feldern
Arduino-Pin-Nummer | in/out (Dropdown) | Device | closed| opened
Berücksichtigt wird dann nur das wo eine Pin-Nummer eingetragen ist, letztere beide gelten nur für Taster
Bsp.
"12"- "out" - "flurbeeper"
"13" - "in" - "flurtaste1" - "pressed" - "released"
"15" - "in" - "flurbeeper" - "off" - ""
Ankommende Messages würden natürlich nur auf "out"-Einträge gematched.
Die Taste an 13 würde beim Drücken "fhem/status/gpio/flurtaste1 pressed" und beim Loslassen ".... released" senden,
die Taste an 15 beim Drücken "fhem/status/gpio/flurbeeper off" senden (und damit einen eventuell eingeschalteten Beeper muten) und beim Loslassen nichts.
"fhem/status/" wäre entsprechend immer das "Status topic" des HSD.
Alle Änderungen zu GPIOs würde ich in eigene .cpp und .hpp auslagern und entsprechend includen nebst der entsprechenden Methoden begin und update und beim Start bzw. in der Haupt-Schleife zyklisch aufrufen. Evtl. könnte man dann noch das delay(100) der Hauptschleife in eine Konstante auslagern, die die Zeitberechnung für die GPIO mit berücksichtigt (hier dann 1 Sekunde = 10 Durchläufe bpw.)
Einwände/Gegenvorschläge?
Auf den ersten Blick scheint das ganz ok. Eine Sache muss man aber berücksichtigen, das HSD darf nicht "fhem/status/..." publishen, sondern sowas wie "statusdisplay_name/gpio/..." oder sowas, siehe oben. Es geht ja hier nicht um den FHEM Status, sondern den HSD Status. Den "Namen" des Pins würde ich wohl ganz weglassen, sondern einfach die Nummern der IO verwenden.
Gut, Github kommt, aber lass mir bitte Zeit ;) ... in der zweiten Lebenshälfte wird man langsamer.
Zitat von: Joker am 30 Januar 2019, 08:44:58
Es gibt den Arduino Filesystem Uploader (https://github.com/esp8266/arduino-esp8266fs-plugin). ...
Probier ich mal aus und berichte.
ZitatHelligkeit ... Man könnte darüber nachdenken dass das Display bestimmte Topics (z.b. brightness) subscribed, und auf diese reagiert.
Nur so hatte ich das gedacht. Klar wäre ein Helligkeitssensor und eine automatische Anpassung chic... Derzeit wird die Helligkeit aber nur beim Booten des HSD gesetzt, das müsste man eben noch anpassen.
ZitatGPIO: ... sollte möglichst ohne zusätzliche Hardware funktionieren
Ja, natürlich optional. Um die Hardware muss der User sich kümmern - braucht er keine, lässt er sie weg und die Konfiguration, und dann werden sie auch in Ruhe gelassen. Und anschließen soll er können was er will, solange er mit den Konsequenzen leben kann. ;)
ZitatIch würde da den Aufwand vielleicht noch geringer halten: "statusdisplay_flur/gpio/1 on", "statusdisplay_flur/gpio/1 off". Dazu braucht man in der Software nichts weiter einbauen als diese Topics abzufangen und den Pin an oder auszuschalten.
Soll letztlich so funktionieren, allerdings habe ich nicht einmal an die Wildcards gedacht, stimmt. Zumindest aber sollte man die GPIOs einstellbar vorsehen wie den stripe-Ausgang, den man aktuell auch an jeden beliebigen GPIO legen kann.
Der Name war dazu gedacht, die Pins bei mehreren HSD individuell anzusprechen. Alternativ kömmte man gleich ans HSD-individuelle Kommandotopic senden (also das wo auch test läuft) - Für die paar Fälle wo man mehrere HSD parallel addressieren müsste, kann man das auch getrennt publishen.
ZitatEs macht wenig Sinn, Timer etc. im HSD zu implementieren, wenn es in FHEM dazu schon sehr ausgefeilte und funktionierende Lösungen gibt.
Richtig: Ein einfaches Ein-/Aus ließe sich bereits in der "Kommandoentgegennahme" (MQTT-Verarbeitung) setzen, dort aber ohne Timer, weil sonst blockierend. Aber als Performance/Funkgeschädigter gebe ich bspw. vielen Homematic-Geräten eine maximale Einschaltzeit mit und möchte das nicht mehr missen. Dabei ist es doch einfach: Derzeit wird doch ein Array dazu verwendet, die Aktionen der LEDs zu speichern - erst ein anderer Codeteil arbeitet das Array an die LEDs ab - dann eben ein zweiter analog das GPIO-Array an die GPIOs - würde den Timer setzen und die Ausgabeschleife ihn herunterzählen und ggf. den Port abschalten. Genau dort sollte auch die Tasterabfage passieren.
Zitatdas HSD darf nicht "fhem/status/..." publishen, sondern sowas wie "statusdisplay_name/gpio/..." oder sowas, siehe oben. Es geht ja hier nicht um den FHEM Status, sondern den HSD Status
.
Damit kann ich leben. Die "Eigenreaktion" (also das direkte Beeinflussen von abonnierten Topics des HSD) wäre nur ein netter Nebeneffekt, aber in der Tat entbehrlich.
Kleines Update von mir:
a) mit dem Arduino Filesystem Uploader kann ich nicht das machen was mir vorschwebt - ich möchte nämlich die Konfiguration auch sichern können.
b) die Problematik mit den Zusatz-GPIO ist bei mir akut vom Tisch und damit vertagt, weil anderes wichtiger ist.
Dann:
Das Flashen leicht geänderter Firmware hat bis gestern immer prima funktioniert. Seit ich in der Boardverwaltung der Arduino-IDE "ESP8266" auf 2.5.0 geupdaten hatte (für ein anderes Projekt), sind die kompilierten Binarys statt 312k plötzlich 364k groß, und das HSD startet damit nicht (seriell erscheint Zeichensalat und ein Hinweis, dass das Filesystem nicht gemountet werden konnte). Ich dachte schon alle Daten verloren zu haben, aber nach der Rückkehr auf ESP8266 2.3.0 sind die Binarys wieder so groß wie vorher und das Display läuft wie gehabt, sogar alle Daten waren noch da.
Ich vermute, dass es mit einem jungfräulichen HSD klappt, werde berichten.
Für das bisher ungelöste Problem "Wie erwecke ich das Display wieder zum Leben, wenn WLAN und/oder MQTT zu lange aus waren?" gibt es jetzt einen versteckten Taster hinter der Plexiglasscheibe, mit dem man durch einen leichten Druck auf die Scheibe von vorn einen Reset des ESP8266 auslösen kann (Stromversorgung ist bei mir dauerhaft versteckt verkabelt, da kommt man nicht so gut ran).
Und wenn das Display Probleme macht (WLAN oder MQTT zu lange weg), kann ich durch den Druck auf die Plastikscheibe an einer bestimmten Stelle einen Reset auslösen, weil sich dahinter ein versteckter Taster befindet.
Zitat von: Pfriemler am 17 Februar 2019, 15:17:57
Für das bisher ungelöste Problem "Wie erwecke ich das Display wieder zum Leben, wenn WLAN und/oder MQTT zu lange aus waren?" gibt es jetzt einen versteckten Taster hinter der Plexiglasscheibe, mit dem man durch einen leichten Druck auf die Scheibe von vorn einen Reset des ESP8266 auslösen kann (Stromversorgung ist bei mir dauerhaft versteckt verkabelt, da kommt man nicht so gut ran).
Und wenn das Display Probleme macht (WLAN oder MQTT zu lange weg), kann ich durch den Druck auf die Plastikscheibe an einer bestimmten Stelle einen Reset auslösen, weil sich dahinter ein versteckter Taster befindet.
Baue ein Reed-Relay hinter die Scheibe an eine bestimmte Stelle.
Dann kannst du mit einem kleinen Magnet den du dagegen hältst einen Reset auslösen.
Zitat von: AxelSchweiss am 17 Februar 2019, 15:43:09
Baue ein Reed-Relay hinter die Scheibe an eine bestimmte Stelle.
Dann kannst du mit einem kleinen Magnet den du dagegen hältst einen Reset auslösen.
War auch eine meiner Ideen. Der "Taster" (mit Markierung auf der Beschrifung) hat aber einen deutlichen höheren WAF ;)
Die Reed-Variante nutze ich tatsächlich in einem wasserdichten Homematic-Außengehäuse (Energiemonitor) als Not-Ein/Aus-Schalter.
Zitat von: Pfriemler am 17 Februar 2019, 16:13:16
War auch eine meiner Ideen. Der "Taster" (mit Markierung auf der Beschrifung) hat aber einen deutlichen höheren WAF ;)
Die Reed-Variante nutze ich tatsächlich in einem wasserdichten Homematic-Außengehäuse (Energiemonitor) als Not-Ein/Aus-Schalter.
Nu ja .. Ansichtsichtssache ... mein WF würde einfach sagen .. "geht nicht mehr ... machs ganz" ;D
Sagt mal, hat jemand vielleicht auch ein Problem mit dem Speichern von Konfigurationsdaten?
Ich bin gerade dabei, mein drittes Display zu bestücken. Es ließ sich anfangs sauberst durchkonfigurieren, nach dem Zusammenbau hatte ich diverses Flacken - Ursache war hier aber eine zu knappe Bauteildimensionierung - ich las mal von 100 µF und 100nF hinter dem Linearregler, aber das ist deutlich zu wenig, wenn der Chip WLAN zieht, bölkt er Spitzen von 200 mA und mehr aus der Versorgung, und bei zu knappen Bauteilen mit zu hohem Serienwiderstand bricht die Spannung am ESP deutlich ein. Wird gerade in einem solchen Peak der LED-Strip aktualisiert, gibt es "Kleinholz". Der gleiche Effekt wie bei Betrieb ohne Pegelwandler.
Das aber machte dem Chip irgendwie zu schaffen. Die schwankende Versorgung und die häufigen Reboots - und plötzlich war die Colormap weg, dann auch die Devicemap. Also gab ich alles brav nacheinander ein, drückte hin und wieder brav auf Save, und nach einem Reboot fehlt das eine oder andere.
Nachdem ich nun die Versorgung gefixt habe und alles flackerfrei läuft, waren die Colormap-Daten wieder weg. Also habe ich alles zum gefühlt 10. Mal eingegeben und dabei heftig geflucht, dass die Software keine Speichern und Einlesen von Konfigdaten erlaubt ... aber mal nach dem 11., mal nach dem 16. Eintrag ist Schluss. Egal ob ich zusätzliche Einträge eingebe oder welche lösche, nach Save und Reboot ist nur die halbe Tabelle wieder da.
Richtig spannend wurde es zwischendurch, als ich nach einem Reboot die Tabelle komplett löschte und anschließend ein Undo machte. Da waren alle, also wirklich alle gewünschten Einträge wieder da. Nach dem nächsten Reboot wieder nur die halbe Tabelle.
Ich nutze die gleiche Firmware auf meinem ersten Display mit gleich großer Colormap und einer sogar noch größeren Devicemap ohne jedes Problem. Auch das zweite Minidisplay mit 30 LED macht keine Mucken.
Ich würde ja auch mal das ganze Display resetten und von vorn anfangen, aber die EEPROM-Daten vergißt das Scheißding ja bei nüscht. Das ist aber bei anderen Sketchen auch so. Nicht mal in der Arduino-IDE kann man den Chip plätten, nur mit esptool.py. Das will auf einem Win10-rechner aber erst mal zum Rennen gebracht werden.
Also falls noch jemand ähnliche Erfahrungen gemacht hat oder einen Tip hat: bitte gerne...
Hier mal ein paar Details dazu aus der seriellen Konsole:
Neustart:
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
...
Initializing config.
Mounted file system.
Reading config file /config.json
File size is 279 bytes
Main config data successfully parsed.
JSON length is 279
...
Config data is complete.
Deleting color mapping config data.
Reading config file /colormapping.json
File size is 659 bytes
Color mapping config data successfully parsed.
JSON length is 659
Adding or editing color mapping entry at index 0, new values: name closed, type 4, color 3840, behavior 1
...
Adding or editing color mapping entry at index 16, new values: name warning, type 4, color 16776960, behavior 2
Deleting device mapping config data....
und dann wird die Devicemap geladen, Wifi connected etc. Alles normal.
Jetzt lösche ich die Colormap:
Need to delete all color mapping config entries
Header size: 1279
Page size: 3310
Free RAM: 24200
und drücke anschließend UNDO.
Need to undo changes to color mapping config
Deleting color mapping config data.
Reading config file /colormapping.json
File size is 696 bytes
Color mapping config data successfully parsed.
JSON length is 696
Adding or editing color mapping entry at index 0, new values: name closed, type 4, color 3840, behavior 1...
Adding or editing color mapping entry at index 17, new values: name green, type 4, color 65280, behavior 1
Header size: 1279
Page size: 5650
Free RAM: 24272
So: Nach dem reboot ist die Colormap:
Reading config file /colormapping.json
File size is 659 bytes
Color mapping config data successfully parsed.
JSON length is 659
Nach Delete und Undo:
Reading config file /colormapping.json
File size is 696 bytes
Color mapping config data successfully parsed.
JSON length is 696
In beiden Fällen wird die gleiche Datei aus dem Filesystem geladen, aber sie ist plötzlich unterschiedlich groß und hat unterschiedliche Einträge.
Der im zweiten Fall geladene Stand entspricht dem zuletzt gespeicherten aus der vorigen Sitzung. Nur beim Booten fehlt die Hälfte.
Vervollständige ich die Tabelle und speichere sie, werden wieder nur 16 Einträge geladen. Nach Delete und Undo wieder alle.
Immerhin funktioniert dann alles, aber nur bis zum nächsten Neustart.
Das kriege ich jetzt einfach nicht mehr auf die Reihe....
So, jetzt kommts.
Colormap vervollständigt. Dann ein paar mal durch die Weboberflächen gezappt - ohne jede Änderung - und im "General" dann Reboot.
Nun sind alle Farben da, aber die Devicemap vollständig weg und nicht wiederholbar.
Wie im Film kommt das Beste zum Schluss: die gesamte Devicemap ließ sich eingeben, speichern und war nach mehreren Reboot noch da und die Colormap auch, auf deutsch: es ist alles richtig.
Ich geh mich jetzt besaufen ...
Update: Am Einsatzort: Helligkeit für zu hoch befunden, reduziert, gespeichert, reboot.
Wieder nur 16 von 27 Colors.
Dann erneute Versuche, und irgendwann nach Delete all, Undo (das HSD zeigt auf der seriellen immer die gleiche Anzahl wie im Browser, ist also nicht etwa eine Cache-Seite oder so) mit viel Glück wieder ein Zustand, der über die Reboots anhält.
Das zickige Display läuft jetzt seit 14 Tagen stabil. Doppelt ärgert mich, dass der Reconnect nach einem WLAN-Ausfall nicht mehr automatisch funktioniert (bleibt alles rot) und der eigenes dafür eingebaute Reset-Knopf zuweilen funktionslos scheint - nur Unterbrechung der Stromzufuhr hilft dann. Normal ist das alles nicht, wieso ballt sich das wieder bei mir? :(
Meine kleine Neben-dem-Bett-Variante ist so groß wie ein 7x10-cm-Foto und arbeitet mit einem "Kästchenmuster" mit Buchstabenkürzeln und Symbolen, die von den LEDs grob hintergrundbeleuchtet werden. Hätte ich einen 3D-Drucker, würde ich mir da was basteln, so ist es mir zu fummlig. Besser als auf den Bildern erkennt man auch so sofort, was gemeint ist. Nur so als andere Umsetzungsidee. Und auch wenn es extrem unschön ist - es war an einem Nachmittag fertig :D Die Presspappe war nur grob zu groß und wurde später auf das genaue Bilderrahmenmaß angepasst.
Moin zusammen,
ich möchte mein Statusdisplay auch zum besten geben, dieses läuft jetzt ca. über ein halbes Jahr zur probe und ca. vor 2 Monaten habe ich es an seinen finalen Standort verfrachtet :)
Die Frontblende hatte ich bereits vor ca. 5 Jahren lasern lassen, hier plante ich den Aufbau jedoch noch mit 5mm LEDs die durch eine Horde von 1Wire DS2408 Bausteinen geschaltet werden sollten, das Projekt lag aber lange Zeit aufgrund der Menge an Einzeladern und dem damit verbundenen Lötfrust hauptsächlich in der Schublade ;D
Durch die Möglichkeiten, die Jokers HomeStatusdisplay im Zusammenspiel mit der neuen Generation von LEDs versprach habe ich mit einigen Stripes herumprobiert, bis ich einen gefunden habe, der den idealen LED Abstand aufwies, der auf die bestehenden Löchern passte, jede LED einzeln abzutrennen und neu verbinden zu müssen hätte das Projekt wieder direkt in die Schublade befördert.
Fixiert sind die LEDs mit Heißkleber, in die 5V Zuleitung habe ich einen Reed Kontakt eingebunden, um das Display jederzeit mit Hilfe eines Magneten reseten zu können oder dauerhaft vom Strom zu trennen.
Auf der Blende sind alle Räume/Bereiche aufgeführt, die über Fenster bzw. Tore verfügen, da das Display seinerzeit lediglich den Fenster/Türzustand anzeigen sollte, ggfs. lasse ich mir irgendwann noch eine Blende erstellen, die auch die restlichen Räume abbildet.
Nun stellt jeweils die erste LED den Fenster/Tür/Tor Zustand dar (Zu=Aus,gekippt=gelb, offen=rot, die zweite signalisiert Bewegung (Keine Bewegung=aus, Bewegung=blinkendes blau) und die dritte zeigt an, ob in dem Raum eine Beleuchtung aktiv ist (Aus=aus, An=orange), die Eingangstür im Windfang hat je nach Schlosszustand noch weitere Anzeigevarianten.
Besten Dank noch einmal für das HomeStatusDisplay!
Greetz
Eldrik
Hallo,
ich habe auf dem Wemos D1 Mini den Sketch hochgeladen , komme drauf mit 192.168.4.1, bei General gebe ich die Daten ein , Save und Reboot gedrücke speichert er nix auf dem Wemos D1 Mini . Bei Neustart sind die Zeilen wieder leer.
was mache ich falsch :-\
Hattest du den Wemos nach dem Flashen mal stromlos?
Ja, sicher. Zweitens: hast du die Konstanten signifikant erhöht? Anzahl Leds?
Ich vermute ein Problem mit der Initialisierung des internen Dateisystems. Mal über den Seriellwandler und einem Monitorprogramm die Bootmeldungen mitlesen... weiter oben habe ich das mal auszugsweise erwähnt.
Bei mir war ESP8266 auf Version 2.5.0 habe es geändert auf 2.3.0 , jetzt geht das speichern auf dem Wemos.
Ich bekomme keine Wlan-Verbindung , mein Wlan-Passwort ist 64 Zeichen lang. Ist es möglich die länge im Sketch anzupassen .
Zitat von: tschonder am 10 August 2019, 12:31:32
Bei mir war ESP8266 auf Version 2.5.0 habe es geändert auf 2.3.0 , jetzt geht das speichern auf dem Wemos.
Ich bekomme keine Wlan-Verbindung , mein Wlan-Passwort ist 64 Zeichen lang. Ist es möglich die länge im Sketch anzupassen .
Blöde Seiteneffekte mit den Versionen. Ich hab schon gar keine Lust mehr auf das Geraffel deswegen.
Habe durch ein wenig Suchen in der HSDConfig.hpp gefunden:
static const int MAX_WIFI_PSK_LEN = 30;Ganz davon abgesehen, dass es für 64 Zeichen lange WLAN-Passwörter nach wie vor absolut keinen Grund gibt und Du ständig Probleme haben wirst...
Danke für die Antwort , Wlan läuft :)
Hallo,
erst mal ein Kompliment, ist ein schönes Stück Software!
Ich habe die Software soweit für mich angepasst, damit es mit FastLed Lib läut und somit auch meine LED's unterstützt ( und noch ein paar mehr :-) ), benutze selber
APA102 mit Data und Clock Pins.
Es funktioniert alles soweit.
Was mich stört, ist ein schönheits Problem , wo ich nicht weiter komme, meine c++ Kenntnisse sind sehr rudimentär.
Die FastLed Lib muss mit konstanten initialisiert werden, sprich es wird mit festen Einstellungen kompiliert und somit hat man keine Möglichkeit mehr
die Pin Einstellungen per Webinterface vorzunehmen.
Kann da mal jemand rüber kucken, vielleicht kann man das irgendwie anders lösen...
Die Sources sind noch ein wenig chaotisch, aber ich denke jemand mit Ahnung steigt da durch.
https://github.com/FastLED/FastLED (https://github.com/FastLED/FastLED)
https://github.com/FastLED/FastLED/wiki/Basic-usage (https://github.com/FastLED/FastLED/wiki/Basic-usage)
https://github.com/FastLED/FastLED/blob/master/examples/Blink/Blink.ino (https://github.com/FastLED/FastLED/blob/master/examples/Blink/Blink.ino)
Sorry, ich sehe gerade das ich im Eifer des Gefechts die falschen source Dateien hochgeladen habe. Sobald ich zu Hause bin, werde ich den Fehler korrigieren.
wie versprochen, hier die richtigen Dateien.
Hi,
ich habe jetzt gerade Weihnachtsbedingt keine Zeit es mir im Detail anzusehen, aber ich bin gar nicht sicher ob ich das Problem richtig verstehe.
Es geht ja im Prinzip um die Methode begin(), die bei dir jetzt so aussieht:
void HSDLeds::begin()
{
m_numLeds = m_config.getNumberOfLeds();
m_ledDataPin = m_config.getLedDataPin();
m_ledClockPin = m_config.getLedClockPin();
m_pLedState = new LedState[m_numLeds];
FastLED.addLeds<LEDTYPE, DATAPIN, CLOCKPIN, COLORORDER>(leds, m_numLeds);
FastLED.setBrightness(m_config.getLedBrightness());
clear();
}
Was spricht dagegen das so zu schreiben:
void HSDLeds::begin()
{
m_numLeds = m_config.getNumberOfLeds();
m_ledDataPin = m_config.getLedDataPin();
m_ledClockPin = m_config.getLedClockPin();
m_pLedState = new LedState[m_numLeds];
FastLED.addLeds<LEDTYPE, m_ledDataPin, m_ledClockPin, COLORORDER>(leds, m_numLeds);
FastLED.setBrightness(m_config.getLedBrightness());
clear();
}
Also einfach die ausgelesenen Werte aus der Config auch zu übergeben?
Es könnte jetzt noch sein dass man das Array "leds" dynamisch allokieren müsste damit auch eine Neukonfiguration geht, im Prinzip so wie ich das mit "m_pLedState" gemacht habe, mit new und delete.
Sorry falsch ich das Problem noch nicht verstanden haben sollte, konnte wie gesagt nur kurz reinschauen ;)
In dem Fall bitte einfach noch mal melden ;)
Zitat
Was spricht dagegen das so zu schreiben:
void HSDLeds::begin()
{
m_numLeds = m_config.getNumberOfLeds();
m_ledDataPin = m_config.getLedDataPin();
m_ledClockPin = m_config.getLedClockPin();
m_pLedState = new LedState[m_numLeds];
FastLED.addLeds<LEDTYPE, m_ledDataPin, m_ledClockPin, COLORORDER>(leds, m_numLeds);
FastLED.setBrightness(m_config.getLedBrightness());
clear();
}
Habe es auch so probiert, die Funktionen habe ich auch implementiert, allerdings meckert der
Compiler über:
src/HSDLeds.cpp:35:84: error: 'this' is not a constant expressionKann ein falscher Rückgabewert / typ den Fehler verursachen?
Zitat von: maclovlin am 26 Dezember 2019, 17:21:23
Kann ein falscher Rückgabewert / typ den Fehler verursachen?
Ne, eigentlich nicht. Das hängt irgendwie mit der Instantiierung der Template-Klassen aus dem FastLED zusammen. Eine gute Idee was man da machen kann habe ich aber auch gerade nicht :(
Zitat von: Joker am 29 Dezember 2019, 09:48:17
Eine gute Idee was man da machen kann habe ich aber auch gerade nicht :(
Ich noch weniger :-)
Aber ist ja eher ein "kosmetisches" Problem.
Man kann ja immer noch konstanten im Quellcode definieren. Kompilieren muss man die Soft eh...
Ich habe für die von mir geänderte Version ein Gitlab repository eingerichtet.
Zu finden unter https://gitlab.com/djusha/homestatusmonitor (https://gitlab.com/djusha/homestatusmonitor)
Wir können die Repos auch zusammen führen, wenn dir die Änderungen gefallen.
Folgende Sachen habe ich geändert:
- Webinterface redesignt, damit es auch auf Smartphones gut aussieht (habe mich an dem Design von Tasmota orientiert)
- FastLED LIB eingebaut, damit mehr LED Typen unterstützt werden
- Verbindung zum MQTT Brocker ist jetzt auch mit Benutzername und Kennwort möglich
- Check ob eine SSID vergeben ist, wenn nicht wird sofort der AP Modus gestartet, wenn ja dann halt WLAN, der ESP ist dadurch schneller einsatzbereit.
und noch ein paar Sachen.
soso... sieht gut aus. Wenn ich das richtig sehe, kann ich das weiterhin für meine WS2812B nutzen? #define HASCLOCKPINANDCOLORORDER
Sonstige Änderungen sind ja wohl kaum am Code?
Ich hatte ja noch Zusatzfarben definiert und die LED-Obergrenze erhöht, gerate da aber offensichtlich an Speicherprobleme. Momentan traue ich mich nicht, die Module anzufassen...
Details ab #113 (https://forum.fhem.de/index.php/topic,68948.msg895184.html#msg895184).
Also mal ganz generell:
Ich nehme gerne Änderungen die allgemein sinnvoll sind in das Repository auf.
Aber das funktioniert NUR, wenn ihr die Repositories als Fork von meinem einrichtet, und dann die einzelnen logischen Änderungen auch einzeln committet. Dann kann ich die Änderungen sehen. So müsste ich ja jetzt das per Hand alles vergleichen und erstmal überlegen was jede Änderung macht und was dazu gehört.
Also der GitHub Workflow ist so:
- Fork des Original Repositories anlegen
- Änderung durchführen (in sich abgeschlossen, nicht mehrere Dinge auf einmal!)
- Pull Request erstellen
Dann sehe ich was ihr gemacht habt, kann es gegebenenfalls noch anpassen und ihr erscheint dann als Contributor im Original repository. Aber wenn das ein komplett losgelösten Repository ist, ist das viel zu viel Aufwand.
Zitat von: Joker am 03 Januar 2020, 11:49:04
Aber das funktioniert NUR, wenn ihr die Repositories als Fork von meinem einrichtet...
Funktioniert das auch mit Gitlab?
Wollte demnächst Github komplett aufgeben...
Zitat von: Pfriemler am 03 Januar 2020, 11:44:55
soso... sieht gut aus. Wenn ich das richtig sehe, kann ich das weiterhin für meine WS2812B nutzen? #define HASCLOCKPINANDCOLORORDER
Sollte an sich klappen.
Du wirst wahrscheinlich deine jetzigen Einstellungen komplett verlieren...
Zitat von: Pfriemler am 03 Januar 2020, 11:44:55
Sonstige Änderungen sind ja wohl kaum am Code?
Doch, musste einiges anpassen, wegen der Passwort Geschichte für MQTT und WLAN.
Zitat von: maclovlin am 03 Januar 2020, 11:53:37
Funktioniert das auch mit Gitlab?
Wollte demnächst Github komplett aufgeben...
Prinzipiell funktionieren eigentlich alle git-basierten Repositories nach diesem Prinzip. Kann man noch viel weiter aufbohren, aber der Grundmechanismus ist immer so.
Wie meinst du das mit Github komplett aufgeben? Gibts öffentliche Repositories mit Gitlab? Ich kenne es nur Firmen-intern bzw. selbst gehostet.
Zitat von: Joker am 03 Januar 2020, 16:46:33
Wie meinst du das mit Github komplett aufgeben? Gibts öffentliche Repositories mit Gitlab?
Klar gibt's die. Auch private Repositories gibts da für umsonst.
Insgesamt bietet Gitlab sehr viele Funktionen die bei Github kosten bzw. nicht existieren.
Du musst es dir unbedingt ankucken.
https://about.gitlab.com/devops-tools/github-vs-gitlab.html (https://about.gitlab.com/devops-tools/github-vs-gitlab.html)
Ja, also Gitlab kenne ich schon, arbeite in der Arbeit jeden Tag damit ;)
Es hat auch einige Funktionen die Github nicht hat, aber die sehe ich jetzt für so Hobby-Projekte wie das HomeStatusDisplay nicht wirklich relevant. Ich werd jetzt nicht anfangen da Time Tracking oder sowas zu betreiben :) Für den professionellen Einsatz liegen die Vorteile klar auf der Hand.
Aber ich glaube wir werden Offtopic ;D Was ich eigentlich nicht verstanden hatte war, dass du schriebst du willst Github komplett aufgeben, aber das liegt ja nicht in deiner Hand. Die Projekte die halt nun mal aktuell auf Github liegen werden deswegen ja nicht plötzlich alle auf Gitlab wechseln. Daher kommst du ja nicht wirklich drum rum wenn du in diesen Projekten mitarbeiten willst.
Zitat von: Joker am 04 Januar 2020, 09:45:04
Daher kommst du ja nicht wirklich drum rum wenn du in diesen Projekten mitarbeiten willst.
Das ist wohl wahr.
Zitat von: maclovlin am 24 Dezember 2019, 13:03:27
https://github.com/FastLED/FastLED (https://github.com/FastLED/FastLED)
https://github.com/FastLED/FastLED/wiki/Basic-usage (https://github.com/FastLED/FastLED/wiki/Basic-usage)
https://github.com/FastLED/FastLED/blob/master/examples/Blink/Blink.ino (https://github.com/FastLED/FastLED/blob/master/examples/Blink/Blink.ino)
Danke. Ich überlege gerade ein Status-Board mit 75 LEDs, komme aber auf 4.5A im Betrieb und damit erheblichen Stromkosten im Jahr.
Kennt jemand eine Erweiterung, die die LEDs nur beim Anschlagen eines PIR-Sensors an dem ESP für eine definierte Zeit aktiviert?
Danke, -MN
Zitat von: Morgennebel am 31 Juli 2020, 12:13:49
Danke. Ich überlege gerade ein Status-Board mit 75 LEDs, komme aber auf 4.5A im Betrieb und damit erheblichen Stromkosten im Jahr.
Es gibt ja noch Low Power Led mit 1mA Stromaufnahme.
Grüße Jörg
Zitat von: JoWiemann am 31 Juli 2020, 14:04:44
Es gibt ja noch Low Power Led mit 1mA Stromaufnahme.
Grüße Jörg
:o Ja? Dann hätte ich mal gerne nen Link zu den LEDs...
(Nur zur Info, in diesem Thread geht es um adressierbare LEDs (durch Adafruit auch als NEOPIXEL bekannt). In einer ,,LED" sind drei LEDs (rot, grün, blau) und ein Microcontroller. Diese LEDs nehmen bei voller Helligkeit (,,weiß") bis zu 60mA Strom auf.)
https://arduino.stackexchange.com/questions/44389/low-power-rgb-led-for-wearable-device
Die WS2812B gibt es auch als WS2812C und WS2812D mit maximal 5mA Stromaufnahme je Farbe, zum Teil WS2812-mini genannt. Auch die gibt es als Stripes, allerdings ist das Angebot geringer (Suche nach WS2812C RGB Stripe, 4mm, 144 LED/m)
Viele Grüße
Manfred
Zitat von: Morgennebel am 31 Juli 2020, 12:13:49
Danke. Ich überlege gerade ein Status-Board mit 75 LEDs, komme aber auf 4.5A im Betrieb und damit erheblichen Stromkosten im Jahr.
Hi, hast du mit max. Strom pro LED gerechnet (60 ma) ?
Ich denke nicht das die LEDs die ganze Zeit mit voller Helligkeit laufen werden.
Ich habe meine mit 10% Helligkeit am laufen und das ist schon ziemlich hell.
Habt Ihr mal über die latente Mengenbegrenzung nachgedacht? Ich betreibe drei der Statusdisplays mit der Firmware von Joker und das auf 50 LED aufgebohrte (mit real 44 genutzten) läuft bei mir im Moment irgendwie instabil und rebootet mehrmals täglich. Ich schiebe das auf Probleme im Speichermanagement.
Die kleineren tun es mit - mit ansonsten identischer Hardware - problemlos.
Ich sollte vieleicht wirklich mal maclovelin's Version ausprobieren...
Hi,
ich klink mich hier mal ein. Heute habe ich auch ein HSD gebaut. Soweit so gut. Leider startet es mit der HSD 0.5 beta nicht und da wollte ich die Version von maclovlin testen. Da ich es mit WS2812B gebaut habe sind ja ein paar Änderungen im Code zu machen.
Die habe ich wie folgt gemacht:
#define LEDTYPE HASCLOCKPINANDCOLORORDER
//#define HASCLOCKPIN
#define HASCLOCKPINANDCOLORORDER
//#define HASALL
Nun bekomme ich beim compilieren folgenden Fehler:
C:\Users\jochen\Documents\Arduino\libraries\FastLED/FastLED.h:472:25: note: template argument deduction/substitution failed:
HSDLeds.cpp:38:67: error: wrong number of template arguments (3, should be 2)
FastLED.addLeds<LEDTYPE, CLOCKPIN, COLORORDER>(leds, m_numLeds);
^
exit status 1
parse error in template argument list
Nun sind meine Programmierkenntnisse eher noch aus der BASIC und Turbo Pascal zeit und somit wollte ich fragen wo ich die passende Info zu den richtigen Argumenten für die WS2812 bekomme und wie der Code dann anzupassen ist?
Gruß Jochen
Hi,
versuche mal das in der HSDLeds.hpp:
#define LEDTYPE WS2812B
#define HASCLOCKPINANDCOLORORDER
Danke, so lässt es sich kompilieren.
Jetzt kommt noch ein Hinweis der aber wohl o.k. sein dürfte:
C:\Users\jochen\Documents\Arduino\libraries\FastLED/fastspi.h:130:23: note: #pragma message: No hardware SPI pins defined. All SPI access will default to bitbanged output
# pragma message "No hardware SPI pins defined. All SPI access will default to bitbanged output"
Nach dem Start des wemos wird auch ein offenes W-Lan aufgespannt, leider kann ich mich aber darauf nicht verbinden. Ich habe es sowohl mit dem Handy als auch mit dem Notebook probiert. Mache ich da was falsch oder habe ich zu viele LEDs dran (57 Stück)?
Gruß Jochen
Warum kannst du dich nicht verbinden? Wirst du sofort rausgeschmissen oder meckert android über nicht vorhandenes Internet?
Der AP ist Kennwort geschützt:
SOFT_AP_SSID "StatusDisplay"
SOFT_AP_PSK "statusdisplay"
Falls zweites zutrifft, "mit Netzwerk trotzdem verbinden" wählen und im Browser die ip vom Status Monitor eintippen.
Die ganzen Daten werden auch, beim start, über serial monitor ausgeben. Der Punkt ist irgendwo in der arduino ide.
Der AP wird als "offen" angezeigt und wenn ich auf verbinden gehe scheint er ein paar mal versuchen sich anzumelden und dann werde ich rausgeschmissen. In W10 erhalte ich die Meldung "keine Verbindung mit dem Netzwerk möglich".
Die SSID ist auch nicht "StausDisplay" sondern "ESP_FE491D". Ist "StatusDisplay" eine Variable?
Gruß Jochen
Blinkt bei dir nach den flashen die Blaue LED an dem ESP Board dauerhaft?
Nein, die blinkt erst nach dem Neustart dauerhaft.
Was mir gerade noch einfällt. Ich habe die ESP8266 Version 2.3.0 zum kompilieren genommen. Ich werde es mal mit der 2.7.4 testen ob eine Veränderung feststellbar ist und dann Rückmeldung geben.
Gruß Jochen
Kuck mal bitte im Serial Monitor nach ob der Code abstürzt, nachdem der Webserver geladen wird (steht in klartext da).
Das habe ich heute bei mir festgestellt, als ich mit deinen Einstellungen kompilliert und geflasht habe.
Der ESP läuft an, blinkt wie wild und im Serial Monitor habe ich folgende Ausgabe (weiß leider noch nicht woran es liegt):
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 3584, room 16
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld
Initializing config.
Mounted file system.
Reading config file /config.json
File size is 220 bytes
Main config data successfully parsed.
JSON length is 220
• host : HomeStatusDisplay
• wifiSSID :
• Hostname :
• wifiPSK : not shown
• mqttServer :
• mqttServerUser :
• mqttServerPass : not shown
• mqttStatusTopic :
• mqttTestTopic :
• mqttWillTopic :
• ledCount : 0
• ledBrightness : 50
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.
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Leider bekomme ich auf dem Serial Monitor bei keiner Baudeinstellung eine brauchbare Ausgabe. Nach dem Neustart blinkt er wie wild. Ich habe gerade die Version 2.4.0 des ESP8266 versucht, keine Änderung im Verhalten. 2.7.1 ist beim Hochladen mit einem Header Fehler abgebrochen.
Gruß Jochen
Habe für dich die letzte Version ausm Repo von Joker kompilliert, mein Wemos D1 mini läuft damit.
Probier mal aus.
Das Tool zum Flashen: https://github.com/marcelstoer/nodemcu-pyflasher/releases
Die Baudrate für den Serialmonitor ist 115200.
Mit Deiner FW konnte ich mich auf die Einstellungsseite einloggen. Nachdem ich auf 57 LED Datapin 2 und meine SSDI gewechselt hatte war wieder Schluss. Jetzt habe ich mal neu geflasht und werde nur die SSID ändern um in mein W-Lan zu kommen. Mal sehen ob das geht.
Einige Tests durchgeführt:
Nur SSID und Passwort eingeben -> Nach dem Neustart logt er sich nicht auf dem W-Lan ein sondern macht wieder das StatusDisplay auf.
Alle Felder in "General" ausfüllen -> Nach dem Neustart ist er zuerst nicht im W-Lan und meldet sich aber auch nicht, nach einer Weile ist er wieder als "StatusDisplay" sichtbar. Allerdings ist der Aufruf der Config Seite 192.168.4.1 nicht möglich.
Soweit der Stand für heute Abend. Morgen werde ich noch mal versuchen selbst zu kompilieren.
Gn8 Jochen
Bin heute erst dazu gekommen die hochgeladenen Firmware zu testen.
Bei mir läuft alles stabil, habe aber auch keine LED's dran, nur das nackte ESP Board.
Wlan geht, ich kann mich drauf einloggen und konfigurieren.
Was für ein Board hast du? Genaue bezeichnung
Hallo,
leider bin ich erst heute wieder zum testen gekommen. Ich habe dieses Board:
D1 Mini NodeMcu 4 MB Byte Lua WIFI Development Board ESP8266 WeMos von L2J8
Um einen Fehler an der Hardware auszuschließen habe ich ein 2. baugleiches auch ohne LED getestet. Selbes Verhalten. Dann habe ich noch das USB Kabel gewechselt und siehe da, nun geht es. Vermutlich war beim Flashen was schief gelaufen. Jetzt kämpfe ich noch mit der MQTT Broker Verbindung die nicht klappen will. Im Feld MQTT-Server kommt wohl die IP:Port und wo kommt das Passwort hin?
Ah, erst jetzt gerade gelesen. Du hast mir die Version von Joker als fw kompiliert. Deshalb kein PW beim MQTT. Auch das Design sieht etwas anders aus.
Gruß Jochen
So,
jetzt habe ich noch mal mit Deiner Version kompiliert und mit dem anderen USB Kabel auch eine Ausgabe auf der Schnittstelle. Mir ist an der Funktion MQTT gelegen. Leider wie auch bei Dir eine Endlosschleife:
ets Jan 8 2013,rst cause:2, boot mode:(3,0)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld
Initializing config.
Mounted file system.
Reading config file /config.json
File size is 220 bytes
Main config data successfully parsed.
JSON length is 220
• host : HomeStatusDisplay
• wifiSSID :
• Hostname :
• wifiPSK : not shown
• mqttServer :
• mqttServerUser :
• mqttServerPass : not shown
• mqttStatusTopic :
• mqttTestTopic :
• mqttWillTopic :
• ledCount : 0
• ledBrightness : 20
Config ⸮(W⸮.⸮⸮⸮⸮⸮ѕ.
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.
Exception (28):
epc1=0x40106860 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: cont
sp: 3fff0d70 end: 3fff1090 offset: 01a0
>>>stack>>>
3fff0f10: 3ffeff78 00000543 00000543 4010020c
3fff0f20: 3fff1020 3ffefb48 3fff0f80 40100690
3fff0f30: 00000000 00000000 3fff4084 00000063
3fff0f40: 00000014 00000002 3fff0f80 4020b1e8
3fff0f50: 00000000 00000000 00000000 00000000
3fff0f60: 14140000 3fff0314 00000000 40100690
3fff0f70: 00000010 00000000 3ffef90c 4020b300
3fff0f80: 00000000 00000000 00000000 00000000
3fff0f90: 14140000 00000314 00000000 40214c34
3fff0fa0: 3ffe8dcc 3ffefd7c 3ffef90c 402124f8
3fff0fb0: 3f141414 000000d3 000000d3 4010020c
3fff0fc0: 4020b29c 00000000 00000000 00000001
3fff0fd0: 00000000 00000000 00000000 40201410
3fff0fe0: 3ffe8dcc 00000000 3ffef90c 00000000
3fff0ff0: 00000000 3ffefd08 3ffef90c 4020ae34
3fff1000: 00000000 00000000 3ffefb48 4020aebe
3fff1010: 00000000 3ffefd08 3ffef90c 4020afa2
3fff1020: 00000000 3ffef930 3ffefb48 4020c51c
3fff1030: 00000000 3ffefb48 3ffeffa0 3ffe8dc4
3fff1040: 3ffe8dcc 3ffeffa0 3ffef938 4020d406
3fff1050: feefeffe feefeffe feefeffe 3fff0060
3fff1060: 3fffdad0 00000000 3fff0059 4020da9e
3fff1070: feefeffe feefeffe feefeffe 40214d68
3fff1080: feefeffe feefeffe 3fff0070 40100710
<<<stack<<<
Hast Du eine Idee an was das liegen könnte?
Gruß Jochen
Nein, noch nicht.
Das Problem tritt komischerqweise nur auf wenn man mit LED Typen kompilliert die keine Clock leitung benötigen.
Die Kompilierung läuft ohne Fehler durch und beit booten kommt es zur einem Bootloop.
Habe auch gesehen, das ich die Pin's falsch betitelt habe, Pin 2 ist normalerweise der Datapin und der Pin 3 ist der Clockpin.
So, offensichtlich mag FastLED es nicht wenn die Anzahl der LED's bei null ist.
Die Repo nochmal downloaden, firmware mit deinen Einstellungen kompilieren und mit NodeMCU PyFlasher flashen (link weiter oben),
ganz wichtig "yes, wipes all data" aktivieren.
Falls der Flashvorgang nicht startet, weil das Board wild am blinken ist, die Reset taste festhalten bis in der Software "Connecting ..." steht,
dann Reset loslassen.
!!! Vorsicht !!!
Die Definitionen haben sich geändert zu:
#define LEDTYPE WS2812B
#define HASDATAPINANDCOLORORDER
#ifdef HASDATAPINANDCOLORORDER
#define DATAPIN 2
#define COLORORDER RGB
#endif
So,
das kompilieren und flashen hat nun funktioniert. Die Weboberfläche meldet sich und nach dem Eintragen der Daten komme ich ins W-Lan und auch eine Verbindung zum MQTT Broker. Die LEDs werden lt. Statusseite korrekt gesetzt. Vielen Dank dafür.
Ein Problem besteht aber noch. Zwar werden lt. Statusseite die LED gesetzt, leider leuchten Sie an der Hardware nicht. Nun bin ich nicht sicher ob evtl. am Board was kaputt ist oder noch der falsche DatenPin definiert ist. Lässt sich das irgendwie rausfinden? Ich habe die LED an D2 angelötet.
Gruß Jochen
GPIO 2 ist Pin D4
Vielen Dank.
Übers WE habe ich mal einige LED programmiert. Was mir noch aufgefallen ist: Die Farben zwischen HTML Seite und Hardware sind verdreht (rot <-> grün). Das ist vermutlich noch eine Anpassung im Code oder?
Gruß Jochen
Ja, die Definition:
#define COLORORDER RGB
ist dafür verantwortlich.
Für eine andere Colororder einfach die Buchstaben tauschen, also "GRB" oder "RBG". Ist vom LED typ abhängig.
Am einfachsten ist wahrscheinlich das Beispielscript aus dem "Examples" Ordner der Fastlib zu kompilieren und zu flashen, um dort mit der Colororder zu "spielen".
Hallo zusammen,
ich wollte mir nun auch ein Display bauen. Ich habe mir den Wemos D1 Mini von az-delivery und ein 1m WS2812E LED Strip geholt. Ein paar kleine Sachen habe ich mit den Arduinos schon gemacht, aber ich stecke nicht sehr tief drin.
Das Board soll man laut az-delivery Doku auf "LOLIN(WEMOS) D1 R2 & mini" stellen.
Ich habe mir die nötigen ESP8266 Bibliotheken zusammengeklaubt. Alle bisherigen Hürden scheinen genommen (massig Compiler-Fehler, JSON, Abhängigkeiten... usw.).
Jetzt wird in WiFiClientSecureBearSSL.cpp folgendes erwartet:
WiFiClientSecureBearSSL.cpp:48:22: error: mmu_iram.h: No such file or directory
#include <mmu_iram.h>
^
compilation terminated.
exit status 1
mmu_iram.h: No such file or directory
Diese mmu_iram.h ist nirgendwo auf github zu finden. Wenn ich die mal spaßenshalber auskommentiere, daß es weitergeht, kommt der nächste Fehler:
WiFiClientSecureBearSSL.cpp:50:40: error: umm_malloc/umm_heap_select.h: No such file or directory
#include <umm_malloc/umm_heap_select.h>
^
compilation terminated.
exit status 1
umm_malloc/umm_heap_select.h: No such file or directory
Kann mir da mal jemand auf die Sprünge helfen? Das ist ja ein echter Krampf mit dieser Arduino-IDE.
Gruß Roland
Erstmal Entwarnung :-)
Ich habe mir in einer Win10-VM ein jungfäuliches Arduino-IDE und die genannten Libs installiert. Damit lief zumindest der Compiler durch. Ich habe auf meiner Stamm-Maschine mehrere Versionen der IDE, weil ESPEasy auch nur mit einer älteren Version geht. Wahrscheinlich ist da irgenwas vergurkt.
Jetzt muß ich nur noch kucken, wie den seriellen Port durchgeschleift kriege.
Gruß Roland
Ich kann jeden nur Empfehlen zum Kompilieren / Programmieren auf Platform IO umzusteigen:
https://platformio.org/ (https://platformio.org/)
Die benötiten LIBS sind ja bei mir auf der Gitlab Seite aufgeführt, diese einfach in den Ordner "libs" des Projektes kopieren und dann kompilieren.
Ich finde Platformio vom handling her viel angenehmer und problemloser als Arduino IDE.
Danke für den Tip, das kuck' ich mir gleich mal an. Das wäre mir sympathisch, ich habe etliche Jahre mit VisualStudio gearbeitet...
Für das HomeStatusDisplay habe ich als Zwischenlösung das Projekt in meiner VM als Binary kompiliert und via ESPFlasher auf den Wemos gepackt. Der serielle Port war in der VM nicht zur Mitarbeit zu bewegen.
Ich habe aber jetzt gerade ein anderes Problem. Ich habe nun ein paar LEDs konfiguriert. Die ersten neun waren Fenster, die sollten nur "weiß - on" gehen. Bis dahin klappt alles. Jetzt will ich die 18. LED als Sonderfall in Orange leuchten lassen. Die geht aber nur weiß. Wenn ich die anderen jetzt nachträglich auf andere Farben und Verhalten stelle, gehen alle nur "weiß- on". Weder Farbzuweisung noch blink, flash oder flickr geht. Ich habe bei Tests mit der ersten LED und einem dummy-Fenster in fhem die Farben und Verhalten durchprobiert, da ging alles.
Habe ich da irgendwas übersehen? Ist es möglicherweise ein Problem, daß ich einige LEDs des stripe auslasse, weil an der Stelle das Design der Schablone, die drüber liegen soll, eine Lücke hat? Ich habe als Widerstand einen 470 Ohm und als Kondensator einen 470 myF dran, die hatte ich noch rumliegen.
Gruß Roland
Zitat von: hauwech am 14 Dezember 2020, 15:22:11
Ich habe aber jetzt gerade ein anderes Problem. Ich habe nun ein paar LEDs konfiguriert. Wenn ich die anderen jetzt nachträglich auf andere Farben und Verhalten stelle, gehen alle nur "weiß- on". Ich habe als Widerstand einen 470 Ohm und als Kondensator einen 470 myF dran, die hatte ich noch rumliegen.
Gruß Roland
Ich hatte in letzter Zeit Probleme mit verschiedenen Stripes. Probiere mal statt 470 Ohm 2,2 kOhm.
Mit 2,2 kOhm laufen bei mir alle. (WeMos D1 mini Pro)
Billy
Keine Änderung mit 2,2k Ohm, nur weiß-on/off.
Zitat von: hauwech am 14 Dezember 2020, 16:04:42
Keine Änderung mit 2,2k Ohm, nur weiß-on/off.
Schade. :'(
Könnte auch an der Stromversorgung liegen?
Ich teste meine Stripes in Verbindung mit dem Wemos immer vorher mit Tasmota.
Da kann ich einfacher testen ob alles funktioniert.
Wenn ja dann flashe ich um für HSD.
Bei mir laufen 3 HSD Problemlos.
Mir ist gerade aufgefallen, daß beim Anstecken im Status "kein WLAN" die letzen 20 der 60 LEDs gar nicht angehen. Ich habe das empfohlene 2,4A Anker Steckernetzteil dran. Allerdings nehme ich nur die 5V vom 5V PIN des Wemos ab. Die sollten ja laut Beschreibung am Wemos Mini vom USB Anschluß durchgeschleift sein.
Ich hoffe, daß der Stripe kein Rückläufer ist. Ich hatte mich gewundert, daß das Tütchen, wo er drin war, bereits seitlich aufgeschnitten war.
Zitat von: hauwech am 14 Dezember 2020, 16:37:31
Mir ist gerade aufgefallen, daß beim Anstecken im Status "kein WLAN" die letzen 20 der 60 LEDs gar nicht angehen.
Die Original Konfiguration ist m.W. auf 35 LED begrenzt! ;)
Wenn du nichts in der HSDConfig.hpp verändert hast kann das mit 60 nicht gehen.
Siehe auch Beiträge dazu von Pfriemler.
Häng mal einfach einen kurzen Streifen mit z.B 10 LED ran und teste ob alles geht.
Blinken, Farbe etc.
Wenn ich das richtig verstanden habe, konnte man in dieser Version über die WebGUI auch nur 30 oder 35 LEDs auswählen. In der Version, die ich geflasht habe, kann man mehr einstellen. Immerhin: ich hatte unter General 40 eingestellt, das erklärt, warum nur die ersten 40 angehen. ;D Wenn ich 50 einstelle, gehen auch 50 an.
Du warst schneller :-)
Ich mit einem Breadboard Netzteil jetzt mal 5V zusätzlich an den Stripe gegeben, geht trotzdem nur weiß on/off. Einen 470 myF Elko habe ich auch nochmal dazu gesteckt, ändert auch nix.
Mit wieviel LED im Stripe?
Ich habe den stripe jetzt auf 16 LEDs abgeschnitten, soviel will ich in einer Spalte haben. Geht nur weiß on/off :-(
Mit Farbe, blink, flickr usw. geht nur die erste LED. Alle anderen gehen nur weiß on/off. Wenn ich den Wemos aber anstecke, gehen ALLE rot bzw. gelb (kein MQTT) und grün. An den stripe LEDs selbst kann es also nicht liegen.
Probiers mal wenn du willst mit der Original bin.
Flashen mit
Das Tool zum Flashen: https://github.com/marcelstoer/nodemcu-pyflasher/releases
Mehr fällt mir auch nicht ein!
Ist das binary für den Wemos mini (ohne Pro) compiliert? Ich mußte in der Arduino IDE laut Doku von AZ Delivery den "LOLIN(WEMOS) D1 R2 & mini" auswählen. Den source code habe von Jokers Github, das sollte eigentlich auch "original" sein.
Habe gerade nochmal gekuckt: static const char* VERSION = "0.6_dev";
Zitat von: hauwech am 14 Dezember 2020, 17:15:50
Mit Farbe, blink, flickr usw. geht nur die erste LED. Alle anderen gehen nur weiß on/off. Wenn ich den Wemos aber anstecke, gehen ALLE rot bzw. gelb (kein MQTT) und grün. An den stripe LEDs selbst kann es also nicht liegen.
Frage: 1. Du kannst also über MQTT die 1. LED komplett ansprechen
2. Du kannst also über MQTT die anderen LED einzeln ansprechen? nur on off weiß.
habe ich das richtig verstanden?
Richtig!
Zitat von: hauwech am 14 Dezember 2020, 17:54:17
Richtig!
Stell deine Konfiguration mal hier ein, sonst ist das Kaffeesatzleserei.
Nicht dass es daran liegt! Das reicht für die ersten z.B 5 leds
Natürlich nur wenn du willst. Ansonsten schönen Abend.
Die letzen Drei zeigen auf die indessen abgeschnittenen LEDs, Device #1 bekommt das topic "test" von meinem fhem dummy-Fenster und sollte weiß flickern, geht aber nur an/aus.
Das mapping open/closed auf 0/1 ist eine IOBroker Krücke, also nicht wundern, daß ich mit "Message 1" arbeite.
state:topic={"state/HG/ke/$base"} state:expression={($value eq 'open')?'1':'0'} state:topic={"fhem/status/window/test"}
battery:topic={"state/HG/ke/$base"} battery:expression={($value eq 'low')?'1':'0'}
Mit dieser Einstellung auf LED0 geht's: die flasht orange.
Aus meiner Sicht verstehe ich dein Color mapping nicht.
Message immer 1 ist dein Problem!
Kann so nicht funktionieren :'(
Schau mal hier
https://www.bernd-schubart.de/wp-content/uploads/2017/06/homestatusdisplay_39.png
Color mapping sieht bei mir z.B so aus!
Die Fensterkontakte senden via mqtt anstatt open/closed "1" und "0", deswegen Message=1 (=open).
Das mußte ich damals so bauen, weil die IOBroker Widgets kein open/close, sondern nur 1/0 verstehen.
Wenn das hier an der Stelle falsch wäre, würden die LEDs auf das mqtt topic gar nicht reagieren und nicht an/aus gehen, oder?
Da hast du einiges nicht verstanden?
Wie willst du z.B bei gleichen Messages (1) und gleichen Type (alle Window)
unterschiedliche Behavior bekommen!
Du wunderst dich dann wieso meistens alle weiß on/off reagieren.
Steht eigentlich alles in der Doku.
So ich klinke mich jetzt für heute aus,
Hallo Billy,
ich will ja nicht rechthaberisch rüberkommen und ich möchte Dich für Deine Hilfsbereitschaft auch nicht ärgern :)
Jedes device hat doch ein anderes topic. Um beim Beispiel zu bleiben:
Badfenster:
- fhem/status/window/Bad
Die resultierenden messages lautet dann:
- Badfenster auf: fhem/status/window/Bad 1
- Badfenster zu: fhem/status/window/Bad 0
Test-"Fenster":
- fhem/status/window/test
message:
- Test-Fenster auf: fhem/status/window/test 1
- Test-Fenster zu: fhem/status/window/test 0
Ich hatte bisher angenommen, daß die "Nr" im ColorMapping mit der "Nr" im DeviceMapping korrespondiert und auf die LED verweist.
Damit bin ich aber scheinbar auf dem Holzweg. Ich muß mir das alles nochmal in Ruhe anschauen.
Gruß Roland
Ich glaube, jetzt habe ich's gerafft. ::)
Ich dachte, man kann mit der "Nr"-"Nr" Beziehung für jede LED für den Fenster-Zustand "offen" eine andere Farbe/Verhalten im Colormapping festlegen. Deshalb hatte ich für jede LED-Nr ein colormapping angelegt.
Wie es aussieht, kann man Farbe/Verhalten nur pro DeviceType festlegen.
Danke, Billy, Deine Colormapping config hat mich erleuchtet.
Gruß Roland
Zitat von: hauwech am 14 Dezember 2020, 21:12:53
Ich glaube, jetzt habe ich's gerafft. ::)
Danke, Billy, Deine Colormapping config hat mich erleuchtet.
Gruß Roland
Gern geschehen
Gruß Billy
Hi, hier noch eine kurze Rückmeldung von mir:
Mein HSD mit 57 LED läuft nun seit Anfang November. Vielen Dank an dieser Stelle noch mal an Mclovlin. Die Firmware scheint nicht zu 100% Stabil zu sein. Das ist ja ein bekanntes Problem bei so vielen / zu vielen LED. Da ich es aber so montiert habe dass ein Neustart nur eine Sache von Sekunden ist kann ich mit einem Absturz alle 2-3 Wochen gut leben. Noch sind nicht alle LED belegt aber es werden wöchentlich mehr die genutzt sind. Es scheint keinen Einfluss auf die Abstürze zu haben wie viele genutzt sind sondern nur die Anzahl der eingebauten/in der FW freigeschalteten LED bringen die Probleme.
Wenn es was neues gibt werde ich Bericht erstatten.
Gruß Jochen
Danke für die Rückmeldung Jochen1977.
Wie äußert sich der Absturz? Ist der Controller dabei noch per WLAN erreichbar?
Wenn der Controller abgestürzt ist leuchten alle LED rot was ja bedeuten sollte kein W-Lan. Aber wirklich probiert habe ich das noch nicht :-[ Wenn es das nächste mal auftritt versuche ich ob ich ihn im Netzwerk noch erreichen kann.
Gruß Jochen
Kuck mal bitte ob es mit den neustart der Fritzbox / Routers zusammenhängt. Habe festgestellt das der Controller sich nicht wiederholt verbindet wenn WLAN oder der MQTT Server aus irgendwelchen Gründen nicht erreichbar oder ausgefallen ist.
Bei mir passiert es, wenn ich z.B meinen Docker Stack neu starte wo der MQTT Server drauf läuft, dann lechten die LED's dauerhaft gelb, bis ich den Controller mit dem
Resettaster resete.
Ich habe mein HSD nun am Laufen.
Hier war immer mal die Rede von einem c't Projekt für WS2812 Steuerung. Ich habe noch einen Wemos rumliegen zum Experimentieren. Könnte mir bitte mal jemand einen Tip geben, wo ich was zu dem c't Projekt finden könnte?
https://www.heise.de/select/ct/2018/18/1535268230640696
Wenn Du mehr wissen möchtest, frag doch mal jemanden heimlich von dem Du denkst dass er den Artikel haben könnte ....
Zitat von: maclovlin am 20 Dezember 2020, 10:38:30
Habe festgestellt das der Controller sich nicht wiederholt verbindet wenn WLAN oder der MQTT Server aus irgendwelchen Gründen nicht erreichbar oder ausgefallen ist.
Die Versuche der Wiederverbindung sind auf eine bestimmte Anzahl Wiederholungen mit einem bestimmten Intervall begrenzt. Ich habe beides so angepasst, dass das Display mehrere Minuten einen Reconnect versucht. Reicht bei Firmwareupdates etc. dennoch nicht aus.
Alle meine Versuche, meine drei Displays zu stabilem Verhalten zu überreden, sind bislang nicht von Erfolg gekrönt. Aus nicht nachvollziehbaren Gründen verliert eines der Displays mal alle 20min, mal nach 2h den Kontakt zum MQTT-Server (hier noch als Mosquitto auf dem Raspi, also nicht MQTT2). Da das Verhalten aber immer nur einzelne Displays zeigen, nie alle zusammen, handelt es sich dabei eher nicht um ein Problem des MQTT-Servers. Die anderen beiden steigen in völlig unregelmäßigen Abständen inklusive WLAN-Verbindung aus (erst voll-rot, dann voll-gelb, dann Wiederaufnahme). Da ich praktisch alle MQTT-Messages mit retain sende, passiert der anschließende Wiederaufbau des Dispays ohne Zutun von FHEM automatisch. Immerhin. Dort sieht es mir eher nach einem Reboot aus, denn das WLAN hat zu diesen Zeiten eigentlich nie Störungen gehabt. Checks über den seriellen Monitor stehen noch aus.
Nachts im Schlafzimmer ist die vollflächige gelbe Beleuchtung bis zum Reconnect trotz extrem reduzierter Helligkeit nicht lustig. Ich habe das .setAll in der Reconnect-Routone nun durch eine einzelne rot blinkende 1. LED ersetzt, warum nicht gleich so ... ein setAll im Start ist ja sinnig zur Erstkontrolle der Verdrahtung, aber danach doch entbehrlich, zumal es ja auch entsprechende Test-Befehle gibt.
Auch die Reduktion der LED-Anzahl auf 30 (wie Original, um Speicherplatzproblemen zu entgehen) hat nichts gebracht in Sachen Stabilität. Zumindest das Schlafzimmerdisplay macht hier keinen Reboot nach Absturz, sondern meldet nur einen Reconnect zum MQTT über den seriellen Monitor (leider auch zuvor keinen Verlust der Verbindung, aber das kann ich ja leicht nachzurüsten in der Firmware), es findet kein Reboot statt (keine Meldungen diesbezüglich, auch die Uptime zählt weiter hoch). Allerdings zeigt es auch im Gegensatz zu den anderen Displays nie vollflächig rot (Verlust der WLAN-Verbindung), was aber auch damit zusammenhängen kann, dass es über einen Repeater verbunden ist, dessen WLAN weiterläuft, wenn die Fritte rebootet oder sonst zickt.
Moin Zusammen,
seit längerem habe ich schon ein Display in Verwendung.
Aktuell schalte ich es via Zwischenstecker komplett An oder halt Aus.
Ich frage mich aktuell, ob ich mir evtl. den Zwischenstecker sparen kann und das Display anderweitig ausschalten kann, ohne dem WeMos den Strom komplett zu klauen? :D
Ein allgemeines On / Off existiert bei dem Display ja nicht oder habe ich hier grundlegend was übersehen?
Gruß
Hier noch mal eine Rückmeldung von mir:
- Das Display ist jetzt mehrmals "rot" geworden. Da ich im selben Zeitraum auch Probleme mit meinem W-Lan hatte tippe ich stark darauf dass es sich nicht re-connected wie mclovlin geschrieben hat. Zu meinem Erstaunen war es per W-Lan erreichbar.
Nachdem ich meine Proleme mit dem W-Lan "hoffentlich" aussortiert habe läuft es jetzt wieder stabil.
Gruß Jochen
Zitat von: t1me2die am 28 Dezember 2020, 13:32:22
Ein allgemeines On / Off existiert bei dem Display ja nicht oder habe ich hier grundlegend was übersehen?
Nein das gibts nicht.
Zitat von: Jochen1977 am 04 Januar 2021, 21:37:04
- Das Display ist jetzt mehrmals "rot" geworden. Da ich im selben Zeitraum auch Probleme mit meinem W-Lan hatte tippe ich stark darauf dass es sich nicht re-connected wie mclovlin geschrieben hat. Zu meinem Erstaunen war es per W-Lan erreichbar.
Hmm, ein Bug oder ein Feature... ;-)
Ich kucke da mal nach dem rechten wenn ich wieder ein wenig Zeit habe.
Das generelle on/off könnte man mal nachrüsten per topic. Bei der Gelegenheit gleich noch eine GPIO-Abfrage einbauen, um so vielleicht gleich ein manuelles Ein/Ausschalten per Taster am Display zu ermöglichen. Eine zusätzliche Variable und eine Abfrage derer in der 10x/sek aufgerufenen Senderoutine und der Drops ist gelutscht.
Mein eines unregelmäßig rot werdendes Display hängt nun am PC mit einem seriellen Monitor in Überwachung, dort habe ich lediglich den Hinweis bekommen, dass der Watchdog Resets ausgelöst.
Hallo,
nachdem mein HSD nun lange und problemlos gelaufen ist bin ich an die Grenze von 37 Einträgen im Device Mapping gekommen. Das ist mir gar nicht aufgefallen dass die LED Anzahl zwar im Webinterface auf 57 gesetzt werden kann aber die Einträge in der Software auf 37 begrenzt sind. Nun wollte ich die Firmware neu kompilieren aber leider lässt sich die neu kompilierte Firmware nicht auf dem Wemos starten. Da ich meinen PC neu aufgesetzt habe ist vermutlich bei den Updates der Arduino Software etwas neu hinzugekommen daß den Firmwarestart verhindert. Zum Thema Firmware mache ich mal einen neuen Thread auf damit das hier nicht unübersichtlich wird. -> Hier lang https://forum.fhem.de/index.php/topic,122226.0.html (https://forum.fhem.de/index.php/topic,122226.0.html)
Hei,
ich nutze auch einen AZ, der Code kompiliert ohne Probleme aber ich bekomme ständig exceptions.
Gibt es irgendwo eine Info (ich habe sie jedenfalls noch nicht gefunden) mit welchen IDE/Bibliotheksversionen der Sketch funktioniert? Mit den Firmware die hier im Thread verfügbar sind klappt es, es ist somit kein HW Problem.
Danke und Grüße
Christian
Hi,
hier: https://gitlab.com/djusha/homestatusmonitor
unter compile oder in der Platform.ini
Zitat von: maclovlin am 16 Januar 2022, 09:12:55
Hi,
hier: https://gitlab.com/djusha/homestatusmonitor
unter compile oder in der Platform.ini
Danke,
ich bekomme das auch mit den Angaben nicht kompiliert, sowohl in der Arduino IDE als auch mit einem extra installierten PlatformIO.
VSCode bringt den Fehler
no return statement in function returning non-void [-Werror=return-type] [218,1]
no return statement in function returning non-void [-Werror=return-type] [272,1]
Ich habe mit Git heute den Code auf meinen Rechner kopiert.
Kannst Du mir da einen Tip geben? Gerne auch per PM um den Thread nicht zu kapern ...
Grüße
Christian
Clone nochmal die Repo und probiere es nochmal, müsste jetzt durchlaufen, mit ner Menge Warnings ;-)
Denk an die korrekte Config
Hallo Zusammen,
ich habe mir das hübsche Projekt auch angesehen und plane aktuell die Umsetzung.
Allerdings müsste ich die Einstellungen doch "etwas" aufbohren, da bei mir ca. 80 LEDs zur kompletten Anzeige benötigt werden
und ich gerne die erforderliche Speichergröße berechnen möchte.
Wo ich noch nicht ganz dahintergestiegen bin, ist das Verhältnis zwischen
MAX_SIZE_DEVICE_MAPPING_CONFIG_FILE
und
JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE
ich habe in den Sketch mal ein paar Debugzeilen eingearbeitet.
Der Inhalt von der Datei "devicemapping.json" lautet:
{
"0":{"n":"1234567890123456789012345","t":1,"l":0},
"1":{"n":"1234567890123456789012345","t":1,"l":1},
"2":{"n":"1234567890123456789012345","t":1,"l":2}
... etc.
}
Würde also bedeuten das ich bei voller Nutzung aller LEDs (35 Stück) und max. Länge des Devicenamens (25 Zeichen) + 2 Klammern auf
1732 Zeichen komme.
Im Code steht nun:
static const int MAX_SIZE_DEVICE_MAPPING_CONFIG_FILE = 1900; // 1801 exactly
static const int JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE = 4000; // 3908 exactly
Demnach habe ich beim ConfigFile (1801 exactly) 69 Zeichen Differenz (sofern der Comment im Code stimmt), die ich mir nicht erklären kann.
Ebenso unklar ist mir die Bedeutung/Errechnung des Buffers.
Kann mich da Jemand erhellen ?
Gruß,
JudgeDredd
Hallo,
letzte Woche habe ich ein paar neue Funktionen auf die LED zugeordnet. Zuerst hatte ich das Problem dass das Devicemapping gelöscht wurde wenn ich neue Definitionen eingetragen hatte. Das lag wohl daran dass der Speicher zu Ende war (57 LEDs). Um das zu umgehen habe ich die Namen gekürzt. Also statt Alle_Fenster ist der Device Name nun A_Fe. Somit habe ich genug Platz um alle gewünschten LEDs zu benennen.
Nun ist es aber so daß nach einiger Betriebszeit alle LEDs dunkel werden und dann erst beim nächsten Publish wieder anzeigen.
Vermutlich liegt hier also das selbe Problem vor dass der Speicher zu Ende ist.
Jetzt wollte ich die Firmware neu kompilieren und bekommen hier die Fehlermeldung:
Compilation error: no return statement in function returning non-void [-Werror=return-type]
in der Zeile bool HSDConfig::readColorMappingConfigFile()
{
bool success = false;
.... der Datei HSDConfig.cpp
beim letzten mal hat diese Version funktioniert. Das ArduinuJson habe ich im Arduino IDE von Version 6 auf 5 zurückgestellt da mir das zuvor als Fehler angezeigt wurde.
Könnte mir bitte jemand sagen was hier falsch läuft?
Danke und Gruß Jochen
Moin Jochen,
bei mir kompiliert die Firmware einwandfrei.
Muss dazu sagen, das ich mein Repo genommen habe und mit PaltformIO kompiliert habe.
Bin aber aus einem anderen Grund hier und zwar kam ja mal der Wunsch auf, den Rahmen automatisch neu zu starten.
Ich benutze mittlerweile HomeAssistant und habe es so gelöst:
config.yaml
shell_command:
reboot_led_frame: 'curl -X Post -m 2 -s http://192.168.178.120/?reset=Reboot > /dev/null'
automations.yaml
- id: '1688710085020'
alias: WHZ Reboot LED Frame
description: ''
trigger:
- platform: time
at: 00:01:00
condition: []
action:
- service: shell_command.reboot_led_frame
data: {}
- service: notify.signal
data:
message: LED Frame neugestartet
mode: single
Hallo,
ich nutze das Homestatusdisplay seit einigen Jahren und finde es echt toll.
Leider bin ich jetzt gezwungen ein neues System aufzusetzen und habe da so meine Probleme, denn ich bekomme beim Hochladen des Sketch mit Arduino IDE ständig Fehlermeldungen.
Ich habe mir extra ein neues Linuxsystem aufgesetzt und Arduino neu installiert.
Ich bin exakt (soweit das mit den neueren Softwareversionen möglich ist) nach der Installationsanleitung vorgegangen (mehrfach!):
https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/ (https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/)
Nach einem ersten Hinweis über Google-Suche habe ich die ArduinoJson-Version heruntergesetzt. Dann bekam ich andere Fehlermeldungen. Wieder eine neue ArdunioJson-Version, wieder andere Fehlermeldungen.
Mein laienhafter Verstand sagt mir, dass es wahrscheinlich mit irgendwelchen Softwareständen zu tun hat. Ich bin aber nicht sicher.
Seit der Anleitung in dem Link hat sich einiges verändert. Sowohl Arduino IDE selbst, als auch die ganzen Softwarepakete sehen alle anders aus.
Daher weiß ich nicht, was ich wo genau einstellen muss. LEIDER nutze ich Arduino IDE auch nur ca. alle 2 Jahre mal, so dass ich mich damit nicht gut auskenne.
kann mir jemand sagen, was genau ich wo einstellen muss, um einen Wemos D2 mini zu flashen und welche Softwareversionen ich einstellen soll?
Vielen Dank!
Edit: 24.12.2023
Ich habe jetzt mit einigen Versionen herumprobiert und eine Lösung für mich gefunden. Ich dokumentiere sie hier, denn vielleicht hat ja irgendwer irgendwann das gleiche Problem.
Folgendes funktioniert bei mir:
Arduino DIE 1.8.19
ESP8266 Version: 2.5.2
Adafruit_NeoPixel: https://github.com/adafruit/Adafruit_NeoPixel Version: 1.8.2
PubSubClient: https://github.com/knolleary/pubsubclient Version: 2.5.0
ArduinoJson: https://github.com/bblanchon/ArduinoJson Version: 5.12.0
Die Einstellungen unter "Werkzeuge" hänge ich als Screenshot an.
Ziemlich genau so etwas habe ich letztes Jahr als "Internet-Ampel" für meine >80jährige Mutter gebaut. Das Teil prüft, ob WLAN geht, die Fritzbox-Homepage und ein paar andere strategische URLs und Ports (SMTP Submission, IMAPS) funktionieren. Das hat meinen Remote-Support-Aufwand massiv verringert.
Als Gehäuse für so etwas ist ein Ikea-Bilderrahmen (SANNAHED) hervorragend geeignet. Bei dem lässt sich die Kunststoffscheibe samt Passepartout an die Front verschieben, dann hat man genug Tiefe für die Elektronik.
Die Frontbeschriftung habe ich einfach auf Papier gedruckt. Dahinter eine dünne Pappe, vor den LEDs habe ich ein Loch in die Pappe, aber nicht ins Frontpapier gestanzt. Damit dient das Frontpaier als Diffusor und alles sieht ordentlich aus.