HomeStatusDisplay (ESP8266, MQTT, WS2812B)

Billy · 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

Billy · 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/

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

eldrik · 08 Januar 2019, 09:35:10

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

Tobias · 08 Januar 2019, 10:44:17

Jupp, meins mit 54 läuft auch 1a

Gesendet von iPhone mit Tapatalk

Joker · 08 Januar 2019, 11:12:38

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/

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:

Code Auswählen

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

Billy · 08 Januar 2019, 11:57:16

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:
Code Auswählen Erweitern
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

Code Auswählen

static const int MAX_SIZE_DEVICE_MAPPING_CONFIG_FILE = 1900;    // 1801 exactly
static const int JSON_BUFFER_DEVICE_MAPPING_CONFIG_FILE = 4000; // 3908 exactly

sollte ich für 41 LED's nehmen ?

Billy

Pfriemler · 08 Januar 2019, 12:34:38

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.

Billy · 11 Januar 2019, 19:26:31

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

Pfriemler · 12 Januar 2019, 12:58:07

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.

Billy · 12 Januar 2019, 14:19:13

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.

Pfriemler · 20 Januar 2019, 15:21:23

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

Pfriemler · 25 Januar 2019, 14:11:48

So, hier die von mir in Post #113 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

Code Auswählen

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:

Code Auswählen

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:

Code Auswählen

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.

Code Auswählen

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

Code Auswählen

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:

Code Auswählen

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.

Billy · 25 Januar 2019, 19:32:32

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

Pfriemler · 26 Januar 2019, 09:48:11

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

Joker · 28 Januar 2019, 12:34:18

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.