OpenKNX-VirtualPresence release (VPM)

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

Kann das Diagnoseobjekt nicht helfen?

Sicher, Beschreibung ist hier

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

[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

[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

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

[mumpf]

So, jetzt mal ein paar Antworten, was gestern nur mit Handy unterwegs...

Also z.B. „vpm p01s“

Nein, bei der SAMD-Version ist es noch ohne vpm vorweg.

Aktuell bin ich wohl im manuellen modus (M1 D33).

Ja, Licht ist manuell an, Du bist in Tagesphase 3 und wenn das Licht ausgeht, bleibt der Melder in Phase 3.

Meine aktuelle Vermutung ist, dass Du auch über Manuell ausschaltest und dann erwartest, dass das Licht über Präsenz/Helligkeit angeht (M0 in Diagnose). Manuell bedeutet aber eben KEIN Automatik. Du musst den Melder in den Automatikmodus versetzen, damit er was automatisch macht.

Dabei werden ja alle Zeitschaltuhren nachgeholt und senden ein EIN

Natürlich muss man, wenn man Schaltzeiten nachholen will, auch die AUS-Zeiten bei allen Zeitschaltuhren definieren . Bei mir funktioniert das hinreichend, ich hatte hier letztens jemanden, der ein Beispiel hatte, bei dem es nachvollziehbar nicht gehen konnte - ich komme nur nicht drauf. Du kannst mal schauen, ob es bei Dir erstmal ausreicht.

Es wird aber aus diesem Grunde noch eine Erweiterung bei den Zeitschaltuhren geben, die das Handling vereinfacht.

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

Die sind alle reine Semantik, technisch nicht relevant. Die ETS nutzt die Einstellung am KO, um

• bei der Erstzuweisung einer GA der GA den selben DPT zu geben
• bei der Zuweisung der GA an weitere KO für Warnungen, dass unterschiedliche Subtypen zugewiesen werden

Technisch relevant ist nur die Länge des KO. Ich versuche immer, bei allen Geräten den korrekten (erwarteten) DPT an allen KO zu haben.

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

Es ist offensichtlich, dass es z.B. beim Logikmodul nicht geht, den korrekten DPT auszuliefern. Aber sobald z.B. ein Ausgang über GA mit seinem Ziel verbunden ist, kann man zur korrekten Anlagendokumentation die DPT an den KO anpassen. Gleiches gilt für Hersteller, die sich um den DPT nicht hinreichend kümmern, dann kann der User das nachholen.
Und nein, es gibt keine Geräte, die das beachten, denn das wird gar nicht beim Programmieren übertragen.

Gruß, Waldemar

[mumpf]

Heute war es leider wieder soweit, der Feiertag wurde nicht berücksichtigt und ich finde keinen Fehler. Bitte um Hilfe.

Hi,

hat zwar etwas gedauert, aber ich hab es jetzt gefunden. War ein Denkfehler. Ich habe bei der Suche der Zeitpunkte (bei der Sonntagsbehandlung) zwar bei einem Sonntag-Zeitpunkt diesen genommen (egal welcher Wochentag aktuell gültig ist), aber nicht verhindert, dass ein zum Wochentag passender Zeitpunkt verworfen wird, falls er früher gefunden wird. Das wird in der nächsten Version korrigiert sein (Logikmodul 3.4).

Was als Workaround bis zum Release gehen müsste:

• Du machst den Sonntagstermin in eine eigene Zeitschaltuhr, bei der Du "Feiertage wie Sonntage schalten" einstellst.
• An der bisherigen Zeitschaltuhr stellst Du "An Feiertagen nie schalten" ein und löscht da den Sonntag raus.

Ich bin mir allerdings sehr sicher, dass die neue Version noch vor Weihnachten erscheint, dann musst Du nur dafür sorgen, dass Du vorher ein Update machst.

Gruß, Waldemar

[henfri]

Hallo,

es war tatsächlich der manuelle Modus. Das lag aber nicht daran, dass ich übersteuert hätte, sondern darauf, dass ich den Aktor-Status auf den Eingang für die Manuelle Bedienung gelegt habe (in der Zeile verrutscht)

War gar nicht einfach zu finden :-)

Jetzt hab ich aber noch ein Problem:
Sitzt man auf dem Klo, geht das Licht aus.
Nachlaufzeit ist vier Minuten, Handy war aber nicht in der Hand , sprich: Das ist nach gefühlt 30s schon ausgegangen. Was mache ich falsch?

ETS6N_LNMCr3SD3e.png
Den Hardware-PM habe ich auf kurze Nachlaufzeit gesetzt.
Auch habe ich geprüft, dass der PM nicht mehr direkt mit dem Licht verknüpft ist.
Es ist der VPM der abschaltet:
chrome_tTx59xJp44.png

Gruß,
Hendrik

[traxanos]

Du hast das Problem das du helligkeitsabhängig arbeitest. Sobald das Licht eingeschaltet wird, steigt die Helligkeit an und du kommst über die Schwelle. Dann läuft die Ausschaltverzöggerung die bei dir mit 30s angegeben wurde. Du musst wenn ich das richtig sehen, sagen wieviel heller der Raum werden darf und dass muss die Helligkeit der Beleuchtung inne haben. 100 Lux sind da sicher zu wenig

[willisurf]

Handy war aber nicht in der Hand

Versuch auch mal das nachzustellen und direkt zu beobachten. Mit der Diagnose hast Du jetzt Werkzeuge das direkt live zu beobachten und zu analysieren. Falls nicht bereits bekannt und ein iOS Handy vorhanden, EasyKNX ist dazu das ideale Werkzeug.

[henfri]

Ok, mache ich.

Noch eine Frage:
Ich habe zusätzlich zur Präsenz, die das Licht einschalten soll einen Reed, der das Licht anschalten soll.
Wenn der Reed aber wieder Aus geht, soll erst abgeschaltet werden, wenn der PM abschalten würde (warum auch immer er abschalten würde).

Ich hatte überlegt, den Reed auf "Automatik Modus übersteuern" verknüpfe. Aber dann würde der Reed auch abschalten.

Also brauche ich einen Logik-Kanal zwischen Reed und VPM, oder?

Gruß,
Hendrik

[traxanos]

Ich habe sowas in der Art auch mit der Hauseingangstüre gemacht. Ich möchte das beim öffnen sofort das Licht angeht, bevor der PM mich erkennt. Dazu kannst du einfach den externen Eingang nutzen.

[gbglace]

Ja vom Prinzip her REED gaukelt dem PM Bewegung vor.

[henfri]

Ach ja, wie naheliegend...

Wobei - und das hatte ich nicht gesagt: Der Reed soll helligkeitsunabhängig sein - Präsenz allgemein nicht.

Habt ihr dafür auch eine Lösung?