HomeStatusDisplay (ESP8266, MQTT, WS2812B)

[Joker]

Hi Marco,

wow was für ein langer Text 
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.

[Tobias]

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.

[Joker]

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

[marco-f]

Hi,

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 :-(

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

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.

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.

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.

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

[Firetic]

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 

Kann mir jemand sagen wo mein Denkfehler liegt...

Danke und Gruß
Firetic

[Tobias]

Mein Tipp nicht als copy&paste sehen, war aus dem Kopf heraus

Wifi.cpp = hsdwifi.cpp

Gesendet von meinem Leap mit Tapatalk

[Tobias]

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.

[Joker]

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

[marco-f]

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

[Joker]

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 oder hier.
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)...

[Tobias]

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

[Pfriemler]

Da ich gerade am Bauen bin: Die Levelshifterproblematik kann man laut Hackaday mit nur einer Diode lösen...

Aber das kapiere ich jetzt nicht:
Provisorisch nutze ich den in FHEM definierten MQTT-Broker zum Senden, bspw.

Code: [Auswählen]

set myBroker publish fhem/cmd/statusdisplay_01/test 2worauf 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

Code: [Auswählen]

set myBroker publish fhem/status/fhemhealth ondie LED 1 weiß einschalten sollte. Der Mosquitto auf Betriebssystem zeigt auf Betriebssystemebene

Code: [Auswählen]

Client mosqsub|8538-raspberryp received PUBLISH (d0, q0, r0, m0, 'fhem/status/fhemhealth', ... (2 bytes))
fhem/status/fhemhealth onEs tut sich aber  ... nichts. Warum?

P.S.: meine OBI-Steckdose kann ich mit dem topic aus dem publishSet einwandfrei schalten:

Code: [Auswählen]

set myBroker publish cmnd/SmartHome/mobile/OBIplug1/POWER ON

[Joker]

Hi,

der Befehl muss in deinem Beispiel so aussehen:

Code: [Auswählen]

set myBroker publish fhem/status/light/fhemhealth on

[Pfriemler]

ach ... da kommt doch meine sig wieder zu Ehren.

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

[Joker]

ach ... da kommt doch meine sig wieder zu Ehren.

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.

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

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?