FHEM Forum

Moin zusammen,

ich war ne Weile lang extrem eingespannt, aber in der freien Zeit hab ich langsam weiter an meiner neuen Firmware gearbeitet. Die Version für den Esp8266 funktioniert schon ganz gut.
Ein paar Dinge sind noch nicht implementiert, so zum Beispiel die Presets und Gruppen, aber das meiste davon ist für den Betrieb mit fhem nicht von Belang.

Ihr würdet mir sehr helfen, wenn Ihr ein paar (nicht lebenswichtige) Controller auf die neue Version updaten könntet (geht zumeist auch mit denen, die einen defekten Flash Baustein haben und kein web Frontend mehr zeigen *aufdennägelnkau*).

Die update-url ist:

http://lightinator.de/version.json

das Dateisystem des Controllers wird dann komplett umgebaut, statt spiffs kommt ein lfs (little File System) drauf. Wenn Euch die Konfiguration des Controllers also wichtig ist, sichert sie vorher in ein json File, Ihr könnt sie danach wieder hochladen.

Sollte der Controller nach einem solchen over-the-air nicht wieder starten, sondern immer "OTA in progress" melden, macht ihn kurz stromlos. Nach dem Neustart gibt es mit ziemlicher Sicherheit kein UI, Linux Nutzer können jetzt auf der Kommandozeile mit

curl -X POST http://<controller-adresse oder name>/update -H 'Content-Type: application/json' --data '{"rom":{"url":"http://lightinator.de/download/esp8266/develop/debug/rom0.bin"}}'ein manuelles Update anstoßen. Bei meinen Controllern hat das immer geholfen, sie wieder zum Leben zu erwecken.
Wer den Controller an den PC anschließen kann, der kann das rom0.bin natürlich auch direkt flashen.

Wenn Ihr Bugs findet oder Vorschläge habt, bitte am besten gleich im Github Repo angeben:

http://github.com/pljakobs/esp_rgbww_firmware

Achtung: obwohl die Firmware aktuell auf Esp8266, Esp32 und Esp32c3 läuft, sind die OTA Routinen für die beiden Esp32 Typen noch nicht scharfgeschaltet, wenn Ihr da experimentieren wollt, müsst Ihr zwingend via USB flashen.

im Anhang findet Ihr ein paar Screenshots. Die meisten im dark Mode, weil der mir besser gefällt, eines auch im hellen Mode.

Ihr seht

• den Color Picker (leider ist der, den Quasar da zur Verfügung stellt ziemlich klein und auch nicht skalierbar - soweit ich weiß)
• das Pop out Menü (auf kleinen Bildschirmen wird es ausgeblendet, auf großen ist es immer zu sehen)
• die Color Settings Seite - wie schon beim alten Controller
• die Network Settings Seite, die jetzt einen schnellen Überblick über die Einstellungen gibt, das Setzen eines Namens zulässt, sowie dhcp und mqtt ein und ausschalten lässt
• die System Information Seite gibt in ähnlicher Weise Überblick über die aktuelle Systemkonfig, die DeviceID, welches rom (0/1) gerade aktiv ist, welche Version gerade installiert ist, welches Sming dem zugrunde liegt, wieviel Heap (RAM) frei ist (da bin ich besonders stolz, in der alten Version waren das oft unter 10kB, was zu Netzwerkproblemen geführt hat) und welcher SoC, also welche CPU verbaut ist. Außerdem ist hier die Firmware Update Funktion
• die Firmware update Funktion ist erheblich ausgeweitet worden, sie erlaubt jetzt die Auswahl zwischen debug und release builds (mit/ohne Serieller Log Ausgabe) und wird später noch stable / testing / nightly anbieten. (im Moment ist alles testing)
• weiter auf der System Settings Seite gibt es den Selektor für die Pin Konfiguration. Der ist jetzt flexibler und ich kann zentral über eine Datei neue Konfigurationen shippen. Was noch fehlt ist die manuelle Konfiguration
• ganz unten sind die Knöpfe um die Systemkonfiguration zu speichern / hochzuladen. Wenn Ihr eine Datei zum Hochladen auswählt wird sie in dem kleinen Fenster angezeigt, so dass Ihr checken könnt, ob das auch die korrekte Datei ist (keine Edit Funktion) bevor Ihr sie abschickt
• oben im popout Menü gibt es ein Dropdown, das alle Controller mit der neuen Firmware im LAN anzeigt, die Firmware verwendet mdns, um die Controller auffindbar zu machen. Hier könnt ihr zwischen verschiedenen Controllern umschalten und die so von einem Frontend aus bearbeiten, egal von welchem Controller das geladen worden ist.

Soviel zum neuen UI.

Ich bin auf Euer Feedback gespannt.

schönes neues Jahr

pj

ach, und PS:

ich hab Anfangs ja ein bisschen mit Sming gefremdelt, aber wie cool sind die Leute da!
Ich hatte im Sommer diesen Diskussionsbeitrag geschrieben:
https://github.com/SmingHub/Sming/discussions/2871

entstanden ist daraus das hier:
https://github.com/mikee47/ConfigDB/tree/develop

damit konnte ich fast die gesamte Konfiguration des Controllers aus dem RAM in's Flash schieben, was alleine über 10kB RAM und ungelogen 1200 Zeilen Code eingespart hat (das ganze lesen/schreiben der Konfigdatei sowie das gleiche im http API - es hat mich immer schon genervt, dass der quasi gleiche Code da doppelt vorkam).
ConfigDB ist jetzt ein fester Bestandteil der Firmware und macht mein Leben da extrem viel einfacher und wird auch in Zukunft viele Funktionen möglich machen.

Mitles

Hallo pjakobs,

werden die Änderungen in der Konfiguration direkt übernommen nach der Bestätigung oder muss ein Neustart durchgeführt werden.
Wenn ich einen neue Namen vergebe taucht der Controller noch relativ lange mit dem alten Namen bei den andern Controllern auf.

Kann man über die Weboberfläche einen Neustart auslösen?


Gruß rippi

P.S.: Presets konnte ich bis jetzt keine abspeichern, MQTT taucht unter fhem nicht auf

Hallo pjakobs,

super dass du die Firmware weiter entwickelst!
Ich habe die Version 9d5d-dirty-[develop] mal auf einen meiner Controller gespielt (OTA). Update hat gut geklappt. Leider habe ich jetzt aber das Problem, dass der Controller exakt alle 60s einen Crash hinlegt und neu startet. Jedenfalls sehe ich exakt in diesem Abstand im WLAN Protokoll meiner Fritz!Box, dass sich der Controller ab- und wieder anmeldet. Außerdem wird das Licht auf einen festen Wert zurückgesetzt (von dem ich nicht weiß wo er herkommt) und in FHEM werden sämtliche Readings aktualisiert. Die Uptime im Webinterface bleibt bei 0 stehen (sind das Minuten?).
Irgendwas klemmt da offenbar noch.

Grüße
Markus

Zitat von: rippi46 am 10 Januar 2025, 16:21:25Hallo pjakobs,

werden die Änderungen in der Konfiguration direkt übernommen nach der Bestätigung oder muss ein Neustart durchgeführt werden.
Wenn ich einen neue Namen vergebe taucht der Controller noch relativ lange mit dem alten Namen bei den andern Controllern auf.

Änderungen werden im Allgemeinen sofort übernommen. Das, damit die anderen Controller die Änderung allerdings sehen, muss erst das mDNS Timeout ablaufen.
Dabei fällt mir gerade etwas ein: im neuen Code (ich hab die Art, wie andere Controller abgelegt werden gerade geändert), muss ich noch was einbauen, wenn der Name geändert wurde.

Zitat von: rippi46 am 10 Januar 2025, 16:21:25Kann man über die Weboberfläche einen Neustart auslösen?

ich glaub, in der Version gerade nicht, aber in Zukunft: ja.

Zitat von: rippi46 am 10 Januar 2025, 16:21:25Gruß rippi

P.S.: Presets konnte ich bis jetzt keine abspeichern, MQTT taucht unter fhem nicht auf

genau, Presets sind gerade nicht drin, da hab ich das ganze Backend geändert. Kommt bald (im Moment hängt meine CI weil ich zwei Änderungen an Sming brauche, die aber gerade auf die Version 6.1 warten :/ )

Wie meinst Du MQTT taucht unter fhem nicht auf? Siehst Du keine mqtt updates? Ich gestehe, dass ich den mqtt Code selbst kaum angefasst habe.

Zitat von: Mafi am 11 Januar 2025, 15:06:34Hallo pjakobs,

super dass du die Firmware weiter entwickelst!
Ich habe die Version 9d5d-dirty-[develop] mal auf einen meiner Controller gespielt (OTA). Update hat gut geklappt. Leider habe ich jetzt aber das Problem, dass der Controller exakt alle 60s einen Crash hinlegt und neu startet. Jedenfalls sehe ich exakt in diesem Abstand im WLAN Protokoll meiner Fritz!Box, dass sich der Controller ab- und wieder anmeldet. Außerdem wird das Licht auf einen festen Wert zurückgesetzt (von dem ich nicht weiß wo er herkommt) und in FHEM werden sämtliche Readings aktualisiert. Die Uptime im Webinterface bleibt bei 0 stehen (sind das Minuten?).
Irgendwas klemmt da offenbar noch.

ja, in der Version sind das noch Minten. Hmm.. warum er crasht kann ich so natürlich nicht sagen. Hast Du ne Chance, das Log zu speichern (also mit einem Terminal ran zu gehen, 115200bps)?
Dann kann ich nachsehen, was da los ist.

Hallo

ZitatMQTT taucht unter fhem nicht auf

hatte es bisher nicht benuzt, und habe gedacht ich könnte aus fhem heraus den Controller mit MQTT steuern.
Hatte dazu meinen MQTT-Server angegeben. Aber ich glaube der Gedankengang war vekehrt.

Ab und zu habe ich das Gefühl, dass die Weboberfläche hängt oder Änderungen werden nicht übernommen.
Gibt es einen einfachen Weg auch wieder zurück auf die alte Version, oder geht das nur über das ESPTool?

Der Weg zur neuen Version hat Problemlos funktioniert.
Auch der Aufruf der Weboberfläche funktioniert besser (auch über VPN), da es über die ./index.html aufgerufen wird.
Bei der ./webapp Version mekert bei mir immer der Browser und über VPN geht gar nichts.

Gruß rippi

Zitat von: rippi46 am 13 Januar 2025, 19:25:25hatte es bisher nicht benuzt, und habe gedacht ich könnte aus fhem heraus den Controller mit MQTT steuern.
Hatte dazu meinen MQTT-Server angegeben. Aber ich glaube der Gedankengang war vekehrt.

ja, das geht grundsätzlich, allerdings ist das ein json rpc over mqtt interface, d.h. Du musst json rpc messages erstellen und die über mqtt an den Controller schicken.

Zitat von: rippi46 am 13 Januar 2025, 19:25:25Ab und zu habe ich das Gefühl, dass die Weboberfläche hängt oder Änderungen werden nicht übernommen.

Ich habe folgenden Verdacht und muss mich darauf noch kümmern:

Wenn über das API die Farbe verändert wird, dann wollte ich erreichen, dass alle Endgeräte, die gerade mit dem Controller sprechen (etwa, wenn Du das Web Frontend auf dem PC und dem Telefon offen hast) die neue Farbe korrekt darstellen.
Dazu sendet der Controller die neue Farbeinstellung als json-rpc Update über die vorhandenen Websocket Verbindungen raus - auch an das Frontend, das die Veränderung angestoßen hat.
Ich versuche das zwar da herauszufiltern, aber das scheint nicht immer zu funktionieren, so dass es quasi eine Rückkopplung gibt.

Zitat von: rippi46 am 13 Januar 2025, 19:25:25Gibt es einen einfachen Weg auch wieder zurück auf die alte Version, oder geht das nur über das ESPTool?

nein, es gibt keinen Weg, den Controller auf die alte Version zurück zu setzen, ohne über die serielle Schnittstelle zu flashen.
Das liegt daran, dass ich in der neuen Version ein anderes Flash Datei System (LittleFS statt SPIFFS) verwende.

Hintergrund dabei: mit der alten Firmware sind viele Controller mit defekten Flash Zellen einfach ausgefallen, das SPIFFS Volume konnte nicht mehr gemountet werden und das führte zu dem "normalen" Fehler, dass das Webfrontend nicht mehr aufzurufen war und der Controller meist auch in den reinen RGB Modus zurückgefallen ist (weil er seine Konfiguration nicht mehr lesen konnte).

LittleFS hat sehr viel besseres wear levelling (verteilt also die Daten gleichmäßig über den verfügbaren Flash Bereich) und ist auch resilienter gegen defekte Sektoren, weil die Metadaten (also die eigentlichen Strukturdaten des Dateisystems) immer doppelt gehalten werden.

Aber: ein OTA auf die alte Version muss daran scheitern, dass dann eben kein SPIFFS mehr da ist. Das Update überschreibt immer nur den eigentlichen Programmbereich, nicht das Dateisystem. Ich überlege allerdings gerade, da das OTA für die alte Version auch das SPIFFS image mitliefert könnte ich eine Funktion bauen, die das alte Zeug wieder flasht. hmm..
Würde ich aber eigentlich gerne vermeiden, denn das wäre viel Aufwand für etwas, was eigentlich niemand brauchen sollte.

Zitat von: rippi46 am 13 Januar 2025, 19:25:25Der Weg zur neuen Version hat Problemlos funktioniert.

ich hab noch einen Edge-case gefunden, den ich beachten muss, aber ja, im großen und ganzen funktioniert das gut (und war ziemlch viel Gefrickel)

Zitat von: rippi46 am 13 Januar 2025, 19:25:25Auch der Aufruf der Weboberfläche funktioniert besser (auch über VPN), da es über die ./index.html aufgerufen wird.
Bei der ./webapp Version mekert bei mir immer der Browser und über VPN geht gar nichts.

Das höre ich gern. Die Weboberfläche ist jetzt ja Vue bzw Quasar und nicht mehr AngularJS. Dazu wird die Webapp jetzt auch nicht mehr als externes Dateisystem ausgeliefert, sondern ist in das eigentliche Firmware Image eingebaut. Das macht die Updates kleiner und flexibler.

Zitat von: pjakobs am 13 Januar 2025, 17:45:57ja, in der Version sind das noch Minten. Hmm.. warum er crasht kann ich so natürlich nicht sagen. Hast Du ne Chance, das Log zu speichern (also mit einem Terminal ran zu gehen, 115200bps)?
Dann kann ich nachsehen, was da los ist.

Hmm, ist nicht ideal dranzukommen, weil das Ding etwas blöd verbaut ist, aber ich werde das am Wochenende mal versuchen. Eine Möglichkeit das per Webinterface herunterzuladen wäre genial. Aber idealerweise braucht man später ja gar kein Log mehr. Man kann übrigens auch an der LED auf dem ESP Board sehen, dass tatsächlich ein Neustart stattfindet. Wenn das Licht zu dem Zeitpunkt an ist ändert sich oft kurz vorher die Farbe, dann folgt der Neustart.
Ich melde mich, sobald ich das mal mitgeschnitten habe. Gibt es einen Unterschied zwischen den beiden Versionen Release und Develop oder geben beide Logs auf der Konsole aus?

Grüße
Markus

Hallo,

Zitatnein, es gibt keinen Weg, den Controller auf die alte Version zurück zu setzen, ohne über die serielle Schnittstelle zu flashen.
Das liegt daran, dass ich in der neuen Version ein anderes Flash Datei System (LittleFS statt SPIFFS) verwende.

Das ist nicht zwingend notwendig. wäre nur zum testen gewesen. Gehr aber auch relativ schnell über die serielle Schnittstelle

ZitatHintergrund dabei: mit der alten Firmware sind viele Controller mit defekten Flash Zellen einfach ausgefallen, das SPIFFS Volume konnte nicht mehr gemountet werden und das führte zu dem "normalen" Fehler, dass das Webfrontend nicht mehr aufzurufen war und der Controller meist auch in den reinen RGB Modus zurückgefallen ist (weil er seine Konfiguration nicht mehr lesen konnte).

LittleFS hat sehr viel besseres wear levelling (verteilt also die Daten gleichmäßig über den verfügbaren Flash Bereich) und ist auch resilienter gegen defekte Sektoren, weil die Metadaten (also die eigentlichen Strukturdaten des Dateisystems) immer doppelt gehalten werden.

Das höre ich gerne, da ich ca. 13 Controller im Einsatz habe und immer mal wieder einer ausfällt.
Manchmal reicht es dann neu zu flashen. In der Regel tausche ich aber den ESP aus.

Was ich bis jetzt noch nicht geschafft habe den Controller über MQTT anzusteuern!!!???
da stehe ich glaube ich auf dem Schlauch  :))

Zitat von: Mafi am 16 Januar 2025, 10:19:29

Zitat von: pjakobs am 13 Januar 2025, 17:45:57ja, in der Version sind das noch Minten. Hmm.. warum er crasht kann ich so natürlich nicht sagen. Hast Du ne Chance, das Log zu speichern (also mit einem Terminal ran zu gehen, 115200bps)?
Dann kann ich nachsehen, was da los ist.

Hmm, ist nicht ideal dranzukommen, weil das Ding etwas blöd verbaut ist, aber ich werde das am Wochenende mal versuchen. Eine Möglichkeit das per Webinterface herunterzuladen wäre genial. Aber idealerweise braucht man später ja gar kein Log mehr. Man kann übrigens auch an der LED auf dem ESP Board sehen, dass tatsächlich ein Neustart stattfindet. Wenn das Licht zu dem Zeitpunkt an ist ändert sich oft kurz vorher die Farbe, dann folgt der Neustart.
Ich melde mich, sobald ich das mal mitgeschnitten habe. Gibt es einen Unterschied zwischen den beiden Versionen Release und Develop oder geben beide Logs auf der Konsole aus?

Grüße
Markus

tatsächlich habe ich ein bisschen Code, der das Log umleiten kann. Ich weiß nur nicht, ob ich das in's Flash schreiben will, weil das relativ schnell dazu führen kann, dass Zellen ausfallen. Vielleicht mach ich was für rsyslog.

Zitat von: rippi46 am 16 Januar 2025, 15:53:04Was ich bis jetzt noch nicht geschafft habe den Controller über MQTT anzusteuern!!!???
da stehe ich glaube ich auf dem Schlauch  :))

am besten schaltest Du bei einem Controller mal mqtt master ein und schaust Dir an, wie das Nachrichtenformat aussieht.
Ohne es vor mir zu haben, glaube ich, dass es etwa so aussehen sollte:

Zitat{
  "cmd": "color",
  "hsv":{
    "h":60,
    "s":30,
    "v":50
  }
}

Ich weiß aus dem Kopf gerade nicht das Topic, an das die Nachricht geschickt werden muss. Muss ich mir ansehen.

Zitat von: pjakobs am 17 Januar 2025, 16:13:39tatsächlich habe ich ein bisschen Code, der das Log umleiten kann. Ich weiß nur nicht, ob ich das in's Flash schreiben will, weil das relativ schnell dazu führen kann, dass Zellen ausfallen. Vielleicht mach ich was für rsyslog.

Ins Flash würde ich das auch nicht schreiben. Mit rsyslog müsste ich mich mal vertraut machen. Aber für diesen Fall hier alles nicht nötig, ich bin seriell am Controller dran und habe ein erstes Log, das auch einen Fehler zeigt. Ich hoffe das hilft, ich kann damit leider nichts anfangen.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2025.01.18 12:35:00 =~=~=~=~=~=~=~=~=~=~=~=

Fatal exception 0(IllegalInstructionCause):
epc1=0x4000e296, epc2=0x00000000, epc3=0x40000f68, excvaddr=0x00000000, depc=0x00000000þ
 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 1948, room 16
tail 12
chksum 0x37
ho 0 tail 12 room 4
load 0x3ffe8000, len 772, room 12
tail 8
chksum 0x6c
csum 0x6c

rBoot v1.3.0 - richardaburton@gmail.com
Flash Size:   32 Mbit
Flash Mode:   QIO
Flash Speed:  40 MHz
rBoot Option: Big flash
rBoot Option: RTC data

Booting rom 0.
< hier stehen 2 Zeilen Kauderwelsch, die das Einfügen des kompletten Logs verhindern >
==========

Registered storage devices:
  spiFlash: type flash, size 0x400000. Partitions:
    spiFlash/rom0, app/ota0 @ 0x2000, size 0xfe000
    spiFlash/lfs0, data/littlefs @ 0x106000, size 0xf8000
    spiFlash/rom1, app/ota1 @ 0x202000, size 0xfe000
    spiFlash/lfs1, data/littlefs @ 0x300000, size 0xf8000
    spiFlash/rf_cal, data/rfCal @ 0x3fb000, size 0x1000
    spiFlash/phy_init, data/phy @ 0x3fc000, size 0x1000
    spiFlash/sys_param, data/sysParam @ 0x3fd000, size 0x3000



Registered storage devices:
  spiFlash: type flash, size 0x400000. Partitions:
    spiFlash/rom0, app/ota0 @ 0x2000, size 0xfe000
    spiFlash/lfs0, data/littlefs @ 0x106000, size 0xf8000
    spiFlash/rom1, app/ota1 @ 0x202000, size 0xfe000
    spiFlash/lfs1, data/littlefs @ 0x300000, size 0xf8000
    spiFlash/rf_cal, data/rfCal @ 0x3fb000, size 0x1000
    spiFlash/phy_init, data/phy @ 0x3fc000, size 0x1000
    spiFlash/sys_param, data/sysParam @ 0x3fd000, size 0x3000


sleep disable
mode : sta(5c:cf:7f:a2:ea:23)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with HnT1, channel 6
dhcp client start...
ip:192.168.178.118,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
Fatal exception 0(IllegalInstructionCause):
epc1=0x4000e296, epc2=0x00000000, epc3=0x4000dea1, excvaddr=0x00000000, depc=0x00000000þ
 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 1948, room 16
tail 12
chksum 0x37
ho 0 tail 12 room 4
load 0x3ffe8000, len 772, room 12
tail 8
chksum 0x6c
csum 0x6c

rBoot v1.3.0 - richardaburton@gmail.com
Flash Size:   32 Mbit
Flash Mode:   QIO
Flash Speed:  40 MHz
rBoot Option: Big flash
rBoot Option: RTC data

Booting rom 0.

usw. Wiederholt sich dann jede Minute


Ich habe gerade nochmal explizit die Debugversion auf den Controller gespielt (OTA) und die ist ja noch gewaltig gesprächiger. Kann man vermutlich noch mehr mit anfangen:

***** Fatal exception 0 (ILLEGAL)
pc=0x4000e296 sp=0x3ffffed0 excvaddr=0x00000000
ps=0x00000030 sar=0x00000010 vpri=0x401012c6
r00: 0x4021ff0c=1075969804 r01: 0x3ffffed0=1073741520 r02: 0x13b31c20= 330505248
r03: 0x00000000=         0 r04: 0x00000002=         2 r05: 0x00000014=        20
r06: 0xffffffff=-         1 r07: 0x010000e0=  16777440 r08: 0xf7ffffff=- 134217729
r09: 0x00000000=         0 r10: 0x3ffef27c=1073672828 r11: 0xfb0000e0=-  83885856
r12: 0x3fff2cd0=1073687760 r13: 0x00000001=         1 r14: 0x3fff2cd0=1073687760
r15: 0x3ffec1b8=1073660344

Stack dump:
To decode the stack dump call from command line:
   make decode-stacktrace
and copy & paste the text enclosed in '===='.

================================================================
3ffffed0:  3ffee088 3fff2998 3fff2828 4022023a 
3ffffee0:  3ffed980 00000006 00000000 3fffdab0 
3ffffef0:  3ffef27c 3fff2818 00000185 40223071 
3fffff00:  3ffe0000 00000024 0000002a 3fff2828 
3fffff10:  3ffec1a4 3ffef268 3ffef270 4021f828 
3fffff20:  00000014 005e0001 3fff2998 3ffec17c 
3fffff30:  00000000 3fff2828 0000001c 3ffec196 
3fffff40:  3fffdc80 3fff2828 3fff2998 4021f37c 
3fffff50:  00000050 3ffeea18 00000000 00000030 
3fffff60:  00000018 3fff4b60 00000002 402320d3 
3fffff70:  3ffed9f8 3ffec170 3fffdcc0 3ffea080 
3fffff80:  40232046 3ffed9f8 00000000 3fff2a98 
3fffff90:  3fffdc80 00000000 3fff2828 4021e10b 
3fffffa0:  40000f49 3fffdab0 3fffdab0 40000f49 

================================================================
To decode the stack dump call from command line:
   make decode-stacktrace
and copy & paste the text enclosed in '===='.


***** Software Watchdog Reset

Stack dump:
To decode the stack dump call from command line:
   make decode-stacktrace
and copy & paste the text enclosed in '===='.

================================================================
3ffffdc0:  3ffffde0 00000036 3ffffdd0 400005e1 <
3ffffdd0:  4000e296 00000030 00000010 401012c6 
3ffffde0:  4021ff0c 13b31c20 00000000 00000002 
3ffffdf0:  00000014 ffffffff 010000e0 f7ffffff 
3ffffe00:  00000000 3ffef27c fb0000e0 3fff2cd0 
3ffffe10:  00000001 3fff2cd0 3ffec1b8 00000000 
3ffffe20:  0000001f 0357608f 3ffee154 4010570c 
3ffffe30:  3ffea840 00000000 00000000 3ffee154 
3ffffe40:  0000001f 0357608f 40105bd6 00000100 
3ffffe50:  3ffea840 00002200 7fffffff 00000001 
3ffffe60:  00000001 00004208 0000001a ffffffff 
3ffffe70:  4020af29 3ffea840 0357608f 3ffea84c 
3ffffe80:  00000000 2c9f0300 4000050c 00000000 
3ffffe90:  3fffc278 401058e8 3fffc200 00000022 
3ffffea0:  00000000 10ad291a 4020fb32 3fff4548 
3ffffeb0:  40212ae1 00000030 00000007 ffffffff 
3ffffec0:  4021fefa 00000000 00000020 00000000 
3ffffed0:  3ffee088 3fff2998 3fff2828 4022023a 
3ffffee0:  3ffed980 00000006 00000000 3fffdab0 
3ffffef0:  3ffef27c 3fff2818 00000185 40223071 
3fffff00:  3ffe0000 00000024 0000002a 3fff2828 
3fffff10:  3ffec1a4 3ffef268 3ffef270 4021f828 
3fffff20:  00000014 005e0001 3fff2998 3ffec17c 
3fffff30:  00000000 3fff2828 0000001c 3ffec196 
3fffff40:  3fffdc80 3fff2828 3fff2998 4021f37c 
3fffff50:  00000050 3ffeea18 00000000 00000030 
3fffff60:  00000018 3fff4b60 00000002 402320d3 
3fffff70:  3ffed9f8 3ffec170 3fffdcc0 3ffea080 
3fffff80:  40232046 3ffed9f8 00000000 3fff2a98 
3fffff90:  3fffdc80 00000000 3fff2828 4021e10b 
3fffffa0:  40000f49 3fffdab0 3fffdab0 40000f49 

================================================================
To decode the stack dump call from command line:
   make decode-stacktrace
and copy & paste the text enclosed in '===='.


Das komplette Log einer Minute kann ich hier irgendwie nicht einfügen. Vermutlich zu lang. Daher hänge ich es mal als Datei an.

das ist echt seltsam, das ist einfach ne illegal instruction, wenn ich das richtig sehe.
Und es wird scheinbar nicht durch irgendwas getriggert (jedenfalls durch nichts, was eine logzeile ausgibt).

Ich hoffe, dass ich morgen einen neuen Build fertig krieg, wenn das mit dem auch noch passiert, dann kann ich auch mit dem Stacktrace was anfangen (im Moment hab ich schon zu viele Änderungen drin, das passt nicht mehr).

@mafi - wenn Du die Zeit hast, mach doch bitte mal ein Update auf die pj-1-632-gc15f (jetzt im OTA Stream) und schau, ob Du den gleichen Fehler bekommst, wenn ja, dann kann ich den stack dump besser troubleshooten.

Update hat geklappt. Der Fehler ist jetzt nach 6 Minuten noch nicht wieder aufgetreten. War ja vorher alle 60s.
Ich beobachte das mal weiter, aber auf jeden Fall hat sich was verbessert. Ich denke morgen kann ich mehr sagen. Aber sieht vielversprechend aus! Danke!

Zitat von: Mafi am 20 Januar 2025, 22:01:51Update hat geklappt. Der Fehler ist jetzt nach 6 Minuten noch nicht wieder aufgetreten. War ja vorher alle 60s.
Ich beobachte das mal weiter, aber auf jeden Fall hat sich was verbessert. Ich denke morgen kann ich mehr sagen. Aber sieht vielversprechend aus! Danke!

das wäre natürlich spitze!

Ich habe ein bisschen den Verdacht, dass es mit dem genutzten FLASH Block zu tun haben könnte, es gibt zwei, die für die Firmware genutzt werden: rom0 und rom1.
Nach einem OTA bist Du jeweils im anderen Block (rom0->rom1 bzw rom1->rom0). Nur das Flash File System ist immer gleich.

Bin gespannt, wie es sich entwickelt.

Am genutzten Flashblock wird es nicht gelegen haben, denn ich hatte ja nach dem ersten seriellen Mitschnitt nochmal ein Update auf die Debugversion gemacht. Dabei wurde dann ja auf den anderen Bereich gewechselt. Der Fehler trat aber genauso weiter auf.
Heute Morgen funktionierte jedenfalls immer noch alles. Was immer es war, es scheint mit der neuen Version gelöst zu sein. Ich werde diesen Controller weiter aktuell halten wenn es neue Versionen gibt und berichten, falls irgend etwas auffällt.

Wenn ich einen Wunsch äußern dürfte: Ich fände es gut, wenn der Wert Config-Color-Startup_Color auch im Webinterface gesetzt werden könnte. Ich habe die Controller immer auf einen festen Wert eingestellt, damit das Flash geschont wurde. Über das Reading in FHEM war das immer recht umständlich zu machen, zumal laut Doku bei Angabe eines falsch formatierten Werts auch der Controller crashen konnte.

Tja, leider zu früh gefreut. Der Fehler ist wieder da! Mitschnitt im Anhang.
Keine Ahnung, was jetzt anders sein soll als heute morgen.

okay, das ist interessant und das hab ich noch nicht gesehen.

Der Fehler passiert im IGMP Modul (Internet Group Management Protocol) - das gehört zum Multicast Protokoll. Die Controller beherrschen aber kein Multicast bzw nutzen das nicht.
Hast Du Multicast Geräte laufen? Also etwa Multi-Room WiFi Musiksysteme oder sowas?

Ich könnte mir gut vorstellen, dass dieser Code innerhalb des ip Stacks sehr alt und ggf. buggy ist (ich hab schon zwei Bugs in LwIP gefunden), allerdings habe ich leider wenig Möglichkeit, das zu debuggen.

Ich will mal sehen, ob ich Dir einen Build mit LWIP debug enabled bauen kann. Du kannst zur not auch seriell flashen, oder?

0x402201ea: igmp_input at /opt/Sming/Sming/Arch/Esp8266/Components/esp-open-lwip/esp-open-lwip/lwip/core/ipv4/igmp.c:458
0x40223021: pbuf_alloc at /opt/Sming/Sming/Arch/Esp8266/Components/esp-open-lwip/esp-open-lwip/lwip/core/pbuf.c:389
0x4021f7d8: ip_input at /opt/Sming/Sming/Arch/Esp8266/Components/esp-open-lwip/esp-open-lwip/lwip/core/ipv4/ip.c:569
0x4021f32c: ethernet_input at /opt/Sming/Sming/Arch/Esp8266/Components/esp-open-lwip/esp-open-lwip/lwip/netif/etharp.c:1372
0x40232083: ppRxPkt at /home/xcg/workspace/debug/esp8266_nonos_sdk_core_20180510/app/pp/pp.c:1121
0x40231ff6: pp_tx_idle_timeout at /home/xcg/workspace/debug/esp8266_nonos_sdk_core_20180510/app/pp/pp.c:992
0x4021e0bb: ets_snprintf at ??:?


und wenn ich dann mal drüber nachdenke - mDNS (also das Protokoll mit dem sich die verschiedenen Controller finden) nutzt natürlich auch multicast ip - 224.0.0.251 in meinem Fall.
Das bedeutet, dass dieser Code eben doch genutzt wird. Seltsam.
Ich hab mal eine Version mit aktiviertem lwip debug gebaut, mal sehen, ob wir damit mehr erkennen können.
Ist im OTA stream als "lwip_test" zu haben.
Diese Version generiert so richtig viel output, mal sehen, ob ich es damit einkreisen kann.

pj

Das ging ja schnell! Wenn ich heute Abend dazu komme, werde ich die Version gleich mal installieren. Bin gespannt, ob der Fehler dann wieder sofort auftritt oder erst nach einem Tag. Merkwürdig ist das ganze ja schon.
Ob in meinem Netz viele Multicast Pakete herumschwirren weiß ich nicht. Ich habe eine ganze Hand voll Echos und Echo Dots, sowie FireTV Sticks und Fernsehen läuft über WaipuTV. Schon möglich, dass da für TV oder Lautsprechergruppen auch Multicasts zum Einsatz kommen.

Flashen per serieller Schnittstelle habe ich ewig nicht mehr gemacht, sollte aber immer noch funktionieren, falls nötig.

So, da sind wir schon. "Generiert so richtig viel output" trifft es kaum. Es ist gigantisch!
Das letzte, was vor dem Crash kommt, ist eine Anfrage von Adresse 192.168.178.21. Es hilft vielleicht zu wissen, was das ist. Unter der Adresse verbirgt sich ein TP Link TL-WA890EA WLAN Bridge Device, das mein WLAN auf Ethernet übersetzt (also ein WLAN Client ist). Daran hängt zur Zeit aber nur noch eine Energernie Steckdosenleiste. Früher auch Bluray Player, Fernseher und Kabelbox. Da der WA890EA schon öfter durch Ausfall glänzte in den letzten Wochen und dann die besagte Steckdosenleiste nicht mehr für FHEM erreichbar ist, wird er in Kürze in Rente geschickt. Gerade heute habe ich Ersatz für die Steckdosenleiste (immerhin schon 10 Jahre alt) bestellt. In Form von Nous A8T WLAN Steckdosen mit Tasmota. Möglicherweise ist die Ursache des Problems dann beseitigt, wenn der WA890EA weg ist. Obwohl der Lightinator natürlich trotzdem nicht so auf die Nase fallen sollte, wenn ein solches Paket kommt. Die anderen, noch mit der alten Software laufenden Platinen haben interessanterweise auch kein Problem.

Viel Erfolg! Ich kann mein Setup gern noch so belassen, um Bugfixes zu testen-

sehr schön, damit kann ich schonmal ein bisschen was anfangen.

ich hab diesen Codeblock im Verdacht:
       groupref = igmp_group_list;
       while (groupref != NULL) { //pj added explicit NULL check
         /* Do not send messages on the all systems group address! */
         if ((groupref->netif == inp) && (!(ip_addr_cmp(&(groupref->group_address), &allsystems)))) {
           LWIP_DEBUGF(IGMP_DEBUG, ("igmp_input: delaying membership on group %i ",groupref)); //pj added message
           igmp_delaying_member(groupref, igmp->igmp_maxresp);
         }
         groupref = groupref->next;
       }

Der Fehler ist ein uneraubter Speicherzugriff, etwa ein Nullpointer, diese Schleife soll alle gültigen multicast Gruppen durchlaufen, ich will mal sehen, ob da was schief geht.

da ich vermute, dass Du jetzt nicht über das UI flashen kannst, kannst Du (Linux oder WSL oder einen anderen http client vorausgesetzt) folgendes eingeben um vom anderen ROM zu booten :

curl -X POST http://192.168.178.118/system -H 'Content-Type: application/json' --data '{"cmd":"switch_rom"}'

damit sollte wieder der Code ohne so viel debug output laufen und das UI zugänglich sein, und Du solltest normal den OTA Prozess anstoßen können.

Sollte das nicht funktionieren, kannst Du Dir von http://lightinator.de/download/app-merged.bin (http://lightinator.de/download/app-merged.bin) das ganze flash image herunterladen und mit
esptool.py -p <com-port> -b 115200 --chip esp8266 write_flash -z -fs 4MB -ff 40m -fm dio 0x00000 app-merged.bin
flashen.

Es ist möglich, dass der explizite NULL Check das Problem behebt, aber ich gehe davon aus, dass es weiter auftritt, aber ich diesmal sehen kann, welche multicast Gruppen durchlaufen werden.
Entweder damit bestätigt sich diese Stelle als das Problem oder ich muss anderswo suchen.

Mein Eindruck ist, dass, was immer da von dem WA890EA kommt irgendwie einen Bug im lwip code triggert, denn sonstwo hab ich dieses Verhalten noch nicht beobachtet.

Viel Spaß ;-)

Guten Abend!

Hier das neueste Log. Der Fehler tritt weiterhin auf. Man sieht im Mitschnitt, dass auch meine FritzBox (192.168.178.1) IGMP Nachrichten an Adresse 224.0.0.1 sendet. Das führt aber nicht zum Absturz. Nur die Pakete vom WA890EA tun das. Irgend etwas muss an diesen Paketen besonderes sein. Ich habe keine Ahnung vom IGMP Protokoll. Ich sehe nur das bei der FritzBox [igmp_maxresp=100] protokolliert wird, beim WA890 aber [igmp_maxresp=1]. Was immer das bedeutet. Der Fehler tritt vermutlich bei der Verarbeitung des Paketinhalts auf. Der NULL Check scheint leider nicht gewirkt zu haben, da muss es wohl an anderer Stelle krachen.

ich glaube, ich hab den Bug gefunden.

igmp_start_timer(struct igmp_group *group, u8_t max_time)
{
  ip_addr_debug_print(IGMP_DEBUG, &group->group_address);
  LWIP_DEBUGF(IGMP_DEBUG, ("igmp_start_timer for %i",max_time));
  /* ensure the input value is > 0 */
  /* actually, it needs to be > 1 as 1 is subtracted before the modulo */
  if (max_time == 0 ) {
    max_time = 1;
  }
  /* ensure the random value is > 0 */
  group->timer = (LWIP_RAND() % (max_time - 1)) + 1;
}
Dein Router sendet ein igmp paket mit max_time 1, diese Funktion erfordert, dass max_time mindestens 1 ist.
Allerdings wird danach LWIP_RAND() % (max_time - 1) berechnet. %, der Modulo Operator ist der Divisionsrest, also wird hier eine Division durch 1-1 = 0 durchgeführt. Das muss knallen.

Neuer Build ist im OTA Stream und sollte das beheben.

ps: issue gegen Sming: https://github.com/SmingHub/Sming/issues/2936
pj

Der Fehler tritt leider weiterhin auf.
Ich verstehe auch den Fix nicht recht. Soweit ich den Code verstehe, würde jetzt immer noch durch 0 geteilt, wenn max_time=1. Nur auf das Ergebnis würde dann 1 addiert. Wäre das denn dann korrekt? Es geht ja meinem Verständnis nach darum, eine zufällige Verzögerung mit einem maximalen Wert von max_time zu wählen. Wenn max_time=1 also zwischen 0 und 1. Würde die Formel so nicht zu einem Wert zwischen 1 und 2 führen (die Division durch 0 mal außen vor gelassen)? Aber ich glaube, du hast genau die richtige Stelle gefunden. Im Log sieht man, dass für den Wert 1 der Timer gestartet werden soll und dann knallt es.

Der Code hier ist (bis auf meinen Kommentar) der original Code.
Ich hab einen PR gegen Sming, der den Fix backportet, den esp-open-lwip upstream gemacht hat. Ich gehe ziemlich sicher davon aus, dass das das Problem löst.
Ich kann nachher mal eine Version damit bauen.

so, ich hab dann nochmal mit dem candidate patch gebaut.
igmp_start_timer(struct igmp_group *group, u8_t max_time)
{
  group->timer = (u16_t)(max_time > 2 ? (LWIP_RAND() % max_time) : 1);

  if (group->timer == 0) {
    group->timer = 1;
  }
}
Im Grunde macht die Funktion das selbe, aber der div 0 Case kann nicht mehr auftreten, wenn max_time <=2 ist, wird der timer auf 1 gesetzt. Wenn LWIP_RAND()%max_time zufällig 0 sein sollte, wird der timer auf 1 gesetzt.

In Deinem speziellen Fall sollte er also klar definiert 1 sein.

Wie üblich, im OTA Stream.

Warum der vorherige Patch nicht funktioniert hat ist mir nicht ganz klar, da hatte ich eigentlich auch schon auf ">=2" gecheckt. Egal, upstream hat diese Lösung.

Das Problem mit dem IP Stack für den Esp8266 in Sming ist, dass es eine *sehr* alte Version ist (7-9 Jahre). Upstream ist zwischenzeitlich viel gefixt worden, aber im Moment traut sich niemand, das anzupacken, auch weil der 8266 nicht unbedingt eine Zukunftsplattform ist.

Ah, ich hatte aufgrund deiner Kommentare gedacht, das wäre schon ein geänderter Quellcode.
Mit der neuen Version scheint es jetzt zu funktionieren! Leider kriege ich aber keine lesbaren Ausgaben auf der seriellen mehr. Das Kauderwelsch sieht aus als wenn ich die Baudrate falsch eingestellt hätte. Aber davon abgesehen sieht es gut aus! Webinterface und Steuerung via FHEM funktionieren wie gewohnt. Ich werde weiter beobachten. Gute Arbeit!

Zitat von: Mafi am 24 Januar 2025, 17:03:44Ah, ich hatte aufgrund deiner Kommentare gedacht, das wäre schon ein geänderter Quellcode.
Mit der neuen Version scheint es jetzt zu funktionieren! Leider kriege ich aber keine lesbaren Ausgaben auf der seriellen mehr. Das Kauderwelsch sieht aus als wenn ich die Baudrate falsch eingestellt hätte. Aber davon abgesehen sieht es gut aus! Webinterface und Steuerung via FHEM funktionieren wie gewohnt. Ich werde weiter beobachten. Gute Arbeit!

ah, sorry, der build benutzt eine Baudrate von 460800, ich flash die Testversionen hier immer seriell und will nicht so lange warten :D

Hallo pjakobs,

nach dem OTA Update wird für die WIFI Verbindung ein Passwort verlangt.

Gruß
Matthias

Zitat von: Matze66 am 26 Januar 2025, 14:08:17nach dem OTA Update wird für die WIFI Verbindung ein Passwort verlangt.

Du meinst, der Controller startet ohne WiFi Verbindung sondern öffnet seinen Accesspoint?
Das Password ist "configesp" - danach solltest Du auf die Seite kommen, um die Verbindung zum WLAN wieder herzustellen.
Warum die verloren gegangen ist weiß ich allerdings nicht. Die WiFi Daten werden eigentlich nicht aus der ConfigDB genommen.

so, neue OTA Version.

• multicast group bug gefixt
• Icons werden im Dark Mode jetzt hell dargestellt (ein paar Details fehlen noch, etwa werden die drop down arrows in select boxen nicht dargestellt
• Ich habe angefangen, die Presets neu zu implementieren. Im Moment ist das aber noch nicht wirklich funktional
• der mDNS Code, der andere Controller findet ist überarbeitet, Teil der Host Struktur ist jetzt die Chip ID, die ich als Key für Szenen nutzen will.

@mafi - bitte mal testen, ob dieser Build Dein Problem löst.

3 von 4 Controller wollten für den Accesspoint ein Passwort.
Update verlief bei allen ohne Probleme.
Danke für die Weiterendwicklung.

Zitat von: Matze66 am 27 Januar 2025, 17:49:493 von 4 Controller wollten für den Accesspoint ein Passwort.
Update verlief bei allen ohne Probleme.
Danke für die Weiterendwicklung.

die liefen aber vorher problemlos mit der alten Firmware?
Kann ich mir gerade nicht erklären.

WLAN Passwort musste ich nach keinem Update neue eingeben. Teste aber nur mit einem einzigen Controller.
Ich habe meinen TL-WA890 nochmal angeworfen und sehe keine Probleme. Auf der Konsole werden diese Pakete ja nicht mehr protokolliert, aber es gibt keine Reboots. Von daher würde ich sagen das Multicast Group Problem ist auch in dieser Version gelöst.

Zitat von: Mafi am 27 Januar 2025, 20:26:27WLAN Passwort musste ich nach keinem Update neue eingeben. Teste aber nur mit einem einzigen Controller.
Ich habe meinen TL-WA890 nochmal angeworfen und sehe keine Probleme. Auf der Konsole werden diese Pakete ja nicht mehr protokolliert, aber es gibt keine Reboots. Von daher würde ich sagen das Multicast Group Problem ist auch in dieser Version gelöst.

Super, danke!

Und - ja, ich will in Code, den ich selbst nicht maintaine keinen log output einbauen, und für den debug build macht es nicht wirklich Sinn, das debugging für das multicast group management einzubauen. Es gibt ca 20 verschiedene debug Domains für debug outputs.

Der Bug war ja ziemlich offensichtlich, von daher genügt mir die Bestätigung, dass es nicht mehr vorkommt.

Hallo pjakobs,

habe 5 Controller im Batteriebetieb im Einsatz (gesteuert über Bewegungsmelder) gibt es eine Möglichkeit einen Sleepmodus zu aktivieren um die Batterien etwas zu schonen
oder müsste man dazu die Schaltung ändern?


Gruß rippi 

Sleepmode bedeutet, dass der Controller nicht mehr per WLAN erreichbar ist, das macht eher keinen Sinn.
Wenn Du einen der neueren, kleinen Controller hast (grüne Platine mit grünen Klemmen entlang der langen Seite), dann kannst Du den Controller schlafen schicken, indem Du die beiden pins auf der rechten Seite (wenn der Controller mit den Klemmen zu Dir vor Dir liegt) brückst. Dann ist er allerdings komplett ausgeschaltet, Licht ist aus und er braucht ca. 3s um wieder hochzufahren.

Ok, danke für die Info.

Das hatte ich nicht bedacht, dass der Controller dann aus ist. Somit wäre er ja auch nicht für den Bewegungsmelder sichtbar.

Ich habe diverse Sensoren über WLAN im Betrieb, aber die wachen einfach nach einer festen Zeit auf schicken ihre Werte und gehen wieder in den Sleepmodus.


Gruß rippi

Zitat von: rippi46 am 04 Februar 2025, 15:39:48Ok, danke für die Info.

Das hatte ich nicht bedacht, dass der Controller dann aus ist. Somit wäre er ja auch nicht für den Bewegungsmelder sichtbar.

Jein, es gibt auch unterschiedliche Power Save Modi, aber die wesentliche Ersparnis wäre immer, das WLAN abzuschalten. Dann ist der Controller aber halt nicht mehr erreichbar.

Die beiden Pins sind einfach eine Methode, mit dem aktuellen Design und der aktuellen Firmware den Controller abzuschalten.

Zitat von: rippi46 am 04 Februar 2025, 15:39:48Ich habe diverse Sensoren über WLAN im Betrieb, aber die wachen einfach nach einer festen Zeit auf schicken ihre Werte und gehen wieder in den Sleepmodus.

Sensoren haben es da einfach: die wachen auf, messen etwas und übertragen das Datum in's Netz.

Der Controller funktioniert aber umgekehrt: er wartet auf einen Befehl aus dem Netzwerk. Wenn er nicht erreichbar ist, geht der Befehl in's Leere.

Moin, so, es gibt mal wieder was zum ausprobieren - der neue Build im OTA channel unterstützt jetzt hsv Presets - raw kommt als nächstes.
Ihr könnt jetzt eine Farbe im Colorpicker auswählen und unter einem Namen auf dem Controller speichern.
Diese Presets werden dann unter dem Presets Tab angezeigt, dort könnt Ihr sie auch wieder löschen (achtung: da gibt's noch einen bug, siehe weiter unten)
Ihr könnt auch den Stern anklicken und ein Preset zum Favorite machen, es kann mehrere Favorites geben (das ist nur ein Flag im Preset selbst).
Wenn Ihr mindestens ein Preset als Favorite markiert habt, taucht in der Reiterleiste vorne ein weiterer Tab für Favorites auf. Der ist dann auch der default Tab, der geöffnet wir, wenn Ihr die Controller App öffnet.
Hier habt Ihr schön große Farbflächen, die Ihr direkt anwählen und so die Farbe einstellen könnt.

Die ganze Geschichte hat gerade noch einen Pferdefuß: tief in Sming ist eine Komponente, die json streams formatiert und die geht mit utf-8 Zeichen (also Zeichen, die nicht im ascii vorkommen) wie unseren Umlauten etwas .. ruppig um, sprich: sie werden escaped. Aus einem Ä wird so \u00c3\u0084 - wenn das im Namen des Presets ist, dann kann das Preset über den Namen nicht mehr ausgewählt werden.
Ich gehe davon aus, dass das relativ schnell gefixt wird, in der zwischenzeit, beschränkt Euch für Namen bitte auf alles ohne Sonderzeichen, keine Accents, keine umlaute, kein scharfes s etc.

Ansonsten - viel Spaß!

Update:

offenbar fehlt im upstream Sming repo noch ein fix in ConfigDB, in der OTA Version funktioniert deshalb leider noch nicht alles. Unter anderem kann man Presets noch nicht verändern, also nicht zu Favoriten machen, also gibt's die Favoriten Seite nicht dauerhaft.
Ich hoffe, die beiden Bugs sind bald in Sming

Hallo,

die Presets lassen sich anlegen und funktionieren auch, aber sie lassen sich nicht mehr löschen.
Wenn man den gleichen Namen noch einmal vergibt, gibt es das Preset trotzdem zweimal. Versucht man dann eines zu löschen,
will er beide löschen - was aber ja nicht funktioniert.

Gruß rippi

PS: irgendwie reagiert der Controller nicht immer korrekt, jetzt konnte ich die Presets doch löschen.
       Und er meckert jetzt auch wenn ich ein Preset mit dem gleichen Namen anlegen will.

Zitat von: rippi46 am 10 Februar 2025, 11:53:32Hallo,

die Presets lassen sich anlegen und funktionieren auch, aber sie lassen sich nicht mehr löschen.
Wenn man den gleichen Namen noch einmal vergibt, gibt es das Preset trotzdem zweimal. Versucht man dann eines zu löschen, will er beide löschen - was aber ja nicht funktioniert.

der Hintergrund ist, dass wir in ConfigDB die Möglichkeit eingebaut haben, json Objekte (also etwa die Presets) per Namen zu addressieren. ein {"presets[name=rot]":{"favorite":true}} etwa sollte für das Preset mit dem Property "name":"rot" das Property "favorite" auf true setzen. Ein {"presets[name=gruen]":[]} sollte das ganze preset mit dem Namen "guen" löschen.
Ich bin mir nicht sicher, ob ich mit einer alten Version ConfigDB gebaut habe (die ist ja als git submodule eingebunden) oder ob es in ConfigDB eine Regression gibt.

Zitat von: rippi46 am 10 Februar 2025, 11:53:32PS: irgendwie reagiert der Controller nicht immer korrekt, jetzt konnte ich die Presets doch löschen.
       Und er meckert jetzt auch wenn ich ein Preset mit dem gleichen Namen anlegen will.

öh, okay? so sollte es eigentlich sein.

ich glaube, das Problem ist gelöst, der Build hat eine ältere Version von ConfigDB genutzt.
Mit der OTA Version von heute früh (pj-1-665-g5502) sollten die Presets problemlos funtkionieren.

so, nachdem in den letzten paar Stunden ein kaputter Build im OTA Channel war, funktioniert es jetzt wieder (ich hab den API Endpoint /presets in /data umbedannt, weil dort alle Applikationsspezifischen Daten gespeichert sind).

Das Frontend hat eine neue Funktion bekommen: Ihr könnt jetzt im Presets Tab auf den Pfeil nach rechts klicken, und das aktuelle Preset auf ausgewählte andere Controller übertragen.

Als nächstes will ich Gruppen einbauen (z.B. alle Controller in der Küche) und dann Szenen, also definierte Einstellungen für eine Gruppe bzw. mehrere Controller.

Hallo

ich habe immer wieder das Problem, dass die Controller nicht mehr reagieren. Beim Aktualisieren im Browser hab ich manchmal ein Ewigkeit die Sanduhr und der Controller ist nicht erreichbar. Beim senden der Presets taucht der andere Controller nicht immer auf.
Aktuell habe ich nach dem OTA-Update wieder einen Controller der nicht mehr erreichbar ist. Vermutlich muss ich ein Hardreset durchführen.

Gruß rippi

Zitat von: rippi46 am 11 Februar 2025, 19:44:56Hallo

ich habe immer wieder das Problem, dass die Controller nicht mehr reagieren. Beim Aktualisieren im Browser hab ich manchmal eine Ewigkeit die Sanduhr und der Controller ist nicht erreichbar.

Das hab ich tatsächlich hier auch schon beobachtet, aber leider noch nicht bei einem Controller, den ich am Seriellen Interface hängen hatte, ich weiß also gerade nicht, was die Ursache ist. Aber immerhin: wenn ich es reproduzieren kann, sind die Chancen nicht schlecht, dass ich es finden und fixen kann.

Zitat von: rippi46 am 11 Februar 2025, 19:44:56Beim senden der Presets taucht der andere Controller nicht immer auf.

Die Liste der Controller ist dynamisch und wird über mDNS dauernd upgedatet. Wenn ein Controller gerade erst gestartet wurde, dann muss er die Liste erstmal füllen. Wenn ein Controller eine Weile nicht sichtbar war, wird er aus der Liste gelöscht.

Zitat von: rippi46 am 11 Februar 2025, 19:44:56Aktuell habe ich nach dem OTA-Update wieder einen Controller der nicht mehr erreichbar ist. Vermutlich muss ich ein Hardreset durchführen.

hab ich jetzt lange nicht gehabt - war das einer, der zuvor Probleme mit dem Flash Storage hatte? Das wäre aktuell mein Verdacht.

pj

Hallo

Der Controller der gerade nicht mehr erreichbar ist, hatte heute das Problem, dass er in fhem ab und zu als Offline aufgetaucht ist.
Habe ihn dann upgedatet. Das hat auch soweit funktioniert. Dann habe ich etwas mit den Presets und dem Netzerknamen rumgespielt.
Danach hat ich wieder das Problem im Browser mit dem aktualisiern. Habe dann ein Update durchgeführt aus dem er nicht mehr aufgewacht ist.

Gruß rippi

hmm.. ist er wirklich tot oder ist er nur nicht erreichbar?
Kannst Du ihn manuell neu starten?
Dass er schon vorher in fhem nicht erreichbar war ist ja schon verdächtig.

Zumindest ist er nach einem Reboot nicht mehr sichtbar. Muss ihn vermutlich wieder seriell flashen oder der Speicher ist wieder einmal defekt (ESP austauschen!!?? :)) ).

Habe ja noch ein paar als Ersatz bis er wieder funktioniert.

Die beiden anderen Controller funktionieren bis jetzt. Also Presets setzen, als Favoriten speichern, auf den andern Controller übertragen.

Gruß rippi

Eigentlich ist die neue Firmware nicht so empfindlich, was ausfallende Flash Zellen angeht, aber ganz gefeit ist sie halt doch nicht.
Schau mal, was er auf der Seriellen ausgibt, vielleicht lässt sich was machen.
Sollte es Flash Probleme im rom Block geben (also da, wo die Firmware liegt) dann sollte es immer wechselweise mit Updates funktionieren oder nicht, weil OTA ja wechselweise in rom0 und rom1 schreibt.

OK Alles wieder Gut.

Controller war im Accesspointmodus und hat ein Passwort verlangt, deswegen  war er nicht mehr erreichbar.

Jetzt ist er wieder online :)

Gruß rippi

das haben jetzt schon ein paar Tester berichtet.
Würde mich mal interessieren, warum manche Controller die Netzwerkkonfiguration verlieren. Die liegt nicht in einer der User Partitionen, sondern, soweit ich weiß, in der sys_param Partition, die ich nicht verändere.
Allerdings kann es sein, dass noch ESP8266 dabei sind, deren Firmware aus der allerersten Charge stammt, damals gab es soweit ich weiß noch keine Partitionen, sondern nur fest zugeordnete Flash Blocks, da könnte ich mir vorstellen, dass die wifi config verloren geht.

Partition map: two_roms_two_lfs_Esp8266
options:
Device            Start       End         Size        Type      SubType   Name              Filename
----------------  ----------  ----------  ----------  --------  --------  ----------------  ------------
spiFlash          0x00000000  0x00001fff          8K                      Boot Sector      
spiFlash          0x00002000  0x000fffff       1016K  app       ota_0     rom0              $(RBOOT_ROM_0_BIN)
spiFlash          0x00100000  0x00105fff         24K                      (unused)         
spiFlash          0x00106000  0x001fdfff        992K  data      littlefs  lfs0             
spiFlash          0x001fe000  0x00201fff         16K                      (unused)         
spiFlash          0x00202000  0x002fffff       1016K  app       ota_1     rom1             
spiFlash          0x00300000  0x003f7fff        992K  data      littlefs  lfs1             
spiFlash          0x003f8000  0x003f9fff          8K                      (unused)         
spiFlash          0x003fa000  0x003fafff          4K                      Partition Table  
spiFlash          0x003fb000  0x003fbfff          4K  data      rfcal     rf_cal           
spiFlash          0x003fc000  0x003fcfff          4K  data      phy       phy_init          $(FLASH_INIT_DATA)
spiFlash          0x003fd000  0x003fffff         12K  data      sysparam  sys_param


Endlich kann ich den Controller über das Menü neu starten :)  :)

Gibt es eigentlich die Möglichkeit eine Spannung zu messen. Ich dachte da an meine batteriebetriebene Controller.
Es wäre ja schön zu wissen, wann man die Spannungsquelle aufladen oder austauschen muss. (nur so als Idee)
Ist aber nicht zwingend notwendig.

Gruß rippi

die gute Nachricht: ich hab einen Weg gefunden, die debug Ausgabe von der Seriellen Schnittstelle auf websocket umzuleiten und so auf dem Frontend darzustellen.
die schlechte Nachricht: das funktioniert nur dann, wenn nur ein einziges Frontend mit dem Controller verbunden ist, weil zumindest auf dem Esp8266 nicht genug RAM vorhanden ist. Wenn viele Nachrichten schnell nacheinander kommen, dann crasht der Controller.
Schade, sah nicht schlecht aus.

Zitat von: rippi46 am 12 Februar 2025, 22:59:35Endlich kann ich den Controller über das Menü neu starten :)  :)

war schon die ganze Zeit drin, aber wegen eines Tippfehlers im Firmware Code wurde es nicht dargestellt ;-)

Zitat von: rippi46 am 12 Februar 2025, 22:59:35Gibt es eigentlich die Möglichkeit eine Spannung zu messen. Ich dachte da an meine batteriebetriebene Controller.
Es wäre ja schön zu wissen, wann man die Spannungsquelle aufladen oder austauschen muss. (nur so als Idee)
Ist aber nicht zwingend notwendig.
Grundsätzlich hab ich irgendwo gelesen, dass der Esp8266 seine VCC (also Versorgungsspannung) messen kann, aber die interessiert Dich ja nicht wirklich, was Du wollen würdest wäre die 12V Spannung - die 3.3V für den ESP werden ja vom Spannungsregler sehr konstant gehalten.

Um die 12V zu messen bräuchte es ein bisschen extra Schaltung, nur in Software geht da nix.
Gruß rippi

ZitatUm die 12V zu messen bräuchte es ein bisschen extra Schaltung, nur in Software geht da nix.

Interresant währe im Prinzip einfach die Spannung bzw. der Wert an A0 des ESP. Den Rest würde ich über einen kleinen Spannungsteiler erledigen.

Wenn ich es richtig weiss verträgt der nackte ESP8266 1.0V an A0.

Ich habe 5 Controller batteriebetrieben. Solange ich eine LiFePo-Akku dran habe ist das nicht sehr kritisch. Der schaltet einfach bei ca 10,5 Volt ab.
Bei den normalen Blei-Akkus funktioniert das nicht. Die werden ausgesaugt bis nichts mehr geht und dann sind die relativ bald defekt.

Wenn es jetzt einfach ein Möglichkeit gäbe die Spannungsmessung über die Weboberfläche ein bzw auszuschalten. könnte ich den Wert weiterverarbeiten und bei unterschreiten einer Grenze darauf reagieren (Akku tauschen)

Gruß rippi

Zitat von: rippi46 am 13 Februar 2025, 11:31:14

ZitatUm die 12V zu messen bräuchte es ein bisschen extra Schaltung, nur in Software geht da nix.

Interresant währe im Prinzip einfach die Spannung bzw. der Wert an A0 des ESP. Den Rest würde ich über einen kleinen Spannungsteiler erledigen.

Wenn ich es richtig weiss verträgt der nackte ESP8266 1.0V an A0.

Ich habe 5 Controller batteriebetrieben. Solange ich eine LiFePo-Akku dran habe ist das nicht sehr kritisch. Der schaltet einfach bei ca 10,5 Volt ab.
Bei den normalen Blei-Akkus funktioniert das nicht. Die werden ausgesaugt bis nichts mehr geht und dann sind die relativ bald defekt.

Wenn es jetzt einfach ein Möglichkeit gäbe die Spannungsmessung über die Weboberfläche ein bzw auszuschalten. könnte ich den Wert weiterverarbeiten und bei unterschreiten einer Grenze darauf reagieren (Akku tauschen)

Gruß rippi

verstehe.
Ich denk mal drüber nach, wenn ich mit allem anderen fertig bin ;-)
Das ist doch eine eher ungewöhnliche Anforderung.
Aber: Du kannst ja einen Pull Request machen ;-)

argh! Ich hab mir gedacht, ich räum kurz mal die Messaging Protokolle auf (aktuell spricht der Controller jsonrpc über tcp socket, mqtt und websocket, tcp socket wird früher oder später raus fliegen, aber die anderen beiden sollten gleichwertig sein.

Jetzt schreibe ich eine abstrakte Interface Klasse für die drei Transport Mechanismen, eine abstrakte Message Klasse, einen abstrakten Eventserver und wenn ich Zeit hab auch noch einen abstrakten Callback Mechanismus, damit ich einfach erweitern kann, wie der Controller auf Messages reagiert.

Wenn, wie in dem Fall, drei, vier Entwicker nacheinander an einer relativ großen Firmware arbeiten schraubt jeder seinen Teil an das bestehende an (so hab ich's mit websocket gemacht) und irgendwann muss dann mal die Architektur überdacht werden.

Call me Mr. Scope Creep

okay, neue Version incoming. Nicht so sehr viel offensichtlich neues, aber ich hab hinter den Kulissen ein bisschen aufgeräumt und ein paar Dinge sollten jetzt etwas besser aussehen.
es gibt auch eine neue top-level Seite für "Groups and Scenes", die aber noch nicht wirklich fertig ist. Die Idee ist hier, dass ich dort die Verwaltung von Gruppen von Controllern und Szenen, also vordefinierten einstellungen für Controller unterbringe.

Im moment ist mein Gedanke so:

• Gruppe definieren (etwa "Wohnzimmer")
• manuell für jeden Controller die Helligkeit/Farbe einstellen, die für die Szene gewünscht ist
• Eine Szene anlegen, die erstellte Gruppe auswählen und abspeichern. Dabei wird der Controller im Hintergrund die aktuelle Farbe und Helligkeit der anderen in der Gruppe abfragen und das als den Wert für die Szene speichern

Wie gesagt, das ist so noch nicht implementiert, aber so kann ich es mir vorstellen.
Ich weiß noch nicht so richtig, wo die Szenen dann im UI hin gehören. Eigentlich sollten sie so ziemlich direkt erreichbar sein, ähnlich wie jetzt die besternten Presets. Vielleicht werfe ich die Szenen dort mit rein, so dass es eine Oberfläche gibt, von der aus sofort alle "one Touch" Funktionen erreichbar sind.

Habt Ihr bessere Ideen?

im Moment ist offenbar ein Fehler im Frontend, der dazu führt, dass es gar nicht erst geladen wird.
Macht mal keine Updates, bis ich das behoben habe.
(ich glaube, es hängt mit einem Change zusammen, der die Auswahl des aktuellen controllers betrifft)

Problem behoben (es saß ziemlich mittig zwischen meinen Ohren) - Ihr könnt wieder testen.

Weil du gerade neue Features einbaust und nach Ideen gefragt hattest. Ich hätte eine, aber wahrscheinlich ist die recht speziell:
Ich setze mehrere der Controller für die Aquarienbeleuchtung ein. Man kann hervorragend Tagesabläufe simulieren, inklusive rötlichem Sonnenaufgang, fahlem Mondlicht etc. Nun würde ich aber oftmals Einstellungen der fünf Kanäle nutzen wollen, die nur per RAW Befehl möglich sind, weil sie in der Wohnraumbeleuchtung keinen Sinn ergeben. Zum Beispiel beide Weißkanäle gleichzeitig auf 100% oder sogar alle 5 Kanäle auf 100%. Mit RAW Befehlen möglich, aber man kann dann leider die automatische Überblendung nicht nutzen, die die Controller gerade so attraktiv macht.

Mein Wunsch wäre daher so etwas wie ein Boost-Modus, der sich wie folgt verhält:
Normalerweise wird bei Vorhandensein eines oder beider weißen Kanäle der Weißanteil der eingestellten Farbe auf den Weißkanälen ausgegeben und von den RGB Kanälen abgezogen. Außerdem wird je nach eingestellter Farbtemperatur der Weißanteil zwischen den beiden Weißkanälen aufgeteilt, sodass beispielsweise bei mittlerer Farbtemperatur beide weiße Kanäle zu je 50% maximal angesteuert werden. Das ergibt auch Sinn, denn es soll sich beim Ändern der Farbtemperatur die Helligkeit ja nicht ändern, sodass nie mehr als die Helligkeit eines der beiden Kanäle allein genutzt werden kann.
Ich hätte jetzt gern, dass der Controller sich in diesem speziellen Wunschmodus so verhält, dass der Weißanteil der eingestellten Farbe weiterhin auf den weißen Kanälen ausgegeben wird, aber ohne diesen Anteil von den RGB Kanälen abzuziehen. Das würde dazu führen, dass Weiß dann gleichzeitig mit allen RGB Kanälen und den Weiß Kanälen dargestellt würde. Außerdem sollte auch bei der Wahl der Farbtemperatur die Helligkeitskorrektur entfallen, sodass bei einer mittleren eingestellten Farbtemperatur beide Weißkanäle auf 100% laufen würden.
Zusammen genommen würde also bei einer angenommenen Konfiguration von WW 3000K und CW 5000K und einer Einstellung von Weiß mit 4000K als Ergebnis alle RGB Kanäle auf 100% (weil weiß) und beide Weißkanäle auf 100% (weil mittlere Farbtemperatur) herauskommen.

Für die Wohnraumbeleuchtung ergibt das natürlich wenig Sinn, weil sich mit der Farbeinstellung auch immer die Helligkeit verändern würde. Aber wenn es darum geht, die maximale Helligkeit aus den installierten LEDs zu holen (weil man z.B. ein Aquarium beleuchtet und die Eigenarten dieser Betriebsart im Ablauf berücksichtigen kann), dann wäre das für mich ein echt praktisches Feature.

Ist meine Beschreibung nachvollziehbar? Ich habe keine Ahnung wie komplex die Umsetzung wäre, möglicherweise geht es ganz leicht, vielleicht hängt aber viel mehr dran als ich mir naiv vorstelle. Dann wäre die Frage, ob so ein Feature außer für mich auch für andere interessant wäre. Es muss ja nicht zwingend um Aquarien gehen. Eine per Infrarot steuerbare RGBW E27 Lampe von Jedi hat beispielsweise einen Modus "Arbeitslicht", bei dem die maximal mögliche Helligkeit abgerufen wird, indem einfach alle Kanäle auf 100% gestellt werden, unabhängig von der sich ergebenden Farbtemperatur. Das ist manchmal schon ganz nützlich.

Man könnte das ja im Webinterface bei der Einstellung der angeschlossenen LED Kanäle unterbringen. Einfach eine Tickbox "Boostmode" oder so, die natürlich nur Sinn ergibt, wenn mindestens ein weißer Kanal vorhanden ist. Oder als weitere Auswahl bei der Farbmischung (Spektrum, Regenbogen oder was es da alles gibt, übrigens eine Einstellung deren Wirkung mir nicht so ganz klar ist).

@Mafi, das klingt eher wie etwas, das ich in der nächsten Version angehen würde (V6) - da will ich die rgbww library angehen und unter anderem "virtuelle Leuchten" einbauen, also etwa die Möglichkeit, die fünf Kanäle eines ESP8266 in eine RGB und zwei Reinweiß Leuchten zu konfigurieren, die dann auch getrennt steuerbar sind. Sinnvoll ist das dann vor allem für die größeren ESP32, die 12 Kanäle ansteuern können.
Ich behalt Deine Idee mal in Hinterkopf. Aber: das kann ein bisschen dauern. ;-)

so, gerade hab ich eine neue Version gepusht, die ein paar Verbesserungen unter der Haube mitbringt, aber auch ein paar Sachen, die sichtbar sind:

• Presets sind jetzt global, das heißt sie werden auf alle aktuell sichtbaren Controller verteilt. Das ist nützlich, wenn ich im nächsten Sprint auch Presets in der Definition einer Szene nutzen will. Alle Elemente, ob Szenen, Presets, Gruppen oder Hosts werden jetzt über eine eindeutige ID angesprochen, so dass sie über das ganze Netzwerk (genaugenommen sogar global, weil die ChipID des Controlers eingeht) eindeutig sind.
• es gibt einen Button, der alle Presets überall löscht. Ob der später in den Production Build eingeht weiß ich noch nicht, ich hab den primär gebraucht, wenn ich die Controller aufräumen musste, weil alle unterschiedliche Presets hatten
• es Gruppen können angelegt werden, um später eine Szene für eine Gruppe anzulegen. Eine Szene bezieht sich immer auf eine Gruppe von Controllern, d.h. die Gruppe muss vorhanden sein, bevor die Szene dafür angelegt wird.
• auch wenn es so aussieht, noch funktionieren Szenen nicht, ich hab die Colorpicker Seiten so umgebaut, dass ich die Komponenten in der Definition von Szenen nutzen kann - das einzubauen ist der nächste Schritt
• im Firmware Update Dialog wird jetzt automatisch die build Variante vorgewählt, die aktuell auf dem Controller läuft (debug oder release). Ich bau noch eine Funktion ein, um alle sichtbaren Controller auf einmal updaten zu können. Ich überlege auch, ob ich statt des "check firmware" einfach von vornherein checke, ob es neuere Firmware gibt und dann den Button "update Firmware" nenne, das spart dann einen Schritt, denn der Button wäre nur verfügbar, wenn die aktuelle Firmware auf lightinator.de neuer wäre als die gerade laufende. Allerdings gibt es da ggf. die Situation, dass man den build Type wechseln möchte. Ich muss überlegen. Außerdem denke ich, ich werde eine Funktion einbauen, die alle Controller auf einmal updaten kann.

die auffälligste Änderung ist aber, dass die verschiedenen Karten des UI jetzt als default eingeklappt sind (ausgenomen der Colorpicker). Das empfinde ich als übersichtlicher und schöner - sagt mir, was Ihr denkt.
Weil ich neulich das Caching auf dem Controller aktiviert habe, müsst Ihr vermutlich den Reload des UI erzwingen, indem Ihr auf einem neu geflashten Controller einmal <shift> reload klickt.

Und am Rande: ich nutze diese Version mittlerweile auf all meinen Controllern, wenn sie aus fhem heraus angesteuert wird, hat sie sich bisher als völlig stabil erwiesen. Ich habe etliche Controller, die zuvor mit der alten Firmware an der Ermüdung des FLASH gestorben waren hiermit wieder reanimiert und nutze sie wie gehabt.

und noch ein neuer Build für's OTA - diesmal gibt's die ersten Szenen Funktionen.
Die Logik ist derzeit so:
Ihr legt eine Gruppe von Controllern an (etwa für einen Raum oder ein Objekt oder was immer bei Euch zusammen gehört)
Ihr legt dann eine Szene an und wählt die zugehörige Gruppe aus. Danach könnt ihr für jeden Controller der Szene entweder ein Preset, einen hsv oder einen raw Wert auswählen, der dann in der Szene gespeichert wird.
Die Szenen werden als hierarchische Liste unter den Gruppen angezeigt, allerdings sind die Namen global (es kann aber den gleichen Namen mehrfach geben, denn intern verwendet der Controller eindeutige IDs)
Wenn Ihr in der Liste eine Szene anklickt, dann wird sie auf die Controller der Gruppe angewendet.

Was noch kommt:

• neben dem Gruppenkopf ist schon ein kleines Kamera Icon, der Gedanke ist da, einen Snapshot der aktuellen Beleuchtung zu machen, d.h. Ihr stellt wie gehabt jeden Controller ein und die Szene speichert dann, was gerade ist.
  
• jede Szene hat schon ein Sternchen Icon, damit macht Ihr sie zum Favoriten. In zukunft sollen die favorisierten Szenen dann auf der Startseite im gleichen Screen dargestellt werden wie jetzt schon die favorisierten Presets, so dass Ihr schnell von dort aus eine Szene aktivieren könnt
  
• ich habe im Schema vorbereitet, dass Ihr für jeden Controller und jede Szene ein eigenes Icon vorgeben könnt, allerdings aus einer Auswahl von internen Icons, ich will die Controller so weit wie möglich Internet-unabhängig halten
  

Ich glaube, so langsam erreiche ich einen Funktionsumfang, den man kommerziell ohne Server oder Cloudanbindung nicht finden wird.

Wie oben schon gesagt: alle Daten werden auf alle Controller geschrieben, es ist demnach egal, mit welchem Controller Ihr Euch verbindet. Der Nachteil ist, dass das bei vielen Controllern länger dauern kann.

Worüber ich nachdenke: Ich könnte auch noch Animationen als Objekt einführen. Der Controller kann ja selbständig Farbwechsel ausführen und es gibt eigentlich keinen Grund, die nicht auch über das UI zugänglich zu machen. Schwieriger wird es, dann mehrere Controller halbwegs synchron zu halten, ohne dann mqtt zu nutzen.

Der Szenen Dialog kommt langsam zusammen. Es fehlen noch ein paar Kleinigkeiten und favorisierte Szenen müssen noch in der Favorites Page eingebunden werden, aber langsam wird's.

Neue Version heute Morgen!

eigentlich gibt es jetzt auf https://lightinator.de die Möglichkeit, die aktuelle Firmware per web-install zu installieren (ideal für noch nicht geflashte Controller) - aber zumindest bei mir spiel Chrome da nicht mit.

Vielleicht klappt's ja bei Euch.

pj

Noch ne neue Version. Diesmal funktioniert die Synchronisation mit existierenden Controllern und ein neuer Controller, der eingebunden wird, holt sich erstmal die Presets, Gruppen und Szenen von den anderen, oder genauer: immer, wenn das Frontend auf einem Controller gestartet wird, werden Presets, Gruppen und Szenen mit allen anderen synchronisiert.

neues Feature, jetzt können von einem Controller aus alle im Netzwerk upgedatet werden. Hat noch ein paar kosmetische Probleme, aber funktioniert insgesamt schon ziemlich gut.

so, jetzt funktioniert auch die Pin Konfiguration vollständig.

jetzt werden die Szenen, die Ihr mit Stern versehen habt auch auf der Schnellzugriff-Seite angezeigt, so dass Ihr nicht in die Szenen Seite müsst.
Dieses Setting ist, wie auch bei den Presets, lokal, dass heißt jeder Controller hat seine eigene Zusammenstellung von Szenen und Presets da.

Die Darstellung der Szenen ist noch nicht ganz korrekt, da sollten alle Controller der Gruppe mit der entsprechenden Farbe dargestellt werden.

Ich hab noch ein paar andere Ideen, aber langsam wird das hier feature complete. Bei mir laufen aktuell 10 controller mit der Firmware, die letzten 10 mal hab ich die "update all" Funktion benutzt und das hat einwandfrei funktioniert.

Ich würde die Version jetzt als Beta betrachten und es wäre super, wenn es ein paar Tester gäbe, die auch einige der neueren Funktionen testen.

kurzer Nachtrag: "Alle" bedeutet hier: alle Controller, die der aktuell ausgewählte Controller per mDNS gesehen hat. Das müssen nicht immer wirklich alle sein. Ich habe eine Idee, wie ich das ein bisschen stabiler machen kann.

@mafi, wenn Du magst, kannst Du Dir mal die letztes Version im OTA Channel ansehen, da sind jetzt ca. 80% funktionierende Animationen drin, und ich meine, die müssten auch für RAW Settings funktionieren
Was Du machen kannst ist:
Du legst eine Gruppe an, in der der/die gewünschte Controller ist.
In der Gruppe legst Du eine Szene an (geht am einfachsten über das Camera Icon als Snapshot)
In der Szene kannst Du jetzt den Namen ändern und auch das Setting.
Das Setting besteht einerseits aus der Farbe (das kann HSV, RAW oder Preset sein) als auch die Transition. Dort kannst Du Zeit oder Geschwindigkeit einstellen.
Wenn Du die Szene jetzt aktivierst, wird die Animation auf den Conroller geladen und ausgeführt.
Ich glaube, damit solltest Du etwa auch von aus auf 100%cw / 100%ww faden können, aber das hab ich nicht getestet.

Das werde ich mir bei passender Gelegenheit mal ansehen! Dazu muss ich den Controller am Aquarium wahrscheinlich einmal ausbauen und seriell flashen. Per OTA hatte es vor kurzem einfach nicht geklappt. Er bootete nicht mehr und war nach Rücksetzen auf Werkseinstellung per Taster dann weiterhin in der alten Software. Damit läuft er aber weiterhin. Ein anderer Controller hat gar kein Webinterface mehr, kann aber via FHEM gesteuert werden. Der muss wohl auch einmal seriell bearbeitet werden.
Kann ich denn eine im Controller angelegte Szene per FHEM abrufen?

bei dem Controller, der kein UI mehr zeigt ist mit ziemlicher sicherheit das SPIFFS defekt, weshalb es nicht mehr gemountet werden kann - weil die UI Files in der alten Version darin liegen, kann er sie dann nicht mehr ausliefern.
Du kannst da immer versuchen, über das API ein OTA anzustoßen:
curl -X POST http://<ip-adresse>/update -H 'Content-Type: application/json' --data '{"rom":{"url":"http://lightinator.de/download/esp8266/develop/debug/rom0.bin"},"spiffs":{"url":"http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'
mit ein bisschen Glück, kommt er danach mit der neuen Firmware hoch, vielleicht, wenn es ein ganz alter Controller ist, muss das WLAN neu konfiguriert werden.

und zum FHEM Thema: nein, die Szenen sind heute ausschließlich im Frontend integriert, aber das Frontend natürlich die gleichen API Calls, die auch FHEM nutzt, so dass sich das auch aus FHEM heraus machen lassen würde.

Zitat von: Mafi am 26 März 2025, 10:11:48Ein anderer Controller hat gar kein Webinterface mehr, kann aber via FHEM gesteuert werden. Der muss wohl auch einmal seriell bearbeitet werden.

Üblicherweise kann man solche Controller einfach aus FHEM heraus einmal neu flashen und dann sollten sie wieder gehen:
set myLed fw_update 1(die "1" forciert das Flashen, weil normalerweise nur geflasht werden würde, wenn eine neuere Firmware zur Verfügung steht)

Zitat von: vbs am 26 März 2025, 10:33:12Üblicherweise kann man solche Controller einfach aus FHEM heraus einmal neu flashen und dann sollten sie wieder gehen:

einmal geht vermutlich, weil der Controller dann auf die anderen rom/spiffs Blöcke umschaltet, sprich wenn die spiffs Strukturen in spiffs0 nicht mehr schreib/lesbar sind, dann funktionieren sie vermutlich noch in spiffs1 - aber die chance ist groß, dass beim nächsten OTA das SPIFFS wieder nicht funkioniert.
Liegt einfach daran, dass SPIFFS nicht sehr fehlertolorant ist, wenn bestimmte Flash Blöcke nicht mehr beschreibbar sind, und die alte Firmware führt mehr oder weniger dazu, indem sie nach jeder Änderung die startup color neu schreibt. Diese Änderungen werden zwar statisch "ge-wear-levelled" - nicht aber der iNode, und wenn der nicht mehr korrekt geschreiben werden kann, dann kann die Firmware das Dateisystem eben nicht mehr mounten.

Deshalb habe ich in der neuen Firmware zwei Dinge grundlegend geändert:
- das UI ist Teil des rom Blocks, also nicht mehr in einer eigenen Filesystem Partition
- das Dateisystem für die veränderlichen Daten ist little fs (lfs) - ich hab das wear levelling und die Fehlertoleranz ausgiebig getestet und lfs ist ein riesen Schritt voran, wenn es um die Dauerhaftigkeit des Flash Blocks geht.

Dazu kommt natürlich, dass in der V5 Firmware ein paar hässliche Bugs in lwip gefixt sind, die früher für Probleme gesorgt haben. Ich habe das json API nicht verändert, sodass alle bisherigen Funktionen auch mit der V5 funktionieren (ich habe hier 10 Controller upgedatet, die ich weiterhin über FHEM steuere)

Ich würde zwar die V5 noch als Beta bezeichnen, weil sich immer wieder was ändert, aber für fhem only Nutzer gibt es imho keinen Grund mehr, die alte Version zu nutzen.

Ich hab damit schon sehr viele Male das Webinterface wiederbeleben können (auch beim gleichen Controller). Wenn der Flash wirklich irgendwann kaputt sein sollte, dann ist das so. Dann hilft aber auch kein serieller Flash mehr.
Wenn ich mich richtig erinnere, hatte ich aber tatsächlich in all den Jahren bisher nur einen (oder zwei??) Controller, die ich wirklich austauschen musste.

Ich muss aber dazu sagen, dass ich das Webinterface auch eigentlich gar nicht nutze, weil ich alles zentral über FHEM steuere. Sprich: ich bekomme im Zweifel auch gar nicht mit, wenn es bei einem Controller ausfällt bzw. es stört dann auch nicht.

Zitat von: vbs am 26 März 2025, 12:38:43Ich muss aber dazu sagen, dass ich das Webinterface auch eigentlich gar nicht nutze, weil ich alles zentral über FHEM steuere. Sprich: ich bekomme im Zweifel auch gar nicht mit, wenn es bei einem Controller ausfällt bzw. es stört dann auch nicht.

Aber auch dann fällt es auf, weil ja die Konfiguration auch im SPIFFS liegt, ich sehe es dann immer daran, wenn ein Controller statt echtem weiß aus rgb gemischtes weiß anzeigt. Das kommt leider häufiger vor. Über die Jahre habe ich bestimmt 20 ESPs ausgetauscht (was bei insgesamt 1350 Controllern, die durch meine Hände gegangen sind immer noch eine kleine Quote ist)
Das Fehlerbild ist dabei immer gleich: SPIFFS kann nicht gemountet werden. Die Dinger sind so billig, da will ich auch gar nicht groß rum machen, SPIFFS ist ne Schwachstelle, deshalb wird jetzt ja fast überall lfs benutzt.
Und wie gesagt: die neue Version ist ja auch in vielen anderen belangen besser, alleine die vielen Bugfixes in SMING zwischen Version 4 und 6, ConfigDB statt des aufwendigen internen config Handling, dadurch 10kB mehr heap frei und und und. Und - Dein Code ist da ja auch immer noch drin 😉

Aber: neben der Portierung auf Sming 6 und damit auf die esp32 war mein Ziel tatsächlich, die firmware ein bisschen unabhängiger zu machen. Mit dem neuen UI braucht man halt keinen Server mehr, um mehrere Controller zu steuern. Damit kann man sie dann in einem Wohnmobil verbauen oder, wie in meinem Fall, im Boot.
vielleicht setze ich mich auch noch hin, und erweitere das mqtt schema so, dass auch home assistant damit klar kommt (die wollen die live Werte in einzelnen topics).
und neue Hardware gibt es dann auch, die ist so klein, dass sie an's Ende eines LED Strips passt. Und: sie kann 10 bit pwm noch mit, wenn ich mich nicht täusche, 8kHz

Das mit dem unzuverlässigen SPIFFS ist schon eine ärgerliche Sache und echt klasse, wenn das robuster wird in der neuen FW. Ich wollte doch dem Kollegen nur helfen, dass er nicht den Controller hinter'm Schrank vorkramen und seriell flashen muss ;)

Und ja, ich finde auch, dass 20 von 1350 wirklich recht wenig sind. Kommen jedoch sicher noch ein paar dazu, die die Leute selbst getauscht haben.

Zitat von: vbs am 26 März 2025, 14:33:26Das mit dem unzuverlässigen SPIFFS ist schon eine ärgerliche Sache und echt klasse, wenn das robuster wird in der neuen FW. Ich wollte doch dem Kollegen nur helfen, dass er nicht den Controller hinter'm Schrank vorkramen und seriell flashen muss ;)

Tatsächlich ist die Idee, aus fhem heraus zu flashen gut, das hab ich nur ganz selten gemacht - dem muss ich die url auf die bin files mitgeben, richtig? Die OTA URL funktioniert auf dem Weg nicht.
Grundsätzlich habe ich ja sehr darauf geachtet, dass die neue Firmware auch im OTA zu flashen ist (frag nicht, weil die SMING 3 basierte Firmware noch kein Partition Table mitbringt musste ich da ein paar seltsame Verrenkungen machen, aber auch für SMING 4, also Deine Version, muss ich das Partition Table ändern, weil lfs ein anderer Typ ist als SPIFFS)
Ich habe ein oder zwei Fälle, in denen das nicht direkt funktioniert hat, meistens hat ein einfachers aus- und wieder anschalten geholfen und sie sind in die neue Firmware gestartet. Blöd ist: wenn das nicht geht, dann geht halt nur noch seriell.
Das schöne ist aber, dass es mir bei einigen Controllern mit defektem Flash gelungen ist, auf V5 upzudaten, und sie haben direkt funktioniert, ohne Probleme.

Zitat von: vbs am 26 März 2025, 14:33:26Und ja, ich finde auch, dass 20 von 1350 wirklich recht wenig sind. Kommen jedoch sicher noch ein paar dazu, die die Leute selbst getauscht haben.

Ja, und wenn ich mir heute so ansehe, wieviel (oder wenig) Resonanz hier noch kommt glaube ich auch, dass viele einfach nicht mehr genutzt werden. Zu sehr sind sie an fhem gebunden, und ja auch billig zu ersetzen. Aber ich glaube, was Funktionsvielfalt und vor allem sanfte Fades angeht gibt es halt immer noch nicht vieles, was das ähnlich gut kann.

und wie gesagt: wenn ich die neue Hardware soweit habe, dann sind die ungefähr 12mm breit und 30mm lang und können dennoch 5A pro Kanal.

ZitatJa, und wenn ich mir heute so ansehe, wieviel (oder wenig) Resonanz hier noch kommt glaube ich auch, dass viele einfach nicht mehr genutzt werden. Zu sehr sind sie an fhem gebunden, und ja auch billig zu ersetzen. Aber ich glaube, was Funktionsvielfalt und vor allem sanfte Fades angeht gibt es halt immer noch nicht vieles, was das ähnlich gut kann.

Mahlzeit!
Tja, Resonanz - bisher sind meine beiden Controller ohne Probleme mit der initialen Firmware gelaufen, sie sind nicht immer im Einsatz, nur zur Gartenzeit in den Abendstunden zur Beleuchtung vom Wintergarten... Aber ja, zumindest war dein Kommentar - den ich nicht böse aufgefasst habe - der Anstoss mal ein Update der FW vorzunehmen.
Fazit:
2x ohne Probleme. Beide kamen nach dem Update im AP Modus hoch - WLAN Cfg durchführen, Backup der Cfg einspielen, fertig.
Und - ich freue mich, dass aktiv weiter entwickelt wird und denke, die neue 'Mini' Hardware verspricht etwas Bastelei im nächsten Winter. Dann finden sicherlich noch ein paar davon im Rest des Hauses Einzug...
Gruß Peter

moin @PSI69 - Du hast die alte Konfiguration exportiert und auf der neuen Firmware erfolgreich importiert?
Dann kann ich es Dir ja jetzt sagen: den Pfad hatte ich noch nie getestet! :-)
Es gab keinen wirklichen Grund, warum das nicht funktionieren sollte, weil das ja nur die json Struktur ist, die der /config API Endpoint nutzt. Aber genau der Code hat sich vollständig verändert, früher gab es zwei unterschiedliche Code Blöcke für den API Endpoint und die save/restore Funktion, das ist heute beides in der ConfigDB (https://github.com/mikee47/ConfigDB) Komponente die im Rahmen dieses Rewrite entstanden ist. Insofern bin ich schon froh, dass das Ergebnis hier offensichtlicht passt!

Du hast die alten, schwarzen Controller mit den TO220 MOSFETS, oder? also die Platine, auf der die fünf großen Transistoren stehend aufgelötet sind, nicht die grüne mit den fünf kleinen Transistoren auf der Rückseite, oder? Ich frage, weil mir noch nicht ganz klar ist, wann das wifi neu konfiguriert werden muss, meine Hypothese ist, dass das die allererste Firmware war (also nicht @VBS), und die Art, wie der ESP den Flash verwaltet hat damals noch ganz anders war, weshalb die wifi Konfiguration überschrieben wird.

pj

Du hast die alte Konfiguration exportiert und auf der neuen Firmware erfolgreich importiert?Ja.
den Pfad hatte ich noch nie getestet :)) - hat ja dann geklappt.
Du hast die alten, schwarzen Controller mit den TO220 MOSFETS, oder? also die Platine, auf der die fünf großen Transistoren stehend aufgelötet sind, nicht die grüne mit den fünf kleinen Transistoren auf der Rückseite, oder?Ich habe die grüne, mit den 5 liegenden auf der Rückseite.
Gruß Peter

Zitat von: PSI69 am 28 März 2025, 08:01:43Ich habe die grüne, mit den 5 liegenden auf der Rückseite.
Gruß Peter

Interessant, die haben wir doch eigentlich alle mit der @vbs firmware ausgeliefert, zumindest im Rahmen der Sammelbestellung. Dann ist meine Hypothese wohl falsch.

Zitatzumindest im Rahmen der Sammelbestellung

Meine beiden sind daraus...

Ich habe eben noch einmal nachgeschaut, in meinem Changelog steht das hier als alte Version:
Firmware vbs35
Web Interface 0.3.3-shojo7
RGBWW Version 0.8.1-vbs5
SMING Version 3.5.1 Ich habe ich die OTA URL geändert und das Update durchgeführt: OTA URL: 'http://lightinator.de/version.json' (ALT: 'http://rgbww.dronezone.de/release/version.json')
Danach dann der AP Mode nach dem reboot beider Controller.

hmm.. das war die letzte Firmware vor der jetzigen.
Aber ich meine, Sming 3.5 hatte noch keine Partition Tables. Ich muss mal suchen.
Jetzt hast Du aber Firmware "pj-1-719-gad87" und Sming Version 6, oder?
(ich muss die git-version Strings mal fixen)

info-firmware ad87-dirty-[develop]
info-sming_version 6.0.0
info-webapp_version 8843-dirty-[devel]

ich muss wirklich die git-version Strings fixen

Hier bin ich 'gelandet' nach dem Update:
Git Version ad87-dirty-[develop]
Build Type release
Git Date 2025-03-25
Webapp Version 8843-dirty-[devel]
Sming Version 6.0.0

So, ich hab mal die Release Struktur komplett umgebaut. Es gibt jetzt drei production Stages:
stable/testing/develop

• develop ist, wo ich teste. Die kann schonmal komplett kaputt sein, im Normalfall sollte aber von dort aus sollte zumindest immer ein OTA funktionieren (gestern ging das nicht, weil ich eben am Umbauen war)
• testing ist die Stage, in die ich builds schiebe, von denen ich glaube, dass sie stabil genug für den normalen Gebrauch sind. Wer nicht allzu abenteurlustig ist, aber neue Features testin will, sollte die verwenden.
• stable gibt es aktuell noch nicht, denn noch verändert sich ja vieles. Sobald die 5.0 fertig ist, wird das die stable und neue Features für eine 5.1 laufen dann in die anderen beiden stages ein

Dazu gibt es für alle Stages mindestens zwei Builds zur Auswahl: Stable und Testing haben immer eine aktuelle und eine historische Version, so dass, wenn etwas wirklich nicht funktioniert, eine Fallback Möglichkeit besteht. Für develop gibt es 10 historische Versionen.

zudem haben die Versionen jetzt alle sinnvolle Version Strings im Fommat V<major>.<minor>-<build>-<stage> also etwa V5.0-334-develop. Beachtet, dass V5.0 für Frontend und Firmware immer gleich ist, aber die Build Nummer sich unterscheidet (in diesem Moment 334 für die Firmware und 116 für das Frontend). Weil ein Update des Frontend immer einen Rebuild der Firmware mit sich bringt, nicht aber umgekehrt, wird die Firmware build-Nummer immer größer sein und schnelelr größer werden als die des Frontends.

Was ich noch nicht implementiert habe sind entsprechend aufgeteilte Stages für das Frontend, was ggf. zu Problemen führen kann, weil der Firmware build aktuell immer den develop Zustand des Frontend nutzt, d.h. wenn ich eine neue Testing Version starte, nimmt sie das aktuelle Frontend. Ich glaube aber, dass das kein wirklich großes Problem ist.

Wow, vielen Dank für die neue Version.

Ich habe eine Platine V1.3, meiner Erinnerung nach aus der allerersten Serie (stehende LED Treiber).
Mit OTA Update war da leider nichts zu machen, auch nicht über die curl Tricks aus der Linux Shell. In der Web GUI hat mir der Controller sofort einen "Netzwerkfehler" gemeldet. Via curl ist er mal länger mal kürzer auf "ota ongoing" gegangen, hat aber immer den alten Stand behalten.

Ich habe ihn dann schließlich via Kabel geflasht und nach dem üblichen Drama, das Ding in den Flash-Modus zu bekommen, hat der Update auch funktioniert.
Danach waren die Einstellungen weg, was ich erwartet hatte. Nicht erwartet hatte ich aber, dass der AP nun per Default ein Passwort benötigt. Das ist dann auch nur hier in einem Post zu finden - ganz schön gemein   :D . Für andere wäre es sicher hilfreich, das hier im ersten Post und in Github noch zu wiederholen.

Eine Kleinigkeit ist mir noch aufgefallen: Ich habe manuell einen Hostnamen vergeben. Der wurde mir aber zweimal überschrieben und zwar mit dem Devicename aus FHEM. Da scheint irgendwas zu aktualisieren, was nicht soll.

Zitat von: weini am 01 April 2025, 19:08:56Wow, vielen Dank für die neue Version.

Ich habe eine Platine V1.3, meiner Erinnerung nach aus der allerersten Serie (stehende LED Treiber).
Mit OTA Update war da leider nichts zu machen, auch nicht über die curl Tricks aus der Linux Shell. In der Web GUI hat mir der Controller sofort einen "Netzwerkfehler" gemeldet. Via curl ist er mal länger mal kürzer auf "ota ongoing" gegangen, hat aber immer den alten Stand behalten.

so einen hatte ich auch schonmal, und kann nicht sagen, was da los ist.

Zitat von: weini am 01 April 2025, 19:08:56Ich habe ihn dann schließlich via Kabel geflasht und nach dem üblichen Drama, das Ding in den Flash-Modus zu bekommen, hat der Update auch funktioniert.
Danach waren die Einstellungen weg, was ich erwartet hatte. Nicht erwartet hatte ich aber, dass der AP nun per Default ein Passwort benötigt. Das ist dann auch nur hier in einem Post zu finden - ganz schön gemein  :D . Für andere wäre es sicher hilfreich, das hier im ersten Post und in Github noch zu wiederholen.

Password braucht der AP eigentlich immer schon, aber Du hast recht, ich sollte es nochmal irgendwo vermerken.

Zitat von: weini am 01 April 2025, 19:08:56Eine Kleinigkeit ist mir noch aufgefallen: Ich habe manuell einen Hostnamen vergeben. Der wurde mir aber zweimal überschrieben und zwar mit dem Devicename aus FHEM. Da scheint irgendwas zu aktualisieren, was nicht soll.

das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das? @vbs?

Zitat von: pjakobs am 01 April 2025, 23:25:10

Zitat von: weini am 01 April 2025, 19:08:56Wow, vielen Dank für die neue Version.

Ich habe eine Platine V1.3, meiner Erinnerung nach aus der allerersten Serie (stehende LED Treiber).
Mit OTA Update war da leider nichts zu machen, auch nicht über die curl Tricks aus der Linux Shell. In der Web GUI hat mir der Controller sofort einen "Netzwerkfehler" gemeldet. Via curl ist er mal länger mal kürzer auf "ota ongoing" gegangen, hat aber immer den alten Stand behalten.

so einen hatte ich auch schonmal, und kann nicht sagen, was da los ist.

So ging es mir auch, aber auch mit der neueren Hardware (SMD Transistoren). Ich habe alle Controller der Reihe nach seriell geflashed. Nur beim allerersten Controller (alter Stand) hat es tatsächlich über das GUI mit geänderter OTA URL funktioniert. Jetzt laufen alle mit der neuen Software (noch die AD87 Version, noch nicht die allerneuste). Die Variante mit der wget Anfrage zum Anstoßen des Updates war in keinem einzigen Fall erfolgreich. Nach dem vermeintlichen Update startete der Controller nicht von alleine neu und hatte dann auch keine neue Software drauf.

Zitat von: pjakobs am 01 April 2025, 23:25:10

Zitat von: weini am 01 April 2025, 19:08:56Ich habe ihn dann schließlich via Kabel geflasht und nach dem üblichen Drama, das Ding in den Flash-Modus zu bekommen, hat der Update auch funktioniert.
Danach waren die Einstellungen weg, was ich erwartet hatte. Nicht erwartet hatte ich aber, dass der AP nun per Default ein Passwort benötigt. Das ist dann auch nur hier in einem Post zu finden - ganz schön gemein  :D . Für andere wäre es sicher hilfreich, das hier im ersten Post und in Github noch zu wiederholen.

Password braucht der AP eigentlich immer schon, aber Du hast recht, ich sollte es nochmal irgendwo vermerken.

Also ich wurde von der alten Software (vbs) noch nie nach einem Passwort für den WLAN AP gefragt! Das passierte mit der neuen V5 das erste mal und auch ich habe längere Zeit gesucht, um das Passwort hier zu finden.

Zitat von: pjakobs am 01 April 2025, 23:25:10

Zitat von: weini am 01 April 2025, 19:08:56Eine Kleinigkeit ist mir noch aufgefallen: Ich habe manuell einen Hostnamen vergeben. Der wurde mir aber zweimal überschrieben und zwar mit dem Devicename aus FHEM. Da scheint irgendwas zu aktualisieren, was nicht soll.

das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das? @vbs?

Auch das ist mir ebenfalls passiert! Ganz klar wird der Hostname von fhem überschrieben, aber offenbar nicht immer. Unter welchen Bedingungen das passiert oder durch was es ausgelöst wird, ist mir nicht klar. Es führt jedenfalls zu Verwirrung.

Apropos Verwirrung: Die Maske zum Setzen der WLAN Zugangsdaten fragt zweimal nach der SSID, in Wirklichkeit ist das zweite SSID Feld aber das Passwort für das WLAN. Außerdem ist mir nicht klar, wie und wann diese Daten übernommen werden. Ich brauchte jedes mal mehrere Versuche bis der Controller sich dann mit dem WLAN verband. Soll das nach der Eingabe des Passworts von selbst passieren oder muss ich unten auf den grünen Haken tippen oder noch was anderes?

Zitat von: pjakobs am 01 April 2025, 23:25:10das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das?

Ja, genau! Das kam für mich unerwartet. So etwas über einen Set-Befehl anzubieten fände ich gut. Es "automatisch" zu tun ist überraschend.

Zitat von: Mafi am 02 April 2025, 10:14:33Auch das ist mir ebenfalls passiert! Ganz klar wird der Hostname von fhem überschrieben, aber offenbar nicht immer. Unter welchen Bedingungen das passiert oder durch was es ausgelöst wird, ist mir nicht klar. Es führt jedenfalls zu Verwirrung.

Ich habe mittlerweile das Attribut "deviceName" auf den FQDN gesetzt. Seitdem überschreibt er den Hostname auf dem Controller nicht mehr. Sieht für mich gut aus, sollte man nur noch dokumentieren (habe zumindest in der Hilfe nichts dazu gefunden).

Meine Farbrotation geht aktuell wohl auch noch nicht. Die starte ich in FHEM durch "set led_Bartresen hsv +5,100, 120 r", da ändert der Controller aber keine Farben.

Zitat von: pjakobs am 01 April 2025, 23:25:10das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das? @vbs?

Puhh, ist ein paar Jahr her, aber so aus dem Kopf würde ich sagen: kann es nicht (und tut es nicht). Also zumindest die vbs-Variante.

Zitat von: Mafi am 02 April 2025, 10:14:33So ging es mir auch, aber auch mit der neueren Hardware (SMD Transistoren). Ich habe alle Controller der Reihe nach seriell geflashed. Nur beim allerersten Controller (alter Stand) hat es tatsächlich über das GUI mit geänderter OTA URL funktioniert. Jetzt laufen alle mit der neuen Software (noch die AD87 Version, noch nicht die allerneuste). Die Variante mit der wget Anfrage zum Anstoßen des Updates war in keinem einzigen Fall erfolgreich. Nach dem vermeintlichen Update startete der Controller nicht von alleine neu und hatte dann auch keine neue Software drauf.

Ich kann nur vermuten, dass das ein Fehler in der OTA Komponente ist. Damit hat mein Code wenig zu tun, der übergibt einfach eine URL und rebootet, wenn der Flash Bereich erfolgreich geschrieben wurde (so ungefähr).
Wenn dazwischen was schief geht, dann funktioniert das OTA Update nicht. Es kann sein, dass das Update nicht korrekt heruntergeladen werden konnte, dass es nicht korrekt geschrieben werden konnte oder dass beim Reboot was schief ging.
Ich muss mir das bei Gelegenheit mal ansehen.

Zitat von: Mafi am 02 April 2025, 10:14:33Also ich wurde von der alten Software (vbs) noch nie nach einem Passwort für den WLAN AP gefragt! Das passierte mit der neuen V5 das erste mal und auch ich habe längere Zeit gesucht, um das Passwort hier zu finden.

auch die alte Version hatte mit großer Sicherheit ein Password auf dem Accesspoint, den Teil des Code habe ich nicht geändert. Aber: sobald das mal eingegeben worden ist, behält sich das Endgerät die SSID/Password Kombi. Ich glaube, der richtige Weg ist, das sauber zu dokumentieren.

Zitat von: Mafi am 02 April 2025, 10:14:33Apropos Verwirrung: Die Maske zum Setzen der WLAN Zugangsdaten fragt zweimal nach der SSID, in Wirklichkeit ist das zweite SSID Feld aber das Passwort für das WLAN. Außerdem ist mir nicht klar, wie und wann diese Daten übernommen werden. Ich brauchte jedes mal mehrere Versuche bis der Controller sich dann mit dem WLAN verband. Soll das nach der Eingabe des Passworts von selbst passieren oder muss ich unten auf den grünen Haken tippen oder noch was anderes?

Du hast völlig recht, damit hab ich mich selbst schon verwirrt, da muss ich das UI ein bisschen verbessern.
Die Felder sind, von oben nach unten:

• ein Dropdown Selector mit allen WIFI SSIDs, die der Controller gefunden hat
• ein Freitext Feld, um sich mit einem nicht sichtbaren Netz verbinden zu können
• das zugehörige Password (wann sich da eingeschlichen hat, dass das Feld SSID heißt weiß ich nicht, fällt mir gerade zum ersten mal auf! dafür sind Tester gut :-) )
  

Auf die Seite gehört auch noch ein "connect" Button. Mach ich in einem Aufwasch.

Der grüne Haken unten rechts ist kein Action Button, sondern zeigt lediglich den Zustand der Websocket Verbindung an. Da mach ich noch ein Tooltip dran.

Zitat von: weini am 01 April 2025, 19:08:56Ja, genau! Das kam für mich unerwartet. So etwas über einen Set-Befehl anzubieten fände ich gut. Es "automatisch" zu tun ist überraschend.

Zitat von: weini am 01 April 2025, 19:08:56Ich habe mittlerweile das Attribut "deviceName" auf den FQDN gesetzt. Seitdem überschreibt er den Hostname auf dem Controller nicht mehr. Sieht für mich gut aus, sollte man nur noch dokumentieren (habe zumindest in der Hilfe nichts dazu gefunden).

mir fehlt im Moment die Zeit, mir das fhem Modul auch noch anzusehen. Vielleicht kann das wer anderes machen?

Zitat von: weini am 01 April 2025, 19:08:56Meine Farbrotation geht aktuell wohl auch noch nicht. Die starte ich in FHEM durch "set led_Bartresen hsv +5,100, 120 r", da ändert der Controller aber keine Farben.

hmm... und auf Controllern mit der alten Firmware funktioniert das?
Das triggert drei Stellen im Code, an einer hab ich was getan:

• jsonprocessor.cpp - da werden json Messages verarbeitet.
  
  • einen Bug in der Verarbeitung von Messages gefixt, die mehr als einen Befehl beinhalten und den dafür verfügbaren Speicher etwas vergrößert
  • die Anzahl der Meldungen wenn sich die Farbe verändert auf 2/s verringert.
  beides sollte so eine einfache Operation nicht stören.
  
  • ledctrl - hier werden die eigetlichen Aktionen für die LED gesteuert - da habe ich außer der Umstellung auf named channels nichts geändert. Und wenn andere Animationen funktionieren, dann sollte das auch für Rotation gelten
  • RGBWWLed - die Library, die die ganze Farbraumkonversion und das eigentliche Ansteuern der PWM Kanäle übernimmt. Da habe ich ein paar große statische Tabellen vom Heap in's PGM Mem verschoben, aber auch das sollte nicht eine einzelne Animation stören.
  kurz: seltsam.
  
  

und: die neuen Prototypen sind da!

ich hab für das "failing OTA" mal ein Issue (https://github.com/pljakobs/esp_rgbww_firmware/issues/48) aufgemacht - aaaber: was immer da passiert, passiert im alten Code, mit altem SMING. Ich weiß, dass sich auch im OTA manches geändert hat, ich kann mir vorstellen, dass es da noch bugs gibt, aber im Grunde ist es für mich wertlos, danach zu suchen, denn damit die gefixt werden können, muss der Controller ja sowieso auf die neue Firmware geflasht werden.
Ich werde aber mal sehen, ob ich vielleicth mehr Status Reporting für das aktuelle OTA einbauen kann, falls sowas da auch mal passiert.

Die UI issues im Network Config hab ich gefixt, ship' ich dann mit dem nächsten dev build

Das mit dem OTA ist für mich alles ok. Ich habe nach dem Update auf die neue Version erfolgreich einen OTA Update (bzw. minimalen Downgrade) durchgeführt, das hat funktioniert.

Die Rotation hat in der alten Fassung geklappt.

Nochmal eine DAO Frage: Gibt es vom FEHM Modul eigentlich jetzt 2 Versionen von VBS und von dir oder wurde das mal zu einer Version konsolidiert?

Jetzt funktioniert die Rotation wieder!
Ich glaube, das Problem liegt eher im Zusammenspiel zwischen FHEM Modul (ich nutze EspLedController, sollte wohl passen) und der Firmware.
Mein "state" Reading stand auch auf "disconnected", wobei "get ... info" oder "get ... config" trotzdem funktioniert haben. Ggf. sind das noch Problemchen aus der Zeit, bevor ich das "deviceName" Attribut gesetzt haben.

Nachdem ich jetzt nochmal ein modify gemacht habe, passt der "state" und die Rotation funktioniert.

Hallo,

ich würde das gerne testen, aber mein (verbauter) espled-controller bringt leider beim derzeitigen Stand bei aufruf der webapp ein 404. kann man die ota auch ausserhalb der web-oberfläche irgendwie anstossen? in fehm reagiert er noch. und pingbar ist er auch. gibts evtl eine adresse, die man per curl aufrufen kann und der man die neue ota-url mitgeben kann?
Cheers,
Pula

Kleine Zusatzfrage: bei einem zweiten, den ich gebraucht hier gekauft habe, mit der Bezeichnung lightinator 3 kann ich leider die Bezeichnungen der PINs auf der Platine nicht lesen. (und er leitet zwar auch auf webapp weiter, aber das gleiche Problem).
Und finde irgendwie auch nichts dazu (vermutlich suche ich wieder mal falsch). Kann mich bitte jemand erleuchten und mir die Belegung der PINs zum flashen (oder eine ganze Anleitung, wie man evtl den esp in den flash-mode versetzen kann mit der Platine) sagen? Ich bilde mir ein, ich hatte das schon mal gefunden, weil ich auf einen der Controller testweise esphome drauf getan habe, aber ich finde leider nichts mehr dazu....
Cheers,
Pula

Zitat von: weini am 02 April 2025, 18:31:11Jetzt funktioniert die Rotation wieder!
Ich glaube, das Problem liegt eher im Zusammenspiel zwischen FHEM Modul (ich nutze EspLedController, sollte wohl passen) und der Firmware.
Mein "state" Reading stand auch auf "disconnected", wobei "get ... info" oder "get ... config" trotzdem funktioniert haben. Ggf. sind das noch Problemchen aus der Zeit, bevor ich das "deviceName" Attribut gesetzt haben.

Nachdem ich jetzt nochmal ein modify gemacht habe, passt der "state" und die Rotation funktioniert.

guter Tip, das könnte im messagehandler liegen - in der Version von VBS nutzt der Controller ja raw TCP Socket, um Information an FHEM zu schicken. Schau ich mal rein.

Zitat von: pula am 02 April 2025, 19:31:33Kleine Zusatzfrage: bei einem zweiten, den ich gebraucht hier gekauft habe, mit der Bezeichnung lightinator 3 kann ich leider die Bezeichnungen der PINs auf der Platine nicht lesen. (und er leitet zwar auch auf webapp weiter, aber das gleiche Problem).
Und finde irgendwie auch nichts dazu (vermutlich suche ich wieder mal falsch). Kann mich bitte jemand erleuchten und mir die Belegung der PINs zum flashen (oder eine ganze Anleitung, wie man evtl den esp in den flash-mode versetzen kann mit der Platine) sagen? Ich bilde mir ein, ich hatte das schon mal gefunden, weil ich auf einen der Controller testweise esphome drauf getan habe, aber ich finde leider nichts mehr dazu....
Cheers,
Pula

schau mal hier, ich hab damals versucht, alle möglichen Fragen im FAQ zu beantworten

Support Thread (https://forum.fhem.de/index.php?topic=101240.msg946874#msg946874)

Zitat von: weini am 02 April 2025, 16:49:31Das mit dem OTA ist für mich alles ok. Ich habe nach dem Update auf die neue Version erfolgreich einen OTA Update (bzw. minimalen Downgrade) durchgeführt, das hat funktioniert.

prima!

Zitat von: weini am 02 April 2025, 16:49:31Die Rotation hat in der alten Fassung geklappt.

Ich hab das gerade mal bei mir versucht, erst
set LED_Bu sat 100dann
set LED_Bu rotate 60(aus der FHEM Oberfläche)
Funktioniert einwandfrei mit der Version V5.0-334-develop

Zitat von: weini am 02 April 2025, 16:49:31Nochmal eine DAO Frage: Gibt es vom FEHM Modul eigentlich jetzt 2 Versionen von VBS und von dir oder wurde das mal zu einer Version konsolidiert?

das VBS Modul ist das aktuellste, ich habe meines nicht weiterentwickelt und nuzte auch in der V5 ein API, das auf dem aufbaut, was @VBS gebaut hat. Irgendwann werde ich wohl mal den raw Socket durch Websocket erstetzen, aber im Moment will ich bei zwei Sprachen (C++ und JavaScript) bleiben.

Zitat von: pula am 02 April 2025, 19:16:40Hallo,

ich würde das gerne testen, aber mein (verbauter) espled-controller bringt leider beim derzeitigen Stand bei aufruf der webapp ein 404. kann man die ota auch ausserhalb der web-oberfläche irgendwie anstossen? in fehm reagiert er noch. und pingbar ist er auch. gibts evtl eine adresse, die man per curl aufrufen kann und der man die neue ota-url mitgeben kann?
Cheers,
Pula

Du kannst in FHEM mit
set <device> config-ota-url https://lightinator.de/version.jsonerstmal die neue OTA URL setzen und dann mit
set <device> fw_update ein update anstoßen

Zitat von: pjakobs am 02 April 2025, 19:45:31

Zitat von: pula am 02 April 2025, 19:16:40Hallo,

ich würde das gerne testen, aber mein (verbauter) espled-controller bringt leider beim derzeitigen Stand bei aufruf der webapp ein 404. kann man die ota auch ausserhalb der web-oberfläche irgendwie anstossen? in fehm reagiert er noch. und pingbar ist er auch. gibts evtl eine adresse, die man per curl aufrufen kann und der man die neue ota-url mitgeben kann?
Cheers,
Pula

Du kannst in FHEM mit

Code Auswählen Erweitern

set <device> config-ota-url https://lightinator.de/version.jsonerstmal die neue OTA URL setzen und dann mit

Code Auswählen Erweitern

set <device> fw_update ein update anstoßen

vielen lieben dank, so was in der Art hätte ich auch gedacht, aber leider:
Unknown argument config-ota-url, choose one of hsv rgb state hue sat white stop val pct dim dimup dimdown on off toggle toggle_fw raw pause continue blink skip config restart fw_update ct rotate security off-till on-till off-for-timer on-till-overnight intervals on-for-timer off-till-overnight ich komm mir grad wie ein depp vor, sorry für die blöden fragen...
falls es hilft, ich bin in linux zuhause und curl ist auch keine fremdsprache für mich ;-)

Zitat von: pjakobs am 02 April 2025, 19:34:25

Zitat von: pula am 02 April 2025, 19:31:33Kleine Zusatzfrage: bei einem zweiten, den ich gebraucht hier gekauft habe, mit der Bezeichnung lightinator 3 kann ich leider die Bezeichnungen der PINs auf der Platine nicht lesen. (und er leitet zwar auch auf webapp weiter, aber das gleiche Problem).
Und finde irgendwie auch nichts dazu (vermutlich suche ich wieder mal falsch). Kann mich bitte jemand erleuchten und mir die Belegung der PINs zum flashen (oder eine ganze Anleitung, wie man evtl den esp in den flash-mode versetzen kann mit der Platine) sagen? Ich bilde mir ein, ich hatte das schon mal gefunden, weil ich auf einen der Controller testweise esphome drauf getan habe, aber ich finde leider nichts mehr dazu....
Cheers,
Pula

schau mal hier, ich hab damals versucht, alle möglichen Fragen im FAQ zu beantworten

Support Thread (https://forum.fhem.de/index.php?topic=101240.msg946874#msg946874)

danke schön, dort hätte ich schon geschaut, ein halten von clr und drücken von rst bringt mich leider auch nicht weiter.
RX/TX hab ich mittlerweile auf der Platine identifiziert, aber ich suche noch nach einer spannungsversorgung während des flashens. wenn ich 12V an die klemmen anlege und gleichzeitig den flasher an RX/TX, werde ich vermutlich entweder den controller oder den flasher grillen, befürchte ich....

Zitat von: pula am 02 April 2025, 19:59:52

Zitat von: pjakobs am 02 April 2025, 19:45:31

Zitat von: pula am 02 April 2025, 19:16:40Hallo,

ich würde das gerne testen, aber mein (verbauter) espled-controller bringt leider beim derzeitigen Stand bei aufruf der webapp ein 404. kann man die ota auch ausserhalb der web-oberfläche irgendwie anstossen? in fehm reagiert er noch. und pingbar ist er auch. gibts evtl eine adresse, die man per curl aufrufen kann und der man die neue ota-url mitgeben kann?
Cheers,
Pula

Du kannst in FHEM mit

Code Auswählen Erweitern

set <device> config-ota-url https://lightinator.de/version.jsonerstmal die neue OTA URL setzen und dann mit

Code Auswählen Erweitern

set <device> fw_update ein update anstoßen

vielen lieben dank, so was in der Art hätte ich auch gedacht, aber leider:

Code Auswählen Erweitern

Unknown argument config-ota-url, choose one of hsv rgb state hue sat white stop val pct dim dimup dimdown on off toggle toggle_fw raw pause continue blink skip config restart fw_update ct rotate security off-till on-till off-for-timer on-till-overnight intervals on-for-timer off-till-overnight ich komm mir grad wie ein depp vor, sorry für die blöden fragen...
falls es hilft, ich bin in linux zuhause und curl ist auch keine fremdsprache für mich ;-)

sorry, mein Fehler, es fehlte ein "config"
set <device> config config-ota-url https://lightinator.de/version.json
die curl Zeile steht irgendwo weiter oben im Thread.

Zitat von: pula am 02 April 2025, 20:15:52danke schön, dort hätte ich schon geschaut, ein halten von clr und drücken von rst bringt mich leider auch nicht weiter.
RX/TX hab ich mittlerweile auf der Platine identifiziert, aber ich suche noch nach einer spannungsversorgung während des flashens. wenn ich 12V an die klemmen anlege und gleichzeitig den flasher an RX/TX, werde ich vermutlich entweder den controller oder den flasher grillen, befürchte ich....

Ah, doch, Du musst den Controller an 12V hängen, denn nur von dort wird der ESP mit Spannung versorgt, also:
- +12V an VCC (die innere Klemme des Zweierblocks)
- GND an die unbeschriftete Klemme des Zweierblocks
- RX/TX/GND an die Pins auf dem Sechser-Header

Solange Du nicht die 12V an irgendeinen 3.3V Pin hängst, wird da nichts gegrillt.
Ich hatte damals tatsächlich einfach nicht daran gedacht, auf den Header noch eine 3.3V Versorgung zu legen, die auch aus anderen Gründen praktisch gewesen wäre.

ah, und weil ich es gerade nochmal gelesen habe: nicht [CLR] und [RST], sondern [PRG]und [RST] ([PRG] ist der mittlere der drei Taster)

Zitat von: pjakobs am 02 April 2025, 21:04:05

Zitat von: pula am 02 April 2025, 19:59:52

Zitat von: pjakobs am 02 April 2025, 19:45:31

Zitat von: pula am 02 April 2025, 19:16:40Hallo,

ich würde das gerne testen, aber mein (verbauter) espled-controller bringt leider beim derzeitigen Stand bei aufruf der webapp ein 404. kann man die ota auch ausserhalb der web-oberfläche irgendwie anstossen? in fehm reagiert er noch. und pingbar ist er auch. gibts evtl eine adresse, die man per curl aufrufen kann und der man die neue ota-url mitgeben kann?
Cheers,
Pula

Du kannst in FHEM mit

Code Auswählen Erweitern

set <device> config-ota-url https://lightinator.de/version.jsonerstmal die neue OTA URL setzen und dann mit

Code Auswählen Erweitern

set <device> fw_update ein update anstoßen

vielen lieben dank, so was in der Art hätte ich auch gedacht, aber leider:

Code Auswählen Erweitern

Unknown argument config-ota-url, choose one of hsv rgb state hue sat white stop val pct dim dimup dimdown on off toggle toggle_fw raw pause continue blink skip config restart fw_update ct rotate security off-till on-till off-for-timer on-till-overnight intervals on-for-timer off-till-overnight ich komm mir grad wie ein depp vor, sorry für die blöden fragen...
falls es hilft, ich bin in linux zuhause und curl ist auch keine fremdsprache für mich ;-)

sorry, mein Fehler, es fehlte ein "config"

Code Auswählen Erweitern

set <device> config config-ota-url https://lightinator.de/version.json
die curl Zeile steht irgendwo weiter oben im Thread.

danke! das ding hat lt fhem zwar die ota-url übernommen, aber das mit dem fw_update macht nix. dauerping auf das device läuft durch. sonst tut sich auch nix. elend.

Zitat von: pula am 02 April 2025, 21:29:10danke! das ding hat lt fhem zwar die ota-url übernommen, aber das mit dem fw_update macht nix. dauerping auf das device läuft durch. sonst tut sich auch nix. elend.

versuch mal
curl -X POST http://<controller>/update -H 'Content-Type: application/json' --data '{"rom":{"url":""http://lightinator.de/download/testing/V5.0-332-testing/esp8266/release/rom0.bin"},"spiffs":{"url":"http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'Das ist exakt der API call, den das Frontend auch macht.

danach sollte ein

curl -X GET http://<controller> immer ein "OTA in progress" liefern - solange, bis es halt durch ist. Danach gibt es, wie andere hier auch beschrieben haben, Fälle, in denen das OTA nicht funktioniert hat und der Controller mit der alten Firmware hoch kommt, dann hilft wirklich nur noch der direkte serielle Weg.

Zitat von: pjakobs am 03 April 2025, 00:17:11

Zitat von: pula am 02 April 2025, 21:29:10danke! das ding hat lt fhem zwar die ota-url übernommen, aber das mit dem fw_update macht nix. dauerping auf das device läuft durch. sonst tut sich auch nix. elend.

versuch mal

Code Auswählen Erweitern

curl -X POST http://<controller>/update -H 'Content-Type: application/json' --data '{"rom":{"url":""http://lightinator.de/download/testing/V5.0-332-testing/esp8266/release/rom0.bin"},"spiffs":{"url":"http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'Das ist exakt der API call, den das Frontend auch macht.

danach sollte ein

Code Auswählen Erweitern

curl -X GET http://<controller> immer ein "OTA in progress" liefern - solange, bis es halt durch ist. Danach gibt es, wie andere hier auch beschrieben haben, Fälle, in denen das OTA nicht funktioniert hat und der Controller mit der alten Firmware hoch kommt, dann hilft wirklich nur noch der direkte serielle Weg.

danke schön. allerdings bekomme ich ein:
curl -X POST http://192.168.1.123/update -H 'Content-Type: application/json' --data '{"rom":{"url":""http://lightinator.de/download/testing/V5.0-332-testing/esp8266/release/rom0.bin"},"spiffs":{"url":"http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'

{"error":"missing param"}
der aufruf scheint syntaktisch korrekt zu sein und stimmt auch mit dem in post #78 überein. hm...

Zitat von: pula am 03 April 2025, 08:17:56der aufruf scheint syntaktisch korrekt zu sein und stimmt auch mit dem in post #78 überein. hm...

ich vermute, das ist das Problem. Poste doch mal den Output von <controller>/info

Zitat von: pjakobs am 03 April 2025, 09:22:35

Zitat von: pula am 03 April 2025, 08:17:56der aufruf scheint syntaktisch korrekt zu sein und stimmt auch mit dem in post #78 überein. hm...

ich vermute, das ist das Problem. Poste doch mal den Output von <controller>/info

danke, es hat sich erledigt. der controller hatte das problem, daß er die webapp-seite nicht mehr angezeigt hat (404). hab dann über fhem noch einmal ein "update" mit der original-fw angestoßen (set device fw_update 1), jetzt tuts wieder und das flashen der v5 hat auch funktioniert :-)
DANKE SCHÖN!

Es gibt mal wieder eine neue develop Version, diesmal mit ein paar Änderungen unter der Oberfläche:

• ich habe die Liste der mDNS-Controller und die Liste der Controller, wie ich sie für Gruppen nutze zusammen in ConfigDB gepackt. Ich glaube, dass sie damit jetzt stabiler und über alle Controller hinweg gleich ist
• Ich habe ein "leader" Konzept eingeführt, also einen Controller, der als Anlaufpunkt dienen soll. Eigentlich sollte es genügen, wenn Ihr im Browser "http://lightinator.local" eingebt - leider funktioniert das noch nicht. Mein eigentlicher Plan ist es, einen Leader für jede Gruppe zu haben, so dass ihr etwa auf "Kueche.local" gehen könnt. Das könnte aber die Fähigkeiten der mDNS Library übersteigen
• zusätzlich habe ich die Frontend Bugs im "connect to network" Tab gefixt

Ich habe mal eine kurze Anmerkung zur Web-Oberläche:
1) irgendwie fehlt mir da ein einfacher on/off Button
2) irritierend finde ich, dass der Color Picker im Zustand "off" immer auf "rot" geht. Da würde ich mir wünschen, dass die Farbeinstellung auch im ausgeschalteten Zustad beibehalten wird. Wenn es einen on/off Button gibt, dann könnte man an dem ja den on/off Zustand ablesen.

Da ich den Controller aber fast ausschließlich via FEM steuere ist das zugegebenermaßen eher "schöner Wohnen"   ;)

Zitat von: weini am 10 April 2025, 18:22:40Ich habe mal eine kurze Anmerkung zur Web-Oberläche:
1) irgendwie fehlt mir da ein einfacher on/off Button
2) irritierend finde ich, dass der Color Picker im Zustand "off" immer auf "rot" geht. Da würde ich mir wünschen, dass die Farbeinstellung auch im ausgeschalteten Zustad beibehalten wird. Wenn es einen on/off Button gibt, dann könnte man an dem ja den on/off Zustand ablesen.

Da ich den Controller aber fast ausschließlich via FEM steuere ist das zugegebenermaßen eher "schöner Wohnen"   ;)

Wenn Du Dir Presets oder Scenes für ON und OFF anlegst und die als Favoriten auf die Startseite legst ,sollte das doch passen.

Und: das aus rot ist liegt einfach daran, dass aus als h=0, s=0 ,v=0 definiert ist und h=0 nunmal rot ist. Du kannst Dein Present beliebig anders anlegen, solange v null ist, sind die LED aus.

Danke dir, verstehe. Als Workaround für mich ok.
Aber es bleibt irgendwie strange für mich, dass ich keinen "on" Button habe, mit dem ich den Controller einfach wieder mit der identischen Farbe anschalten kann, die er beim Ausschalten hatte.

Zitat von: weini am 11 April 2025, 07:05:14Danke dir, verstehe. Als Workaround für mich ok.
Aber es bleibt irgendwie strange für mich, dass ich keinen "on" Button habe, mit dem ich den Controller einfach wieder mit der identischen Farbe anschalten kann, die er beim Ausschalten hatte.

was ich machen kann: ich kann "on" und "off" als virtuelle Presets anlegen, die, als "off" einfach v=0 setzen und als "on" das letzte Setting nehmen. Die könntest Du dann genauso als favorite übernehmen.

Zitat von: pjakobs am 11 April 2025, 10:54:25

Zitat von: weini am 11 April 2025, 07:05:14Danke dir, verstehe. Als Workaround für mich ok.
Aber es bleibt irgendwie strange für mich, dass ich keinen "on" Button habe, mit dem ich den Controller einfach wieder mit der identischen Farbe anschalten kann, die er beim Ausschalten hatte.

was ich machen kann: ich kann "on" und "off" als virtuelle Presets anlegen, die, als "off" einfach v=0 setzen und als "on" das letzte Setting nehmen. Die könntest Du dann genauso als favorite übernehmen.

das würde ich auch SEHR praktisch finden! (und auch von einer Leuchte so erwarten) :-)

so, jetzt gibt's endlich mal wieder eine neue Version (V5.0-361-develop).
die große Änderungen:

• in den älteren Versionen war der "CLR" Pin disabled, weil ich ihn in meinem Test Setup meist nicht brauchen konnte, und weil er auch für unterschiedliche Hardware unterschiedlich sein kann. Jetzt gehört der CLR Pin zur Pin Konfiguration und wird für einen bestimmten Controller im Flash gespeichert.
• Wenn Ihr einen Controller ohne WLAN Konfiguration startet und Euch mit dem Access Point des Controllers verbindet, findet Ihr jetzt einen neuen Konfigurations-Wizzard, der den Hostnamen, die Pin Konfig und dann das WLAN abfragt. Bisher war es immer ein bisschen blöd, wenn ein Kontroller ohne gültige Pin Konfiguration gestartet ist, das sollte hiermit gelöst sein.
• die größte Änderung ist: die Controller sind ja schon immer (zumindest unter Windows) unter <hostname>.local erreichbar. Die neue Version ist ein bisschen smarter.
• Die Controller wählen jetzt untereinander einen "Leader", der unter "http://lightinator.local" erreichbar ist.
• Es geht aber noch einen Schritt weiter: Wenn Ihr Gruppen anlegt, dann wählen die Controller untereinander einen Leader für die Gruppe, der dann unter http://<gruppenname>.local erreichbar ist. Wenn Ihr eine Gruppe "Garage" habt, dann sind deren Controller etwa als "http://garage.local" erreichbar.

Linux Nutzer: Ich hab Fedora, seit gestern Fedora 42, und aus Gründen, die ich nicht verstehe, sind die .local Addressen über avahi nicht auflösbar. Fedora nutzt aber sowieso systemd-resolved, da müsst Ihr in der /etc/nsswitch die folgende Zeile ändern:
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
hosts:      files myhostname mdns4 [NOTFOUND=return] resolve [!UNAVAIL=return] dns

sprich von "mdns4_minimal" auf "mdns4"

Unter Android 13 habe ich es bisher nicht hinbekommen, auf die .local Adressen zuzugreifen. Es wäre super, wenn Ihr da mal testen könntet, gleiches gilt für Apple Produkte.

Grüße

pj

vielleicht war die 361 ein bisschen voreilig. V5.0-374-develop ist jetzt aktuell und sollte deutlich stabilere Controller-Listen zeigen.

zusätzlich gibt es ein python tool namens controller-ctrl, das ein paar Aufganben wahr nimmt, die weder in Firmware noch Web-Frontend wirklich passen - etwa den ganzen Schwarm discovern:
$> ./controller-ctrl discover led-ku.fritz.box

Discovery completed in 169.1 seconds
Found 12 unique controllers

Controller List:
+------------+---------------+------------------------+----------+
|         ID | Hostname      | IP Address             | Status   |
+============+===============+========================+==========+
| 2147483647 | antarestest2  | 192.168.29.65          | ✓ Online |
+------------+---------------+------------------------+----------+
| 4229738372 | antarestest2  | antarestest2.fritz.box | ✓ Online |
+------------+---------------+------------------------+----------+
|    6737456 | led-be        | 192.168.29.125         | ✓ Online |
+------------+---------------+------------------------+----------+
|    2827530 | led-bu        | 192.168.29.101         | ✓ Online |
+------------+---------------+------------------------+----------+
|    2827485 | led-ku        | led-ku.fritz.box       | ✓ Online |
+------------+---------------+------------------------+----------+
|   12742997 | led-so2       | 192.168.29.115         | ✓ Online |
+------------+---------------+------------------------+----------+
|     390774 | led-te1       | 192.168.29.112         | ✓ Online |
+------------+---------------+------------------------+----------+
|    1451258 | led-te2       | 192.168.29.111         | ✓ Online |
+------------+---------------+------------------------+----------+
|   10964518 | led-tr        | 192.168.29.25          | ✓ Online |
+------------+---------------+------------------------+----------+
|   15603867 | led-tvu       | 192.168.29.113         | ✓ Online |
+------------+---------------+------------------------+----------+
|    2826766 | led-wo        | 192.168.29.102         | ✓ Online |
+------------+---------------+------------------------+----------+
|            | 192.168.29.65 | 192.168.29.65          | ✓ Online |
+------------+---------------+------------------------+----------+

Controller Visibility Matrix:
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| Controller                | 192.168.29.65 (None)   | antarestest2 (2147483647)   | antarestest2 (4229738372)   | led-be (6737456)   | led-bu (2827530)   | led-ku (2827485)   | led-so2 (12742997)   | led-te1 (390774)   | led-te2 (1451258)   | led-tr (10964518)   | led-tvu (15603867)   | led-wo (2826766)   |
+===========================+========================+=============================+=============================+====================+====================+====================+======================+====================+=====================+=====================+======================+====================+
| 192.168.29.65 (None)      | -                      | (*)                         | *                           | *                  | *                  | *                  | *                    | *                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| antarestest2 (2147483647) |                        | -                           |                             |                    |                    |                    |                      |                    |                     |                     |                      |                    |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| antarestest2 (4229738372) |                        | (*)                         | -                           | *                  | *                  | *                  | *                    | *                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-be (6737456)          |                        | *                           |                             | -                  | *                  | *                  | *                    | *                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-bu (2827530)          |                        | *                           |                             | *                  | -                  | *                  | *                    | *                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-ku (2827485)          |                        | *                           |                             | *                  | *                  | -                  | *                    | *                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-so2 (12742997)        |                        | *                           |                             | *                  | *                  | *                  | -                    | *                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-te1 (390774)          |                        | *                           |                             | *                  | *                  | *                  | *                    | -                  | *                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-te2 (1451258)         |                        | *                           |                             | *                  | *                  | *                  | *                    | *                  | -                   | *                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-tr (10964518)         |                        | *                           |                             | *                  | *                  | *                  | *                    | *                  | *                   | -                   | *                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-tvu (15603867)        |                        | *                           |                             | *                  | *                  | *                  | *                    | *                  | *                   | *                   | -                    | *                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+
| led-wo (2826766)          |                        | *                           |                             | *                  | *                  | *                  | *                    | *                  | *                   | *                   | *                    | -                  |
+---------------------------+------------------------+-----------------------------+-----------------------------+--------------------+--------------------+--------------------+----------------------+--------------------+---------------------+---------------------+----------------------+--------------------+

Legend:
  *   - Controller is currently visible (/hosts response)
  (*) - Controller is historically visible (/data.controllers response)
  -   - Same controller (self)
  (✗) - Controller is offline (ping failed)
  [empty] - Not visible by this controllerIn der Tabelle könnt Ihr sehen, welche Controller welche anderen in der Datenbank haben (*) und aktiv sehen können * - das nutze ich primär fürs Debugging.

Ihr könnt auch einen Controller fragen, welche anderen Controller er kennt:
$> ./controller-ctrl list-hosts led-ku.fritz.box
Found 8 controllers in /hosts response
Found 10 controllers in /data response

Controllers known to http://led-ku.fritz.box:
+------------+--------------+----------------+-------------+----------------------+
|         ID | Hostname     | IP Address     | Last Seen   | Status               |
+============+==============+================+=============+======================+
| 2147483647 | antarestest2 | 192.168.29.65  | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|    6737456 | led-be       | 192.168.29.125 | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|    2827530 | led-bu       | 192.168.29.101 | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|     390774 | led-te1      | 192.168.29.112 | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|    1451258 | led-te2      | 192.168.29.111 | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|   10964518 | led-tr       | 192.168.29.25  | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|   15603867 | led-tvu      | 192.168.29.113 | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|    2826766 | led-wo       | 192.168.29.102 | Now         | Currently visible    |
+------------+--------------+----------------+-------------+----------------------+
|    2827485 | LED-Ku       | 192.168.29.121 | Unknown     | Historically visible |
+------------+--------------+----------------+-------------+----------------------+
|   12742997 | led-so2      | 192.168.29.115 | Unknown     | Historically visible |
+------------+--------------+----------------+-------------+----------------------+

Legend:
  Green - Controller is currently visible (/hosts response)
  Yellow - Controller is historically visible (/data.controllers response)

um Euch auf der Kommandozeile anzeigen zu lassen, wer welche Firmware hat geht:
$> ./controller-ctrl firmware led-ku.fritz.box

Firmware Versions:
+------------------------+------------------------+------------------+--------------+---------+----------------+
| Hostname               | IP Address             | Firmware         | Build Type   | Sming   | Webapp         |
+========================+========================+==================+==============+=========+================+
| 192.168.29.65          | 192.168.29.65          | V5.0-374-develop | debug        | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| antarestest2           | 192.168.29.65          | V5.0-374-develop | debug        | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| antarestest2.fritz.box | antarestest2.fritz.box | V5.0-374-develop | debug        | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-be                 | 192.168.29.125         | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-bu                 | 192.168.29.101         | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-ku.fritz.box       | led-ku.fritz.box       | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-so2                | 192.168.29.115         | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-te1                | 192.168.29.112         | V5.0-374-develop | debug        | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-te2                | 192.168.29.111         | V5.0-374-develop | debug        | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-tr                 | 192.168.29.25          | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-tvu                | 192.168.29.113         | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
| led-wo                 | 192.168.29.102         | V5.0-374-develop | release      | 6.0.0   | V5.0-124-devel |
+------------------------+------------------------+------------------+--------------+---------+----------------+
(hier ist erkennbar, dass es noch ein paar Problemchen hat, eineindeutige Controler zuzuweisen)

das Tool kann auch gezielt einzelne oder alle host Einträge von einzelnen oder allen Controllern löschen, wenn Ihr etwa wie ich mit dauernd wechselnden Konstellationen zu tun habt - aber das ist, denke ich, eher nicht so wichtig.

Um auch die Daten aller Controller zu finden, braucht das Tool für die meisten Kommandos einen "start controller" - den fragt es dann nach den bekannten und aktiven Hosts und arbeitet sich dann an den Listen entlang durch um möglichst alle Controller zu finden, die irgendjemand im Netz kennt. Das dauert ein bisschen und lässt sich vielleicht auch noch optimieren (vor allem kommen im Moment immer mal noch völlig falsche fqdns vor, ich weiß nicht warum).
Das Tool braucht ne Menge python libraries, bei Gelegenheit schreibe ich einen Installer dafür

Hallo,

habe gerade die aktuelle Versionder Firmware auf meinen Controllern. Leider entwickeln sie ihr Eigenleben.
Plötzlich ändert sich die Helligkeit oder gehen ganz aus.
Hat das auch schon jemand festgestellt?

Gruß rippi

Kann ich so nicht bestätigen.
Ich habe aber nur einen Controller und nutze keine der neuen Sync-Funktionen.

Hallo,

hatte zuerst das Netzteil im Verdacht, aber als ich heute Morgen in der Dusche und am Waschbecken das gleiche Verhalten hatte,
glaube ich, dass es an der aktuellen Fimware liegt. Syncfunktionen nutze ich zur Zeit nicht.

Gruß rippi

Zitat von: rippi46 am 06 Mai 2025, 09:42:53Hallo,

hatte zuerst das Netzteil im Verdacht, aber als ich heute Morgen in der Dusche und am Waschbecken das gleiche Verhalten hatte,
glaube ich, dass es an der aktuellen Fimware liegt. Syncfunktionen nutze ich zur Zeit nicht.

Gruß rippi

hmm...
schau mal nach der uptime (in den system settings) - es könnte sein, dass die Controller einfach immer rebooten.
check auch mal die Pin Configuration (in controller config) - die sollte bei allen alten Controllern mrpj sein.

pj

Hallo,

die Controller, die ich upgedatet habe booten offensichtlich immer wieder. Die Pinkonfiguration is überall mrpj.


Gruß rippi

Zitat von: rippi46 am 06 Mai 2025, 11:36:06Hallo,

die Controller, die ich upgedatet habe booten offensichtlich immer wieder. Die Pinkonfiguration is überall mrpj.


Gruß rippi

Mist.

Ich schätze, Du hast keine Chance, den log output zu bekommen?

Könnte was mit dem CLR pin zu tun habenn🤔

Hallo,

Habe jetzt einen Controller noch einmal mit der aktuellen Firmware geflasht.
Leider kann ich über VPN die Log-Datei nicht herunterladen.
Kann ich aber später ohne VPN noch einmal probieren.

Gruß rippi

ich hatte irgendwann zwischendrin mal einen Bug, der zu einem Memory Access Error führte, mit Glück hattest Du die (172 iirc) und jetzt ist alles gut. Ich hab die aktuelle devel auf allen Controllern laufen und keine Probleme.

So habe jetzt all Controller wieder auf der 355, die scheint zu funktionieren.

Habe 3 Controller zum Test laufen, die werde ich heute noch einmal mit der neuen Firmware flashen.
Vielleicht komme ich dann an die Log-Datei

Gruß rippi

Hallo,

Ich kann die Log-Datei herunterladen, aber sie ist immer 0 Byte groß.

Gruß rippi

Zitat von: rippi46 am 06 Mai 2025, 17:56:06Hallo,

Ich kann die Log-Datei herunterladen, aber sie ist immer 0 Byte groß.

Gruß rippi

oh, ja, das mit dem Log download läuft auf den ESP8266 leider nicht, denen fehlt dazu RAM. Ich hatte das irgendwann mal enabled, aber da sind die Teile dauernd abgestürzt.

Mahlzeit! :-)

wollte jetzt auch mal die 5.0 antesten.
OTA gelingt es mir aber nicht.
einer steht mit "OTA in process" still, egal wie oft er stromlos wird.
ein anderer verweigert das Update mit "OTA failed - Network error - could not reach the Controller. Please check your connection"

Seis drum, würde dann mal einen lokal flashen.
Ich habe hier jetzt die Version mit 6 Pins, RX, TX, GND und noch drei.
--> Weis da grad jemand das pinout der anderen 3 PINs? finde grad im Forum nichts. ist da evtl nen 3,3V Eingang dabei zum flashen?
--> falls nicht, kann ich gefahrlos mit 12V extern versorgen und dann RX/TX/GND per Adapter zum PC?

Danke & Grüße
Frank

EDIT, die Antwort zur 12V Frage habe ich hier gefunden. https://forum.fhem.de/index.php?msg=1338489
falls aber jmd die Belegung der weiteren Drei Pins hat wäre das super. :-)

EDIT2, wer lange genug sucht, auch das Pinout habe ich gefunden. https://forum.fhem.de/index.php?topic=101240.msg946874#msg946874

Was ich aber noch für ein Problem habe, ich bekomme den ESP nicht in den Flashmode.
das war doch [PRG]halten, dann [RST] drücken, dannach sollte er 2 x aufblinken?
bei mir blinkt er 1 x auf und keines der ESP Tools mag das flashen starten.

EDIT3, Nach 100 Versuchen mit mehreren Controllern habe ich dann einen anderen TTL Adapter verwendet. und TaDa. Flashen war OK. auch wenn er nur 1 x geblinkt hat.
dann nochmal nach dem Default WLAN Passwort gesucht (die alte Firmware war ohne PW) und schon ist der Controller im Netz.
Was ne schwere Geburt, aber läuft.

Als nächstes werde ich ihn die Tage am Objekt austauschen. dort hat er 10m 24V RGBWWCW Streifen zu steuern.
der jetzige hat kein Web mehr und die Konfig ist auch weg. bekanntes Thema, ich weis. :-)

Danke für die Arbeit die ihr hier rein steckt!

Mahlzeit!

kurzes Feedback von mir zur neuen Firmware:

- Wenn man wieder weis wie ist das flashen ein Kinderspiel. ;-)
- die neue Firmware gefällt mir sehr gut. Klasse Arbeit! 
- FHEM setzt den Gerätenamen im ESP als Hostname. reproduzierbar. das hatte ich hier im Thread schon als Vermutung gelesen.
- Beim WLAN einrichten ist das zweite "CSID" Feld das Passwort Feld. kleiner kosmetischer bug. aber auch schon bekannt hier im Thread.

einen kleinen Verbesserungsvorschlag von mir:
wenn ich den Controller auf nur RGB einstelle, dann habe ich unter der manuellen Kontrolle noch immer alle 5 Regler,
sollte man im RGB Modus nicht die weis Kanäle ausblenden?

So, jetzt noch ein anderes "Problem",
einer der Controller lässt sich flashen, spannt dann aber kein WLAN auf. über die Konsole wiederholt sich jede Sekunde die Meldung:
no DAHOAM found, reconnect after 1s
reconnect
scandone
no DAHOAM found, reconnect after 1s
reconnect
scandone
no DAHOAM found, reconnect after 1s
reconnect
ist hier der ESP durch oder gibt es eine mögliche Rettung?

Heißt dein WLAN "DAHOAM" und das wird nicht gefunden? ;D

Frisch mit v5 per seriell geflasht hatte Ich erwartet er spannt ein eigenes WLAN auf, so wie die anderen 8 die ich heute geflasht habe. Da war alles dabei, die alte mit stehenden MOSfets, die neue mit 3 und 6 Pins.
Nur dieser eine hat das Problem.

Ist das tatsächlich ein WLAN Name?
Dann sollte das ja über die CLR Taste rucksetzbar sein.
Teste ich morgen, der eine liegt noch im Büro...

EDIT:
Also es ist definitiv kein WLAN-Name. selbst nach Stunden kommt im Sekunden-Takt diese Meldung.
Nach einem Kaltstart war wohl kurz der AP aktiv, seit über 1h aber nur noch die "no DAHOAM found"
Ich denke den ESP kann ich abschreiben.

--> falls jemand die Möglichkeit zum ESP-Tausch hat, ich verschenke den Controller. Hab selbst keine Möglichkeit dazu. 

Zitat von: Frank_Huber am 22 Mai 2025, 18:16:13Frisch mit v5 per seriell geflasht hatte Ich erwartet er spannt ein eigenes WLAN auf, so wie die anderen 8 die ich heute geflasht habe. Da war alles dabei, die alte mit stehenden MOSfets, die neue mit 3 und 6 Pins.
Nur dieser eine hat das Problem.

Ist das tatsächlich ein WLAN Name?
Dann sollte das ja über die CLR Taste rucksetzbar sein.
Teste ich morgen, der eine liegt noch im Büro...

EDIT:
Also es ist definitiv kein WLAN-Name. selbst nach Stunden kommt im Sekunden-Takt diese Meldung.
Nach einem Kaltstart war wohl kurz der AP aktiv, seit über 1h aber nur noch die "no DAHOAM found"
Ich denke den ESP kann ich abschreiben.

--> falls jemand die Möglichkeit zum ESP-Tausch hat, ich verschenke den Controller. Hab selbst keine Möglichkeit dazu.

Moin Frank,

in einigen Versionen war der CLR Button einfach nicht aktiv. Die Tatsache, dass Deine die ======== beim Boot zeigt, dass Deine dazu gehört. Ich meinte, die aktuelle develop auf dem Update Server sollte das schon anders machen. Magst Du das mal probieren? (ich überlege gerade, ob die Download Links zur richtigen Version führen... :o)
nimm mal diese http://lightinator.de/download/develop/V5.0-374-develop/esp8266/debug/single_image/app-merged.bin
Dein Log sagt eigentlich, dass er einen Access Point aufmacht und auch den dhcp server startet, ich glaub, mit dem Chip is alles in Ordnung. Probier mal die 374 und sag mir, was passiert.

pj

So, ich glaube, ich schulde Euch ein Update, gerade passiert wenig Sichtbares an der Firmware, das hat Gründe.

Ich habe angefangen, mit der neuen Hardware zu testen und dabei ein paar Probleme gefunden, ganz besonders rund um Elektromagnetische Vertgräglichkeit.
Zum Teil ist das Schluderei meinerseits (ich hatte gehoff, ohne übermaßig große Kondensatoren in der 12V Schiene auskommen zu können ... errr... nein)
Aber es ist auch etwas, was ich in Software angehe.
Hintergrund: die neue PWM (Pulsweitenmodulation, also das Dimmen der LED) läuft statt mit den alten 400Hz jetzt mit 4kHz - beim ESP32, denn der kann das in Hardware. Damit ist jegliches Flimmern weg. Aber das Spektrum, mit dem die Controller ihre Umgebung beeinflussen rückt auch ein gutes Stück nach oben. Gut ist: bei höheren Freuquenzen komme ich mit kleineren Kondensatoren aus.
Nur will ich auch ein paar Dinge in Software machen.
1. Phase Shifting. Aktuell schalten alle drei bis fünf LED Kanäle synchron, das heißt alle schalten zum Zeitpunkt t=0 ein und dann, entsprechend der gewünschten Helligkeit zwischen 0 und 100% entsprechend entlang der 250µs wieder aus. 125µs "ein" wäre etwa 50% Helligkeit (stimmt nicht ganz, weil die Firmware die wahrgenommene Helligkeit berechnet und entsprechend einer Kennlinie korrigiert). Mit Phase Shifting schalten jetzt alle fünf Kanäle gleichmäßig über den 250µs Zeitslot verteilt, also jeweils um 62,5µs versetzt zueinander. Dadurch verteilt sich der Anstieg des Stromverbrauchs über die Zeit und es kommt nicht zu dieser einen großen Spitze am Anfang des Zeitslots. Das sollte schon dafür sorgen, dass das Spektrum flacher und breiter wird.
2. Spread Spectrum. Das haben viele vermutlich schonmal im UEFI BIOS ihres PC gesehen: die Idee ist, dass ich anstatt einer starren Taktfreqenz eine Frequenz nehme, die leicht um einen Mittelwert herum "wobbelt", sagen wir mal zwischen 3750 und 4250Hz, mit einer Wobbelfrequenz von ca. 100Hz - dadurch verteilt sich das Spektrum noch weiter und die Einstreuung in Radios, Funkgeräte etc. wird geringer, weil auf jeder Frequenz über die Zeit weniger Energie abgestrahlt wird.
Beides lässt sich in der Firmware machen. Für 1. hat der ESP32 sogar Hardwareunterstützung, das läuft hier schon, für 2. treibe ich ein bisschen mehr Aufwand (ein Timer, der mit 1/ntel der PWM Frequenz läuft und eine Tabelle mit Sinuswerten, die mit einer Schrittweite m durchlaufen wird bestimmen dann die neue Frequenz, die jedes mal, dass der Timer auslöst gesetzt wird).
Wenn ich das durch habe, kann ich wieder in das UI auftauchen.

Grüße

pj

Mich würde aber tatsächlich noch interessieren, was es mit diesem "DAHOAM" auf sich hat  ;D

Zitat von: vbs am 24 Mai 2025, 20:30:58Mich würde aber tatsächlich noch interessieren, was es mit diesem "DAHOAM" auf sich hat  ;D

Ich würde meinen, dass das ein zuvor konfiguriertes WLAN war 🤔

Ja, wäre auch meine Vermutung nach wie vor.

Zitat von: Frank_Huber am 22 Mai 2025, 18:16:13EDIT:
Also es ist definitiv kein WLAN-Name. selbst nach Stunden kommt im Sekunden-Takt diese Meldung.

Die Meldungen werden (zumindest gemäß unserer Theorie) so lange kommen, bis das "DAHOAM"-WLAN auftaucht und sich der verzweifelte Controller endlich dort einbuchen kann.

Frank, kommst du zufällig aus Bayern?  8)

Zitat von: vbs am 24 Mai 2025, 20:57:49Ja, wäre auch meine Vermutung nach wie vor.

Zitat von: Frank_Huber am 22 Mai 2025, 18:16:13EDIT:
Also es ist definitiv kein WLAN-Name. selbst nach Stunden kommt im Sekunden-Takt diese Meldung.

Die Meldungen werden (zumindest gemäß unserer Theorie) so lange kommen, bis das "DAHOAM"-WLAN auftaucht und sich der verzweifelte Controller endlich dort einbuchen kann.

Frank, kommst du zufällig aus Bayern?  8)

Nein, bin schon immer in Karlsruhe. 😉
Der Controller war aber bei mir nie in Betrieb. Hab den second Hand bekommen. 

Aber alle meine Controller die aktiv waren haben während dem flashen die Konfig und das WLAN verloren. 

Warum sollte das gerade dieser eine behalten haben? 

Zitat von: Frank_Huber am 24 Mai 2025, 21:38:49Warum sollte das gerade dieser eine behalten haben?

Irgendwann ziemlich früh ist mal das Flash Layout geändert worden. Dabei ist die WLAN Config von ganz vorne in die hinteren Blöcke gerutscht. Controller mit der alten Version vergessen iirc ihr WLAN, neuere nicht.

Zitat von: pjakobs am 24 Mai 2025, 21:43:42

Zitat von: Frank_Huber am 24 Mai 2025, 21:38:49Warum sollte das gerade dieser eine behalten haben?

Irgendwann ziemlich früh ist mal das Flash Layout geändert worden. Dabei ist die WLAN Config von ganz vorne in die hinteren Blöcke gerutscht. Controller mit der alten Version vergessen iirc ihr WLAN, neuere nicht.

Ah, OK. Das könnte Sinn machen.
Musste er aber nach paar Minuten wenn er sein WLAN nicht findet in den AP Modus wechseln und die Suche aufhören? 
Egal, ich versuch das Montag mit der anderen FW. 

Könntest dir auch temporär ein WLAN "DAHOAM" aufspannen. Handy-Hotspot zum Beispiel.

OK, es scheint wirklich ein konfiguriertes WLAN zu sein. nach aktivieren eines offenen Hotspots mit "DAOAM" kam ich auf ihn raus und konnte die WLAN Konfig löschen.
Das Update auf v5 lief wohl durch, er hatte nur die Konfig nicht gelöscht. (als einziger von vielen)

@pj, dein Link auf die develop firmware greift nicht. der ist wohl nicht öffentlich frei.

also am Ende alles gut mit dem Controller. :)

Danke für eure Hilfe!

Hallo zusammen,

ich habe mal wieder eine neue Beobachtung zu vermelden. Aktuell habe ich die Software V5.0-374-develop auf meinen Controllern laufen. Aufgefallen ist mir folgendes:
Immer wenn die WLAN Verbindung aus irgend einem Grund mal kurz ausfällt rebooten die Controller. Dabei wird natürlich jegliche laufende Animation abgebrochen. Beim Reboot kommt dann ein zweiter Fehler zum Tragen.
"Ab Werk" steht der Parameter config-color-startup_color auf last. Das funktioniert aber nicht. Es wird nach dem Reboot nicht der zuletzt eingestellte Wert wiederhergestellt, sondern die Controller gehen auf 10% Helligkeit in weiß. Das habe ich inzwischen bei drei verschiedenen Controllern beobachtet. Die haben inzwischen allerdings einen festen Wert vorgegeben bekommen, sodass ich nicht sagen kann, ob die Einstellung last generell nicht geht oder nur einmal von Hand neu gesetzt werden muss.
Wünschen würde ich mir, dass die Lightinators einen kurzen Ausfall des WLAN ignorieren, das heißt die laufende Animation nicht abgebrochen wird und es auf gar keinen Fall einen Reboot gibt. Dass sie dann während dieser Zeit nicht erreichbar sind ist natürlich klar. Sollte das WLAN länger ausfallen dürfen und sollen sie natürlich ihr eigenes WLAN wieder aufspannen, idealerweise auch das ohne Reboot. Notfalls wäre das nach einer angemessenen Wartezeit (z.B. 60s) aber OK.

Warum die WLAN Verbindung hin und wieder kurz abbricht weiß ich nicht. Denkbar wäre, dass meine Fritzbox versucht, einen Controller im Mesh umzubuchen von Repeater zur Box oder umgekehrt. Danach sieht es aber im Log der Box eigentlich nicht aus. Aber bei allen Funkverbindungen muss man ja ohnehin immer mit Störungen rechnen.

Markus

Zitat von: Mafi am 01 Juni 2025, 21:50:26Warum die WLAN Verbindung hin und wieder kurz abbricht weiß ich nicht. Denkbar wäre, dass meine Fritzbox ...

Falls es eine 7590 ist schau dir mal das hier an: https://www.golem.de/news/fritzbox-7590-ursache-fuer-fruehzeitige-wlan-ausfaelle-vermutlich-gefunden-2505-196647.html

Zitat von: Mafi am 01 Juni 2025, 21:50:26Hallo zusammen,
[...]

Markus

Moin Markus,

ich hab für beides mal kurze Issues in https://github.com/pljakobs/esp_rgbww_firmware/issues (https://github.com/pljakobs/esp_rgbww_firmware/issues) aufgemacht. Ich bin gerade an ner ganz anderen Stelle, aber ich werde die Issues nacharbeiten.

Das Ding mit der "last color" ist, soweit ich mich erinnere, wirklich noch nicht implementiert, das war früher ja eine der Kernursachen, warum die Controller nach einiger Zeit gestorben sind, das will ich für die Zukunft vermeiden.

pj

Zitat von: pjakobs am 02 Juni 2025, 09:13:18Das Ding mit der "last color" ist, soweit ich mich erinnere, wirklich noch nicht implementiert, das war früher ja eine der Kernursachen, warum die Controller nach einiger Zeit gestorben sind, das will ich für die Zukunft vermeiden.

Man konnte (bzw kann) das aber jederzeit entschärfen, indem man "startup_color" nicht auf "last" setzt, sondern auf einen festen Farbwert. In dem Fall wird dann im Controller nicht ständig die aktuelle Farbe weggeschrieben. Zugegeben ist aber "last" als Default vermutlich nicht so geschickt.  O:-)