Defaultwerte Kommunikationsobjekte

[lidl]

Ich habe einige konventionelle Taster an den Weinzierl Binäreingang angebunden. "Funktion schalten", "Aktion Ausgang A" = "Umschalten".
Aus der Dokumentation geht leider nicht hervor, mit welchem Wert (1 oder 0) der Ausgang initialisiert wird. Ich gehe mal von 0 aus.

Kann man hier irgendwie Default-Werte konfigurieren?

Ich habe mir das auch beim MDT Binäreingang angeschaut. Auch dort dürfte man keine Default-Werte vergeben können.
Gefunden habe ich nur die Funktion "Verhalten bei Busspannungswiederkehr" --> "Werte für Umschaltung abfragen". Ich schätze dass ich damit über das Status-Objekt des Aktors den "Soll-Wert" des Tasters festlegen kann.

Das ist aber nicht das was ich Suche. Der Status des Binäreingangs wird nämlich nur im MDT-Logikmodul weiterverarbeitet. Ein Aktor kommt da garnicht zum Einsatz.

[gbglace]

Tja wenn es keine weiteren Optionen zum Verhalten bei Busspannungswiederkehr hast wird da wohl nichts passieren.
Sonst must deiner Konstruktion halt beibringen ggf zyklisch den Ausgang / Zustand der Logik zu senden, dann ist der BE nur ne begrenzte Zeit undefiniert.

Gibt es ggf ne andere Lösung, was soll denn mit der Konstruktion erreicht werden?

[Gast1961]

Ich habe einige konventionelle Taster an den Weinzierl Binäreingang angebunden. "Funktion schalten", "Aktion Ausgang A" = "Umschalten".
Aus der Dokumentation geht leider nicht hervor, mit welchem Wert (1 oder 0) der Ausgang initialisiert wird. Ich gehe mal von 0 aus.

Warum raten, wenn man es testen kann? Frag doch einfach mal den Zustand nach dem Neustart per ETS Diagnose ab.

[lidl]

Warum raten, wenn man es testen kann? Frag doch einfach mal den Zustand nach dem Neustart per ETS Diagnose ab.

Ich präzisiere: Ich habe theoretisch einige konventionelle Taster an den Weinzierl Binäreingang angebunden. Ich hab die Hardware noch nicht ^^.

Sonst must deiner Konstruktion halt beibringen ggf zyklisch den Ausgang / Zustand der Logik zu senden, dann ist der BE nur ne begrenzte Zeit undefiniert.

Dem kann ich noch nicht ganz folgen, versuche das aber noch.

Gibt es ggf ne andere Lösung, was soll denn mit der Konstruktion erreicht werden?

Primär war das eine grundsätzliche Frage, ob es eine Möglichkeit gibt die Werte der Gruppenadressen zu speichern, bzw. default-werte zu vergeben. Scheinbar gibt es dazu aber keine allgemein gültige Antwort, nachdem KNX ja einen dezentralen Ansatz verfolgt. Es bräuchte einen persistenten Speicher.

Aufgefallen ist mir diese Herausforderung bei dieser Logik hier:
https://knx-user-forum.de/forum/%C3%...t-es-einfacher
GA "Berechtigung_Erforderlich" welche per konventionellem Taster am Weinzierl geändert werden soll.

[lidl]

Gut im Logik-Modul hab ich jetzt was gefunden, was da vl. helfen könnte:

Bildschirmfoto 2019-05-09 um 20.04.22.png


In der Tiefe ist mir das aber trotzdem noch unverständlich.

• Bus startet, Taster "Berechtigung erforderlich" wurde noch nicht gedrückt.
• Welchen Wert hat die zugehörige GA "Berechtigung erforderlich" dann? (Auf der GA liegt nur der Taster). Annahme: 0 (Angenommen der Weinzierl liefert 0 per default), Undefined oder Null wird es wahrscheinlich ja nicht geben.
• Wofür ist dann der oben markierte rote Bereich überhaupt noch gut? Die GA hat ja einen Wert, da brauch ich die Eingänge nicht noch manuell vorbelegen. Oder gehts da um die paar Sekunden, die vergehen bis alle Geräte gebootet sind und korrekt arbeiten?

[gbglace]

Das liegt nicht daran das KNX dezentral organisiert ist sondern die Verarbeitung eventbasiert erfolgt. Passiert irgendwo etwas wird ein Telegramm ausgelöst und alle Geräte die mit der GA verbunden sind reagieren dann wie parametriert darauf. Einige Geräte speichern sich dann intern den zuletzt empfangenen Wert andere, die Werte erzeugen, können auch von extern gebeten werden den Zustand zu senden (Readrequest).

Bei Busreset haben alle Eingangs KO einen leeren Zustand bis irgendein Gerät ein erstes Telegram sendet. Ein normaler Taster muss sowas nicht, macht ja auch kein Sinn, von daher findet man in den Applikationen dazu meist auch keine Einstellungen. Aktoren hingegen haben meist Einstellungen um genau zu definieren wie der Kanal bei Busreset gestellt werden soll. Wetterstationen usw. können eingestellt werden das sie eben einfach zyklisch Ihre Werte senden, damit eben nach einer gewissen Totzeit nach Reset alle Systeme am Bus wieder enen definierten Zustand haben.
Logikserver werden gern so eingestellt das diese nach Busreset eben für ihre Eingänge Redrequests senden, damit die üblicherweise den Status senden Geräte diesen nochmal ausgeben (Aktoren) und die Server (meist ne Visu) wieder sinnvolle Daten anzeigen.

Deine Logik ist da quasi so ein Aktor und daher kannst Du da genau einstellen welcher Defaultwert bei Reset gesetzt werden soll um einen definierten Zustand der Logik zu erreichen.
Du solltest der Logik dann noch beibringen Ihr Ergebnis dann auch noch zeitnah zu senden, damit der Taster dann über den Statuseingang auch richtig toggeln kann.

PS:
Eine GA ist kein "physisches" Element im KNX, es ist quasi nur ein virtueller Draht über dem ein Telegramm transportiert wird. eine GA hat also niemals einen Speicher oder sonst eine geartete persistenz. Auf einer GA gibt es nur in dem Moment des Telegramtransfers eine Information. Träger/Speicher einer Information kann nur ein Gerät mit seinem KO sein. Wie die Informationen einer GA an einem KO verarbeitet werden regeln die Flags an den KO.

[lidl]

Hui. Danke für die umfangreiche Erklärung. Das macht einiges verständlicher.

Bei Busreset haben alle Eingangs KO einen leeren Zustand bis irgendein Gerät ein erstes Telegram sendet. Ein normaler Taster muss sowas nicht, macht ja auch kein Sinn

Gerade in meinem Fall würde das schon Sinn machen. Zumindest wüsste ich jetzt noch nicht wie ich das anders lösen könnte. Siehe weiter unten.

Deine Logik ist da quasi so ein Aktor und daher kannst Du da genau einstellen welcher Defaultwert bei Reset gesetzt werden soll um einen definierten Zustand der Logik zu erreichen.

Hört sich sinnvoll an. Ich denke das ist genau der im obigen Screenshot rot markierte Bereich.

Du solltest der Logik dann noch beibringen Ihr Ergebnis dann auch noch zeitnah zu senden, damit der Taster dann über den Statuseingang auch richtig toggeln kann.

Genau da sehe ich das Problem. Die Logik verarbeitet ja 4 Eingänge. Der Wert des Ausgangs sagt dann nichts mehr über den angenommenen Default-Wert des einen Eingangs ("Berechtigung_Erforderlich") aus.
Mir würde jetzt nur einfallen für diesen Taster eine eigene Logik mit Defaultwert bei Reset anzulegen. Input = Output. Der Wert geht auf den Statuseingang des Tasters und damit es sauber bleibt wird dieser auch für die obige Logik verwendet.
Alternativ könnte ich auch einen Aktor-Kanal verbraten um die notwendige Software-Funktionalität zu erhalten.

Alles in allem erscheint mir das aber schon sehr umständlich. Logik- und Aktorkanäle sind für so simple Sachen viel zu schade .
Kann aber auch sein, dass das für mich als Software-Entwickler der in der Regel alle Freiheiten genießt, einfach nur ungewohnt wirkt.

[gbglace]

Es ist ungewohnt.

Aber soweit hast nun alles erfasst. Ich glaube wenn Du HW hast lässt sich mehr experimentieren und ggf noch ne andere Lösung finden.

[lidl]

Jup, Danke.

Ich muss mal testen, wie das Toggeln nach Busspannungsausfall bzw. Ausfall der 24V Spannungsversorgung reagiert.

Wenn das mal geklärt ist hilft vl. auch die Möglichkeit einen zusätzlichen Kanal des Weinzierls als Ausgang zu definieren. Die Kanalkosten sind da ja überschaubar und es stehen die Funktionen "Rückmeldung", "Verhalten bei Busspannungsaufsfall" und "Verhalten bei Busspannungswiederkehr" zur Verfügung. Damit hätte ich zumindest einen definierten Wert für das KO. Da der Taster am Eingang den Wert nicht einlesen kann muss man da anscheinend basteln. Deshalb ist es mal wichtig zu schauen wie der reagiert.

[Beleuchtfix]

Dein Problem ist, dass dich nicht der Wert des angeschlossen Tasters interessiert, sondern die dadurch ausgelöste Umschaltung. De Taster wird zu 99% offen sein, also 0. Bei einem Umschalter wird der erste Impuls immer ein Ein (1) sein, es sei denn, das du den Status eines Aktors abfragst. Dieses Grundproblem wirst du bei jedem Umschalter haben.
Gruß Florian

[hjk]

Den Wert für Umschaltung kann man im Logikmodul bei Busspannungsausfall abspeichern und bei Wiederkehr senden. Das kostet zwar eine Funktion, löst aber dass Problem des fehlenden Status, da es keinen Aktor gibt. Dann funktioniert der Umschalter auch in diesem Sonderfall immer sauber.

[lidl]

Den Wert für Umschaltung kann man im Logikmodul bei Busspannungsausfall abspeichern und bei Wiederkehr senden.

Super. Danke für die Info.
D.h.: Das Logikmodul hat einen persistenten Speicher oder?

[oggy]

ein reines Logikmodul hätte ich jetzt auch vorgeschlagen. Ich hab so einen "virtuellen" Schalter für den Schlafmodus (bzw für jeden Schlafraum einen virtuellen Schalter) genommen. Bei einem Busspannungsausfall wird dann der letzte Zustand wieder auf den Bus geschickt. So kann man in der Nacht weiterschlafen und wird nicht durch die wiederkehr des Stroms durch Licht geweckt (Präsenzmelder bleibt gesperrt).

[oggy]

D.h.: Das Logikmodul hat einen persistenten Speicher oder?

Es gibt eine Funktion auf dem Logikmodul, die das abbilden kann, aber es ist nicht bei jeder Funktion verfügbar.

[lidl]

Ich hab so einen "virtuellen" Schalter für den Schlafmodus

"Virtuelle Schalter" trifft es ganz gut. Oder Schalter ohne direkter Aktorik, sondern eben mit zwischengeschalteter Logik. Wundert mich, dass unser Vorhaben ein "Sonderfall" ist .

Es gibt eine Funktion auf dem Logikmodul, die das abbilden kann, aber es ist nicht bei jeder Funktion verfügbar

Danke, die werde ich dann schon finden. Die Frage bzgl. des persistenten Speichers war eher grundsätzlicher Natur, weil ich wissen wollte wie das Logikmodul das löst. Eigene Spannungsversorgung hat es ja keine. Gut, das haben die Aktoren von MDT auch nicht und können die Wert speichern.