Die Einstiegshürde ist schon recht hoch, wenn man damit bisher nicht gearbeitet hat. Es gibt zwar im Forum super Beschreibungen wie man das ganze zum Laufen bekommt aber teilweise tue ich mich auch schwer, diese zu Finden. Ich habe jedoch auch bisher keine Idee, wie man es optimaler gestalten kann. 
Im Nachbarforum läuft es ja ähnlich, obwohl die Hürden geringer sind, gibt es viele Fragen zu „basics“.
Das mit der Einstiegshürde kann ich bestätigen. Ich hatte vor dem ESPuino noch nie einen Mikrocontroller in der Hand. Entsprechend viel Zeit hat es auch gedauert, die Anforderungen aus dem Projekt zu überblicken. Mit den richtigen Anleitungen hat das mit Platformio gut funktioniert, aber doch viele Abende an Zeit gedauert (, die bei der Zielgruppe ja bekanntlicherweise Mangelware ist…).
Trotzdem verfolge ich viele Posts interessiert, auch wenn bei den Meisten sehr wenig verstehe 
Und die Aufwand/Nutzen-Argumente von Torsten sind gut nachzuvollziehen.
Folgender Gedanke ist mir zu dem Thema Einstiegshürde beim lesen hier gekommen (sorry, wenn das Off-Topic ist, dann gern verschieben odee ich mache bei Interesse einen eigenen Thread auf):
Wurde schonmal überlegt, unterschiedliche Nutzungsgruppen/Rollen zu definieren und denen dann verschiedene Level an Anpassung zu ermöglichen? Also sowas wie:
- Stufe 3: voller Funktionsumfang (aktueller ESPuino)
- Stufe 1: minimale Funktion, dafür niedrigster Einstieg (Default-Konfiguration, mit ready-to-install image
- Stufe 2 (wenn nötig): irgendetwas dazwischen
Technischen Aufwand kann ich nicht einschätzen, aber vielleicht lässt sich dann auch einiges an Arbeit konsolidieren und die 3/4 der Fragen an Torsten soweit reduzieren, dass es mehr Zeit für die „schönen“ Dinge (oder einfach Freizeit ;D) gibt.
In Summe bin ich sehr begeistert von dem Projekt und dem Forum und würde gern auch mehr beitragen. Vielleicht könnte so eine Aufteilung inkl. Überarbeitung der How-Tos (als DAU) sowas sein.
1 „Gefällt mir“
Ich habe über sowas auch schon nachgedacht, aber tatsächlich müsste man erstmal Optionen wie
- SHUTDOWN_ON_BAT_CRITICAL
- PLAY_LAST_RFID_AFTER_REBOOT
- USE_LAST_VOLUME_AFTER_REBOOT
- PAUSE_WHEN_RFID_REMOVED
- PAUSE_ON_MIN_VOLUME
- DONT_ACCEPT_SAME_RFID_TWICE
- SAVE_PLAYPOS_BEFORE_SHUTDOWN
- SAVE_PLAYPOS_WHEN_RFID_CHANGE
- VOLUMECURVE
in das Webinterface integrieren. Weil daraus ergibt sich ansonsten zu viel Kombinatorik. Größtenteils hängt ganz wenig Code dran - also das wäre schon gut machbar.
Weil dann könnte man sagen, dass man folgende Default-FWs anbietet:
- mini4L + PN5180
- mini4L + RC522
Aber vermutlich könnte man auch das noch vereinheitlichen, indem man auch das über das Webinterface steuert und eben nur das zur Laufzeit instanziert, was auch wirklich gebraucht wird.
Und in „noch ein wenig besser“ würde man auch gerne die Button-Konfiguration im Webinterface haben. Bestenfalls auch noch die Anzahl der Neopixel-LEDs.
Also ja: Ich begrüße Bemühungen, solche Sachen in das Webinterface zu ziehen. Dann müssen die Settings allerdings auch ins Backup rein.
6 „Gefällt mir“
Das feht mir auch so. Theoretisch könnten wir einige der Fragen an @biologist bestimmt auch beantworten, nur können wir sie halt leider nicht sehen. Wobei ich es auch verstehen kann, dass man nicht öffentlich fragt. Es stellt hier ja keiner einfache Fragen. Da denkt man dann man wäre die einzige Person mit Schwierigkeiten und fragt lieber „heimlich“.
Das ist nur aus zwei Gründen unpraktisch: Zum einen hängt der ganz Support an einer einzelnen Person und zum anderen kann man mithilfe der Suche leider diese Probleme auch nicht finden und so selbst zu einer Lösung kommen.
Ich denke man sollte zur Einstiegserleichterung vielleicht neues Thema aufmachen (falls man das angehen möchte).
Im Nachbarforum sind die Fragen auf mehr Schultern verteilt, es sollte also möglich sein.
- den Einstieg (Einrichten von GIT und VSC) kann auch ein Video erleichtern, obwohl beschrieben ist es bereits.
- das Nachbarforum pflegt rege das FAQ - unseres hat den Stand von 01/2021, eventuell kann man da auch einige Standardfragen abfangen
1 „Gefällt mir“
Die letzte Bearbeitung war aber am 13. Dezember. Man sieht das nur erst, wenn man auf das Stiftsymbol oben rechts klickt
2 „Gefällt mir“
Das einfachste wäre es meiner Meinung nach, wenn es eine fertige Firmware gäbe, die dann über die Weboberfläche konfiguriert wird. Dort könnte man dann auch presets anbieten.
Flashen könnte man direkt über den Browser, ohne etwas installieren zu müssen.
Dann wäre es auch einfacher ota Updates zu nutzen. Aber das wäre von der Umsetzung natürlich aufwändig.
2 „Gefällt mir“
Wie unterscheidet sich die von der settings.h?
Dort kann man aktuell ja auch die Anzahl der LEDs anpassen.
gar nicht ich bin einfach eine Schlafmütze. Irgendwie habe ich einfach ein paar parameter vermisst wie das „uint8_t password“ aus RfidPn5180 und dann ging es wohl mit mir durch. Man ich sollte mal schlafen. Sorry!
Moin,
ich würde tatsächlich einen ganz anderen Weg vorschlagen, der auch für die Zukunft mehr Flexibilität bietet und vor allem auch weniger Pflegeaufwand bedeutet.
Wie wäre es wenn die Firmware als Basis auf ESPHome (https://esphome.io/) aufbaut? Das hat so einige Vorteile und würde vor allem auch die Einstiegshürde verringern. Denn die Konfiguration bei ESPHome ist sehr einfach und zudem auch extrem Anpassungsfähig für den, der spezielle Sachen machen will.
Es müssten nur anfänglich die Standard-Sachen wie WLAN & Co auf ESPHome geändert werden und die eigenen Teile als external components registrieren. Man muss nicht alle Sachen bei ESPHome integrieren, sondern kann nebenbei selber eigenen Code entwickeln und selber einbinden. (External Components — ESPHome)
Vorteil ist halt auch, dass man ESPHome eventuell sogar erweitert und somit nachher am Ende nicht die Pflege mehr alleine übernehmen muss (Support for SD-Card as data sink · Issue #513 · esphome/feature-requests · GitHub). So lange Pull-Requests noch nicht angenommen worden, können diese sogar selbst als external components registriert werden (source: github://pr#123).
Als Beispiel kann man hier auch das NSPanel-Projekt von Blackymas nehmen, der das genau so macht (GitHub - Blackymas/NSPanel_HA_Blueprint: This allows you to configure your complete NSPanel via Blueprint with UI and without changing anything in the code). Basiert auf ESPHome und hat eigene Komponenten um die Firmware für das Panel anzupassen.
Ich sehe da tatsächlich nur Vorteile ESPuiino auf ESPHome-Basis zu stellen. Würde da auch mithelfen.
Viele Grüße
Ich glaube nicht das das überhaupt lauffähig wäre…
Wir sind bei RAM Menge und CPU Leistung schon kurz vor knapp, wenn wir da noch viel mehr dazupacken läuft vieles nicht mehr, daher klares Nein von mir zu dem Vorschlag 
1 „Gefällt mir“
Da sehe ich auch gerade den Vorteil von ESPHome. Denn das wird zur Compile-Zeit konfiguriert. Sprich, wenn ich gar kein Bluetooth-Stack brauche, wird der auch gar nicht einkompiliert. Genauso wie mit allen anderen Komponenten. Somit werden die Binaries kleiner, da nur das benötigte einkompiliert wird. ESPHome ist darauf gerade spezialisiert.
Das geht auch ohne esphome über menuconfig, da wir Arduino als Komponente verwenden. Da sind nur Default-Settings gesetzt, so dass ein „normaler User“ das für gewöhnlich nicht muss.
Ja, ich weiß, dass das alles auch händisch geht. Es ging hier ja aber vor allem auch darum die Einstiegshürden zu verringern. Und ESPHome benutzt hierfür halt yaml-Dateien und ESPHome ist durch Home-Assistant eben sehr verbreitet - auch ohne Programmierkenntnisse.
Nee, also ganz ehrlich: ESPuino ist viel zu groß inzwischen dafür, als dass ich auf irgendwen Drittes warten wollte, irgendwelche PRs zu integrieren. Das Issue für SD-Support ist vier Jahre alt. SD ist so ziemlich das Wichtigste, was wir bei ESPuino brauchen.
Wir sollten erstmal die Liste, die ich oben gemacht habe, in das Webinterface integrieren und dann sehen wir weiter.
6 „Gefällt mir“
Kleiner Erfahrungsbericht von mir:
Verständnis für Mikrocontroller-Systeme ist vorhanden. Auch einigermaßen bewandert mit Github und IDEs.
Größte Hürde war Visual Studio Code mit Plattform IO.
Hat durch das Hintergrundwissen und die gute Anleitung von biologist nicht lange gedauert, aber war für mich zumindest neu. Die Konfiguration des richtigen Boards mit den Einstellungen war dann noch ein wenig rumprobieren. Das Flashen mit der richtigen Board Konfiguration dann Hürde 3. War ein netter Abend und hat Spaß gemacht 
Visual Studio Code hat viele coole Funktionen. Da hat Microsoft vieles richtig gemacht
Den Ansatz von biologist die Einstellung erstmal im Webinterface konfigurierbar zu machen finde ich gut.
Im zweiten Ansatz dann vorkompilierte Firmware für bestimmte Boards (Buildserver baut automatisch aus stable, DEV würde ich nicht bauen lassen).
Das Flashen wäre dann noch relativ überschaubar mit einem Komandozeilenbefehl.
Die ganzen Hürden fallen weg wenn biologist ohnehin schon Boards verschickt und die bereits flasht 
Grüße Patrick
2 „Gefällt mir“
Falls die Firmware irgendwann einmal auf einem Stand ist, mit dem vorkompilierte Binaries verwendet werden können, kann ich euch die ESP Web Tools empfehlen (wurden oben bereits mal erwähnt).
Der Anwender kann dann direkt aus einem unterstützten Webbrowser das initiale Flashen durchführen. Und auch das UART Log kann angezeigt werden. Damit müssten sich Nicht-Programmierer nicht mal mehr mit einer IDE herumschlagen.