OpenKNX-VirtualPresence release (VPM)

[Alloc]

Ich wollte gerade mal versuchen das Problem mit dem Abschalten am PM vorbei in einer rein "virtuellen" Umgebung nachzustellen. Also ein PM-Kanal, der nur mit den nötigsten GA verbunden ist und diese auch nur über die ETS füttern, nicht verbunden mit irgendwelchen anderen Geräten.

Aktuell kann ich mit diesem Setup das Problem, dass durch Aktorstatus=off der Ausgang nochmal angeschaltet wird, nachstellen. Allerdings bisher nur auf dem HF-Sensor mit SensorModule-big-4.2.5, noch nicht auf dem VPM im REG1 mit PresenceModule-big-3.6.2. Da muss irgendwas anders sein - oder ich hab irgendwas nicht richtig abgeglichen Hab aber den PM-Kanal über Export+Import rübergezogen.

Das Problem scheint übrigens nur aufzutreten, wenn der PM-Kanal bei Präsenz überhaupt von allein einschalten würde. Sprich Vollautomat (vermutlich auch Auto-Ein) und aktuelle Helligkeit unter der entsprechenden Grenze. Dann reicht aber wirklich auf das KO Aktorstatus 1 (damit der PM-Kanal aktiv ist) gefolgt von 0 zu senden. Danach sendet er wieder den Einschaltwert und läuft dann wieder bis zur Nachlaufzeit. Natürlich geht alternativ auch normale Präsenz auszulösen, so dass der Kanal aktiv ist, und dann Aktorstatus 0 zu senden.


/EDIT: Unter der Annahme, dass es sonst keine Unterschiede zwischen den beiden Geräten gibt die sich da auswirken - und ich beim Testen nichts falsch gemacht habe - würde ich behaupten, das muss funktioniert haben und somit eine Regression aus dem Commit sein. Bin aber noch nicht ganz durchgestiegen, wann wo welche Bits gesetzt werden

/EDIT 2:
Hier nochmal der Konfig-String für den VPM-Kanal, der bei mir als Test ausreicht:

OpenKNX,cv1,0xA012:0x42/PM:0x36/3§p~Name=Test§p~PresenceInputs=1§p~PhaseCount=2§p~Output1Type=4§p~Output2Type=1§p~ChannelActive=1§p~BrightnessIntern=1§p~Phase3Name=Putzen§p~Phase1Scene=20§p~Phase2Scene=21§p~Phase3Scene=1§p~Scene0=2§p~SceneAction0=16§p~EnableDayPhase=1§p~SignalPresence=1§p~ExternalSignalPresence=1§pA~PresenceDelayBase=0§pA~PresenceDelayTime=30§pA~BrightnessOn=10§pA~Output1OnDim=50§pB~PresenceDelayTime=3§pB~Output1OnDim=6§pB~Output1OffDim=1§pC~PresenceDelayTime=5§pC~BrightnessOn=5000§;OpenKNX

Wie gesagt, einfach an das KO Aktorstatus ne GA anhängen und erst 1 und dann 0 senden, dann müsste man das schon sehen (niedrige Helligkeit vorausgesetzt - hätte ich natürlich auch mal hochsetzen können ). Alternativ in aktive Präsenz gehen so dass der PM angeschaltet hat und dann wieder Aktorstatus = 0.

[Alloc]

Beim Wechsel der Tagesphase wird immer der Wert für "Aus" gesendet. Das bedeutet nun, dass beim Wechsel von Tag auf Nacht 1% an die Lichter gesendet wird und dann erst nach der Logik-Nachlaufzeit wieder das Licht auf 0% geht. Beim Wechsel von Nacht auf Tag dann sogar auf 5% und dann wieder nach 10 Sekunden aus.

Habe das auch gerade nochmal mit dem Minimalaufbau (ohne Logik) überprüft: Es wird wohl bei jedem Phasenwechsel der Wert für Aus gesendet. Im Normalfall (wenn man die Phasen so definiert hat, dass deren Aus-Wert bei Dimmwerten 0% ist) ist das natürlich kein Problem, denn wenn der Aktor aus war und 0% gesendet wird ändert sich nichts. In Kombination mit der Ausschaltverzögerung ist das aber ein Problem, wenn die Phasen so definiert sind, dass sie Dimmwerte > 0% als Aus senden, da jeder Phasenwechsel jetzt eben zu einem (temporären) Einschalten des Lichts führt.

Hier wäre die Frage, ob man das eventuell als Option unterbinden könnte. Oder sogar generell beim Phasenwechsel den Aus-Zustand nicht nochmal sendet. Ich denke zumindest im Kontext von Licht dürfte das keinen Unterschied machen (0% senden wenn das Licht eh aus ist bringt ja nichts), weiß aber nicht, ob da jemand irgendeine komplett "verrückte" Nutzung der Kanäle hat, bei denen man dann wirklich Aus mit Werten ungleich 0/false auf dem Bus braucht (eventuell sogar variierend je nach Phase) und diese somit beim Phasenwechsel gesendet werden müssten.

[willisurf]

Oder sogar generell beim Phasenwechsel den Aus-Zustand nicht nochmal sende

Das beim Wechsel der Tagesphase auch Aus nochmal gesendet wird, ist eine bewusst eingebaute Funktion.
Beispiel:
Normale Tagesphase mit Szene Aus und Ein
Ambientelicht Tagesphase mit Szene z.B. 8% bei VPM aus und ebenfalls Ein

Beim Wechsel der Tagesphase auf Ambiente (oder auch auf Normal) soll auch ohne Präsenz die abweichende Ansteuerung für VPM aus gesendet werden. Das läuft bei mir schon fast 2 Jahre so.

Parallel gibt es ja auch immer noch die Möglichkeit die Tagesphase nicht sofort, sondern erst bei nächster Präsenz umzuschalten.

[mumpf]

Alloc: Danke für Dein Beispiel, ich gucke mir das gleich heute Abend an. Ich will ein Bugfix-Release fürs Sensormodul rausbringen, da passt das dann.

Zum anderen Thema:

Es wird wohl bei jedem Phasenwechsel der Wert für Aus gesendet.

Wie willisurf schon sagte, das ist Absicht. Bei Szenen ist recht offensichtlich, dass man so etwas haben möchte, da einzelne Szenen unterschiedliche Lichtkreise betreffen können. Und bei den anderen Schaltobjekten (bool, dim) stört es nicht, wenn ein AUS gefolgt von einem EIN kommt. Das ist der Stand der Implementierung.

Allerdings stimme ich Dir zu, dass man über eine Auswahl an der Stelle diskutieren kann. Denn einerseits braucht man bei normalen Schaltobjekten das AUS nicht wirklich (ich hab da noch so einen Fall, in den eine Logik noch speziell darauf reagiert, aber das ist eher historisch) und andererseits kann man sich auch eine Szene vorstellen, die selber so agiert, dass sie die nicht benötigten Objekte abschaltet und die benötigten einschaltet. Ich hab einfach das Problem, dass mein DALI-Gateway nur 16 Szenen kann und ich somit versuche, möglichst wenige zu "verbrauchen".

Ich gehe nochmal in mich, aber es wird keine kurzfristige Änderung, ich mach das erst in einem Feature-Release, nicht in einem Bugfix-Release.

Gruß, Waldemar

P.S.: Du kannst aber gerne immer wieder nachfragen, das schadet nichts, das wieder in Erinnerung zu bringen. Noch besser: Issue beim VPM auf github.

[Alloc]

Alloc: Danke für Dein Beispiel, ich gucke mir das gleich heute Abend an.

Gerne. Wenn irgendwas unklar ist oder so einfach melden

Ich gehe nochmal in mich, aber es wird keine kurzfristige Änderung, ich mach das erst in einem Feature-Release, nicht in einem Bugfix-Release.

Klar, das ergibt Sinn. Habe dir mal ein Ticket aufgemacht (mit VPM meintest du die OFM-PM, nicht OAM, korrekt?).

Sind eigentlich Meldungen generell lieber direkt als Tickets erwünscht oder lieber immer erstmal hier ansprechen?

[mumpf]

Sind eigentlich Meldungen generell lieber direkt als Tickets erwünscht oder lieber immer erstmal hier ansprechen?

Lieber hier, häufig kann man das klären und andere bekommen die Probleme auch mit und können manchmal davon lernen. Und wenn es dann wirklich ein Bug ist, dann ist ein issue gut, dann vergisst man es nicht.

Und ja, OFM-PM ist gut. Grundsätzlich sind die Module gut (OFM), die hängen ja in mehreren Applikationen (OAM). Und das Problem ist hier ja beim Modul. In OAM gehören solche Issues wie "auf der Hardware kann ich das nicht installieren" oder "warum kann ich 6 Binäreingänge auswählen, obwohl meine Hardware nur 2 BI hat".

Wenn irgendwas unklar ist oder so einfach melden

Wenn ich nicht klarkomme, machen wir mal ne Session und besprechen das online. Aber lass es mich erstmal so versuchen.

Gruß, Waldemar

[mumpf]

Wie gesagt, einfach an das KO Aktorstatus ne GA anhängen und erst 1 und dann 0 senden, dann müsste man das schon sehen (niedrige Helligkeit vorausgesetzt - hätte ich natürlich auch mal hochsetzen können ).

Ich komme dem Problem näher... Wenn ich auf Deine KO-Liste schaue (für Kanal 3), ist da gar kein Eingang für Helligkeit. Das passiert aber nur, wenn man eine Hardware-Lichtsensor ausgewählt hat und dem Kanal gesagt, hat, dass man die Hardware-Sensoren auswählen kann.

Ich probier noch etwas rum, aber vielleicht kannst Du noch einen Screenshot (oder export) der Allgemeinen Einstellungen vom PM machen.

Gruß, Waldemar

[Alloc]

War leider (in dem Kontext hier ) heute Mittag nicht da, daher erst jetzt:

Wenn ich auf Deine KO-Liste schaue (für Kanal 3), ist da gar kein Eingang für Helligkeit.

Ja, im Abtools Sensor hatte ich den internen Helligkeitssensor verwendet, daher ja das sichergehen, dass es dunkel genug ist (per Rollladen)


Allgemeine Einstellungen:
image.png

Export:

OpenKNX,cv1,0xA012:0x42/PM:0x36/0§LEDPresence=2§LEDMove=1§HfPresence=3§HWLux=1§SendRAW=1§HfDelayTime=3§;OpenKNX

[Alloc]

Hi Waldemar,

wollte nur mal fragen, ob es hier was neues gibt oder ob ich noch irgendwie weiterhelfen kann.


Ansonsten ist mir noch etwas aufgefallen, bei dem ich nicht sicher bin, ob das so Absicht ist oder nicht:
Und zwar wenn der Ausgang eines PM-Kanals bereits "An" ist (egal ob mit N1 oder A1) und man ein "Ein" an "Automatik übersteuern" sendet wird nochmals der Einschaltwert gesendet.

Für meine persönliche Anwendung ist es leider etwas störend, da ich das bisher so hatte, dass der Taster zum Einschalten bei aktivem Licht gleichzeitig dazu dient, den Lichtdimmwert in 25% Schritten zu erhöhen. Nun wird zwar immernoch von der Logik, der 25% erhöhte Wert gesendet, danach aber vom PM wieder der ursprüngliche Einschaltwert gesendet.

LG und ein schönes Wochenende

[mumpf]

Hi, sorry dass ich mich bisher nicht drum kümmern konnte - ich bin derzeit viel unterwegs. Ich werde kommende Woche mehr Zeit haben, mich wieder mit OpenKNX zu beschäftigen und will dann versuchen, alle offenen Problemmeldungen abzuarbeiten.

Muss Dich somit noch um etwas Geduld bitten.

Gruß, Waldemar

[Alloc]

Kein Thema, dachte ich frag nur mal ob es was neues gibt oder man was helfen kann

[Alloc]

Hi, mal wieder eine Frage bezüglich der unterschiedlichen HW-Sensoren im VPM:
Ich habe bisher dort, wo die HW nur den HF-Sensor hat das ganze so eingestellt, dass ich erstmal einen PM-Kanal habe, der *nur* den internen Sensor verwendet und das dann als Schaltausgang bereitstellt.
image.png

Die eigentlichen Licht-PM-Kanäle nutzen dann Intern=Nein, Extern=2*Präsenz. Dabei ist der erste Eingang mit dem Signal von den im jeweiligen Raum installierten PIR-Melder verbunden, der zweite Eingang dann mit dem Ausgang vom "HF-PM" und auf "kann Präsenz nur verlängern":
image.png


Jetzt werde ich in einem Zimmer aber den bestehenden PIR-Melder ersetzen durch den AB-MultiSensor mit eigenem PIR- und HF-Sensor.
Da ist mir jetzt nicht wirklich klar, was die verschiedenen Einstellungen für interne Sensoren bedeuten. Als Optionen gibt es ja "nein", "Bewegung", "Präsenz und Bewegung". Nicht aber zum Beispiel "nur HF-Sensor" oder "nur PIR-Sensor". Der HF-Melder erzeugt ja scheinbar sowohl ein Bewegungs- als auch Präsenz-Signal (zumindest suggeriert das das "Status Bewegung" KO 22 wenn man nur einen HF-Sensor verbaut hat, da dort immer noch zwischendurch True raus kommt).

Gibt es also keine Einstellung, dass ich *nur* den internen PIR-Sensor für einen Kanal verwende, ohne dass die Daten vom HF-Sensor mit verwendet werden?

LG,
Chris

[mumpf]

Hi Chris,

in den aktuellen Applikation ist es nicht möglich, der PIR getrennt von dem HF-Sensor anzusprechen, zumindest nicht als interner Sensor. Ich muss auch gleich sagen, ich weiß nicht, wann ich dazu komme, die Applikation und Firmware nochmal diesbezüglich zu überarbeiten, es nähert sich der Sommer, da sind viele andere Tatigkeiten vorrangig...

Intern führt der PIR immer nur zu einem Bewegungssignal, der HF zu einem Präsenzsignal. Wenn Du bei einem Kanal also nur "Präsenz" wählst, hast Du nur den HF. Der PIR war immer nur als Ergänzung zum HF gedacht, falls der zu langsam auslösen sollte oder so. Da es aber nicht der Fall ist, empfehle ich derzeit nicht wirklich, den PIR zu verwenden - es ist einfach nicht nötig.

Was veranlasst Dich denn, den PIR mit verbauen zu wollen?

Gruß, Waldemar

[Alloc]

Hi Waldemar,

danke für deine Antwort!

Was veranlasst Dich denn, den PIR mit verbauen zu wollen?

Ein Wort: Trockenbauwände
Wobei vermutlich noch mehr Gründe dazukämen, bisher konnte ich ja noch nicht testen, wie er an der Zielposition reagieren würde. Aber er wäre halt nah bei Backofen, Mikrowelle, Dunstabzug und diesen Radius könnte ich nicht ausblenden, da dann auch der Esstisch raus wäre.

HF und PIR haben halt immer beide ihre Vor- und Nachteile. PIR ist halt in so fern schön, als er wirklich nicht über Raumgrenzen hinaus reagiert (außer sowas wie offene Tür natürlich) und auch eher weniger auf Geräte etc reagiert. Daher finde ich die Variante "Aktivieren eines PM nur über PIR, Halten dann auch über HF" halt sehr nützlich.

LG,
Chris

[mumpf]

Daher finde ich die Variante "Aktivieren eines PM nur über PIR, Halten dann auch über HF" halt sehr nützlich.

Ich kann mir schon vorstellen, so einen Modus mal einzubauen, aber sicherlich nicht mehr vor dem Sommer. Tut mir leid...
Du willst doch einen PIR ersetzen. Ist der so dezentral angebracht, dass Du denkst, dass alles drumherum auslöst? Ich konnte den HF bisher für jeden Raum anpassen - und meine frühere Befürchtung mit der Küche hat sich überhaupt nicht bestätigt.

Ich persönlich würde dem eine Chance ohne PIR geben. Ich kann zwar nichts garantieren, aber ich bin relativ zuversichtlich, dass es auch so geht.

Gruß, Waldemar