OpenKNX-VirtualPresence release (VPM)

[mumpf]

Gibt es hier keine Möglichkeit der verringerten Helligkeit vor dem Ausschalten?

Nein, das hab ich nicht gemacht, ich arbeite lieber daran, im Zusammenhang mit unserem HF-PM, dass es nicht notwendig ist, vorzuwarnen - weil das Licht einfach nicht unerwartet ausgeht .

An sich sollte sich das durch einen Logikkanal lösen lassen. Folgende Idee (hab ich nicht ausprobiert):

• Dein PM sendet bei EIN irgendeinen Dir genehmen Dimmwert (z.B. 80%), bei AUS den Vorwarn-Dimmwert, z.B. 30%.
• Über das 2. KO sendet er normal EIN und AUS für die Logik.
• Dieses 2. KO gibst Du auf einen Logikeingang (einfaches OR mit einem Eingang).
• Der Ausgang der Logik ist mit einer Ausschaltverzögerung von z.B. 15s konfiguriert, Rest bleibt bei den Default-Einstellungen.
• Der Ausgangskonverter sendet bei EIN gar nichts, bei AUS die 0% für AUS.

Was jetzt passiert: Der PM schaltet EIN, das Licht geht auf 80%, die Logik geht auf EIN, macht aber gar nichts. Wenn der PM ausschaltet, geht das Licht auf 30%, die Logik geht auf AUS und startet die Ausschaltverzögerung. Wenn in den 15 Sekunden wieder ein EIN erfolgt, geht die Logik wieder auf EIN und es passiert gar nichts.
Wenn die 15s abgelaufen sind, sendet die Logik ein AUS und somit den Dimmwert 0%.

Wenn Du über Taster - also PM "auto AUS" - ausmachst, passiert genau das gleiche, der PM sendet 30% und die Logik sendet 15s später 0%.

Gruß, Waldemar

P.S.: Das ist der Grund, warum es in (fast) jedem Gerät bei uns eine Logik gibt. Man muss nämlich nicht jeden "Scheiß" in die Applikation einbauen, so einfache Wünsche wie verzögertes Ausschalten sind sehr generisch und lassen sich individuell über Logik lösen. Würde ich das so in die Applikation bauen, wie Du das möchtest, wird der nächste kommen und sagen, beim AUS über Taster soll aber sofort ausgehen, nicht verzögert. Und der nächste sagt, ich möchte nicht dunkler, ich möchte blinken usw. usw.

[knxlog]

Nachdem ich mal meine TPs und MDTs BWM kombiniert habe im VPM. Vermisse ich noch zu jedem angelegten VPM ein Helligkeitsunabhängiges Präsenzsignal für Displays. Habe ich da was übersehen, oder muss ich nochmal für jeden Raum einen weiteren VPM anlegen?

Bisher aber ein großes Lob, die Applikation ist einfach extrem gut. Bin leider auf den TP angewiesen da er extrem gut schlafende Personen erkennt obwohl er bei mir an der Wand hängt und unser Kleinkind sein Bett direkt darunter hat. Sonst würde ich komplett auf eure HF PMs umsteigen.

[mumpf]

Habe ich da was übersehen, oder muss ich nochmal für jeden Raum einen weiteren VPM anlegen?

Die Philosophie ist: 1 Kanal -> 1 Funktionalität
Also ja, Du musst noch einen Lichtunabhängigen Kanal anlegen.
Da solche Kanäle aber sehr ähnlich von der Konfiguration sind, kannst Du Dir mit dem Konfig-Transfer viel Arbeit ersparen, wenn Du Dir die Kanäle kopierst und nur die Änderungen anpasst.

Gruß, Waldemar

P.S.: Danke für das Lob.

[Alloc]

Hi Bernhard und Waldemar,

erst einmal vielen Dank für eure Tipps!
Aus meiner persönlichen Anwendersicht finde ich es natürlich immer schön, wenn meine Anwendungsfälle direkt unterstützt werden, da man dann weniger zusammen bauen muss und es auch leichter bleibt, die Übersicht zu behalten. Gerade aus Entwicklersicht verstehe ich aber natürlich, dass man gerne alles, was sich über eh vorhandene universelle Module abbilden lässt, nicht nochmal extra einbaut. Ist natürlich wie Waldemar schon schrieb immer, dass dann noch jemand kommt und wieder andre Wünsche hat und man letztlich halt auch Funktionalität mehrfach warten muss.

... dass es nicht notwendig ist, vorzuwarnen - weil das Licht einfach nicht unerwartet ausgeht ...

Das gilt natürlich für den Fall "nicht mehr erkannte Anwesenheit", aber nicht für den Fall (den ich sehr schätze) des manuellen Ausschaltens mit Verzögerung. Wobei man da dann wiederum sicher etwas bauen könnte, dass eben dieses Ausschaltsignal an sich verzögert wird
Aber inzwischen spiele ich selber für die reine Anwesenheitserkennung durchaus auch mit dem Gedanken, mehr Räume noch mit HF-Meldern auszustatten - und eventuell auch mal irgendwann die drei verbauten TPM zu ersetzen, wobei die *bisher* noch relativ zuverlässig arbeiten (hatte bisher keine Erkennungsprobleme (mitbekommen), allerdings ist zumindest über der Couch der Melder ab und an mal rot am Blinken gewesen für ein paar Sekunden/Minuten).


Zurück zum zweistufigen Ausschalten:
Die Idee mit dem zweiten PM-Kanal klingt erstmal natürlich interessant, und bei 40 VPM-Kanälen sicher auch vertretbar. Allerdings bedeutet das auch, dass man die Einstellungen bei jeder Änderung synchron halten muss (zum Beispiel weil sich die Zeiten ändern). Insbesondere hab ich aber Bauchschmerzen dabei, zwei "konkurrierende" Treiber für ein Licht zu haben, bei denen man sich dann darauf verlassen muss, dass sie exakt synchron laufen. Nicht zuletzt auch, weil ja die Zustände der Kanäle dann nicht mehr dem tatsächlichen Zustand entsprechen können (PM 1 denkt "ist aus", PM 2 denkt "ist an", Aktor sagt "ist an").

Die Variante mit dem Logikkanal finde ich aber top. Da muss man erstmal drauf kommen, aber eigentlich ist es dann ja simpel. Wie so oft braucht es nur den richtigen Impuls

Nur nochmal um abzuklären, ob das alles so passt: Das wäre nun meine Umsetzung auf der Logikseite:

OpenKNX,cv1,0xA002:0x36/LOG:0x35/1
f~Logic=2
f~E1=1
f~E1Dpt=2
f~E1OtherKO:2=63
f~E1DefaultExt=2
f~E1UseOtherKO=1
f~E1LowDpt5:1=1
f~ODelayOffBase=0
f~ODelayOffTime=15
f~ODelay=1
f~ODpt=2
f~OOn=0
f~OOnAll=0
f~OOffKOSend=1
f~OOffKOSendNumber=63
;OpenKNX​

Also ODER mit einem Eingang, Eingang und Ausgang wie folgt:
image.png

image.png

Hier wäre vor allem die Frage, ob ich die Verbindung bei Ein- und Ausgang so direkt über das absolute KO des PM-Ausgang (KO 63, eingestellt auf Prozentwert, also DPT 5) nutzen kann. Insbesondere beim Schreiben des Logikergebnisses, da wird dann vermutlich immer noch ein Senden des Wertes auf den Bus getriggert?

P.S.: Das ist der Grund, warum es in (fast) jedem Gerät bei uns eine Logik gibt. Man muss nämlich nicht jeden "Scheiß" in die Applikation einbauen, ...

Absolut nachvollziehbar Ich frage mich sowieso immer, warum Hersteller da recht wenig spendieren. MDT hat zwar zum Beispiel in den meisten Geräten (die ich getestet habe) Logiken drin, aber das sind dann meist gerade mal vier und diese können dann auch nur ganz einfaches UND/ODER mit Ausgangsfilter und das war es auch schon. Und das Logikmodul ist zwar nett und kann recht viel, aber 20 Kanäle sind dann auch nicht sooo viel, da hab ich 3/4 schon voll.

Was ich bisher gesehen habe gefällt mir hier jedenfalls schon sehr gut, auch wenn ich sicher nochmal die ein oder andre Frage haben werde

Danke,
Chris

[mumpf]

Hier wäre vor allem die Frage, ob ich die Verbindung bei Ein- und Ausgang so direkt über das absolute KO des PM-Ausgang (KO 63, eingestellt auf Prozentwert, also DPT 5) nutzen kann. Insbesondere beim Schreiben des Logikergebnisses, da wird dann vermutlich immer noch ein Senden des Wertes auf den Bus getriggert?

Hi Chris, die Idee ist grundsätzlich korrekt, wird aber nicht funktionieren. Der Eingangskonverter sendet ein EIN, wenn der Dimmwert 1-255 ist. Also nur bei 0 AUS. Aber der PM muss nach seiner Ablaufzeit runterdimmen, z.B. auf 30%. Und dann muss der Eingangskonverter ein AUS an die Logik senden, damit die Ausschaltverzögerung wirken kann. Der Wertebereich sollte somit (in dem Beispiel) von 31-100 gehen. Du solltest auch mit DPT 5.001 arbeiten, wenn Du mit Prozentzahlen hantierst (oder entsprechend umrechnen).

Und das Sendeverhalten der Logik (nicht des Ausgangs) muss "nur bei Änderung" sein, so vermeidest Du Zyklen innerhalb der Logik, da Du Ein- und Ausgang gekoppelt hast.

Gruß, Waldemar

[Alloc]

Der Eingangskonverter sendet ein EIN, wenn der Dimmwert 1-255 ist. Also nur bei 0 AUS. Aber der PM muss nach seiner Ablaufzeit runterdimmen, z.B. auf 30%.

Stimmt, das hab ich natürlich übersehen. Da ich das aber nicht an die Helligkeit koppeln will (z.B. weil verschiedene PM-Phasen verschiedene Ausschalthelligkeiten haben) würde es vermutlich Sinn ergeben einfach den zweiten Ausgang des PM zu nehmen, der dann nur schaltend wäre. Dann wäre der Eingang der Logik intern verbunden mit dem zweiten Ausgang des PM (also KO 64), und der Ausgang der Logik intern verbunden mit dem ersten Ausgang des PM (KO 63). Das sollte dann so funktionieren wie gewünscht, oder?

[mumpf]

Genau. Das mit dem 2. Ausgang war auch mein ursprünglicher Vorschlag. Dafür ist er gedacht gewesen: zusätzliche Aktionen zu triggern, unabhängig von dem eigentlichen Objekt.

Gruß, Waldemar

[willisurf]

Und das Logikmodul ist zwar nett und kann recht viel, aber 20 Kanäle sind dann auch nicht sooo viel,

Ich überlege gerade, warum nur 20. Hast Du als Hardwarebasis noch den SAMD?
Wenn es bereits der RP2040 ist, könntest Du die Big Variante nehmen und hättest dann 99 Logikkanäle.

Und früher oder später möchte man das sowieso raumweise haben. Wegen der Übersicht, der Nutzung von internen Verknüpfungen (geht natürlich bei einem Modul auch) oder letztlich wegen Separierung und Redundanz.

[Alloc]

Das mit dem 2. Ausgang war auch mein ursprünglicher Vorschlag.

Das hatte ich vorher überlesen. Aber dann passt das ja alles und ich denke ich habe nun auch einen guten Überblick, wie das Teil arbeitet. Bin mal gespannt, wo die Reise bei mir damit hin geht

Ich überlege gerade, warum nur 20. Hast Du als Hardwarebasis noch den SAMD?

Nein nein, beim REG1 habe ich schon das große Logikmodul. Der zitierte Text bezog sich auf das MDT Logikmodul

[Alloc]

Hi, nochmal eine Umsetzungsfrage:
Wir haben hier eine "Putz"szene, bei der alle PMs alle Lichtkreise als Vollautomaten ansteuern damit man in jedem Raum (bei Anwesenheit) maximale Helligkeit hat.
Ich habe es bisher bei den MDT PM entsprechend so gelöst, dass das jeweils ein eigener Lichtkanal war, und dann bei Szene Putzen entsprechend diesen Freigegeben und dafür den normalen Kanal gesperrt (und umgekehrt bei Aufhebung des Modus).

Hier könnte ich zwar wahrscheinlich eine Phase im normalen PM-Kanal nehmen, aber vermutlich wäre es auch hier sinnvoller das zu trennen?


Gibt es bei dem Modul eine Möglichkeit PM-Kanäle beim Reset zu Sperren? Bisher muss ich bei jedem Programmieren immer einmal die "nicht-Putzen"-Szene senden, damit die Sperre des zusätzlichen Lichtkanals gesetzt wird. Das würde ich mir gerne sparen, sehe aber nichts in der Richtung.

Auch hier wäre dann der nächste Gedanke einen Logikkanal zu nutzen, der nach Reset dann die Szenennummer "sendet". Ein "Gerät gestartet" Signal gibt es ja scheinbar nicht und das "In Betrieb" kommt ja dann zyklisch, man will aber nicht zyklisch die Szene neu senden. Kann ich einen Logikkanal so missbrauchen, dass er einmalig einen Wert sendet? Ich dachte an einen Kanal mit einem Eingang, dessen KO nicht verbinden, dafür aber mit einem Wert (1) vorbelegen. Dann am Ausgang die Szene senden. Das Vorbelegen müsste ja einmalig die Logik auswerten und ein Ergebnis senden, danach aber still bleiben bis zum nächsten Reset?

[mumpf]

Ich dachte an einen Kanal mit einem Eingang, dessen KO nicht verbinden, dafür aber mit einem Wert (1) vorbelegen. Dann am Ausgang die Szene senden. Das Vorbelegen müsste ja einmalig die Logik auswerten und ein Ergebnis senden, danach aber still bleiben bis zum nächsten Reset?

Genau so... bis auf eine Kleinigkeit. Du musst mit 0 Vorbelegen und den Eingang "invertiert aktiv" machen. Ist ein Bug, dass es mit der 1 nicht klappt. Da die 0 ein Workaround ist, hab ich mich noch nicht aufgerafft, es zu korrigieren. Über die Verzögerungszeit des Kanals oder die Einschaltverzögerung in der Ausgangspipeline kannst Du steuern, wie lange nach dem Einschalten die Szene gesendet wird.

Aber eine Tagesphase dafür zu nutzen - zumindest wenn man noch eine frei hat - ist meiner Meinung nach einfacher und eleganter.

Gruß, Waldemar

[thilog]

Hallo zusammen,

ich habe inzwischen den VPM für das automatische Schalten der Schlafzimmerbeleuchtung im Einsatz und sperre den Kanal über einen Bettpräsenzmelder, damit nachts nicht ständig das Licht schaltet. ;-) Dummerweise kommt mir dabei der Tagesphasenwechsel in die Quere, d.h., dieser wertet die Sperre nicht aus und schaltet beim Tagesphasenwechsel um 6 Uhr morgens das Licht an... Suboptimal. ;-)

Ideen?

P.S.: Das ganze tritt mit der aktuellen Version 3.62 auf, genauso aber mit der 1.11.3.
P.P.S.: Die Konfiguration der 3.x in der ETS ist echt hübsch geworden! :-)

[traxanos]

den wechselt der tagesphase ggf durch ein tor gatter schicken? das wäre jetzt so meine idee ohne es je getestet zu haben.

[thilog]

den wechselt der tagesphase ggf durch ein tor gatter schicken? das wäre jetzt so meine idee ohne es je getestet zu haben.

In der Theorie klingt das gut, ich werde berichten, ob die Praxis das ähnlich sieht. ;-)

[willisurf]

wertet die Sperre nicht aus und schaltet beim Tagesphasenwechse

Ich habe den Fehler nachvollzogen. Waldemar wird sich sicher dazu melden.
Dann gibt es wahrscheinlich auch eine Empfehlung für einen Workaround.

Ich nutze Sperren gar nicht, daher habe ich den Fehler bei den Tests der Folgereleases nicht bemerkt. Durch die flexiblen Tagesphasen komme ich ohne Sperren aus, aber jeder gefundene Fehler ist ein guter Fehler.