OpenKNX-VirtualPresence release (VPM)

[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

[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]

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

[Stereofeld]

Damit es mir nicht wie Thomas geht, ...

[Stereofeld]

[...] sonst stimmt alles.

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

[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

[Amenophis]

Mmmh ich hatte etwas befürchtet, dass du mir sagen könntest, dass ich vom Sensormodul 3.8 nicht auf die andere Version wechseln kann. Denn ich habe genau das vor, alleine meine Sensormodule gegen neue mit RP2040 zu tauschen und hatte gehofft hier den ConfigTransfer (nicht FileTransfer, danke für die Korrektur) nutzen zu können

Na gut, ich lese raus, dass ich nun Zeit habe die alten Module händisch auf RP2040 zu wechseln und wenn ich damit fertig bin noch einen Moment warte, bis du den Rest zusammen geführt hast. Aktuell habe ich da keine Eile, daher danke für den Tipp und die Rückmeldung

[mumpf]

Na gut, ich lese raus, dass ich nun Zeit habe die alten Module händisch auf RP2040 zu wechseln und wenn ich damit fertig bin noch einen Moment warte, bis du den Rest zusammen geführt hast.

Da haben wir uns Missverstanden. Sensormodul 3.8 würde ja auf OpenKNX-Sensormodul 3.2.x gehen - da musst Du nicht warten, das ist ja schon verfügbar, natürlich auch für die Sensormodul-Hardware von Masifi.

Bei Deinem Versuch, das Logikmodul auf 1.4.2 auf Presence-Big zu migrieren solltest Du es auch gleich auf ein Sensormodul 3.2 migrieren (hier geht das mit ConfigTransfer). Nur ist das Sensormodul 3.2 derzeit nicht für die REG1-Base verfügbar. Das wird dann mit 3.3 gehen. Deswegen noch warten bzw. gedulden, bis die 3.3 verfügbar ist. Von 3.2 auf 3.3 ist es dann nur noch ein Update-Click in der ETS.

So gesehen kannst Du mit beiden Migrationen sofort beginnen, die eine wird aber erst später auf das REG1 bespielbar sein.

Gruß, Waldemar

[henfri]

Hallo,

ich habe einen VPM konfiguriert (unten der Konfigurations-String; Hardware ist SAMD, Firmware 1.5.1, Applikation 1.6.2), der aber nicht (immer) das macht, was ich erwarte.
Beispielsweise schaltet er gerade nicht ein - ich habe die Tagesphase 1 gesetzt und eine 1 auf den Präsenzeingang gesendet.
Ich habe leider keine Dokumentation über das Diagnoseobjekt des VPM gefunden. Wo finde ich die?

Ich habe den Helligkeitswert im Verdacht. Im Busmonitor wurde DPT 7.013 vorgewählt. Dabei war der Lux-Wert >4000. Wenn ich manuell DPT 9.004 wähle, dann ist der Lux-Wert plausibel.

Jetzt muss ich zugeben, dass ich nicht weiß, was bei der Einstellung des DPT in der ETS ausschlaggebend ist:
- Die Einstellung beim sendenden/empfangenden KO
- Die Einstellung bei der GA

Leider finde ich nicht, welcher DPT vom VPM für die Helligkeit erwartet wird.
In der Dokumentation zum PM (BEG PD11) findet sich nur, dass das KO 2byte ist - nicht aber welcher DPT gesendet wird.

Davon ab: Seht ihr eine andere mögliche Ursache?

Gruß&Danke,
Hendrik

OpenKNX,cv1,0xA040:0x16/PM:-/0§;OpenKNX
OpenKNX,cv1,0xA040:0x16/PM:-/1§p~Name=Elternbad§p~PresenceInputs=1§p~PhaseCount=3§p~Output1Type=4§p~ChannelActive=1§p~LockType=2§p~LockOn=2§p~LockFallback=1§p~StartReadLux=1§p~StartReadPresence1=1§p~StartReadAktorState=1§p~StartReadLock=1§p~StartReadDayPhase=1§p~StartReadScene=1§p~LockFallbackTime=2§p~NumLux:1=90§p~NumPresence1:1=91§p~NumSetAuto:1=93§p~NumSetManual:1=94§p~NumActorState:1=95§p~NumLock:1=96§p~NumReset:1=97§p~NumDayPhase:1=98§p~NumScene:1=102§p~EnableLux=1§p~EnableDayPhase=1§p~SignalPresence=1§p~ExternalSignalPresence=1§pA~BrightnessAuto=1§pA~PresenceDelayTime=2§pA~BrightnessOn=150§pB~PresenceDelayTime=2§pB~Output1OnDim=1§pC~BrightnessAuto=1§pC~PresenceDelayTime=2§pC~Output1OnDim=30§pD~BrightnessAuto=1§pD~Output1OnDim=15§;OpenKNX

[mumpf]

Leider finde ich nicht, welcher DPT vom VPM für die Helligkeit erwartet wird

Das steht direkt am KO:
VPM-DPT-Helligkeit.png
Du kannst bei jedem KO in den Eigenschaften auch genau nachschauen. Was der BEG sendet, weiß ich nicht, aber falls es 7.013 ist, wird es nicht funktionieren. Und das ist komplett unabhängig von dem, was Du in der ETS einstellst, denn auf dem Bus wird immer ohne einem DPT gesendet.

Du solltest es aber über das Logikmodul von 7.013 auf 9.004 konvertieren können. Ob es wirklich daran liegt, kannst Du daran sehen. dass Du mal selber über den Gruppenmonitor 9.004-Werte auf die Helligkeit sendest und schaust, ob es dann geht.

Deinen Config-String kann ich erst morgen ansehen, ich bin derzeit nicht zu Hause.

Gruß, Waldemar

[henfri]

Hallo Waldemar,

keine Eile.
Der BEG scheint 9.004 zu senden. Wenn ich DPT9.004 im Busmonitor einstelle sind die Werte jedenfalls plausibel.

Warum kann man denn am KO den DPT überhaupt ändern - gibt es Geräte, die das beachten?

Edit:
Der Wert, der vom PM kommt ist 0D DC. Das wären 30 Lux. Das passt doch.
Dennoch hab ich den VPM jetzt dazu gebracht anzuschalten, indem ich ihn helligkeitsunabhängig gemacht habe..

Gruß,
Hendrik

[henfri]

Derzeit noch, ja. Je nach Version des Logikmoduls kannst Du mit den neusten Versionen auch die KO (auch die Ausgänge) intern verknüpfen, aber es sind noch 4 Kanäle.

Hier hab ich gerade noch ein Problem:
Ich habe eine GA für die Tagesphase. Die ist mit dem Ausgang der vier Kanäle verknüpft.
Jeder Kanal hat eine Zeitschaltuhr mit einem Schaltpunkt - dann wenn die Szene aktiv werden soll - Szenen müssen ja nicht abgeschaltet werden.
Wenn ich jetzt aber auf die Tagesphasen-GA lese, dann antworten natürlich alle Kanäle.

Ich könnte natürlich jetzt dann, wenn die nächste Phase beginnt das KO auf Aus stellen. Aber dann muss ich bei einer Änderung der Phasen an zwei Kanäle und die immer synchron halten - das wird eh schiefgehen.

Gibt es da eine elegantere Lösung?

Gruß,
Hendrik

[willisurf]

Du musst dazu nur die Flags der 4 Ausgangs KOs anpassen, sodass quasi einer der Master ist, der von allen anderen beschrieben werden kann (S-Flag) und dann auch konsistent auf ReadRequest antwortet (L-Flag).

Wenn das z.B. Kanal 1 ist sind die Flags an den Ausgängen folgende:
bei Kanal 1 KLSÜ
Kanal 2-4 nur KÜ

Das die Logikkanäle nur ein EIN senden und sich gegenseitig ausschließen setze ich mal voraus.

[henfri]

Ich wusste, dass es eleganter geht. Ausprobiert und funktioniert.
Bleibt nur mein ursprüngliches (Helligkeits) Problem.

[willisurf]

Das sollte sich doch mit Beobachtung/Tests im Gruppenmonitor und ggf. Konvertierung eines falschen DPT in einem weiteren Logikkanal lösen lassen.