OpenKNX-VirtualPresence release (VPM)

[mumpf]

Beim Logikmodul ist das die 3.1, das war schon auf 3.0 (zumindest intern) bevor wir die Anpassungen gemacht haben, die das Zwischenrelease erforderten.
Bei allen anderen Modulen konnte ich so eine 2.15 machen, und dann ab 3.0 wieder sauber aufsetzen, beim Logikmodul musste es eine 3.1 werden.

Gruß, Waldemar

[Stereofeld]

[...] sonst stimmt alles.

Muss nicht noch der Zwischenschritt auf die 2.15er Version erfolgen?

[Stereofeld]

Damit es mir nicht wie Thomas geht, ...

[mumpf]

Hallo Etienne,

Damit es mir nicht wie Thomas geht,

Dafür muss da als allererster Schritt stehen: Export des Projektes, damit die aktuelle Version erhalten bleibt .

Habe ich etwas übersehen?

Leider ja...

Wechsel von Sensormodul 3.8 auf OAM-SensorModule mit SAMD Hardware:

Es gibt keinen Migrationspfad vom (uralten) Sensormodul 3.8 (das war noch VOR OpenKNX) auf OpenKNX-Softwarestand. Die haben (aus ETS-Sicht) leider nichts miteinander zu tun, alle IDs, die für das Update relevant wären, sind komplett unterschiedlich. Für die ETS gibt es da keinerlei "Wiedererkennung".

1. Update auf v1.5.2 der Firmware.

Dieser Schritt ist nicht möglich. Da bleibt Dir nur, alles manuell zu übertragen.

Ganz wichtig: Beim SAMD ist bei der 1.6.2 Schluss! Ich weiß nicht, um wie viele Sensormodule es geht, aber ich habe z.B. alle 20, die ich hatte, gegen die RP2040 ersetzt. Alleine schon wegen Update über den Bus...

Wechsel von reinem Logikmodul zu VPM Big.

Da würde ich noch etwas warten (so bis Weihnachten). Ich werde das Sensormodul (mit VPM) bis dahin neu rausgebracht haben und dann auch für den REG1 verfügbar machen. Immerhin könnte man dort auch Sensoren an den I2C-Bus anschließen. Der eigentliche Grund ist aber Konsolidierung. Ich möchte langfristig (ich denke so in einem Jahr ungefähr) das VPM-Big auslaufen lassen. Alle Funktionen sind jetzt schon im Sensormodul-Big verfügbar, ich möchte, dass man das nimmt. Und wenn man keine Sensoren braucht, wird man in der ETS die Möglichkeit haben, das Modul auszublenden.
Ich will Dir einfach ersparen, in einem Jahr dann eine Migration vom VPM-Big auf Sensormodul-Big machen zu müssen.

Am VPM-Big ist ansonsten nichts falsch, ich will nur die Anzahl der Firmwares und ETS-Applikationen, die ich pflegen und testen muss, etwas reduzieren.

Wenn Du es doch schon jetzt machen willst: An Deiner Beschreibung ist Punkt 1 nicht nötig, sonst stimmt alles. Und es ist der ConfigTransfer . Wir haben auch einen FileTransfer, der macht aber was anderes.

Gruß, Waldemar

[Amenophis]

Hallo Waldemar,

ich überlege ein Teil meiner Hardware in nächster Zeit auf den aktuellen Stand zu bringen. Damit es mir nicht wie Thomas geht, würde ich gerne kurz meine Wege erklären. Ich habe jetzt bei allen Releases entsprechend gelesen und es müsste so passen, dass fast nichts verloren geht.

Wechsel von reinem Logikmodul zu VPM Big.

Ausgangslage:
- Hardware ist ein REG1-Base
- Firmware: [2] 1.4
- Applikation: WP-Logic V1.4

1. Update auf die 1.5.3
-> nötig? Da bin ich mir nicht ganz sicher aber glaube schon, dass nichts verloren geht
2. Update auf 3.1
-> Zeitschaltuhren mit Sonnenauf / -untergang mit +/- beachten. Verlieren ihre Zeitpunkte.
3. Update auf 3.3
-> FileTransfer ist jetzt verfügbar
4. Neues Gerät mit VPM Big aktuelles Release anlegen in der ETS
5. FileTransfer der Logiken vom alten Gerät auf das neue Gerät
6. Parametrieren
7. Altes Gerät löschen, wenn es zu keinen Fehlern gekommen ist

Wechsel von Sensormodul 3.8 auf OAM-SensorModule mit SAMD Hardware:

Ausgangslage:
- Hardware: Rev. 3.0 und Rev 3.1
- Firmware: [3] 8.0
- Applikation: Sensormodul 3.8

1. Update auf v1.5.2 der Firmware.
-> Applikation auch nötig?
2. Update auf v1.6.2 der Applikation, Firmeware bleibt gleich
-> FileTransfer jetzt verfügbar

Habe ich etwas übersehen?

[mumpf]

Meine MDT Dimmaktoren können eine Uhrzeit oder sonnenstandsabhängige Dimmkurve (mit 10 Stützpunkten).. M.E. ist ein Kurvenverlauf im Aktor sinnvoller, als die Tagesphasen des VPM dafür zu nutzen.

Bernhard, ich stimme Dir zu, für sowas würde ich nicht Tagesphasen nehmen. Wie schon von Dir geschrieben, ist die Hauptfunktion das Steuern des Verhaltens des PM und nicht der angeschlossenen Lichtkreise.

Mit den neuen Zeitschaltuhren wird man auch in der Logik Dimmkurven komfortabel abbilden können, indem man per Zeitschaltuhr einen Wert sendet, der am Ausgang in einer Benutzerformel den passenden Lichtwert berechnet. Bei 8 Schaltzeiten hast Du 8 Stützpunkte, mit der Verknüpfung von Zeitschaltuhrkanälen dann auch entsprechend mehr.

Gruß, Waldemar

[henfri]

Ja, ich habe aber aktuell Applikation 1.0 und dann vermutlich auch FW 1.0.


Ich glaube, mein Dali Gateway kann keine Tageszeit abhängen Dimmkurven
DA bleibt mir also wenig übrig. Letztlich Frage ich mich aber auch, wie die Funktieren sollen (Jahreszeiten).

[mumpf]

Die kann ich aber nur über USB aktualisieren, oder?

Nur falls Du die Release-Notes zu 1.6.2. nicht gelesen hast:

Dieses Release ist eine reine ETS-Applikation, die mit der Firmware1.5.2 funktioniert. Sie hat den vollen Umfang von 1.5.2, erweitert um den neuen OpenKNX-Konfigurationstransfer.

Du musst also die 1.5.2 per USB aufspielen!

Gruß, Waldemar

[willisurf]

Meine MDT Dimmaktoren können eine Uhrzeit oder sonnenstandsabhängige Dimmkurve (mit 10 Stützpunkten).. M.E. ist ein Kurvenverlauf im Aktor sinnvoller, als die Tagesphasen des VPM dafür zu nutzen.

Diese steuern das Verhalten des VPM, in Bezug auf Helligkeit, Zeiten etc. Natürlich können Sie auch verschiedene Dimmwerte ausgeben, das ist sicher auch noch sinnvoll, aber eben nicht die Nachbildung einer Kurve.

[henfri]

Normalerweise würde ich das in den Dimmaktoren machen.

Wie meinst du das?

[willisurf]

Aber vielleicht mach ich das jetzt erstmal nur für ein Modell und sammle Erfahrungen

Das ist eine gute Idee.

statt vier Tagesphasen würde ich eine Kurve der Dimmwerte bevorzugen

Normalerweise würde ich das in den Dimmaktoren machen.

Das wäre bei vier Zeitpunkten/Tagesphasen einfach (4 KOs).

neue KOs sind nicht „einfach“ (ich schreibe das mal stellvertretend für Waldemar).

[henfri]

Hallo,

verstehe. Ich wollte eigentlich alle meine PMs um VPMs erweitern. Aber vielleicht mach ich das jetzt erstmal nur für ein Modell und sammle Erfahrungen.
Ein Gedanken noch:
statt vier Tagesphasen würde ich eine Kurve der Dimmwerte bevorzugen. Das scheint dann ja zu Weihnachten zu gehen. Aber es wäre super, wenn man die Sollwerte auch über die Visu statt nur über die ETS ändern könnte. Sonst muss ich das immer machen. Das wäre bei vier Zeitpunkten/Tagesphasen einfach (4 KOs). Aber bei 16 natürlich etwas unübersichtlich. Vielleicht hast du da eine Idee.
Edit: ah, das geht natürlich auch über Szenen heute schon...

Zum 1.6.2: Ich dachte eigentlich ich hätte die Variante schon drauf.. Aber wenn ich auf "aktualisieren" klicke, wird 1.6 gewählt (vermutlich ist das 1.6.2), die ich aber nicht programmieren kann (Firmware stimmt ja noch nicht). Die kann ich aber nur über USB aktualisieren, oder?

Gruß,
Hendrik

[mumpf]

Das ist auch die neuste Version für die SAMD-Version, oder? D.h. einen Konfigurationstransfer gibt es nicht, richtig?

Siehe hier. Das Release 1.6.2 hab ich extra mit Konfigurationstransfer gebaut, damit man migrieren kann. Ein neueres Logikmodul wir es hier aber nicht mehr geben, höchstens Bugfixes bei groben Schnitzern...

Gruß, Waldemar

[mumpf]

Ich versteh nicht ganz, wie das mit dpt5 dann mit einem Kanal geht - gibt man dann den Dimmwert statt einer Szene vor?

Ich hab ja byte geschrieben, das DPT5 war nur, um bei Leuten, die sich nur im KNX-Umfeld bewegen, eine Vorstellung zu erzeugen.
Welchen DPT ein Ausgang sendet, gibt man ja dort vor. Du wirst aber beim Schaltzeitpunkt einen Byte-Wert (und eben nicht 16 oder 32 Bit, dafür reicht der Platz nicht) hinterlegen können, den der Ausgang dann senden kann (ist wie bei einer Konstante an einem normalen Eingang E1 oder E2). Und wenn Du den Wert als Szene (DPT17) sendest, dann ist es eben eine Szene :-) Willst Du einen Dimmwert, dann sendest Du es als DPT5.001. Das ist sehr generisch und bietet viele Möglichkeiten.

Man wird dann auch Zeitschaltuhr-Kanäle "verlinken" können, dass sie wie eine Zeitschaltuhr wirken. Dann hat man also auch welche, die 16 oder mehr Schaltzeiten können. Das wollte ich sowieso mal machen, ich hab jetzt selber die Anwendung dafür und werde das mal angehen.

Gruß, Waldemar

[henfri]

Ich sehe gerade:
Das ist ein SAMD Sensormodul. Es hat noch keinen Konfigurationstransfer (Applikation V1).
Das ist auch die neuste Version für die SAMD-Version, oder? D.h. einen Konfigurationstransfer gibt es nicht, richtig?