OpenKNX-VirtualPresence release (VPM)

[willisurf]

Das ist der Spoiler, den Bernhard weiter oben meinte

Ja genau! Ich freue mich schon darauf, denn von den Logikkanälen kann man tatsächlich sehr gut einige mehr für Aktorstatus, Behandlung der Präsenzkanäle u.ä. bei den PM Kanälen brauchen.

Dafür nehme ich auch gern in Kauf noch einmal inkompatibel umzubedaten.

[traxanos]

Ich glaube du hast was missverstanden bei meinem Zitat. Aber denk dran du hast Urlaub

[willisurf]

es werden 3 aus 2 Zustände (An/Aus) wir zu (Inaktiv/Send An /Sende aus)

Du hattest dazu ja einen Vorschlag gemacht.

[mumpf]

Um mich nochmal selbst zu zitieren:

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.

Das ist durchaus noch ein Modus, den ich mal durchdiskutieren möchte.

• Dein Beispiel mit den Fehlauslösenden Slave-PM ist ja eher eine Notlösung, trotdem valide.
• Ich stelle mir gerade Situationen im Bad vor, PM erfasst die Dusche nicht, da ist aber ein Temp-Sensor, der duschen feststellt. Das ist durchaus auch ein Präsenz-Slave, der nicht selber einschalten soll, aber eine Präsenz verlängern soll.
• Oder der Fernsehmodus, der nicht eine bestimmte Lichtszene auslösen soll, aber die bestehende so lange erhalten soll, wie der Fernseher läuft (das ist jetzt eine eher abstrakte Präesenz-Info, aber warum nicht).

Könnte ich mich mit anfreunden. Allerdings habe ich keine KO mehr frei. Man müsste einen der beiden Eingänge (oder beide) mit einem Flag nach dem Motto "kann nicht einschalten, nur verlängern" markieren können (wie auch immer der Text dann final heißen mag). Damit könnte man Präsenz+Bewegung+Erhaltung nicht machen.
Ich gehe nochmal in mich. Gibt es noch weitere Meinungen/Ideen?

Gruß, Waldemar

[mumpf]

Ich glaube du hast was missverstanden bei meinem Zitat

Da haben wir parallel geschrieben. Was hab ich denn missverstanden?

[traxanos]

Zitat von traxanos Beitrag anzeigen
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

was meinst du mit 0-aktive trigger. mir ging es um "Externer PM kann per Bus zurück gesetzt werden". Hier hätte ich gerne stat nur Ja/Nein.

Nicht aktiv, Aktiv sende EIN, Aktiv sende AUS.

So dass man hier nicht noch unübersichtlich einen Logikkanal fürs inventieren opfern muss.

[traxanos]

Ich stelle mir gerade Situationen im Bad vor, PM erfasst die Dusche nicht, da ist aber ein Temp-Sensor, der duschen feststellt. Das ist durchaus auch ein Präsenz-Slave, der nicht selber einschalten soll, aber eine Präsenz verlängern soll.

An das hatte ich tatsächlich selber auch gedacht. Oder der aktive Herd falls man das Beispiel von Willisurf aufgreifen möchte.

Damit könnte man Präsenz+Bewegung+Erhaltung nicht machen.

Das wäre mir egal, weil die MDT BWM/PM auch kurze Nachlaufzeiten kann, so dass ich mit Bewegung+Halten klar käme.

[willisurf]

Das ist durchaus auch ein Präsenz-Slave, der nicht selber einschalten soll, aber eine Präsenz verlängern soll.

Ja, das lässt sich mit externer Logik nicht ganz so einfach nachbilden und deckt durchaus denkbare Anwendungsfälle ab. Ein TOR ist zwar für die Freischaltung eines Kanals sinnvoll, der Steuereingang würde aber nicht selbst verlängernd wirken.

Damit könnte man Präsenz+Bewegung+Erhaltung nicht machen

Das wäre ja nicht schlimm, ein Verlängern nach einem Einschalten würde ja immer über Präsenz gehen. Bewegung ist dafür m.E. nicht notwendig, sondern eher für die erweiterten Funktionen (Kurzzeitpräsenz und LeavingRoom)

Also ja, solch eine Erweiterung könnte sinnvoll sein.

[willisurf]

was meinst du mit 0-aktive trigger. mir ging es um "Externer PM kann per Bus zurück gesetzt werden". Hier hätte ich gerne stat nur Ja/Nein.

Ich denke das passt schon und Waldemar hat Dich richtig verstanden.

Die Überlegung war nur, für einen Ausgang (wie in Deinem Beispiel) lässt sich das sinnvoll umsetzen.
Bei einem Eingang wäre es wichtig die Initialisierung zu betrachten (hier nicht relevant).

[traxanos]

Perfekt, eine Nacht später tummelt sich wieder eine Idee. Du willst ja dein Modul sowieso überarbeiten (ohne abwärtskompatiblität)...

Wäre es nicht vielleicht eine Idee die PM Eingänge direkt von dem VPM zu trennen? Du hast ja jetzt schon bewiesen, wie geil es ist, dass du überall "vorhandene KOs" auswählen kannst. Also könntest du doch eine Liste von 60 PMs pflegen, diese separate Beschriften und direkt sagen ob es ein "trigger" oder "schaltend" ist.

Auf dem VPM machst du dann eine Tabelle wo du die verschiedenen PMs auswählen kannst und wählst dort direkt aus, als was er genutzt werden soll (Bewegung/Präsenz/Nachlaufzeit verlängern). Aktuell hast du 30VPM mit je 2KOs, damit hättest du 60 flexible KOs die du auch mehrfach kannst und somit braucht es auch keine OR-Gatter mehr. Trotzdem bleibt es übersichtlich, weil die PMs jetzt nach Ihrer Position (WZ_Sofa_untendrunter) beschriftet werden können und die VPMs (Esstisch) nach Ihrem Lichtkreis.

Ich versuche das mal an einem Beispiel, wenn auch nur konstruiert zu beschreiben.

PM Liste

- PM1: BWM unter Sofa (schaltend)
- PM2: BWM unter Sideboard am Esstisch / Durchgang (schaltend)
- PM3: PM über Esstisch (schaltend)
- PM4: PM über Sofa (schaltend)
- PM5: Fernseher an (trigger)
- PM6: TPM Küche Bewegung (schaltend)
- PM7: TPM Küche Präsenz (schaltend)
- PM8: Kochfeld an (trigger)

VPM Esstisch
- PM1: Nachlaufzeit verlängern
- PM2: Präsenz
- PM3: Bewegung
- PM4: Nachlaufzeit verlängern
- PM5: Nachlaufzeit verlängern

VPM Sofa:
- PM1: Bewegung
- PM4: Präsenz
- PM5: Nachlaufzeit verlängern

VPM Küche:
- PM6: Bewegung
- PM7: Präsenz
- PM8: Nachlaufzeit verlängern

Wie gesagt, ist etwas konstruiert, damit es etwas verständlicher ist.

[mumpf]

Ich denke das passt schon und Waldemar hat Dich richtig verstanden.

Sehr nett, dass Du so viel von mir hältst, aber ich hab das wirklich falsch verstanden. Ich hab die Diskussion zum Reset zu dem Zeitpunkt noch nicht aufmerksam genug gelesen gehabt und war gedanklich einfach bei dem Reset-Eingang von unserem PM.

Aber das mit dem Ausgang wird dann kein Problem sein und ist auch eine sinnvolle Erweiterung.

[mumpf]

Wäre es nicht vielleicht eine Idee die PM Eingänge direkt von dem VPM zu trennen?

Nein... oder anders gesagt: Es wäre eine Idee, die aber auf längere Zeit (wir sprechen hier von >2 Jahren) nicht realisierbar sein wird. Zu jedem Eingang gehört ja auch Coding, ID's und eine (beim PM recht aufwändige) Zustandsverwaltung.
Und derzeit ist jeder Kanal eines Moduls bei uns "self-contained", also komplett unabhängig von anderen. Das würde hiermit auch verletzt werden.

Ich habe so was schon mal mit dem Logikmodul versucht, das aufgrund des generischen Ansatzes eine wesentlich einfachere Zustandsverwaltung hat und bin da nicht mal weit genug gekommen, um innerhalb der ETS das vernünftig hinzubekommen, geschweige denn in der Firmware (wobei ich mir immer noch die Frage stelle, was letztendlich aufwändiger ist, ETS oder Firmware).

Eine Sache, die vielleicht hier nicht so klar ist: Die Applikation in der ETS ist konzeptionell ein "vollständig entfaltetes UI", man macht somit eine statische Oberfläche für jegliche Parameterkombination, die eine UI-Änderung erfordert. Ich muss also alles auf die Oberfläche bringen und kann dann nur ausblenden. Das lässt sich für einen Kanal noch einigermaßen beherrschen, aber wenn dann plötzlich noch eine dynamische Anzahl von externen Einflüssen kommt, kann das schnell exponentiell steigen.

Du willst ja dein Modul sowieso überarbeiten (ohne abwärtskompatiblität)...

Nein, nicht zum aktuellen Stand (sonst hätte ich es nicht publiziert). Ich will nur mehr Kanäle ermöglichen, weil der neue Prozessor RP2040 eine größere Kapazität hat. Die neue Applikation ist rein technisch notwendig, weil die ETS immer alle Ressourcen runterlädt und ich in einer Applikation nicht irgendwo sagen kann, bitte jetzt aber max. 20 Kanäle runterladen. Und selbst wenn das ginge, wüsste ich nicht wie...

Gruß, Waldemar

[traxanos]

Es wäre eine Idee, die aber auf längere Zeit (wir sprechen hier von >2 Jahren) nicht realisierbar sein wird

Schade, hatte gedacht, dass es evtl. sogar den Programmieraufwand vereinfacht.

Die Applikation in der ETS ist konzeptionell ein "vollständig entfaltetes UI"

Ja ich kenne den groben Aufbau der XML Datei . Hab selber ua. mit Konnekting schon eigene Module gebaut (RS232 Schnittstelle zur TV Steuerung). Aber das ist nicht so komplex wie dein Modul

[willisurf]

als was er genutzt werden soll (Bewegung/Präsenz/Nachlaufzeit verlängern).

Dadurch das Du die Logikkanäle mit einem Namen versehen kannst, bleibt es trotzdem noch übersichtlich.

[mumpf]

Über den Text (zürücksetzen/reset) können wir auch noch reden. Aber so wird das aussehen:
Busreset.png

Gruß, Waldemar