ESP RGBWW Controller - Firmware v5

[pjakobs]

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

Code Auswählen Erweitern

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.

[pc1246]

Mitles

[rippi46]

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

[Mafi]

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

[pjakobs]

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.

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

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

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

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

[pjakobs]

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.

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.

[rippi46]

Hallo

MQTT 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

[pjakobs]

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.

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.

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

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

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

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.

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.

[Mafi]

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.

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

[rippi46]

Hallo,

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.

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

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.

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 

[pjakobs]

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.

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.

[pjakobs]

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

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

[Mafi]

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.

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.

Code Auswählen Erweitern

=~=~=~=~=~=~=~=~=~=~=~= 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


[Mafi]

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:

Code Auswählen Erweitern

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

[pjakobs]

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

[pjakobs]

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

[Mafi]

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!

[pjakobs]

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!

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.

[Mafi]

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.

[Mafi]

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

[pjakobs]

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?

Code Auswählen Erweitern

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


[pjakobs]

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

[Mafi]

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.

[Mafi]

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-

[pjakobs]

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

ich hab diesen Codeblock im Verdacht:

Code Auswählen Erweitern

       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 :

Code Auswählen Erweitern


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 das ganze flash image herunterladen und mit

Code Auswählen Erweitern

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ß

[Mafi]

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.

[pjakobs]

ich glaube, ich hab den Bug gefunden.

Code Auswählen Erweitern

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

[Mafi]

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.

[pjakobs]

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.

[pjakobs]

so, ich hab dann nochmal mit dem candidate patch gebaut.

Code Auswählen Erweitern

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.

[Mafi]

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!

[pjakobs]

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!

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

[Matze66]

Hallo pjakobs,

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

Gruß
Matthias

[pjakobs]

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

[pjakobs]

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.

[pjakobs]

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

[Matze66]

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

[pjakobs]

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

[Mafi]

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.

[pjakobs]

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.

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.

[rippi46]

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 

[pjakobs]

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.

[rippi46]

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

[pjakobs]

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.

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.

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.

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.

[pjakobs]

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

[rippi46]

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.

[pjakobs]

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.

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.

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.

öh, okay? so sollte es eigentlich sein.

[pjakobs]

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.

[pjakobs]

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.

[rippi46]

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

[pjakobs]

Hallo

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.

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

Aktuell 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

[rippi46]

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

[pjakobs]

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.

[rippi46]

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

[pjakobs]

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.

[rippi46]

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

[pjakobs]

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.

Code Auswählen Erweitern

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


[rippi46]

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

[pjakobs]

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.

[pjakobs]

Endlich 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

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

[rippi46]

Um 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

[pjakobs]

Um 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

[pjakobs]

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

[pjakobs]

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?

[pjakobs]

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)

[pjakobs]

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

[Mafi]

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

[pjakobs]

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

[pjakobs]

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.

[pjakobs]

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.

[pjakobs]

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!

[pjakobs]

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

[pjakobs]

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.

[pjakobs]

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.

[pjakobs]

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

[pjakobs]

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.