Ankündigung

**jonofe** · 05.05.2019, 10:33

Edomi sollte doch immer den aktuellen Zustand kennen, denn er hat ja die Werte in der Logik "berechnet".
Edomi liest ja beim Start per Initscan alle KNX Daten, die relevant sind und triggert dann die Logiken.
Ich bin nicht sicher, dass ich verstehe, was du genau speichern willst.
Szenen sind bei mir Trigger ohne Status-Objekte, da man ja auch Elemente einer Szene auf andere Weise verändern kann und somit die Konsistenz nicht mehr gewährleistet wäre. Beispiel: Szene "TV": Rolläden runter, Licht auf 20%. Wenn nun jemand das Licht auf 50% ändert, in welcher Szene bin ich dann?

Vielleicht habe ich dich auch nicht richtig verstanden...

**saegefisch** · 05.05.2019, 10:49

Hat auch etwas mit der eigenen Phiolosophie bei der Umsetzung zu tun.

Der eine hält die KNX-Objekte absolut "dumm" und lässte alles edomi machen -> klare Trennung in HW und Logik, aber kein unmittelbares Fallback, wenn edomi mal weg wäre
Der andere wählt einen Zwischenweg: Minimal-Funktionen (z.B: in jedem Raum mindestens ein Lichtkanal in TS und Aktor), aber alle Komfortfunktionen nur in edomi -> nicht immer eine klare Trennung (und hier greift auch Deine Frage hin), aber das Haus ist auch edomi noch unmittelbar "lebensfähig"
Der andere wählt so viel wie per KNX möglich ist im Bus und ergänzt nur die Komfortfunktionen, die nicht damit lösbar sind

Du musst schauen, ob Du Typ 1 bist oder Typ 2/3. Bei Typ 1 dürfte die Antwort "nur edomi" heißen. Ich bin Typ 2 und meine "golden Source" für jeden (!) Status ist immer edomi, aber einzelne, wenige Status trage ich auch in den Bus, um sie in Aktoren nutzen zu können (z.B: einzelne Sperren). Eigentlich dürfte es bei den von Dir geschilderten Status ja auch um Komfort-Funktionen gehen und keine Frage Haus-Überlebensfähigkeit - was auch zur Antwort "edomi" führen würde.

Und natürlich stimme ich André und seinem Beispiel zu: Das ist genau so und real. Deine drei Beispiele wären vermutlich aber klarer, da binär wahr. Es bleibt aber für Dich konzeptionell zu klären.

Die Antwort auf Deine Frage kannst Du Dir mit diesen Einordnungen nun hoffentlich selber geben. Denn nur Du weisst, was DU möchtest und welche Balance DU zwischen Sicherheit, Komfort, KNX-Erfahrung, Lust und Freude,... hast und welche Balance auch zu der Lebenswirklichkeit Deiner Familie (WAF,wie Technik-affin?, ...) und Deines Haus passt (ist ja auch eine Frage der Sensorik).

**gkamp** · 05.05.2019, 11:04

Hallo jonofe und saegefisch ,

Danke für Eure Antworten.

jonofe : Habe verstanden was Du meinst. Ich rede nicht von Szenen oder darin enthaltene Einzelzuständen, sondern bspw. vom allgemeinen "Anwesend/Abwesend"-Zustand. Und dieser Zustand ist nicht zwangsläufig "nur berechnet", sondern auch manuell von einem Taster (bspw. beim Verlassen des Hauses) verändert.

saegefisch : Ich bin sicher auch Typ2 laut Deiner Definition.

Vielleicht habe ich auch nur das berühmte "Brett vorm Kopf". Nehmen wir den Beispiel-Status "Anwesend (=1) / Abwesend (=0)": Diesen könnte ich ja in edomi als remanentes iKO anlegen. Wie würde ich denn dann bspw. beim Verlassen des Hauses am Taster den Zustand umschalten können (Weggehen oder Heimkommen)? Ich müsste ja dann vom KNX-Bus den Wert eines internen edomi-iKOs schreiben bzw. umschalten und dafür auch den aktuellen Zustand kennen.

**saegefisch** · 05.05.2019, 11:19

Letztlich ist der TS ja nix anderes als die "Bewegung-erkannt"-GA eine PM: KNX-Gerät sendet eine "1".
Also gleiches Verfahren: Status 0/1 im TS in GA schreiben, GA in edomi bekannt machen und dort auswerten/Logik. Finalen Ergebnis-Status (denn wohl möglich ist der Status vom Taster ja nur die halbe Wahrheit für den Status "abwesend", z.B. BWM/PM, Erkennung von Geräten im WLAN,...) nur auf den Bus, wenn es dafür Bedarf gibt, ansonsten in edomi belassen.

**gkamp** · 05.05.2019, 11:32

Hi saegefisch , habe grundsätzlich alles verstanden was Du schreibst, mein Knoten ist allerdings immer noch nicht gelöst. Habe ich Dich richtig verstanden? Wie könnte es konkret aussehen?

- In Edomi ein remanentes iKO namens "Anwesend (=1) / Abwesend (=0)"
- Aus der ETS heraus eine GA namens bspw. "An-/Abwesend gedrückt", welches immer eine "1" auf den Bus sendet

Daraufhin würde dann in edomi der neue Status berechnet und evtl. verändert. Ich hätte dann aber auf dem Bus nicht die Info, ob "Anwesend" oder "Abwesend", oder? Mir fehlt dann allerdings die Möglichkeit bspw. für die Glastaster je nach Zustand anzuzeigen, ob "Anwesend" (bei Status "1") oder "Abwesend" (bei Status "0"). Dieses "Status-KO" habe ich nicht, oder sehe ich tatsächlich die Option nicht?

**jonofe** · 05.05.2019, 11:59

Einfach auch in der ETS zwei GAs:

1. Anwesend schalten
2. Anwesend Status

Beim Schalten bekommt EDOMI die Info und sendet den Status retoure auf den KNX. Den kannst du dann für die Status LED des Tasters verwenden.

In EDOMI kannst du entweder mit den KNX GAs arbeiten oder spiegelst sie auf iKOs.

Ggf. muss man dann das KNX Status Objekt des Tasters lesbar machen, damit es beim Start von EDOMI per InitScan gelesen werden kann oder aber beim Spiegeln auf iKOs das Status iKO remanent machen.

**gkamp** · 05.05.2019, 12:19

Hi jonofe , genau diese beiden Optionen habe ich auch gesehen. Danke, dann liege ich mit meiner Idee nicht falsch. Was ich mich dabei dann gefragt habe: Kann bei Deiner ersten Option (KNX-GA und kein internes iKO) eine Status-GA eines Glastasters von edomi abgefragt werden bzw. was ist bei einer Aktualisierung (Neue Parametrierung) des Glastasters oder eines Bus-Resets? Bleibt der Status im KNX-Gerät gespeichert (also KNX-Remanent :-) ?

**jonofe** · 05.05.2019, 13:30

Bei einer neuen Parametrierung verliert doch m.W. jedes Gerät seinen Status, denn den bekommt er erst, wenn die GAs zum ersten Mal wieder über den Bus gegangen sind, das sollte nichts mit EDOMI zu tun haben. Aber da EDOMI für den Status deiner Taster-LED verantwortlich ist, solltest du diese GA in EDOMI so konfigurieren, das sie per KNX abfragbar ist, z.B.

Screenshot from 2019-05-05 14-28-46.png
Damit würde es sowohl beim Start von EDOMI auf den KNX gesendet (InitSend), als auch vom KNX aus abfragbar/lesbar sein (WRITE/Automatisch antworten).

**gkamp** · 05.05.2019, 19:02

Ja, sehe ich genauso. Um es konkret zu machen, bräuchte ich dann aber doch mehrere KNX-GA und mind. 1 Edomi-internes iKO, oder?

Also im Beispiel mit den folgenden zwei Komponenten "Edomi" und "KNX Glastaster":

- In Edomi ein internes iKO, welches den Zustand verantwortlich hält und speichert (remanent)
- Beim Glastaster eine GA, welche beim Umschalten den Wert erhält und außerdem eine Status-GA, welche beim Taster für den Umschalt-Status verantwortlich ist

Da nur das interne Edomi iKO remanent den Status speichern kann, müssen doch auch die beiden KNX-GA mit in der Edomi-Logik eingebunden werden und bei jeder Änderung des iKO dieser Status auch per Logik (gibt es da etwas fertiges?) auf den Bus per Status-GA gesendet werden, oder?

**Robby** · 05.05.2019, 19:14

Zitat von gkamp Beitrag anzeigen

Ja, sehe ich genauso. Um es konkret zu machen, bräuchte ich dann aber doch mehrere KNX-GA und mind. 1 Edomi-internes iKO, oder?

Also im Beispiel mit den folgenden zwei Komponenten "Edomi" und "KNX Glastaster":

- In Edomi ein internes iKO, welches den Zustand verantwortlich hält und speichert (remanent)
- Beim Glastaster eine GA, welche beim Umschalten den Wert erhält und außerdem eine Status-GA, welche beim Taster für den Umschalt-Status verantwortlich ist

Da nur das interne Edomi iKO remanent den Status speichern kann, müssen doch auch die beiden KNX-GA mit in der Edomi-Logik eingebunden werden und bei jeder Änderung des iKO dieser Status auch per Logik (gibt es da etwas fertiges?) auf den Bus per Status-GA gesendet werden, oder?

Warum denn z.B. ein IKO für den Status eines Schaltausgangs erstellen? Edomi erhält doch beim Initialisieren durch "Init Scan" die Werte der KO´s. Bei Wertänderungen bekommt das Edomi doch auch mit.

**jonofe** · 05.05.2019, 19:24

Ja genau ... so z.B.:

Screenshot from 2019-05-05 20-18-03.png
Damit setzt EDOMI beim Drücken des KNX Tasters zunächst das interne remanent KO und das triggert dann das Senden des KNX Status KO.
Man hätte auch beides in der oberen Ausgangsbox machen können, aber die Separierung macht Sinn, da die Funktion des Tasters (z.B. Abwesenheit) auch z.B. über die VISU gesetzt werden könnte, dann müsstest du nur den auf das iKO Schreiben und damit wird dann auch der KNX Status geupdated. Zusätzlich kannst du ja mit dem iKO noch deinen Logiken triggern, die dann dein Haus in den StandBy Modus versetzen.

Bei manchen meiner Logiken lege ich zwei Pärchen von GAs/iKOs an und habe dann nur eine Logikseite, die das Mapping macht und arbeite in den eigentlichen EDOMI Logikseiten nur noch mit den iKOs.

**jonofe** · 05.05.2019, 19:27

Zitat von Robby Beitrag anzeigen

Warum denn z.B. ein IKO für den Status eines Schaltausgangs erstellen?

Der Punkt ist ja, dass es kein Schaltausgang ist, sondern nur ein Taster, welcher aber nur eine Funktion in EDOMI triggern soll.
Und da EDOMI ja quasi der Schaltausgang ist, sendet EDOMI den Status. Daher sind ja meist die Status-Objekte eines Tasters nicht lesbar, da ansonsten Aktor und Taster antworten würden.

**gkamp** · 05.05.2019, 19:33

Danke jonofe für die Bestätigung und die Klarstellung zum Beitrag von Robby . Genau das ist ja mein "Problem", dass ich kein KNX-Gerät habe, welches den Status verantwortlich "hält" wie einen Schaltaktor. Daher der Weg über ein remanentes iKO in Edomi. Dachte es geht evtl. eleganter oder mit weniger KOs oder GA. Aber dann habe ich jetzt einen Weg und komme weiter.

Nochmals Danke an Euch alle!

**Helyx** · 06.05.2019, 10:44

Ich hab's bei den Stati so gelöst, das ich ein internes remanentes Edomi KO hab das 1-4 annehmen kann und somit keine Doppelbelegungen stattfinden kann.
1=anwesend(und wach)
2=schlafen
3=abwesend
4=Urlaub
Wenn dieses sich ändert werden 4 einzelne KNX GA beschrieben mit
anwesend=1
abwesend=1 etc.

Ankündigung

Was sind das für Zustände :-) ?

Was sind das für Zustände :-) ?

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar