OpenKNX-VirtualPresence release (VPM)

[traxanos]

hatte ich auch schon versucht. es sieht so aus als würde NanoBCU kaputt sein. Weder 3,3 noch 5V kann ich messen. Löte gerade das Reserve-Set zusammen

[mumpf]

Nein, normalerweise klappt das ohne irgendwas vorzubereiten.
Für den Notfall gibt es https://www.raspberrypi.org/document...flash_nuke.uf2, das löscht alles auf dem Pico.
das uf2 File einfach auf das Laufwerk Kopieren, das beim einstecken mit gedrückter BOOTSEL Taste erscheint.

[traxanos]

Was macht man wenn nach dem Flashvorgang das Modul tod ist? Hab das Big-Image drauf gepackt. Keine LED oder sonst was. Hab das alte Image drauf gepackt klappt aber auch nicht. Mhh. Hätte ich vorher irgendwas löschen müssen bevor ist auf Big wechsele?

[traxanos]

Ne wir alle haben für deine tolle Arbeit zu danken!!!

PS: Ich hoffe der Urlaub ist vorbei. Also aus Sicht, dass du das nicht in deinem Urlaub gemacht hast. Urlaub sollte am besten nie vorbei gehen

[mumpf]

Ab letzter Nacht gibt es eine neue Version 1.1.3 des VPM.

• NEU: Wenn ein externer PM zurückgesetzt werden kann, kann man jetzt wählen, ob dieser mit einem EIN- oder einem AUS-Signal zurückgesetzt wird
• NEU: Ein externer Präsenz- oder Bewegungseingang kann jetzt auch dazu genutzt werden, den aktuellen Präsenzzustand zu verlängern, aber nicht, um Präsenz einzuschalten.
• Die enthaltene Logik hat den Firmware-Stand 0.12.3

Und in der (enthaltenen) Logik gab es kleinere Fixes:

• FIX: Treppenlicht konnte erst über KNX wieder abgeschaltet werden, sobald das Logikmodul länger lief als die eingestellte Treppenlichtzeit.
• FIX: "Einschaltverzögerung -> beim 2. EIN sofort schalten" wurde auch erst geschaltet, wenn das Logikmodul länger lief als die eingestellte Verzögerungszeit.
• FIX: "Ausschaltverzögerung -> beim 2. AUS sofort schalten" wurde auch erst geschaltet, wenn das Logikmodul länger lief als die eingestellte Verzögerungszeit.
• FIX: Konvertierung von DPT 9 nach DPT != 9 war um Faktor 10 zu groß. 9.0 wurde auf 90 Konvertiert statt auf 9.

Größte Änderung ist aber eine weiteres Releasepaket "PresenceModule-Big", dass eine neue (aus ETS-Sicht inkompatible) VPM-Applikation enthält und einen VPM mit 40 PM-Kanälen / 99 Logikkanälen implementiert. Die zugehörige Firmware ist nur auf dem RP2040 lauffähig, es gibt auch kein Setup für den SAMD.

Ansonsten sind die (sehr sinnvollen) Vorschläge von traxanos aus diesem Thread eingeflossen, vielen Dank.

Downloadpfade stehen wie immer im ersten Beitrag dieses Threads.

Gruß, Waldemar

[traxanos]

Urlaub!!! Sonst sieht es so aus wie erwartet

[mumpf]

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

Gruß, Waldemar

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

[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

[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

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

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

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

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

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