HomeStatusDisplay (ESP8266, MQTT, WS2812B)

[Pfriemler]

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?.

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?

[Billy]

Legt Mosquitto die Messages dauerhaft in Files, so dass sie nach einem Neustart des Servers wieder präsent sind?

Ja, die werden gespeichert!

[Joker]

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.

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. 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...

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.

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...

Ja, die werden gespeichert!

Jain. Es hängt von der persistence-Einstellung in mosquitto.conf ab.

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?.

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...

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.

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 

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.

[Pfriemler]

Gut, Github kommt, aber lass mir bitte Zeit  ... in der zweiten Lebenshälfte wird man langsamer.

Es gibt den Arduino Filesystem Uploader. ...

Probier ich mal aus und berichte.

Helligkeit ... 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.

GPIO: ... 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. 

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.

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.

Es 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.

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

.
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.

[Pfriemler]

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.

[AxelSchweiss]

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.

[Pfriemler]

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.

[AxelSchweiss]

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" 

[Pfriemler]

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...

[Pfriemler]

Hier mal ein paar Details dazu aus der seriellen Konsole:
Neustart:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

Need to delete all color mapping config entries
Header size: 1279
Page size: 3310
Free RAM: 24200

und drücke anschließend UNDO.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

Reading config file /colormapping.json
File size is 659 bytes
Color mapping config data successfully parsed.
JSON length is 659


Nach Delete und Undo:

Code Auswählen Erweitern

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....

[Pfriemler]

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.

[Pfriemler]

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  Die Presspappe war nur grob zu groß und wurde später auf das genaue Bilderrahmenmaß angepasst.

[eldrik]

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 

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

[tschonder]

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

[Pfriemler]

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.