Sensormodule aktualisieren

[henfri]

Es gibt doch einen endlichen Satz an Argumenten.
-pkg zählt nicht dazu, oder?

[thewhobox]

Du kannst auch Pfade angeben.
-pkg ist halt kein gültiger Pfad.

[henfri]

Genau. Das kann einem das Tool doch verraten.

[willisurf]

Ist halt wirklich die Frage, wie viele Checks bei einem Kommandoszeilentool mit recht flexiblen Eingaben sinnvoll sind. Wenn man das später in einem Tool oder aktuell in einem Batchjob verpackt, ist es sowieso nicht mehr relevant.

[henfri]

Hallo,

ich habe jetzt:
- die FW aktualisiert
- das Applikationsprogramme (2.15 und 3.2) importiert
- das Applikationsprogramme dem Projekt hinzugefügt

Dennoch bleibt der Button zur Aktualisierung grau.
Liegt das hieran?

Wer die (stark abgespeckten) Versionen Vpm und OneWire nutzt und diese auf der RP2040-Hardware verwendet hat, bekommt eine halbautomatische Unterstützung für die Migration auf die Big-Version. Dazu muss man die gleichzeitig erscheinende Vpm- bzw OneWire-Version 1.6.2 nutzen. Diese enthält die Version 1.5.2, ergänzt um den Konfigurationstransfer. Mit dem kann man dann alle Sensor-, PM- und Logik-Einstellungen auf die Big-Version migrieren, Das geht auf jeden Fall schneller und komfortabler, als alles manuell abzutippen.

Ich bin jetzt ein wenig verwirrt.

Ich aktualisiere jetzt die Sensormodul-VPM auf 1.6.2. Dabei bleibt die Konfiguration erhalten. Dann aktualisiere ich ohne Beibehaltung der Konfiguration auf 3.2 und nutze den Konfigurationstransfer, um die Konfig wiederherzustellen?

Gruß,
Hendrik

[mumpf]

Hi Hendrik,

gut dass Du fragst. Ich hatte sowieso nochmal vor, so einen Upgrade zu beschreiben. Da ich derzeit im Urlaub bin, habe ich das noch nicht geschafft. Ich fange heute mal an, so dass Du hoffentlich weiterkommst. Und stell bitte Fragen, ich werde dann ergänzen. Vielleicht kommt schon hier eine gute Upgrade-Anleitung raus, die ich dann auch in die Offizielle Doku übernehmen kann.

Erstmal zum Hintergrund... Es gab 3 ETS-Varianten für das Sensormodul (schon als 1.5.x):

1. Sensormodul-OneWire, dies war die Ursprüngliche vom SAMD (und hieß früher nur Sensormodul), die habe ich auch dann auch für den RP2040 released.
2. Sensormodul-Vpm, die habe ich gebaut, weil ich kein 1-Wire nutze und ich es viel praktischer fand, überall da, wo Sensoren sind (bei mir in jedem Raum), auch einen VPM laufen lassen zu können. Auch die Firmware lief zuerst auf dem SAMD und wurde dann von mir auch auf den RP2040 portiert.
3. Sensormodul-Big, da es natürlich Anfragen gab, warum denn "entweder OneWire oder Vpm" auf einem RP2040, der hat doch genug Kapazität für beides. Also habe idh die Big-Applikation auch noch gemacht. Die natürlich nur für den RP2040.

Das sind für die ETS aber immer verschiedene Applikationen, man kann nicht von einer auf die andere wechseln (im Sinne eines Upgrades). Also habe ich Updates auch immer für alle 3 Applikationen angeboten.

Das neuste Update ist nur für das Sensormodul-Big, also die reine RP2040-Applikation. Die anderen beiden bleiben so, wie sie sind. Und das ist mit Absicht so... nicht, weil ich Dich oder andere mit einem manuellen Update quälen will, sondern weil ich verhindern will, dass sich Benutzer ihre SAMD-Hardware unzugänglich machen.
Würde ich ein Update auf 3.x für das Sensormodul-Vpm anbieten, würde die ETS für jede 1.5.x-Applikation den Update-Button aktivieren, auch wenn da ein SAMD dahinter ist. Und beim nächsten Proggen würde die ETS auch beim SAMD sagen, die Firmware ist zu alt, bitte aktualisieren. Und für den SAMD gibt es keine neuere Firmware und ein Downgrade ohne Parameterverlust gibt es bei der ETS nicht.
Ich habe somit Dich (und andere User, die nicht genau wissen, wann die ETS Updates erlaubt) davor bewahrt, eversehentlich ein Update zu machen. Sensormodul-Vpm und Sensormodul-OneWire haben keine neue 3.x-Applikation, sondern nur Sensormodul-Big.

Man muss also auf die Sensormodul-Big wechseln, wenn man 3.x haben will. Für alle die, die bisher schon die -Big auf dem RP2040 verwendet haben, ist es einfach: Das übliche ETS-Update von der ETS 1.5.x auf 2.15, danach auf 3.x funktioniert.
Alle anderen (ich gehöre mit 16 Modulen dazu) müssen leider den schwierigeren Weg gehen, der normalerweise ein "alles nochmal eingeben" heissen würde (wenn man es so macht, wie die KNXA und die ETS es vorsieht).
Ich freue mich, einen "halbautomatischen" Weg anbieten zu können. Dank unseres neuen Kofiguretiontransfers kann man viel Arbeit die ETS erledigen lassen und viel Klickarbeit sparen. Einiges muss man aber doch noch manuell machen.

Grundidee: Man überträgt mit dem Konfigurationstransfer alle Parameter vom alten Gerät auf das neue, indem man die Parameter beim alten Gerät exportiert und beim neuen Gerät importiert. KO und Flags muss man dann noch manuell zuordnen.
Problem: 3.x hat den Konfigurationtransfer eingebaut (importieren geht also), die 1.5.x aber nicht (exportieren geht somit nicht). Deswegen habe ich eine Applikation 1.6 gemacht, für -Vpm und -OneWire, die als Update zu 1.5 funktioniert und keine neue Firmware braucht. Dort gibt es als einzige Erweiterung den Konfigurationstransfer, der dann auch exportieren kann.

Das ist der Hintergrund, in der nächsten Nachricht kommt die beispielhafte Migration eines Sensormodul-Vpm auf ein Sensormodul-Big.

Gruß, Waldemar

[mumpf]

Ausgangslage: Ein existierendes Sensormodul-Vpm Version 1.5.x (auf RP2040-Hardware), dass man auf ein Sensormdoul-Big 3.x migrieren möchte. Beim Sensormodul-OneWire wird das analog sein, aber derzeit kann Sensormodul-Big noch kein OneWire, deswegen bitte noch nicht migrieren.

Wie man mit Konfigurationstransfer einen Logikkanal überträgt, ist im Detail hier https://knx-user-forum.de/forum/proj...agen-anleitung beschrieben. Vielleicht sollte man vorher mit dem Sensormodul-Big 3.x erstmal etwas üben, wie so eine Übertragung läuft.

Vorgehen:
Erstmal ein normales Update von 1.5.x auf 1.6.x mit der ETS (also 1.6 in Katalog importieren, inst Projekt einfügen, bestehendes Gerät auf Update clicken).
Sensormodul-Big 3.x ins Projekt neu einfügen. Neues Gerät passend benennen, so dass man es nicht mit dem alten Gerät verwechselt.
In der ETS beide Geräte auf eine Seite bringen (split screen, ich bevorzuge horizontalen split). Ich gehe im folgenden davonaus, dass das alte Gerät (Quelle) oben ist und das neue Gerät (Ziel) unten.
Auf beiden Geräten "Parameter" wählen.
Notiert euch bei der Quelle, welche VPM-Kanäle benutzt worden sind (die Kanalnummern) und welche Logikkanäle.
Auf beiden Geräten "Konfigurationstransfer" auswählen.
Bei der Quelle "Export" auswählen. Beim Ziel "Import".

Jetzt müssen nacheinander folgende Bereiche bei der Quelle Exportiert und unmittelbar nach dem Export beim Ziel Importiert werden:

• OpenKNX Basiseinstellungen
• Sensoren Basiseinstellungen
• Präsenzmelder Basiseinstellungen
• Präsenzmelder Kanal 1-5 (nur die verwendeten Kanäle)
• Logiken Basiseinstellungen
• Logiken Kanal 1-70 (nur die verwendeten Kanäle)

Beim Import solltet ihr immer das Importziel aus dem Export übernehmen lassen und die Kompatibilitätsprüfung auf Locker belassen.

Mir ist klar, dass das viel Arbeit ist, aber ich muss da mit meinen 16 Modulen auch durch. Ich habe bereits 6 migriert und brauche bei gut 50 Logikkanälen und 2-3 VPM-Kanälen für ein ganzes Modul unter einer Stunde. Ohne Konfigurationstransfer dauert das eher pro Modul einen Tag.

Mir ist auch klar, dass gleich Fragen kommen, warum man denn das Kanal für Kanal machen muss und nicht gleich alles auf einmal ex- und importieren kann. Die Antwort ist: Weil es der Konfigurationstransfer derzeit nicht kann. Eine solche Funktion wird dezeit entwickelt und wird irgendwann verfügbar sein. Aber ich weiß ehrlich gesagt nicht, ob ich mir dann nochmal die Mühe machen werde, eine 1.7.x zu bauen, denn es ist unglaublich viel Aufwand, auf einem alten Stand eine neue ETS-Applikation zu erzeugen. Ich kann nur empfehlen, die Migration jetzt zu machen, der Aufwand ist vertretbar und weit weniger als eine komplette manuelle Neukonfiguration.

Wichtig: Der Konfigurationstransfer überträgt nur Parameter. Alle GA-Verknüpfungen und alle Flags (falls welche geändert wurden), müssen nach der Parameter übertragung dem neuen Gerät zugeordnet werden.
Das geht sehr einfach, indem man bei Quelle und beim Ziel auf "Kommunikationsobjekte" geht.
Anschließend kann man einfach per Drag&Drop jede GA von oben nach unten zum passenden KO ziehen.

Letzte (und finale) Prüfung: Bei den Logiken im Ziel auf "Übersicht interne KO" gehen. Wenn in dieser interne KO auftauchen, müssen diese auf die neuen KO-Nummern angepasst werden. Die Logik-KO haben sich von der VPM- auf die Big-Version um 720 verschoben, das frühere KO 200 ist jetzt KO 920. Man muss also jeder zu jeder KO-Nummer, die in der Übersicht auftaucht, einfach 720 dazuaddieren.

Viel Erfolg bei der Migration,
Gruß, Waldemar

[henfri]

Hallo,

vielen Dank für die Erklärung der Hintergründe (ich hatte einiges tatsächlich schon vermutet/mich gefragt wie das gehen soll von einer auf die andere Applikation zu wechseln).
Der Transfer hat soweit geklappt. Ich hatte noch nicht viel konfiguriert.
Ich habe folgende Warnungen bekommen:

LOG/1 Import [ >>> Warnungen beachten! <<< ]

[WARN] Unbekannter Parameter: f~E1Convert ("f~E1Convert=4")
[WARN] Unbekannter Parameter: f~E2Convert ("f~E2Convert=5")


SENS/0 Import [ >>> Warnungen beachten! <<< ]

[WARN] Unbekannter Parameter: VocDeltPercent ("VocDeltPercent=5")​

Sind die bedenklich?

Ich habe die Applikation noch nicht parametrisiert (in dem Raum wird gerade geschlafen ;-)

Noch eine Beobachtung: Die ETS ist sehr, sehr träge/hängt manchmal. Ich weiß nicht, ob es an den OpenKNX Geräten liegt. Die CPU-Auslastung durch die ETS ist in den Momenten auch sehr hoch.
Die ETS ist tatsächlich jetzt unbenutzbar. Sobald ich beim alten Gerät eine GA anklicke hängt die ETS. Die GA verschwindet (als wäre keine GA assoziiert).
Edit: Ein Neustart hat zunächst nicht geholfen. Aber plötzlich geht es wieder.

Ist das nur bei mir so?

Gruß,
Hendrik

[mumpf]

Hi Hendrik,

die Warnungen besagen, dass es in der alten Applikation Parameter gab, die es in der neuen nicht mehr gibt. Ich bin nur verblüfft, weil ich eigentlich dachte, dass es die in beiden gab... ich schaue nochmal. Du solltest aber nochmal beim Logikkanal 1 die beiden Eingänge (Quelle und Ziel) vergleichen und bei den Sensoren die VOC-Einstellungen.

Zu der Geschwindigkeit der ETS: Während der Imports/Exports ist die ETS sehr langsam bzw. auch stellenweise geblockt. Dagegen können wir nichts machen, im Prinzip passieren da im Hintergrund alle Eingaben in alle Felder - eben das, was man sonst manuell machen müsste. Was die ETS genau macht, weiß ich auch nicht, wir verwenden nur offizielle APIs, die auch Herstellern zur Verfügung stehen. Während eines Export/Import wird auch viel Rechenzeit verbraucht.

Ansonsten habe ich auch immer wieder eine langsame ETS, vor allem wenn der Gruppenmonitor läuft und der Virenkiller einen scan macht. Sehr häufig hilft ein Neustart der ETS bei mir. Wenn allerdings der Virenkiller läuft, bleibt sie langsam, bis der Virenkiller die Platte "durchgescanned" hat.

Gruß, Waldemar

[mumpf]

So, hab jetzt auch bei den Parametern nachgeschaut.

VocDeltPercent beim Sensormodul war wohl ein Typo und ich hab den in den neueren Versionen auf VocDeltaPercent geändert. Bitte schaue beim VOC nach dem Parameter "VOC bei Abweichung vom vorherigen Wert senden", der dürfte nicht mit übernommen worden sein.

f~E1Convert gibt es, ebenso f~E2Convert, das verstehe ich nicht wirklich. Es geht um den Parameter "Wert für Eingang wird ermittelt durch", bei Logikkanal 1, Eingang 1 und 2. Überprüf das mal, wahrscheinlich sind die nicht korrekt übernommen worden.

Gruß, Waldemar

[henfri]

Hallo,

ja, der Wert wurde tatsächlich nicht übertragen.

Aber die Anleitung ist hiermit validiert ;-) Danke nochmal für die tolle Beschreibung, und natürlich die tolle Software.

Viele Grüße,
Hendrik