Make OPTIMUM_START_STOP visible in configuration also for HMIP-eTRV devices

[neopholus]

Describe the solution you'd like

For HMIP-WTH and HMIP-WTH-2, there is a configuration flag in channel 1 of the device shown: Optimum Start/Stopp
This flag also exists for e.g. HMIP-eTRV devices, but there the flag is not shown in the configuration. See HMIP Device Documentation, Chapter 276.3.2.2.9. Parameter OPTIMUM_START_STOP

Wish: Please show this flag for all devices that support it.

Describe alternatives you've considered

Flag could be set via ioBroker, but this limits the solutions to those who use iobroker.
Also adding a HMIP-eTRV device to a heating group makes the flag configurable via the heating group.

Is your feature request related to a problem?

Yes, I cannot use optimum start/stop in rooms without a HMIP-WTH device or a heating group.

Additional information

No response

[Baxxy13]

Ok, ich seh's.
Optimum Start/Stopp ist bei "standalone" betriebenen eTRV's nicht über die Geräteeinstellungen verfügbar/aktivierbar obwohl die eTRV's das können.
Gucken wir uns an.

[jp112sdl]

Aus meiner Sicht wäre zuerst zu prüfen, ob der HMIPServer den Parameter für den eTRV überhaupt ausgibt.

@Baxxy13 Es fehlt nur die Anzeige in der WebUI - per Skript kann man mit getParamset / setParamset auf den Parameter OPTIMUM_START_STOP von Kanals 1 zugreifen ?

[Baxxy13]

Also ich habe hier:
eTRV-F
eTRV-B1

Beide haben von der Grundfunktionalität her identische MASTER_PARAMETER, auch OPTIMUM_START_STOP.
Zum diffen:

eTRV-B1:
ADAPTIVE_REGULATION integer 2
BOOST_AFTER_WINDOW_OPEN integer 0
BOOST_POSITION integer 80
BOOST_TIME_PERIOD integer 10
DECALCIFICATION_TIME integer 22
DECALCIFICATION_WEEKDAY integer 6
DURATION_5MIN integer 0
MANU_MODE_PRIORITIZATION integer 1
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE integer 0
OPTIMUM_START_STOP integer 1
PARTY_MODE_PRIORITIZATION integer 1
TEMPERATUREFALL_MODUS integer 4
TEMPERATUREFALL_VALUE real 1.400000
TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD integer 15
TEMPERATURE_MAXIMUM real 23.000000
TEMPERATURE_COMFORT real 21.000000
TEMPERATURE_LOWERING real 17.000000
TEMPERATURE_MINIMUM real 4.500000
TEMPERATURE_OFFSET real 0.000000
TEMPERATURE_WINDOW_OPEN real 6.000000
VALVE_ERROR_RUN_POSITION real 0.150000
VALVE_MAXIMUM_POSITION real 1.000000
VALVE_OFFSET real 0.000000

eTRV-F:
ADAPTIVE_REGULATION integer 2
BOOST_AFTER_WINDOW_OPEN integer 0
BOOST_POSITION integer 80
BOOST_TIME_PERIOD integer 10
CHANNEL_OPERATION_MODE integer 0
COOLING_ENABLE integer 1
DECALCIFICATION_TIME integer 22
DECALCIFICATION_WEEKDAY integer 6
DURATION_5MIN integer 0
MANU_MODE_PRIORITIZATION integer 1
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE integer 0
OPTIMUM_START_STOP integer 1
PARTY_MODE_PRIORITIZATION integer 1
TEMPERATUREFALL_MODUS integer 4
TEMPERATUREFALL_VALUE real 1.400000
TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD integer 15
TEMPERATURE_MAXIMUM real 25.000000
TEMPERATURE_MINIMUM real 4.500000
TEMPERATURE_OFFSET real 0.000000
TEMPERATURE_WINDOW_OPEN real 12.000000
TEMPERATURE_WINDOW_OPEN_COOLING real 28.000000
VALVE_ERROR_RUN_POSITION real 0.150000
VALVE_MAXIMUM_POSITION real 1.000000
VALVE_OFFSET real 0.000000

Ansicht WebUI:
eTRV-B1:

eTRV-F:

Und zum Vergleich eine Ansicht aus einer IP-Heizgruppe.
Diese ist überall gleich, egal welches eTRV in der Gruppe ist.

[jp112sdl]

Was für ein Durcheinander. Da fehlt ja bei beiden (B1 / F) jeweils einiges...

[jens-maus]

So ist das wenn man ständig neue Geräteintegrationen from scratch baut anstatt eine brauchbare/saubere Basisklasse für alle Heizkörperaktoren zu haben/nutzen... Broken by design würde ich sagen...

[neopholus]

Danke, dass ihr euch das anschaut!

[jp112sdl]

Danke, dass ihr euch das anschaut!

Eine zufriedenstellende Antwort wird es aber wohl nicht geben...

Hier die technische Antwort, weshalb die Optionen nicht angezeigt werden, obwohl sie im Gerät vorhanden sind:
eQ-3 hat für einige eTRV dedizierte Einstellungs-Layouts gebaut.
Diese liegen in /www/config/easymodes/hmip und heißen

• hmip-etrv-b1_1_master.tcl
• hmip-etrv-b_1_master.tcl
• hmip-etrv-c-2_1_master.tcl
• hmip-etrv-c_1_master.tcl
• hmip-etrv-cl_1_master.tcl
• hmip-etrv_1_master.tcl

Beim Test gestern mit Baxxy haben wir herausgefunden, dass beim Aufruf der Einstellungen des eTRV-B1 in die hmip-etrv_1_master.tcl abgebogen wird. Und dort ist u.a. der Parameter OPTIMUM_START_STOP nicht mit drin.

Wird hingegen die Einstellungs-Seite des eTRV-F aufgerufen, wird die Default-Seite hmipChannelConfigDialogs.tcl geladen.
Und darin ist auch u.a. OPTIMUM_START_STOP vorhanden. Das Element wird angezeigt, sofern es auch im Paramset des Gerätes vorkommt.

Testweise haben wir die hmip-etrv_1_master.tcl umbenannt in hmip-etrv_1_master.tcl.bak, so dass diese nicht gefunden/geladen werden kann.
Es wird dann auch beim eTRV-B1 die Default-Seite geladen und mit allen Optionen (also auch mit OPTIMUM_START_STOP) aufgebaut und angezeigt.

TLDR;
Es ist nicht ersichtlich, aus welchen Gründen diese "speziellen" Einstellungs-Layouts gebaut wurden und es ist auch mühsam, herauszufinden, bei welchem eTRV-Modell in welche Unterseite eingestiegen wird. Und selbst dann müssten diese auch noch gepatcht werden.
Wenn man mutig ist, einfach die .tcl-Dateien aus der Liste oben alle umbenennen und schauen, ob dann alle Parameter angezeigt werden.

[jens-maus]

Testweise haben wir die hmip-etrv_1_master.tcl umbenannt in hmip-etrv_1_master.tcl.bak, so dass diese nicht gefunden/geladen werden kann. Es wird dann auch beim eTRV-B1 die Default-Seite geladen und mit allen Optionen (also auch mit OPTIMUM_START_STOP) aufgebaut und angezeigt.

Hat mal einer (@Baxxy13, @jp112sdl) kontrolliert ob dies nicht auch einfach ein Problem mit nicht entfernten tcl Dateien ist ähnlich wie das vor kurzem gefixte MOD-RC8 Problem bei dem im OCCU Dateien da waren die in der CCU3 Firmware schon längst gelöscht wurden?!?!

[jens-maus]

Hat mal einer (@Baxxy13, @jp112sdl) kontrolliert ob dies nicht auch einfach ein Problem mit nicht entfernten tcl Dateien ist ähnlich wie das vor kurzem gefixte MOD-RC8 Problem bei dem im OCCU Dateien da waren die in der CCU3 Firmware schon längst gelöscht wurden?!?!

Hab mir mal selbst gerade nen diff von CCU3 vs. OCCU generiert und kann hier in der Tat die hmip-mod-rc8_*_master.tcl erkennen die bei RM "zuviel" sind. Bzgl. hmip-etrv ist diesbzgl. nicht zu sehen. Sollte also mit einer reinen CCU3 firmware genauso auftreten.

[Baxxy13]

Das wäre auch zu einfach.
Ich will auch meine eTRV's nicht an eine CCU3 umlernen nur um das zu testen.

Trotzdem habe ich mal ein Spielchen gemacht und alle...
/www/config/easymodes/hmip/hmip-etrv*yxz*_master.tcl umbenannt.
Das führt dann dazu (hatten wir ja schon festgestellt) das die Einstellmasken soweit identisch sind.
Trotzdem fehlen jede Menge Optionen was irgendwie ärgerlich ist.

Also mal...
/www/config/easymodes/hmip/HEATING_CLIMATECONTROL_TRANSCEIVER.tcl umbenannt.

Jetzt gibt's eine Ansicht im "Devconfig - Style", also roh und hässlich.
Dafür ist jeder im Gerät verfügbare Parameter einstellbar.
D.h. das die Masken für eTRV-B und eTRV-F minimal unterschiedlich sind, je nachdem was die Teile so können.
(das eTRV-F hat ja z.B. nen Button wo man Farbe, Dimmstufe usw. wählen kann, schönes Spielzeug)

hier kommen nun hunderte Zeilen für die Wochenprogrammparameter...

[Baxxy13]

Also mal weitergedacht...
Wir bräuchten eine eigene Einstellungsseite für alle eTRV's die einfach alle vorhandenen Parameter anzeigt.
(vielleicht 1-2 die wir ausblenden sollten)

[jp112sdl]

Ich will auch meine eTRV's nicht an eine CCU3 umlernen nur um das zu testen.

Hol dir doch nur die .dev Files rüber in dein Testsystem :) Klappte mit dem RC8 bei mir doch gut

[Baxxy13]

Hab ich schon mal erwähnt das ich keine Ahnung von dem html/tcl Kram habe...
Egal, die Rohfassung der "Universal-eTRV-Einstellungsseite" ist fertig.

vereinfachter Modus (eTRV-B1):

normaler Modus (eTRV-B1):

Muss noch stilistisch optimiert werden und mit dem Code habe ich auch noch Probleme.
Freiwillige? 😉

[jens-maus]

Muss noch stilistisch optimiert werden und mit dem Code habe ich auch noch Probleme. Freiwillige? 😉

Hut ab. Aber wollen wir uns wirklich den Schuh anziehen das jetzt quasi from scratch anders zu machen als eQ3 und damit schrittweise inkompatibel zu zukünftigen Änderungen zu werden?

[Baxxy13]

Naja "wollen" eigentlich nicht.
Aber meinst du die ändern da zukünftig noch groß was, außer vielleicht das 10. eTRV hinzuzufügen das dann vielleicht wieder ne extra eTRVxyz.tcl bekommt?
Ich finde das echt nervig das selbst im "Expertenmodus" mal mehr oder weniger Optionen fehlen und auch die Anordnung der Parameter unterschiedlich ist.

Ich lasse das aktuell alles in der /www/config/easymodes/etc/hmipChannelConfigDialogs.tcl bauen.
Habe da den ursprünglichen Bereich um alle anderen (fehlenden) Optionen erweitert.
Dummerweise wird nur dahingesprungen wenn es keine anderen /www/config/easymodes/hmip/hmip-etrv*.*master.tcl gibt.

Ventil-Offset ist noch unschön, da bräuchte ich irgendwie ne Umwandlung.
Die Optik kommt dann später.
Ansonsten läuft's soweit.

[jens-maus]

Du kannst ja mal dazu nen PR als Draft machen, dann kann man sich das selbst mal anschauen und dann sehen wir weiter. Ist ja eigentlich gut wenn einfach die alten hmip-etrv*master.tcl Dateien gelöscht werden müssen, dann wäre das ne recht einfache sache die wegzupatchen. Die Frage wäre nur wie breit hast du das denn selbst über alle möglichen eTRV Geräte getestet?!? Und dann müsste man mal nen genauen Blick auf die Fallunterscheidungen bzw. exceptions für gewisse eTRV werfen. Ist ja wirklich so das nicht jedes eTRV jetzt Optimum start/stopp usw. hat...

[jp112sdl]

Ist ja wirklich so das nicht jedes eTRV jetzt Optimum start/stopp usw. ha

Die Option(en) wird/werden nur eingeblendet, wenn sie im Paramset des Geräts tatsächlich vorhanden ist/sind (if { [info exists ps($param)] == 1 } {).
Man muss da keine Ausnahmen bauen.

Nur mal ein Ausschnitt
https://github.com/eq-3/occu/blob/master/WebUI/www/config/easymodes/etc/hmipChannelConfigDialogs.tcl#L2919-L2931

Die Frage wäre eher: Nur weil das Gerät laut XML den Parameter OPTIMUM_START_STOP besitzt, kann es den dann in seiner Geräte-Firmware auch tatsächlich verarbeiten/benutzen?
Vielleicht ist das der Grund, warum eQ-3 die Ansicht abgespeckt hat?
Es war ja für sie ein extra Aufwand, diese angepasste Config-Seite zu bauen.

[Baxxy13]

Genau, die Parameter die nicht im PARAMSET des Gerätes sind werden übersprungen, also in der Einstellungsseite nicht angelegt.
Ob die Parameter tatsächlich funktionieren oder weggelassen wurden weil sie eben nicht funktionieren lässt sich schwer bis kaum prüfen.

Es gibt ja nur extra Dateien für eTRV-B / eTRV-B1 / eTRV-C / eTRV-C-2 / eTRV-CL.
Dann gibt's die Datei hmip-etrv_1_master.tcl in die m.E. alle anderen eTRV's reinrutschen sollten.
Da rutscht aber mein eTRV-F nicht rein, dafür aber komischerweise mein eTRV-B1.
Das eTRV-F rutscht in die hmipChannelConfigDialogs.tcl. Hier landen auch die IP-Gruppen und das ist der Pfad mit den wenigsten Parametern.

Wenn man nun spaßeshalber alle hmip-etrv_*.*_master.tcl miteinander vergleicht stellt man fest, die sind von der Funktionalität alle gleich.

Somit reduzieren sich die Einstellungsseiten auf 2, und zwar die die ich oben schon für's eTRV-F und eTRV-B gezeigt habe.
Das eTRV-B1 geht in die hmip-etrv_1_master.tcl und diese ist ja fast vollständig.

Es fehlen 3 Parameter:

• Optimum Start/Stopp
• Ignoriere min./max. Temperatur im Manu-Mode
• Dauer für Fenster-Auf-Temperatur

Diese könnte man leicht zur hmip-etrv_1_master.tcl hinzufügen.

Es bliebe aber das Problem das nicht alle eTRV's in die hmip-etrv_1_master.tcl reinrutschen. Keine Ahnung warum.

Mein Vorschlag:
Wir patchen die hmipChannelConfigDialogs.tcl so das dort alle Parameter gebaut werden können.
Wir löschen alle hmip-etrv_*.*_master.tcl.

So habe ich das hier heute ausprobiert und auch für gut befunden. 😉

[Baxxy13]

Wenn wir es hinbekommen das alle eTRV's in die hmip-etrv_1_master.tcl reinrutschen dann könnte das so aussehen:

(hier sind alle 18 relevanten Einstelloptionen drin)

[jp112sdl]

Wenn wir es hinbekommen das alle eTRV's in die hmip-etrv_1_master.tcl reinrutschen dann könnte das so aussehen:

Die Namenskonvention ist ja bekannt. ($ch_paramid.tcl oder $ch_descr(TYPE).tcl)
https://github.com/eq-3/occu/blob/master/WebUI/www/config/ic_deviceparameters.cgi#L870-L877

Dann einfach Symlinks auf die hmip-etrv_1_master.tcl anlegen, die so heißen wie die verschiedenen eTRV Typen

[Baxxy13]

Das verstehe ich leider nicht.
Bekäme man so auch die Ansicht des IP-Gruppengerätes "umgelenkt"?

Eigentlich finde ich meinen ursprünglichen Plan besser.

Mein Vorschlag:
Wir patchen die hmipChannelConfigDialogs.tcl so das dort alle Parameter gebaut werden können.
Wir löschen alle hmip-etrv_._master.tcl.

Als Bonus gibt's dabei auch noch eine zusätzliche Option für WTH / STH usw.

[Baxxy13]

Update:
Mit dem Styling bin ich soweit durch und zufrieden.
Hier mal die Ansicht von einem IP-Gruppengerät:
(der "Marker-Text" hinter "Minimale Temperatur" kommt noch weg)

Funktioniert auch soweit alles, aber beim Ventil-Offset brauche ich dann doch Hilfe.
Da müsste ja ne ProofAndSetValue Funktion rein oder sowas.
Oder wir machen so ne Drop-Down Box in 5% Schritten.

Edit:
Hab auf Drop-Down umgebaut und gleich noch andere Parameter auf Drop-Down umgestellt.

[jens-maus]

Sieht doch schon recht gut aus. 👏

Ich denke aber bzgl drop-down vs eingabefeld sollten wir am besten zur originalen Firmware so weit es geht kompatibel bleiben damit werte dann auch 1:1 so übernommen werden können und das look&feel gleich ist, oder?

[jp112sdl]

Ich bin immer noch dagegen, die ganzen Anpassungen direkt in der hmipChannelConfigDialogs.tcl zu machen.
Aber das ist mein persönliches Bauchgefühl.
Ich hätte den relevanten Kram - oder zur Not auch die angepasste komplette hmipChannelConfigDialogs.tcl in eine neue Datei gepackt und Symlinks in easymodes/hmip/ für die einzelnen Modelle angelegt, die auf diese neue Datei zeigen.

Nur meine Meinung, um nicht die riesige Originaldatei zu zerfummeln.

[Baxxy13]

drop-down vs eingabefeld

Guck dir mal das Eingabefeld für "Ventil-Offset" genau an.

• Eingeben kann man nur Werte von 0.0 - 1.0 in Zehnerschritten, d.h. der Offset kann nur auf 0% / 10% / 20% usw. gestellt werden.
  Mit einem 0 - 100 Dropdown kann man z.B. auch 3% einstellen.
• Dann passt die Einheit und der Wertebereich nicht zu dem was man eingeben muss, unschön

eQ-3 hat ja selbst über die Zeit vieles auf Dropdowns umgebaut, meist zum Nachteil weil das DropDown - Raster meist sehr grob ist.

Ich bin der Meinung wenn wir schon eine "One-for-All" Einstellungsseite machen dann so wie wir es wollen.

Eingabefeld vs. Dropdown ist natürlich ein Thema.

Hier mal die Dropdown-Version.
(Ansicht von einem IP-Gruppengerät)

Symlinks

Ich verstehe das mit den Symlinks nicht.

um nicht die riesige Originaldatei zu zerfummeln

Wo ist der Unterschied die webui.js zu patchen oder die hmipChannelConfigDialogs.tcl ?

Es gibt doch auch schon 5 Patches die die hmipChannelConfigDialogs.tcl adressieren, der letzte ist 0186-WebUI-Fix-HmIPW-DRI16_DRI32-Channel.patch.

Ich bin natürlich für alles offen. 😄

[jp112sdl]

Ich verstehe das mit den Symlinks nicht.

In "Windows" gesprochen: Eine Dateiverknüpfung
hmipChannelConfigDialogs_custom.tcl -> Verknüpfung erstellen -> easymodes/hmip/hmip-etrv-b_1_master.tcl
hmipChannelConfigDialogs_custom.tcl -> Verknüpfung erstellen -> easymodes/hmip/hmip-etrv-c-2_1_master.tcl
hmipChannelConfigDialogs_custom.tcl -> Verknüpfung erstellen -> easymodes/hmip/hmip-etrv_1_master.tcl
...

Somit gibt es eine einzige gemeinsame .tcl, die für die eTRV aufgehübscht ist, egal was sich eQ3 an Überraschungen einfallen lässt.

[Baxxy13]

Danke, soweit verstanden.
Aber wie symlinke ich das IP-Gruppengerät oder mein eTRV-F die ja beide direkt in die hmipChannelConfigDialogs.tcl gehen?

[jens-maus]

Guck dir mal das Eingabefeld für "Ventil-Offset" genau an.

• Eingeben kann man nur Werte von 0.0 - 1.0 in Zehnerschritten, d.h. der Offset kann nur auf 0% / 10% / 20% usw. gestellt werden.

Ist das wirklich so? D.h. die eTRV akzeptieren nur werte zwischen 0.0 und 1.0 und auch nur mit einer stelle nach dem Komma genauigkeit? Wenn ja, dann müsste hier in der Tat das Dropdown natürlich so ausgerichtet werden das man keine krummen werte übergeben kann die am schluss das gerät nicht fressen kann beim übermitteln.

eQ-3 hat ja selbst über die Zeit vieles auf Dropdowns umgebaut, meist zum Nachteil weil das DropDown - Raster meist sehr grob ist.

Ich bin der Meinung wenn wir schon eine "One-for-All" Einstellungsseite machen dann so wie wir es wollen.

Und das heisst dann? Alles auf Textfelder zurück und keine DropDowns mehr wenn man Werte einstellen kann/soll? Oder einfach nochmal genau draufschauen welche konkreten Wertebereiche es gibt. Oder unterscheiden die sich dann am schluss sogar nach jeweiligem TRV Gerät sodass man das nicht vereinheitlichen kann?

Symlinks

Ich verstehe das mit den Symlinks nicht.

um nicht die riesige Originaldatei zu zerfummeln

Wo ist der Unterschied die webui.js zu patchen oder die hmipChannelConfigDialogs.tcl ?

Es gibt doch auch schon 5 Patches die die hmipChannelConfigDialogs.tcl adressieren, der letzte ist 0186-WebUI-Fix-HmIPW-DRI16_DRI32-Channel.patch.

Ich bin natürlich für alles offen. 😄

Ich prinzipiell auch. Ich verstehe natürlich den Ansatz von @jp112sdl am besten einfach die hmipChannelConfigDialogs.tcl unangefasst zu lassen damit da eQ3 weiter dran rumbasteln kann und es weniger konflikte dann zu uns gibt. Und dann muss man nur ne neue/frische tcl sich ausdenken und dann auf dateisystemebene im Betriebssystem symlinks anlegen auf diese neue datei und fertig. Hat einen gewissen Charme, aber ggf. sogar den Nachteil das man dann weitere änderungen von eQ3 an diesen Dateien nicht mitbekommt weil es dann ggf. keine merge konflikte gibt und wir die dann einfach immer wegschmeissen in unserem WebUI patches.

Vielleicht daher da eine hybride lösung? D.h. an der stelle wo entschieden wird diese anderen hmip-etrv-XXXX_master.tcl quasi nachzuladen nur die neue datei als einzige nachladbare tcl einbauen und diese hmip-etrv-XXXX_master.tcl gänzlich weglöschen? Dann bekommen wir es mit wenn eQ3 da seine finger dran hatte und können ggf. nachpatchen.

[jens-maus]

BTW: Wie wäre es mal, @Baxxy13 macht mal einen ersten PR als Draft fertig und dann diskutieren wir daran weiter statt hier im Ticket? Dann können wir den PR noch verfeinern und so auch gleich gemeinsam testen.

[Baxxy13]

Ist das wirklich so? D.h. die eTRV akzeptieren nur werte zwischen 0.0 und 1.0

Ja. Ist doch bei quasi jedem LEVEL (bei HmIP) so.

und auch nur mit einer stelle nach dem Komma genauigkeit?

Natürlich nicht, und das ist ja eins der Probleme.
Es müsste 0.00 - 1.00 sein damit man für 5% z.B. 0.05 eingeben kann.

dann müsste hier in der Tat das Dropdown natürlich so ausgerichtet werden das man keine krummen werte übergeben

Hab ich bedacht, passt.

Alles auf Textfelder zurück und keine DropDowns mehr wenn man Werte einstellen kann/soll?

Ich mag die Dropdowns mehr, daher habe ich in der letzten Inkarnation so viele Parameter wie möglich darauf umgestellt.
Und auch die Präzision erhöht... "Freiheit für den User". 😉

einen ersten PR als Draft

Ich guck mal.

[Baxxy13]

Nehme ich jetzt die in 0186-WebUI-Fix-HmIPW-DRI16_DRI32-Channel.patch modifizierte hmipChannelConfigDialogs.tcl als .orig und baue darauf auf?

[jens-maus]

Nehme ich jetzt die in 0186-WebUI-Fix-HmIPW-DRI16_DRI32-Channel.patch modifizierte hmipChannelConfigDialogs.tcl als .orig und baue darauf auf?

Ja, immer die letzte inkarnation einer bereits gepatchten version nehmen und darauf aufbauend dann die änderungen in einen neuen WebUI patch einbauen der die Nummer > der alten haben muss. Der neue update-patches.sh skript geht da auch genau so vor um die patch hierarchie bzw. abhängigkeiten dann quasi sicherzustellen... Kannst du auch einfach dann mal aufrufen lokale genauso wie make check um sicherzustellen das der neue WebUI Patch sich ohne konflikte anwenden lässt...

[Baxxy13]

So, hier mal "Stand der Dinge".
(Dropdown-Version / IP-Gruppengerät)

[neopholus]

Wahnsinn, vielen Dank euch allen!