OpenKNX-VirtualPresence release (VPM)

[Ing-Dom]

Platinen sind wohl noch einige bestellbar,

noch 14 Stück.

für die wenigen Bauteile wird es dann sicherlich bald eine Lösung geben

Ich würde euch empfehlen euch da ggf. zu organisieren dass einer die Bauteile bestellt für alle. Das kann man alles in einem Briefumschlag für 85Cent verschicken.
Ich hab jetzt dann mit der Abarbeitung meiner vielen Bestellungen zu tun und kann das definitiv nicht leisten aktuell.

Eine Lösung von mir wird es frühestens zur nächsten Bestellrunde (wahrscheinlich vor Weihnachten) geben.

[willisurf]

Ich denke hier wird auch noch willisurf einiges von seinen Erfahrungen mit dem TP im Zusammenspiel zum VPM einbringen, er war bisher sehr zufrieden

Das mache ich gerne Waldemar. Und vorab möchte ich noch einmal sagen, wie sehr ich mich jeden Tag über die gelungene Applikation freue. Als ich vor einem Jahr unbedingt die Applikation des TP ersetzen wollte, hätte ich niemals vermutet, wie aufwändig die Entwicklung wird.
Herzlichen Dank von mir an Waldemar für die gemeinsame Zusammenarbeit und Deine Entwicklung!

So, und wo und wie kann ich jetzt die Hardware bestellen? Brauche ich ein KNX Sensormodul von Smart-MF?

Das ist sicherlich erstmal die naheliegende, wichtige Frage. Die VPM Software ist auf dem Sensormodul und dem PiPico Modul lauffähig. Da aktuell keine Sensormodule von Masifi lieferbar sind, ist die konkrete Empfehlung den PiPico Adapter von Ing-Dom zu verwenden. Platinen sind wohl noch einige bestellbar, für die wenigen Bauteile wird es dann sicherlich bald eine Lösung geben

Ist noch relativ kompliziert aber ich arbeite an einem Komplett-Bausatz...

Wie das Ganze dann aussehen kann (und wie hoch bzw. niedrig die Kosten sind), hat Stereofeld hier gezeigt. Ein gedrucktes Gehäuse oder 2TE Hutschienengehäuse ist sicherlich möglich, aber ein Schrumpfschlauch und ein Einbau irgendwo, wo ein KNX Kabel zugänglich liegt, tut es auch. Der Hardwareaufwand ist damit sehr überschaubar.

Jetzt zu den Erfahrungen. Als vor 6 Monaten die ersten Beta Versionen von Waldemar entwickelt waren, habe ich beginnend mit einem Raum dann sehr schnell weitere Räume umgestellt. Allein den Aktorstatus einlesen zu können und die elegante Integration in den MDT GTII (für manuellen Override inkl. Patsch) waren eine Riesen Fortschritt. Aktuell ist die Applikation so umfangreich, das aus meiner Sicht kein Wunsch offen bleibt, ich habe immer noch nicht alle Möglichkeiten ausgeschöpft. Aber das macht ja auch nichts, lieber haben als brauchen und man kann auch mit einfachen Funktionalitäten beginnen.

Heute verwende ich zwei Hardwaren (Sensormodul) für den VPM, der PiPico Adapter ist bestellt.

Inzwischen habe ich 6 TP z.T. mit einem weiteren PIR mit dem VPM appliziert. Dabei ist das gesamte Spektrum von 1x TP mit einem VPM Kanal bis zu TP+PIR mit 4 VPM Lichtkanälen in einem Raum im Einsatz. Auch alle bestehenden PIR Melder habe ich über die VPM Applikation integriert, um eine einheitliche und leistungsfähige Applikation zu haben. Ich werde in diesem Thread in loser Folge immer mal wieder Beispiele (einfach oder auch komplex) vorstellen und freue mich insgesamt auf eine rege Diskussion.

[mumpf]

Welches der 3 Hardware-Beispiele ist denn verfügbar bzw. auch für unbegabte wirklich umsetzbar?

Das vierte :

... ich arbeite an einem Komplett-Bausatz...

Sorry dass nichts kurzfristig geht, aber derzeit kommt Hardware "irgendwann" aus der Produktion, da werden Ing-Dom und Masifi eher was dazu sagen können.

Grundsätzlich besteht die Hardware "nur" aus einem Pico, einer BCU, dem Prog-Taster, der Prog-LED, ein paar Dioden, Wiederständen und Kondensatoren. Kann man testweise auch auf einem Steckbrett aufbauen.

Ansonsten könnt ihr euch ja schon mal die Applikation in die ETS laden und schauen, was alles geht.

ist es möglich auch auf masifi’s encoean gateway vpm kanäle zu ermöglichen

Technisch - ja. Wenn es Dir nur darum ginge, den VPN mal auszuprobieren STATT dem ENO, dann könnte ich Dir was zuschicken, was auf der Hardware vom ENO (als VPN) läuft. Sozusagen schon mal spielen, bis man die "richtige" Hardware bekommt. Den ENO kannst Du ja jederzeit wiederbekommen, indem Du dessen Firmware wieder aufspielst und mit der ETS programmierst.

Als Firmware mit ENO+VPM+Logik wird es technisch vielleicht gehen, aber da korelliert Aufwand und Nutzen nicht. Im besten Fall passen da noch 5 VPM-Kanäle rein, wahrscheinlich weniger, und ich müsste das Timing von ENO womöglich ändern. Da bin ich ehrlich, das ist zu Aufwändig. Wenn wir in ein paar Jahren mehrere Module haben, die alle passend untereinander ihre Rechenzeit und die gegenseitigen Bustimings abstimmen können, wird es vielleicht wirklich möglich sein zu sagen, dass man auf Hardware X die Module X mit 20, Y mit 50 und Z mit 80 Kanälen haben will. Aber so weit sind wir (leider) noch lange nicht. Derzeit ist da noch viel Handarbeit und "Feintuning" notwendig, damit alles zusammen läuft.

[henfri]

Wow.
Tolle Idee und tolle Umsetzung.

Werde ich auch ausprobieren.
Ich habe auch viele unterschiedliche präsenzmelder und mich Nerven die Eigenarten jeder Applikation hier und da.

Gruß,
Hendrik

[TabSel]

mir tut das unendlich Leid fragen zu müssen: ist es möglich auch auf masifi’s encoean gateway vpm kanäle zu ermöglichen?

[crewo]

Danke dir für die ausführliche Antwort! Ich gebe gern mit Feedback und würde das hier testen mit 5 TP, die mich immer wieder ärgern. Welches der 3 Hardware-Beispiele ist denn verfügbar bzw. auch für unbegabte wirklich umsetzbar?

[mumpf]

Dann versuche ich mal ein paar Klarheiten zu beseitigen .

Warum das VPM "nur" 30 Logikkanäle hat, weiß ich nicht. Evtl. weil es auf dem SAMD lauffähig sein soll?

Ich habe nur das freigegeben, was ich (und auch willisurf) über längere Zeit getestet habe. Und das ist die Kombi 20 / 30. Und ja, der Test war auch auf einem SAMD und der bietet einfach keine weiteren Kapazitäten.

Größere Kanalanzahlen werden noch getestet, aber die werden nur auf dem RP2040 laufen. Das erfordert aber eine Erweiterung für die Produktion der ETS-Applikationen, denn auch wenn wir derzeit für mehrere Prozessoren bauen können, es gibt nur eine ETS-Applikaiton für alle.

Und einfach die Kanalanzahl hochzuschrauben reicht manchmal nicht. Ich glaube auch, man wird das Scheduling anpassen müssen, also wann welche Komponente Rechenzeit bekommt.

Langer Rede kurzer Sinn: Mehr Kanäle - dann nur für den RP2040 - kommen später und müssen vorher umgeschrieben und getestet werden.

Ich hab mir als Leihe nur gefragt warum macht man sich den Aufwand und baut 2 Firmwares statt eine.

Kann man so sehen. Ich sehe aber auch solche Aspekte wie Kapselung/Modularisierung, Dokumentation, Supportability und Wiederverwendbarkeit, die eine Rolle spielen. Ich kann Funktionalitäten klar beschreiben, ich kann Fehler besser eingrenzen und ich kann neue Funktionen klar zuordnen.

Wenn eine Firmware eine Mixtur von verschiedensten Funktionalitäten ohne klares Layering ist, dann gibt es auch ganz schnell Leute, die sagen, dass der PM doch bitte mal eine Einschaltverzögerung von x Sekunden bekommen soll, kann ja die Logik auch. So weit will ich das aber gar nicht kommen lassen. Hier gibt es für mich eine klare Line. Der PM schaltet, wenn auch noch eine Einschaltverzögerung gewünscht wird, nutzt man einen Logikkanal, der dies realisiert. Und als Service bietet das Modul interne Verknüpfungen an, um den PM-Ausgang mit dem Logik-Eingang zu verbinden, dann spart man sich die Kommunikation auf dem Bus.

--> VPM Modul = RaspBerry PI + Zusatzmodul an KNX angeschlossen (zusätzliches KNX gerät, welches die vorhandenen PM koordiniert)

Kein Raspberry PI, also nicht der Kleinplatinenrechner, der unter dem Namen bekannt ist, sondern der Raspbary Pi Pico, also der neu erschienene Microcontroller von der Raspberry Foundation.

Du hast also nur ein KNX-Gerät, das kann der PiPico-BCU-Connector von Ing-Dom sein
PiPico_BCU_Connector_V00.01_soldered.jpg
oder das Sensormodul von Masifi
Sensormodul.png

oder der fertige RealPresence von Masifi
RealPresence.png
und dieses Gerät funktioniert als VPM mit 20 PM-Kanälen. Beim RealPresence kann man noch zuätzlich auswählen, dass das Präsenz-, Bewegungs- oder Hellikgeitssignal direkt von der Platine und nicht über den Bus kommt.

Ich finde Szenario 2 als Ersatz des TP ganz interessant, dazu ist die Info-Lage noch etwas dürftig ;-)

Ja, der ist eben noch nicht fertig (und sicher auch die teuerste Variante). Ich habe aber beschlossen, die Firmware als VPM bereits freizugeben, weil sie auch ohne eine PM-Hardware sehr gut funktioniert. Und ob der RealPresence ein Ersatz für den TP sein kann, muss jeder selber entscheiden. Wenn sich der TP bei Dir nicht aufhängt (was ich logischerweise nicht durch eine externe Firmware beeinflussen kann), ist der VPM als Ergänzung zum TP eine prima Sache.
Ich denke hier wird auch noch willisurf einiges von seinen Erfahrungen mit dem TP im Zusammenspiel zum VPM einbringen, er war bisher sehr zufrieden .

Ich hab 4 unterschiedliche PM-Typen und die Applikationen sind nicht immer gut und sehr verschieden.

Ist auf jeden Fall eines meiner angedachten und persönlich genutzten Szenarien: Ich lasse mir von den PM nur noch "dumme" Signale schicken und habe eine gleichartige VPM Applikation für alle Räume.

Sprich jeder Status eines PM/BM wird einzelnd erfasst und gilt als aktiv bis dieser eine aus sendet?

Ja, man kann sogar noch zwischen Bewegung und Präsenz unterscheiden (muss dann allerdings alle Slaves in der Logik "verODERn").

da steckt sicher unfassbar viel Zeit drin!

Wie schon oben erwähnt: 96 ETS-Versionen, über 200 Firmware-Versionen und über 1 Jahr Brainstorming-, Entwicklungs- und Dokumentationszeit. Aber sicher ist trotzdem nicht alles perfekt und wir müssen in der Community zusammenarbeiten, um es besser zu machen. Ich hab hier zwar das meiste gemacht, aber ich hätte es ohne andere nicht geschafft!

Um nochmal zu motivieren, warum sicherlich noch Sachen fehlen: Wir sind jetzt seit einem Jahr "drin", ich weiß teilweise gar nicht, was nicht klar ist, denn mir IST alles klar. Und ich kann nicht alles vorweg aufschreiben. Aber ich/wir können Informationen sammeln und hier im Forum und im OpenKNX-Wiki wieder zur Verfügung stellen und so die Doku verbessern und an Beispielen arbeiten.

Soviel erstmal von meiner Seite,
Gruß, Waldemar

[gbglace]

Ja ich beobachte das ja bisher auch nur indirekt über die Gespräche auf den Stammtischen. Ich bin schon recht gut überzeugt ein oder zwei solcher VPM Geräte zu benötigen. Mein gesteigertes Interesse geht da dann auch eher auf das 2TE Modul/Bausatz für den REG Einsatz.

Da gibt es hier doch auch einen Zhread wenn ich mich grob erinnere.

[crewo]

Vielen Dank an alle Beteiligten, da steckt sicher unfassbar viel Zeit drin!

Wenn ich die Beschreibung so durchlese frage ich mich schon, warum hier Hauptberufliche KNX Produktentwickler nicht ebenfalls darauf kommen, mal so eine gelungene Featurezusammenfassung auf die Beine zu stellen.

So, und wo und wie kann ich jetzt die Hatdware bestellen? Brauche ich ein KNX Sensormodul von Smart-MF?

[Ing-Dom]

was sofort verfügbar wäre ein Gerät auf Basis der PiPico BCU Connector

BCU und Adapter-PCB bekommst du von mir, Gehäuse wäre selbst zu drucken und den PiPico und ein paar Kleinteile (Wago Klemmen und Lötpins, Buttons, LED und ein paar Rs und Cs) selbst zu besorgen. Ist noch relativ kompliziert aber ich arbeite an einem Komplett-Bausatz...

[traxanos]

Ja genau das sehe ich auch so. Und ich hoffe sogar folgendes Feature richtig verstanden zu haben:

Das Präsenz-Signal kann schaltend oder triggernd sein

Sprich jeder Status eines PM/BM wird einzelnd erfasst und gilt als aktiv bis dieser eine aus sendet?
Gerade das MDT Feature mit "verkürzter Nachlaufzeit" bei Master/Slave ist nicht wirklich machbar. Und das müsste bei einem schaltenden Signal endlich machbar sein.

[jcd]

Was willst du machen? Ein VPM Modul bauen?

Ja, wenn’s nicht zu kompliziert ist
Ich hab 4 unterschiedliche PM-Typen und die Applikationen sind nicht immer gut und sehr verschieden.

[traxanos]

Ich verstehe nicht genau was du meinst, wo ist der Unterschied zwischen einem Logikmodul mit Logik-Kanälen und VPM-Kanälen und einem VPM-Modul mit Logik-Kanälen und VPM-Kanälen ?

Ich hab mir als Leihe nur gefragt warum macht man sich den Aufwand und baut 2 Firmwares statt eine. Ist ja nur doppelte Arbeit. Wenn es Identisch wäre, wäre es doch nur eine neues Release der Logicfirmware.

[Crashman]

Danke für eure Mühe! Ich sehe schon, dass ihr noch am Anfang steht, deshalb das gut gemeinte Feedback: Neben aller Beschreibung wäre eine Art Tutorial/HowTo --> welche Komponenten brauche ich und wie baue ich sie ein - sehr hilfreich.

So wie ich es verstanden habe kommen gibt es mindestens zwei Szenarien:

--> VPM Modul = RaspBerry PI + Zusatzmodul an KNX angeschlossen (zusätzliches KNX gerät, welches die vorhandenen PM koordiniert)
--> RealPresence Sensor, welcher die VPM Funktionalität in einem Gerät inkludiert



Da mich mein TP jetzt auch ein wenig nervt, ist die Bereitschaft mal was auszuprobieren definitiv da :-) Ich finde Szenario 2 als Ersatz des TP ganz interessant, dazu ist die Info-Lage noch etwas dürftig ;-)

[Ing-Dom]

Aber warum kommt es nicht mit in das LogicModul mit rein, vermutlich wegen Limitierungen.

Ich verstehe nicht genau was du meinst, wo ist der Unterschied zwischen einem Logikmodul mit Logik-Kanälen und VPM-Kanälen und einem VPM-Modul mit Logik-Kanälen und VPM-Kanälen ?

Genau, gar keiner !
Oder geht es dir um die Anzahl der Logikkanäle?

Warum das VPM "nur" 30 Logikkanäle hat, weiß ich nicht. Evtl. weil es auf dem SAMD lauffähig sein soll?
Auf dem RP2040 sollte mehr möglich sein.
Aber dazu soll mumpf was sagen.

Und jetzt stelle ich mir vor, so eine LogicModul im Hutschienengehäuse mit mehreren LogicEngines (Slots) vor

Was meinst du mit Slots ? Hardware oder Firmware?

Was muss man alles kaufen und machen, wenn man bei Null startet?

Was willst du machen? Ein VPM Modul bauen?