OpenKNX-VirtualPresence release (VPM)

[willisurf]

Ja, die Lichtkreise lassen sich sehr universell für alle möglichen zeit-/ präsenz-/ und aktionsabhängigen Steuerungen einsetzen. So werde ich wohl für die Steuerung dsr Spots über der Kochmulde die Stromaufnahme des Kochfeldes auf den Hellogkeitseingang geben.

[traxanos]

Das ist wieder ein neues Thema. Mir fehlt daher ein dritter Eingang auf dem VPM, welches sozusagen eine Präsenz anzeigt, aber nicht das Licht einschaltet. Das kann man dann z.B. für ein Kochfeld nutzen, oder aber auch z.B. für eine Präsenzmelder wie dem TruePM.

Beispiel: Wir haben einige PMs in der Decke. Die lösen leider bei unserem Holzständerhaus wenn man nur die Haustüre öffnet. Dahewr haben wir das mit BWM in der Wand kombiniert. Gleiches gilt halt auch für den TPM im Bad. Aktuell sperre ich die PMs umständlich, aber besser wäre es, wenn die Infos direkt an den VPM gehen würde und diesen nur für die Nachlaufzeit (Reset) nutzen würde.

[willisurf]

Ich habe bei mir für die Präsenzermittlung (ohne das Licht eingeschaltet wird) einfach einen weiteren helligkeitsunabhängigen Lichtkanal. Ich weiß nicht, ob das für Dich bereits eine (Teil-)lösung ist.

Ansonsten kannst Du ja wirklich nahezu beliebig die Präsenzeingänge des VPM vorher mit Logik verarbeiten. Damit sollte sich einiges lösen lassen. Die Logik ist wirklich sehr flexibel.

[traxanos]

Hab ja schon ne Lösung mit der Sperre. Aktuell habe ich die Sperre der betroffenen PMs am dazugehörigen Aktorstatus gehangen (invertiert).

War mehr Ideengeplänke wie man das Modul vielleicht noch besser machen könnte

[willisurf]

Was würdest Du konkret im Modul ergänzen wollen?

[traxanos]

ich glaube ich hätte nur ein drittes KO (neben präsenz und präsens/bewegung) dazu gepackt, welches nahezu gleich arbeitet aber halt das licht nicht einschaltet. es muss also immer zuerst auf den anderen beiden KOs (bzw. ggf per aktorstatus) ein "licht an also präsenz" signal gekommen sein.

[willisurf]

Das geht extern mit der Logik und einem TOR eleganter.

[mumpf]

Kein Stress, mach Urlaub und erhole dich gut!

Ist kein Stress, mir macht das ja Spaß. Wollte nur motivieren, warum ich mich wenig melde und wenn (wie heute Abend), dann nicht vollständig

Aber gerade hab ich etwas Zeit...

warum betrachtet man das Licht eigentlich nur aus BWM/PM Sicht.

Ich betrachte das Licht aus verschiedensten Sichten (Schalter, PM, An/Abwesenheit, Helligkeit, Szenen usw.). Allerdings betrachtet eine PM-Applikation das Lich aus PM-Sicht, wie denn sonst. Es ist ja keine Licht-Applikation. Ich habe in meinen Beispielen zwar Licht verwendet, weil sich hierzu jeder was vorstellen kann, aber der PM kann auch beliebiges anderes schalten (Heizung/Lüftung/Kühlung/Waschmaschine/Herd/Geschirrspüler sind bei mir vorgesehen).

Man könnte ja auch Lampen (ohne PM) ausschalten wenn eine Helligkeit erreicht wurde.

Kannst Du doch? Helligkeitsschwelle ist doch da? Absolut oder adaptiv, ganz nach Wunsch?

Und nicht jeder Aktor hat auch Treppenhausfunktion.

Braucht er doch nicht? Treppenlicht macht doch der PM?

Bei den beiden obigen Punkten wäre schon interessant, was Du eigentlich erreichen willst. Ich sehe noch keine Lücke...

[mumpf]

ich glaube ich hätte nur ein drittes KO (neben präsenz und präsens/bewegung) dazu gepackt, welches nahezu gleich arbeitet aber halt das licht nicht einschaltet.

Sorry, aber das verstehe ich auch nicht (hab auch die Beiträge darüber gelesen): Wenn ich einen Eingang habe, der nichts macht, dann brauche ich den Eingang doch nicht. Wie Bernhard willisurf schon sagte, es gibt 20 Kanäle, da nimmt man einfach einen weiteren, parametrisiert ihn genau so und verknüpft den Ausgang nicht mit Licht. Ich weiß eben nicht, was der genau machen soll, aber Du hast ja auch noch Logik, mit der Du genau das bewirken kannst, was Du willst.

Aber ich hab es eigentlich nicht wirklich verstanden (auch Bernhards Vorschlag mit dem TOR nicht).

[willisurf]

Wenn es einen (dritten) PM gibt, dessen Signal zwar nicht einschalten soll, aber die anderen Präsenzkanäle quasi freigibt, dann wäre das die Anwendung für ein TOR.

[mumpf]

Danke Bernhard willisurf, jetzt hab ich zumindest diesen Teil verstanden. Ich versuche es mal mit eigenen Worten zu formulieren:

Es geht um ein Master-Slave, bei dem der Slave nur dann triggert, wenn der Master bereits aktiv ist. Somit kann ein Slave nur eine Präsenz verlängern, aber nicht von sich aus starten.

Hab ich das korrekt verstanden?

[mumpf]

Und Du hast vollkommen Recht, stand heute würde man das über ein TOR vor einem der Präsenzeingänge erreichen. IMO auch einfach und elegant zu machen, oder?

Gruß, Waldemar

[traxanos]

Genauso da meinte ich. Aber statt Tor kann man auch den pm mit der eingeschalteten Licht einfach entsperren. Wie gesagt das waren erstmal nur sachen die mir durch den Kopf gingen. Bis her hab ich alles wiegend wie so hinbekommen.

einzig der pm reset würde ich gerne als true/false konfigurieren können, da das imho Logik Verschwendung ist und es unübersichtlicher macht wenn es das Modul direkt macht.

[willisurf]

einzig der pm reset würde ich gerne als true/false konfigurieren können

Das kann ich verstehen und klingt für mich auch noch nach einer generischen Lösung.

[mumpf]

einzig der pm reset würde ich gerne als true/false konfigurieren können

Ich schau mal... 0-aktive Trigger sind (genau so wie 1-aktive) recht einfach zu realisieren (bei 0-aktiven Eingängen muss man sich immer extra Gedanken zum Startup-Zustand machen, deswegen verweise ich da auf die Logiken, denn da habe ich mir dezidierte Gedanken zum Startup gemacht). Wird aber noch dauern, ich muss erstmal einen Bug finden, den ich derzeit beim Bauen habe (also in der Infrastruktur). Dafür gibt es dann aber (wenn alles klappt) eine Variante mit 40 PM-/99 Logik-Kanälen (kann sein, dass es nur 30 statt 30 werden), dann aber nur für den RP2040. Kleine Vorwarnung: Das kann ich nur als neue Applikation ein der ETS realisieren, diese "große" VPM-Applikation wird nicht kompatibel zur "kleinen" sein können.

Das ist der Spoiler, den Bernhard weiter oben meinte .

Gruß, Waldemar