Meinungsaustausch zu Updates, Konfiguration, etc.

[D-ominik]

Das hier ist wirklich ein tolles Projekt. Ich habe inzwischen 6 Uhren gebaut (alle identisch als 10x11), davon 5 verschenkt. 3 weitere sind gerade in Arbeit. Obwohl in der Zeit diverse Firmware-Versionen veröffentlicht wurden, haben alle diese Uhren noch Version 3.3, weil die jeweilige Version beim Bau gerade einen Bug oder dergleichen hatte und die Zeit es nicht erlaubte, da erst etwas zu fixen. Ist auch kein Problem, weil die Grundfunktionen bei 3.2 bis auf eine Kleinigkeit gut und zuverlässig funktionieren und MQTT bei den Beschenkten nicht genutzt wird. Dennoch bleibt ein gewisser Eindruck von stetiger Verschlimmbesserung bzw. immer mehr Inkonsistenzen.

Daher möchte ich diese Diskussion anregen, denn mein Eindruck ist, dass es derzeit keine Leitlinien für die Weiterentwicklung gibt. Vielleicht ist aber auch meine Sichtweise falsch.

Grundsätzlich ist es vorgesehen, die Firmware der Uhren eigenständig durch Laien zu aktualisieren. Entsprechende Links und Funktionen sind im Web-Interface vorhanden und im Repository werden fertige Firmware-Builds angeboten. Das ist super, aber es erfordert meiner Meinung nach ein paar Rahmenbedingungen, die derzeit nicht erfüllt sind:

Beständigkeit der Konfiguration

Scheinbar mit jedem Release wird die Konstante SERNR geändert, wodurch die Nutzereinstellungen verloren gehen. Installiert der Nutzer ein anderes Release, muss er die WLAN-Zugangsdaten neu eintragen und sich dazu erstmal erinnern, wie das ging. Nicht vergessen: Nutzer der Uhren sind nicht unbedingt diejenigen, welche die gebaut haben. Das sind u.U. technische Laien. Weiterhin muss der Nutzer alle seine Einstellungen (Farbe, Anzeige, etc.) erneut vornehmen. Viel schlimmer aber ist: der Nutzer erhält nach dem Update unter Umständen eine "defekte" Anzeige, z.B. wenn die Anzeige LEDTYPE Grbw verwendet, die neue Firmware aber Brg als Standard vorsieht. Der beschenkte Laie ist damit überfordert.

Falls der Zweck das Eliminieren eventuell veralteter oder inkompatibler Konfigurationswerte ist, ist das Verwerfen aller Konfigurationsdaten der falsche Weg. Diese Einzelfälle sollten sinnvoll per Software gelöst werden.

Hardwarekonfiguration per Webinterface

Das Webinterface erlaubt permanent die Konfiguration von Hardware-Parametern. Das ist eine unnötige Fehlerquelle. Im Normalfall ändert sich die Hardware nach dem Bau einer Uhr nicht mehr. Wenn der Nutzer z.B. die Bau-Variante oder den LED-Typ verstellt (unpassende Optionen wählt), erhält er eine "kaputte" Anzeige. Wenn er die Einstellung aus Neugier vorgenommen hat, ist das weniger dramatisch, dann weiß er ja, was geschehen ist und kann es sofort rückgängig machen. Diese Einstellungen können jedoch auch schnell versehentlich verstellt werden: dazu genügt es je nach Browser/OS schon, wenn man mit Mauszeiger oder Finger über dem Dropdown scrollt bzw. eine Scroll-Geste macht. Statt zu scrollen wird dann die Auswahl im Select verändert. Weil das unbeabsichtigt geschieht und beim Erreichen der ersten bzw. letzten Select-Option dann in der Regel doch gescrollt wird, bemerkt man dieses Versehen meist nicht gleich. Da manche Einstellungen (z.B. Uhr-Variante) ohne Speichern-Button übernommen werden, ist das ein ziemlich gravierendes Problem. Mir ist es schon gelungen, durch versehentliche Verstellung der Variante in einen boot loop zu gelangen => worst case für Laien.

Meiner Meinung nach gehören alle Hardware-Einstellungen grundsätzlich auf eine Einstellungsseite (sind derzeit auf "Anzeigeoptionen" und "Einstellungen" verteilt) UND diese Einstellungen sollten nicht dauerhaft zugänglich sein. Denkbar wäre hier z.B., dass auf diese Hardware-Einstellungsseite beim Aufruf des Webinterface umgeleitet wird, wenn entsprechende Konfigurationsdaten im EEPROM fehlen (oder eben, wenn man die spezielle URL gezielt aufruft). Nach dem Speichern fragt das Interface "sind die Einstellungen korrekt", bei "ja" wird fortan nur noch das normale Webinterface gezeigt. Die Hardwareeinstellungen erscheinen erst wieder, wenn die entsprechenden Daten im EEPROM fehlen (Reset auf "Werkseinstellungen") oder man die URL zu dieser Seite gezielt aufruft.

Dies betrifft folgende Einstellungen:

• Uhrvariante
• vertikal spiegeln
• horizontal spiegeln
• Bauart (jede LED entspricht...)
• Anzahl der LEDs für Minuten (4 oder 7)
• LED-Typ
• Farbtemperatur der weißen LED

Rückwärtskompatible Updates

Funktionsupdates sollten so erfolgen, dass auch bei Einspielen des Updates auf älteren Modellen die Funktion weiterhin gegeben ist.

Als Beispiel möchte ich hier z.B. #408 nennen, wo mit großem Aufwand und viel Refactoring die Unterstützung für einen anderen Helligkeitssensor ergänzt wurde. Das Problem an der Umsetzung ist jedoch, dass der Fallback-Code für einen LDR (also der Code für alle bislang mit Helligkeitssensor gebauten Uhren und vermutlich auch die allermeisten zukünftig gebauten Uhren) komplett anders aufgebaut ist, als der bisherige, gut funktionierende Code. Das ist aufgrund der Vielzahl möglicher Konstellationen, die man nicht einfach nachstellen und testen kann, eine schlechte Idee und wie sich bei mir zeigt, funktioniert der neue Code für den LDR nicht. Da ich das dokumentierte Setup für MCU und LDR verwende und es vorher tadellos funktioniert hat, nehme ich an, dass der neue Code vermutlich bei so gut wie niemandem mit LDR funktioniert.

Immer, wenn man die möglichen Setups nicht testen kann, sollte man Änderungen so ausführen, dass die Rückwärtskompatibilität durch entsprechende Programmierung garantiert ist. Im genannten Beispiel wäre das der Fall gewesen, wenn der Fallback-Code für den LDR unverändert geblieben wäre.

Auch halte ich es für keine gute Praxis, Bibliotheken und Code für optionale Features fest zu integrieren. Gerade im Bereich Mikrokontroller gibt es genug Beispiele, wo das irgendwann Probleme macht und nachträglich der Code für optionale Funktionen mühsam optional gemacht wurde. Ich handhabe es generell so, dass ich per Konfiguration eine Konstante setzte (z.B. #define USE_AMBIENTSENSOR_BH1750 true) und der jeweilige Code und dessen Bibliotheken dann nur eingebunden werden, wenn die Konstante true ist. Auf diese Weise kann man einfach verschiedene Versionen bereitstellen, welche mit allen Funktionen und welche mit reduzierten Funktionen. Auch kann man zum Debuggen nicht benötigte Komponenten leichter entfernen.

Muss jede Variante alles können?

Mit #483 wurde die Digitalanzeige dahingehend modifiziert, dass sie auch auf zu kleinen Displays angezeigt werden kann. Hier wechselt die Anzeige dann ständig zwischen Stunde und Minute hin und her. Dieses Gezappel widerspricht dem Konzept einer Wortuhr. Schlimmer ist aber, dass auch auf Formaten, die bislang groß genug für die Digitalanzeige waren (und noch sind), diese nicht mehr korrekt angezeigt wird. Auch hier erfolgt völlig unnötig ein Wechsel zwischen Stunden und Minuten-Anzeige.

Meiner Meinung nach: wenn die Bauform der Uhr für ein Feature nicht geeignet ist (im Beispiel: zu klein für die Digitalanzeige), dann ist es besser, das Feature für diese Bauform nicht zur Verfügung zu stellen. Auf keinen Fall sollten geeignete Bauformen durch unbedingte Unterstützung für ungeeignete Bauformen benachteiligt werden.

.

So viel erstmal dazu. Wie sieht ihr das?

[dbambus]

Hey @D-ominik,

Vielen Dank für deine Gedanken und dafür, dass du das so gut zusammengefasst hast.

Ich denke, es lohnt sich, einen Blick in die Vergangenheit des Projekts zu werfen. Ich habe das Projekt damals geerbt und auch so übernommen und bin eigentlich der einzige kontinuierliche Maintainer der Software, weshalb die meisten Entscheidungen eigentlich auf meinen Schultern lasten.

Angefangen hat es damals damit, dass ich eine Uhr gebaut habe, die RGBW LEDs unterstützen sollte und ich auf Github keinen passenden Code dafür gefunden habe und so habe ich PRs erstellt und schließlich die Software übernommen und Features hinzugefügt, die ich für sinnvoll hielt oder die gewünscht wurden waren. Im Laufe der Zeit sind viele Features durch die Beteiligung der Community hinzugekommen, z.B. die Übergänge, die Website, auch weitere Sprachen und ich wollte immer die Kompatibilität zu älteren Uhren erhalten, so dass ich die Auswahl der möglichen Konfigurationen alle in ein Binary packen wollte, so dass Leute, die nur ein Update wollen, auch einfach dieses Update einspielen können und dann quasi neue Features haben, ohne die Software komplett neu kompilieren zu müssen.

Die Grundidee war ein Binary, für alle Uhren und alle möglichen Konfigurationen.

Wie machen wir also weiter?

Natürlich ist das Projekt mittlerweile etwas größer geworden und die möglichen Konfigurationen haben dazu beigetragen, dass es etwas unübersichtlich geworden ist. Ich habe aber immer versucht, die Übersichtlichkeit zu bewahren und versuche auch neue Releases möglichst fehlerfrei zu coden.

Neue Releases könnte man so gestalten, dass man z.B. neue Speicherbereiche immer unten an diese globalen Variablen anhängt, so dass die alten Speicherbereiche unangetastet bleiben. Letztendlich muss man sich nur darauf einigen, wie diese Änderungen kommuniziert bspw. über die Versionsnummer, so dass davon auszugehen ist, dass neue Versionen durchaus auch eine Neukonfiguration des Speichers erfordern und auch die Einstellungen neu vorgenommen werden müssen oder nicht. Die WLAN-Einstellungen sind dabei in einem ganz anderen Speicherbereich und müssen nicht immer neu eingegeben werden.

Ich habe das so gehandhabt, dass reine Bugfix Releases die sich nur ein der letzten Stelle unterscheiden 4.1.x sich nichts an der SERNR ändert und auch nicht an der Speicherkonfiguration, sodass man das Update ohne Problem einspielen kann.

Natürlich ist das eher für den technisch, versierten Anwender gedacht und nicht für den eigentlichen Leien/Beschenktem der jetzt nur schnell neue Funktion dazu haben möchte.

Dein Vorschlag, dass wir die #defines einpflegen ist ein sehr guter Vorschlag, so könnten wir während des Buildprozesses immer wieder neue Änderungen testen.

Auch würde ich vorschlagen, dass wir den bestehenden Code größtenteils Reactor für verschiedene Funktionen auf eigene Dateien auslagern und die Übersicht der Funktionen besser machen. Zum Beispiel, dass jeder Modus seinen eigenen Unterordner hat, um später neue Modi hinzufügen zu können. Alle Eingabe- und Ausgabeparameter sind fest definiert.
Das gilt analog auch für die manuelle Helligkeitszuweisung, die LDR-geschützte Helligkeitszuweisung und die BH1750-Zuweisung. Kommen weitere dazu kann man sie an ein bekanntes Interface anbinden.

Mit freundlichen Grüßen
David

[D-ominik]

Hi David,

klar, es ist halt ein über viele Jahre gewachsenes Projekt. Das läuft zwangsläufig immer so, dass man erstmal einfach so ergänzt und ergänzt, bis man irgendwann eine Menge hat, ab der Aufsplittung sinnvoll erscheint. Oder sogar das ganze Projekt neu strukturiert...

Viele Grüße

Dominik

[D-ominik]

@dbambus Derzeit wird jede Sekunde der Status per MQTT verschickt. Gibt es für diesen kurzen Intervall einen speziellen Grund? Das erzeugt bei mehreren Uhren meiner Meinung nach unnötig viel Stress in Home Assistant. Wenn das keinen speziellen Hintergrund hat, würde ich es auf einen minütlichen Intervall ändern und zudem bei jedem webSocketEvent() den Status senden.

[udo1toni]

Wenn ich als kompletter Nicht-Entwickler meinen Senf dazu geben darf :)
Im Fall von MQTT möchte ich Tasmota als Positiv-Beispiel erwähnen. Alles (wirklich alles), was irgendwie eingestellt werden kann, kann man auch mittels mqtt einstellen, es gibt hier einfach mehrere Schnittstellen, um Befehle zu senden oder die Status einzusehen, so sollte das im Idealfall sein.
Und natürlich scheint es sinnvoll, verwandte Einstellungen entweder als json gemeinsam zu schicken oder sie zumindest in irgendeiner Form zusammenfassen zu können (bei Tasmota z.B. mittels backlog, mehrere Befehle als einen String senden und Tasmota führt die Befehle in angegebener Reihenfolge aus).
Eventuell ist es einfacher, das zu implementieren, wenn man MQTT nicht losgelöst betrachtet, sondern als einen Kommunikationsweg von mehreren (Webschnittstelle, serielle Schnittstelle, whatever), der "einfach" parallel betrieben werden muss (wie gesagt, ich bin kein Programmierer und stelle es mir vielleicht nur so einfach vor...)

[BastiMu]

Hupsi, der Mit #483 geht auf mich. Das ist ein Fehler. Aber ich geb dir schon recht, es muss nicht jede Variante alles können. Hab mal einen Pull request zur Korrektur gemacht.

In #564 ist mir übrigens aufgefallen, das für die 11x11 Uhr für die 4 Minuten LEDs was anderes macht als bei den anderen. Dafür gibt es hier die "Ecken" Option, die genau das macht, was vorher die 4 Minuten LEDs gemacht haben.

Ich würde gerne noch anmerken, die Wahrscheinlichkeit, das jemand Technisch nicht versiertes ein Update macht ist eher gering, aber trotzdem sollte das ganze dann natürlich nicht kaputt gehen, stimmt schon.

Was die Einstellungen / Anzeigeoptionen betrifft stimme ich dir auch zu. Wichtige Einstellungen sollten bestätigt werden müssen (wäre ja leicht zu ändern) und ich bin auch immer verwirrt, wo ich was finde, muss da jedes mal suchen.

[Buckyball240]

Ich bin gerade im Begriff eine Uhr zu bauen. Die Software laeuft auch ganz prima, danke an die Entwickler. Ich verwende einen NoteMCU ESP8266 und im Programm ist der Datenpin auf RX gesetzt. Ich wuerde gerne einen anderen Pin verwenden, aber finde nirgends im Code wo ich das aendern kann.
Kann mir da jemand auf die Spruenge helfen?

Besten Dank

[BastiMu]

Hallo @Buckyball240 ich hatte da schonmal was gebastelt, siehe https://github.com/BastiMu/Multilayout-ESP-Wordclock/tree/Add-drop-down-menu-for-LED-pin

Allerdings bin ich da nicht fertig geworden, weil wir auch Hardware Tasten einfügen wollten (siehe #333)

Kurze Zusammenfassung: Als Methode für den ESP8266 muss statt Neo800KbpsMethod die Methode NeoEsp8266BitBangWs2812xMethod verwendet werden. Dann kann der LED_PIN auch in clockWork.hpp mit angegeben werden.

[Buckyball240]

@BastiMu , besten Dank fuer die Erklaerung.

Um ansonsten mal meinen Senf dazu zugeben. Ich hatte ueberlegt die Uhr mit Buttons zu bauen fuer die Helligkeit und ggf. Reset. Hab die Idee verworfen weil das a) unkonfortabel ist zur Uhr zur latschen b) jemand daran rumfummelt wenn man kein Schalter einsetzt um das zu verhindern.

Was ich mir vorstellen koennte ist ein RCWL-0516 Microwave Radar Proximity Sensor den man via Webinterface einschalten kann, der die Uhr abschaltete nach x Minuten wenn niemand im Raum bzw. dann einschaltet bei Bewegung.

[BastiMu]

@Buckyball240 das wäre auch eine Idee. Meine Idee dazu wäre, mit meiner Heimautomatisierung zu prüfen, ob jemand zuhause ist (=Handy im WLAN) und entsprechen die Uhr via MQTT aus und einzuschalten.

Falls du den Vorschlag umsetzen möchtest, könntest du bitte einen neuen Issue eröffnen, da das hier eigentlich offtopic ist.