Bewegungsmelder und BUS-Reset

[lopiuh]

Hallo zusammen,

Beim Applikations-Upload („Programmieren“) oder Bus-Reset möchte ich:

1. Lichtzustand erhalten (an bleibt an, aus bleibt aus).
2. Licht das an war, nach Ablauf der Ausschaltzeit ohne Bewegung wieder ausschalten.

Meine BWM:

• Elsner Intra-Sewi TH-L-Pr
• Steinel 400784105xxxx, Gen 3000 IS 3360
• MDT SCN-P360D4.03, SCN-P360K3.03, SCN-P360D4.02
• BEG PD2-KNX-DIM-AP
• ESYLUX BASIC

Probleme:

• MDT SCN-P360D4.03 sendet nach Reset direkt „AUS“, kein Status-Read. → Anforderung 1 nicht erfüllt.
• ESYLUX BASIC liest den Lichtstatus nicht aus, Licht bleibt u. U. an. → Anforderung 2 nicht erfüllt. Man kann ihn auf Ein/Aus/keine Aktion konfigurieren.
• Steinel Gen 3000 IS 3360 sendet nach Reset immer „Ein“ (und direkt danach "Aus").Anforderung 1 nicht erfüllt

Lösungsidee: Treppenlichtfunktion der Aktoren, BWM nur Ein-Signale senden lassen. Hilft aber nicht in allen Fällen, siehe Steinel

Unverständlich, dass solches Verhalten nicht dokumentiert ist – KNX ist doch der „Goldstandard“?!

Gruß
lopiuh

[gbglace]

kein Status-Read.

dazu mal das I-Flag am KO mit der Status-GA probieren.

Unverständlich, dass solches Verhalten nicht dokumentiert ist – KNX ist doch der „Goldstandard“?!

KNX ist so Goldig, das stellst ein und dann läuft das einfach durch, wozu also ständig Reset?

Inhaltlich kann Anforderung 1 eigentlich so pauschal auch gar nicht funktionieren, gerade in Bezug nach neuer Programmierung.
Ein PM ist ja gar kein Aktor, sondern ein Sensor und viel logik. Und nach jeder Programmierung kann ja die Konsequenz aus erkannter Bewegung ja/nein eine komplett verschiedene sein.
Insofern ergibt es keinen Sinn das das Ausgangsignal nach Programmierung identisch ist wie vor Programmierung.

Das der PM aber selbst aktiv nach ggf notwendigen Eingangssignalen schaut (wie ein zusätzlicher Status) ist eine berechtigte Anforderung. Aber das er selbst weiß, dass er zuletzt noch in einer Nachlaufzeit für dem Kanal stand ist wohl ein falsches unnötiges Gedächtnis. Und rein die Information, das der Status vom Aktor EIN liefert kein ausreichender Hinweis dafür das das Ausgangsignal auch EIN sein muss, denn Wenn neben dem PM auf dem Aktor oder in weiteren logiken noch ergänzende Abhängigkeiten wie eine Ausschaltverzögerung oder Sperren usw. wirken, dann ist das im Zweifel falsch anzunehmen das der PM zu letzte Bewegung hatte und nun nochmal die Nachlaufzeit mit dem Status EIN runterzählt.

Insofern würde ich sagen Zusätzliche Eingänge für externen Status, ja das sollte der PM einlesen aber daraus keine Aktion ableiten. Und einfach mit nächster Erkannter Bewegung so reagieren wie parametriert. Er ist eben ein Sensor.

Ein Aktor hingegen, der kann bei Busrest gern den Zustand wie vor Programmierung beibehalten oder einen spezifischen Schaltzustand einnehmen. Nachfolgend erhält er dann aber einfach die neuen Befehle.

[lopiuh]

Danke Dir ... dem kann ich weitestgehend folgen.

Dass einm BWM einfach AUS sendet (wie es scheinbar die MDTs machen, werde den Support mal anschreiben) finde ich unnötig. Ich "programmier" halt gerne (als Elektroniker und SI in spe) und habe nichts desto trotz ein bewohntes Haus. Und wenn ich ein Gerät neu konfiguriere, das seine Status beim Neustart nicht sauber abfragt, muss ich einen BUS-Reset machen, um alle Zustände (und somit auch das des konfigurierten Geräts) in einen integeren Zustand zu versetzen.
:-/
klar mein Szenario ist jetzt in keinster Weise die Referenz ;-)


LG

Frank

[mumpf]

muss ich einen BUS-Reset machen, um alle Zustände (und somit auch das des konfigurierten Geräts) in einen integeren Zustand zu versetzen.

Sorry, aber das ist quatsch. Es reicht, einfach nur die ReadRequests in der ETS abzusetzen, die Du beim Gerät vermisst. Oder Du hast ein anderen Gerät, dass ReadRequests senden kann und dass Du antriggerst. Ein Busreset ist doch etwas sehr mit Kanonen auf Spatzen geschossen...

Gruß, Waldemar

[lopiuh]

Ok, gute Info .... kontrollieren, dass die Empfänger KOs das A-Flag gesetzt haben und das sollte funktionieren. Aus der ETS kann man ja auch gut eine Menge an Readrequest in einem Rutsch absenden ..., ich glaube, dass ist eine gute Lösung. Wobei ich den BUS-Reset auch mache, um eben zu kontrollieren, ob bei einem BUS-Reset der Status (wegen Startreihenfolge/Geräteanlaufzeit) stimmt. Aber auf die ETS-Lösung bin ich noch gar nicht gekommen...

LG

lopiuh

[gbglace]

Ja die ETS ist eben DAS KNX-Werkzeug.
Auch wenn es angenehmer zu bedienen sein könnte.

[hjk]

Dass einm BWM einfach AUS sendet (wie es scheinbar die MDTs machen, werde den Support mal anschreiben) finde ich unnötig.

Das ist sogar wichtig, sonst kann es sein, dass z.B. nach einem längeren Stromausfall das Licht im Keller wochenlang an ist.
Ist dort Bewegung, wird das Licht sofort wieder eingeschaltet. Wenn das Licht kurz aus geht, ist das normal kein Problem, bleibt es aber einfach an, ist das ein klares Fehlverhalten. Viele Melder haben auch gar keinen Status vom Aktor.

[lopiuh]

Das ist sogar wichtig, sonst kann es sein, dass z.B. nach einem längeren Stromausfall das Licht im Keller wochenlang an ist.
Ist dort Bewegung, wird das Licht sofort wieder eingeschaltet. Wenn das Licht kurz aus geht, ist das normal kein Problem, bleibt es aber einfach an, ist das ein klares Fehlverhalten.

Hallo HJK, das wollte ich nicht provozieren, dass Du dich einschalten musst 😁.

Zum ungrewollten Licht anbleiben: Dagegen habe ich als Auffangnetz nahezu alle Lichter mit Treppenlichtfunktion am Aktor versehen (auch bei den Lichtern ohne BWM, die nur manuell eingeschaltet werden und vielleicht vergessen wurden auszuschalten: Balkonlicht/Terrasse:6-8 Stunden, danach ist auch die längste Party zu Ende.

Der BWM könnte doch den Status vom Aktor anfordern und eine Minute warten. Wenn kein Response kommt und ein etwaig nach dem BWM gestarteter Aktor seinen Status nicht sendet, dann von mir aus ein paranoia AUS senden.

Oder ist das als Anforderung / Lösung zu "übertrieben"? Ich komme aus dem Softwarebereich und da bin ich auf "Init" und Zustandskonsistenz / -übergänge vielleicht übersensibilisiert. Auf der anderen Seite sind natürlich ausreichend einfache Lösungen zwecks Komplexitätsvermeidung immer zu bevorzugen.

Wenn ich daran denke, dass wir im öffentlichen Treppenhaus die Pflicht der Ausschaltvorwarnung haben, finde ich ein "unnötiges" Ausschalten bei Bus-Reset zumindest diskussionswürdig 🤔 Wobei stimmt schon, die Ausschaltvorwarnung ist ja in der Wirkung (kurz aus und wieder an) vergleichbar mit dem kurz ausschaltende BWM, ja vielleicht verrenne ich mich da in meinem Problem, dass es Tage gibt, in denen ich zu häufig dinge in der Anlage ausprobiere und meinen Mitbewohnern deshalb das Licht ausgeht (oder mitten in der Nacht Ein...)

Viele Melder haben auch gar keinen Status vom Aktor.

ok, dann ist natürlich alles verloren

Gruß

lopiuh

[lopiuh]

Sorry, aber das ist quatsch. Es reicht, einfach nur die ReadRequests in der ETS abzusetzen, die Du beim Gerät vermisst. Oder Du hast ein anderen Gerät, dass ReadRequests senden kann und dass Du antriggerst. Ein Busreset ist doch etwas sehr mit Kanonen auf Spatzen geschossen...

Gruß, Waldemar

würde gut hierdurch automatisierbar:

Hi,

ich suche schon seit längerer Zeit nach einer Möglichkeit, auf dem Bus zu erkennen, dass ein Gerät erfolgreich programmiert worden ist (und natürlich welches). Bisher erfolglos. Mir hilft hier HomeAssistant (unabsichtlich), da die jede Stunde den Status vom Bus lesen. Damit hat man nach der Programmierung eines Gerätes höchsten 1 Stunde lang falsche Zustände. Ist nicht perfekt, da man potentiell noch weitere Aktionen braucht, um Sagen gerade zu ziehen, aber es ist ein kleiner Schritt vorwärts.

Gruß, Waldemar

Hallo @Mumpf,

hast Du zu diesem Punkt neue Erkenntnisse? "Möglichkeit, auf dem Bus zu erkennen, dass ein Gerät erfolgreich programmiert worden ist", bibber, hoff, 4 Jahre: ;-)

Gruß

lopiuh

[mumpf]

Ich weiß, wie es gehen würde, aber es ist nicht einfach zu realisieren. Damit ein KNX-Gerät mitbekommen kann, dass ein anderen programmiert bzw. eben fertig mit dem Proggen ist, müsste das Gerät im Busmonitor-Modus laufen (damit es eben alle Telegramme mitbekommt). In diesem Modus kann es aber keine normale KO-Kommunikation machen, um selber was zu senden. Also müsste es immer wieder den Busmonitor-Modus verlassen, um auf den Bus zu senden, dass ein Gerät fertigprogrammiert wurde. Oder man arbeitet mit 2 BCUs, die eine im Busmonitor-Modus und die andere im normalen Modus. Alles sehr aufwändig und mit recht geringem Nutzen für diese eine Funktion.
Also kurz gesagt: Es gibt hier nichts und ich gehe nicht davon aus, dass es da was geben wird.
Gruß, Waldemar

[lopiuh]

danke für die Info! LG lopiuh