OpenKNX-VirtualPresence release (VPM)

[willisurf]

Eventuell musst Du auch schon bei dem Stand dem Diagnosekommando ein „vpm „ voranstellen.
Also z.B. „vpm p01s“

Die Werte der Erklärung oben in [] bedeuten ein Element aus der aufgezählten Liste. Ich denke das wird klar, wenn Du verschiedene Diagnoseantworten siehst.

[henfri]

Hallo,

Waldemar hat Recht.
Zum Diagnose-Objekt: Aktuell bin ich wohl im manuellen modus (M1 D33). Vermutlich weil das Licht manuell eingeschaltet wurde.

Kann ich dem PM denn irgendwie entlocken,welche Helligkeit er verwendet?
Sorry, ich verstehe das hier nicht:

Die Interpretation der Ausgabe ist
Statusausgabe PM Kanal:
Kommando: p<nn>s

// "[NAM][01] A [1-4](1-4] [L-][H-][X-][R-][T-]"
// N=normal, A=auto, M=manual
// 0=off, 1=on
// D=day phase
// 1-4=current phase
// 1-4=next phase
// L=is lock, -=unlock
// H=in helligkeitsberechnung, -=normal
// X=disable brightness handling, -=normal
// R=leave Room is active, -=not active
// T=in totzeit, -=normal​

Diese Informationen habe ich ihm nicht entlocken können. Es kommt bei p01s nur o.g. Ausgabe.

Gruß,
Hendrik

[mumpf]

Firmware ist wahrscheinlich 1.5.2, Applikation ist 1.6.
Applikation direkt man in der ETS unter Eigenschaften-Information-Applikation, Firmware in der Geräteinfo.

Gruss, Waldemar

[willisurf]

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.

Bist Du sicher, das die Versionen so stimmen?

[willisurf]

Kann das Diagnoseobjekt nicht helfen?

Sicher, Beschreibung ist hier

[henfri]

Hallo,

es hat doch nicht geklappt. Ich glaube, das ist ein Problem des Geräte-Neustart. Dabei werden ja alle Zeitschaltuhren nachgeholt und senden ein EIN. Da gewinnt dann der letzte / höchste Kanal.

ggf. Konvertierung eines falschen DPT in einem weiteren Logikkanal lösen lassen.

Aber der DPT ist ja nicht falsch - der VPM will ja auch DPT 9.

Kann das Diagnoseobjekt nicht helfen?

Gruß,
Hendrik

[willisurf]

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

[henfri]

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

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

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

[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

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

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]

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

[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