VPM: Sensorauswahl weiterhin am echten Präsenzmelder?

[Sven1234]

Sehe ich es richtig, dass die Applikation nicht so gedacht ist, dass man z.B. bei einem vier Sensoren Präsenzmelder jeden Sensor einzeln als Eingang definiert und diese vier Sensoren dann in der Applikation als ein VPM zusammegefasst werden? D.h. man soll/muss weiterhin die Sensorauswahl in der original Applikation durchführen und diese Sensorauswahl dann auf den VPM Eingang legen.

[willisurf]

Es kommt darauf an, was die einzelnen Zonen bewirken sollen. Ich nutze tatsächlich beide Varianten.
Es ist ähnlich, wie Du ja im Präsenzmelder die Sensoren den einzelnen Licht- oder HLK Kanälen zuweisen kannst. Ein VPM Kanal entspricht in der Logik einem Licht-/HLK Kanal im Melder.

[mumpf]

Es würde auch nicht viel Sinn machen, bis zu 4 Einzelsignale über den Bus zu schicken, um dann nur ein Signal daraus zu machen. Die häufigen Präsenzmeldungen würden den Bus unnötigerweise belasten. Wenn Du natürlich 4 Einzelauswertungen brauchst, dann geht das nicht anders.

Gruß, Waldemar

[Sven1234]

Aber die Sensoren zu diesem Kanal kann ich nicht in der OpenKNX Applikation zusammenstellen, oder? Oder kann ich mehr als einen Eingang für einen VPM bekommen?

Ich würde mir das so vorstellen, dass ich für einen VPM die Anzahl der Sensoren des original PM angebe und entsprechend viele Eingänge für diesen einen VPM angeboten bekomme. Dann weise ich jedem Lichtkanal des original PM genau einen Sensor zu und lege diese auf die Eingänge im VPM. Vier Sensoren, vier Eingänge, eine 1:1 Beziehung.
Ab da kann ich dann innerhalb des VPM Lichtkanäle mit einer Auswahl der Sensoren vornehmen, ohne mich noch um irgendwas im Original PM kümmern zu müssen.
Das setzt natürlich voraus, dass der original PM genausoviele Lichtkanäle wie Sensoren erlaubt. Ansonsten kann ich die nicht einzeln als Eingang auf einen VPM legen.

[mumpf]

Nein, wie gesagt, das macht keinen Sinn. Das ist unnötige Buslast.
Du sagst an Deinem PM, welche Sensoren einen Lichtkanal nutzen. Und diesen gibst Du an einen VPM-Kanal.
Wenn Du 3 Sensoren an einem Kanal haben willst, dann ist das auch nur ein OR zwischen diesen 3 Sensoren, das macht man gleich an der Quelle, nicht am Ziel.

Gruß, Waldemar

[Sven1234]

Es würde auch nicht viel Sinn machen, bis zu 4 Einzelsignale über den Bus zu schicken, um dann nur ein Signal daraus zu machen. Die häufigen Präsenzmeldungen würden den Bus unnötigerweise belasten.

Das ist richtig. Damit muss ich aber bei einer Änderung ggf. in zwei Applikationen arbeiten und ersetze nicht komplett die original Applikation.
Und wenn ich mich nicht irre, kann ich dann auch nur genausoviele VPM anlegen, wie ich Lichtkanäle im original PM habe. Danach folgen dann nur noch Dubletten.

Ggf. ein paar mehr, wenn man die einzelnen VPMs per Logik kombiniert. Das wäre der workaround. "Sensorauswahl bzw. -kombination per Logik".

[Sven1234]

Wenn Du 3 Sensoren an einem Kanal haben willst, dann ist das auch nur ein OR zwischen diesen 3 Sensoren, das macht man gleich an der Quelle, nicht am Ziel.

Verstehe ich, bzgl. der Buslast. Ich würde aber auch gerne die original Quelle vergessen können und komplett durch die VPM ersetzen. Daher der Gedanke. Der VPM ist ja nicht das Ziel, sondern sitzt zwischen Quelle und Ziel, als Mittler.

[willisurf]

Damit muss ich aber bei einer Änderung ggf. in zwei Applikationen arbeiten und ersetze nicht komplett die original Applikation.

Ein merkwürdiges Ziel, wenn man dafür die Architektur verbiegen muss.
Außerdem in der Realität nicht relevant, weil man die Sensoreinstellungen nur einmal festlegt und dann daran nichts mehr ändert, sondern nur noch im VPM appliziert.

Und wenn ich mich nicht irre, kann ich dann auch nur genausoviele VPM anlegen, wie ich Lichtkanäle im original PM habe. Danach folgen dann nur noch Dubletten.

Das ist falsch. Einfaches Beispiel: Du hast einen Lichtkanal im PM, der Dir das Präsenzsignal generiert, möchtest aber 3 Lichtquellen mit unterschiedlichen Zeiten/Helligkeiten oder Tagesphasen schalten. Dann sind das 3 VPM Kanäle.

Ich denke Du solltest das einfach mal ausprobieren.

[Sven1234]

Ein merkwürdiges Ziel, wenn man dafür die Architektur verbiegen muss.
Außerdem in der Realität nicht relevant, weil man die Sensoreinstellungen nur einmal festlegt und dann daran nichts mehr ändert, sondern nur noch im VPM appliziert.

Naja, Realitäten hängen immer vom individuellen Fall ab, so pauschal ist das glaube ich nicht richtig. Fakt ist, ein VPM erhöht nicht die Anzahl der möglichen Sensorkombinationen, ohne weitere Logik, er bildet die im original PM festgelegten Sensorkombinationen 1:1 ab. Ab da erhöhen sich dann die Möglichkeiten. Die Sensorkombi ist fix.

Das ist falsch. Einfaches Beispiel: Du hast einen Lichtkanal im PM, der Dir das Präsenzsignal generiert, möchtest aber 3 Lichtquellen mit unterschiedlichen Zeiten/Helligkeiten oder Tagesphasen schalten. Dann sind das 3 VPM Kanäle.

Ich denke Du solltest das einfach mal ausprobieren.

VErstehe was Du meinst, eure Argumentation setzt aber eben immer nach der Zusammenstellung der Sensoren an.

Original PM:
Lichtkanal 1: Sensor 1+2 GA1
Lichtkanal 2: Sensor 1+3 GA2
Lichtkanal 3: Sensor 2+4 GA3
Lichtkanal 4: Sensor 1-4 GA4

VPM1: GA1 und damit Sensor 1+2
VPM2: GA2 und damit Sensor 1+3
...
VPM5: GA1 oder 2 oder 3 oder 4 und damit eine Dublette bzgl. der Sensorkombination.

Alles nach den Sensoren kann ich im VPM variieren, die Sensorauswahl ist aber immer nur eine Dublette der vier "original" Sensorkombinationen/Lichtkanäle.

Hätte der VPM die Sensoren einzeln und würde die Applikation kein Limit für Lichtkanäle setzen, dann könnte ich >4 Lichtkanäle anlegen, die sich auch in der Sensorkonfiguration unterscheiden und nicht nur bzgl. Zeiten oder Helligkeit, also z.B. auch einen Lichtkanal der zusätzlich zu den oben gelisteten Kombinationen Sensor 3+4 nutzt oder 1+4.

Habe aber verstanden, dass ihr das als irrelevant anseht.

[willisurf]

Hätte der VPM die Sensoren einzeln und würde die Applikation kein Limit für Lichtkanäle setzen, dann könnte ich >4 Lichtkanäle anlegen MIT unterschiedlicher Sensorkonfiguration, also z.B. auch einen Lichtkanal der zusätzlich zu den oben gelisteten Sensor 3+4 nutzt.

Das kannst Du immer noch tun. Du musst nur im Sensor die LK nutzen. Ich habe z.B. einen BJ Komfort und nutze die 4 Sensoren für 3 Ausgangs GAs.

[mumpf]

Natürlich kannst Du auch alle 4 Sensoren einzeln an den VPM senden. Aber der VPM-Kanal wird nicht noch weitere Eingänge für Sensoren bekommen. Es gibt 2 Wege, fast beliebig viele Präsenz-Sensoren an einen VPM-Kanal anzubinden (mal von der Telegrammlast abgesehen):

Der VPM-Eingang ist triggernd, wertet also nur EIN-Signale aus. Dann kannst Du alle Sensoren-GA (auch mehr als 4) auf diesen Eingang legen. Deine Quelle muss dann eben nachtriggern können, also die EIN-Signale wiederholt senden können, grobe Regel: Doppelt so oft wie die minimale Nachlaufzeit im VPM-Kanal (oder Kanälen).

Oder der VPM-Eingang ist schaltend, wertet also EIN- und AUS-Signale aus (aus meiner Sicht ist das zu bevorzugen, weil es die Telgrammanzahl reduziert, da man kein Nachtriggern braucht): Dann kannst Du Deine Sensor-Kombinationen auf ein ODER vom integrierten Logikmodul legen und dessen Ausgang mit dem VPM-Kanal verbinden. Bei 99 Logikkanälen kannst Du Dir hier theoretisch ein ODER mit 100 Kanälen basteln. Somit gibt es hier auch keine wirkliche Limitierung.

Du kannst Dein Szenario also durchaus verfolgen, es spricht nichts dagegen. Schon jetzt, ohne irgendwelche Erweiterungen. Ich würde das nicht machen, wenn es nicht nötig ist, aber Du kannst es machen.

Gruß, Waldemar

[Sven1234]

Dass man das Szenario umsetzen kann, stelle ich nicht in Frage. Meine Annahme, dass man einmal alle Sensoren: Präsenz, Helligkeit u.ä. 1:1 in den VPM legt und ab da alles, inklusive Sensorkombinationen, nur noch über den VPM macht, war einfach falsch. Ich nahm an, dass man den original PM zum "dummen" Sensorhalter macht, der ohne irgendwelche Logik (Kombination), seine "Rohdaten" weitergibt. Stattdessen setzt das Konzept eine Stufe später an und man muss mit Logiken arbeiten, wenn einem die Lichtkanäle im original PM ausgehen. In einem solchen Fall wäre die 1:1 Verknüpfung mit einem VPM und dazugehörigen, d.h. in diesem gruppierten, Lichtkanäle komfortabler, da man dann nicht getrennt vom VPM Logiken anlegen und interne KOs manuell miteinander verbinden müsste. Man würde einfach zu einem vorhandenen VPM einen weiteren Lichtkanal hinzufügen und eine beliebige Sensorkombination konfigurieren.

Oder in kurz, "PM 1: ..." aus der Applikation lässt mein Hirn ein Gerät/einen Präsenzmelder erwarten, es sind aber nur Lichtkanäle, ohne Sensorauswahl.

Ich muss nochmal drüber nachdenken. Wenn ich im original PM einen Lichtkanal habe, der Sensor 1+2+3 zusammenfasst, dann schaltet der einmal, wenn jemand in Sensor 2 läuft. Das wäre bei einer 1:1 Verknüpfung auch der Fall - also keine zusätzliche Buslast. Läuft die Person weiter und löst auch noch Sensor 3 aus, dann schaltet der original PM nur dann nicht, wenn kein anderer Lichtkanal Sensor 3 enthält, ansonsten schaltet er nocheinmal, was bei einer 1:1 Verknüpfung auch der Fall wäre - also keine zusätzliche Buslast.

Das heißt ich "spare" nur die Buslasten, bei denen ein Sensor auslöst, der sonst in keinem anderen Lichtkanal vorkommt als dem, der bereits aktiv war. Oder habe ich da einen Denkfehler?

Wenn ich einen vier Sensor-PM nur als Alarm nutze, dann kann ich damit viermal Buslast, statt einmal, erzeugen, wenn ich durch alle vier Sensoren renne - ja, kann vorkommen. Das wäre der schlimmste, anzunehmede Fall. Allerdings würde man sich für so einen Fall entweder keinen Vier-Sensoren-PM kaufen oder nutzt eben doch einfach einen Lichtkanal. Bei mehreren Zonen will man in der Regel auch kombinieren oder vereinzeln. Mal sehen, wie häufig ich an das Limit der original PM Lichtkanäle stoße.

[willisurf]

Alle meine PMs haben mindestens so viele Lichtkanäle wie Sensoren. Scheint mir auch durchaus üblich.
D.h. ich habe bisher noch keine Einschränkungen wahrgenommen und wenn man die schaltende Variante benutzt (bei mir zu 100%) hält sich die Buslast sehr in Grenzen. Da generiert die zyklische Helligkeitsübertragung oder die Übertragung von Bewegung (statt Präsenz) deutlich mehr Buslast.

[mumpf]

Mal sehen, wie häufig ich an das Limit der original PM Lichtkanäle stoße.

Hm... ich hab sicherlich nicht den Marktüberblick, aber die PM, die ich kenne, haben keinen Rohdaten-Ausgang für die Präsenzsesoren, nur für die Helligkeit. Ich muss den Sensor immer einem Lichtkanal zuordnen und kann dessen Ausgang zum weiterleiten verwenden.

Aber unabhängig davon, es ist auch eine konzeptionelle Entscheidung, die ich schon vor laner Zeit für meine Applikationen getroffen habe:
Ich halte bei meinen Kanälen keine KO vor, die nur selten gebraucht werden. KO sind "teuer", weil sie statisch RAM belegen, performance kosten, hohen Aufwand bei Updatefähigkeit verursachen, Änderungen erschweren usw. Und in der ETS muss man immer die Maximalanzahl von Objekten vorhalten und kann diese höchstens ausblenden.
Wenn also ein Kanal (bei egal welcher Applikation) mehrere gleichwertige KO haben könnte (vor allem wenn diese nur trivial über UND oder ODER verknüpft sind), wirst Du bei meinem Applikationen normalerweise diese optionalen Eingänge nicht finden, da das immer mit der beiliegenden Logik einfach umgesetzt werden kann. Die eingesparten KO kommen dann der Kanalanzahl zugute.
Natürlich muss man mit meinen Konzepten nicht einverstanden sein, aber ich hab das nicht "einfach nur so" gemacht, sondern mir dabei was gedacht. Auch den Punkt, dass - wenn ich jetzt 4 Eingänge gemacht hätte - in 2 Jahren vielleicht jemand kommt, der einen PM mit 5 oder 6 Sensoren hat und dann sagt "mach mehr".

So skaliert das Ganze sehr gut. User, die geringe Wünsche/Ansprüche haben, kommen mit den vorhandenen 1 oder 2 Eingängen aus und schnell zum Ziel. Wenn man höhere Ansprüche hat, kann man das immer noch gut und komfortabel realisieren, muss aber etwas mehr dafür machen.

Ist übrigens ein weiterer Leitsatz, an dem ich versuche, mich "langzuhangeln": Einfache Dinge müssen einfach gehen, komplizierte Dinge dürfen ruhig komplizierter sein (aber nicht kompliziert).

Gruß, Waldemar