Verhalten gewollt? Als "Requestable" gekennzeichnete GA wird von EDOMI immer als Response gesetzt

[NurMa]

Hallo,

ich möchte gerne den Schlafstatus verschiedener Räume remanent und abfragbar speichern.

GA 9/0/2 Schlafstatus_Set
GA 9/0/1 RM-Schlafstatus (Requestable)
Interne GA 559 Schlafstatus Remanent

Eine Logik schreibt alles was auf der 9/0/2 kommt direkt in 559. Jede Änderung auf 559 wird unverändert auf 9/0/1 geschrieben. Für 9/0/1 gibt es einen Requestauslöser, welcher den Wert von 559 auf die 9/0/1 schickt.

Funktioniert grundsätzlich super mit einem kleinen Problem:

Sobald ich die GA 9/0/1 als Requestable kennzeichne, sendet EDOMI alles auf die 9/0/1 als Response und nicht mehr als Write, auch wenn es nicht durch den Requestauslöser gesetzt wird. Ist für mich nachvollziehbar weil EDOMI ja nicht weiß ob das setzen der GA von einem Request oder "Normal" erfolgt. Führt aber dazu, dass das setzen als Response von Busteilnehmern (PMs, etc.) nicht angenommen wird, da kein Write.

Hat das schon jemand anders gelöst oder gibt es eventuell eine Möglichkeit EDOMI beizubringen, wann es ein Write und wann ein Response senden soll?

Grüße

Matthias

[gaert]

Das ist kein Bug Aber Du hast schon Recht - in manchen Situationen ist dieses Verhalten hinderlich. Geht aber aktuell nicht anders... Warum nicht einfach 2 verschiedene GAs nehmen? Die meisten KNX-Geräte können doch auf mehrere GAs "lauschen"...

EDIT: Ich hole mal noch etwas weiter aus...
Diese Option (Requestable) ist eigentlich nur dazu gedacht, dass andere Busteilnehmer z.B. die Uhrzeit abfragen können (so spart man sich eine Echtzeituhr in Hardware). Einige Anwender "missbrauchen" EDOMI jedoch z.B. als Logikengine - und machen z.B. die Visu mit anderen Systemen. Das führt dann gerne zu Missverständnissen/Problemen, da ich dies nicht vorgesehen habe. Nichtsdestotrotz mache ich mir mal Gedanken zu "requestable" (blöder Name, by the way...).

[NurMa]

Das ist kein Bug ...

Du warst zu schnell, hatte den Titel schon in "Verhalten gewollt?..." geändert. Bug trifft es wirklich nicht

Aber Danke für die schnelle Antwort. Die Lösung mit den 2 GAs wäre jetzt auch meine nächste Wahl gewesen. Hab noch ein paar in Reserve

[Stoxn]

Hi Matthias,

da bin ich auch schon öfters drüber gestolpert, zuletzt hier. Weitere Adressen fand ich nicht so schön, da ich im Grunde ein Rückmeldeobjekt simulieren möchte - die machen ja auch Schreiben und Antworten.
Mein Anwendungsfall hat sich jedoch erledigt, da ich die Logik vom Drittsystem auf edomi übertragen konnte.

Ich würde mich dennoch freuen, wenn es auf "die Liste" kommt :-)

Viele Grüße,
Patrick

[gaert]

Das ergibt sich ja von selbst - EDOMI hat selbstverständlich keinerlei Bugs

By Design ist es leider kaum möglich eine GA je nach Bedarf per "write" oder "response" zu senden. Das gibt die EDOMI-Struktur so auf die Schnelle nicht her... Wie gesagt: Ich denke mal drüber nach, vielleicht findet sich eine pragmatische Lösung - versprechen kann ich allerdings nichts (kommt erstmal auf meine Liste).

[NurMa]

Hi Patrick,

da gebe ich Dir recht. Genau das ist auch mein Ziel. Aber die Liste ist ja schon mal vielversprechend und die GA-Lösung geht für mich erst mal in Ordnung.

gaert
Eventuell eine einfache Checkbox "Als response senden" bei den entsprechenden Aktionen der Ausgangsbox?

[gaert]

Wenn es denn so einfach wäre

Die Herausforderung ist nicht die Umsetzung als solches, sondern das Einbauen in die vorhandenen Strukturen... EDOMI ist ja mittlerweile recht umfangreich und vielseitig

[NurMa]

Mittlerweile? Fand ich von Anfang an.

Aber klar, dass es mit einer Checkbox nicht getan ist.

[gaert]

Wie wäre es denn, wenn EDOMI immer(!) mit "Write" antwortet - statt mit "response"? Mögen das Eure Devices, oder erwarten die immer ein response nach einem read-Request?

[NurMa]

Also meine haben sich über ein "Write" noch nie beschwert. ist aber nicht so, dass ich das ausgiebig gestestet hätte.

Keine Ahnung ob da mit einem Timeout gearbeitet wird. Sowas würde ich aber eher von einer Logik-Engine erwarten.

[gaert]

EDOMI ist's (optional) Wurscht, ob beim Initscan ein Write oder ein response als Antwort kommt - Hauptsache es antwortet jemand. Per default wartet EDOMI aber auf ein response - denn so ist es "definierter". Zufällige Write-Telegramme könnten ja dazwischen funken oder noch auf dem Bus rumschwirren, obwohl der aktuellste Zustand vielleicht schon aktueller ist

Wie auch immer: Vielleicht biete ich diese Option optional demnächst mal an - dann sehen wir weiter.

[Stoxn]

Meine Aktoren senden bei Änderung ein Write, bei Anfrage eine Response. Das fände ich am "Schönsten".

Beim Testen mit meiner alten Logikengine ist mir aufgefallen, dass die immer ein Write raushaut und die Sensoren + Edomi das genauso nehmen. Alles auf Write sollte also passen. Bleibt die Frage, ob Du das mit Deinem Gewissen vereinbaren kannst ;-)

[gaert]

Schon klar - Response beim Read-Request und ansonsten Write Fände ich auch am Schönsten, ist aber (im Nachhinein) schwer zu implementieren.

Meine Gedanken gehen aktuell in diese Richtung: In der KO-Konfiguration wird man auswählen können, ob bei einem Request

- nichts passiert (requestable=aus)
- mit RESPONSE geantwortet wird (also per Requestauslöser-Logik - wie gehabt)
- mit WRITE geantwortet wird (ebenfalls per Requestauslöser-Logik)

Das bedeutet natürlich auch, dass je nach Einstellung die GA immer mit Response oder Write auf den Bus gesendet wird - egal ob diese abgefragt wurde oder nicht.

[Stoxn]

Wenn das einfach(er) zu implementieren ist, wäre das doch ein guter Mittelweg - würde bei mir funktionieren. Danke!

[gaert]

Wenn ich schon dabei bin, werde ich wahrscheinlich noch das "automatische Antworten" ergänzen - also wird ggf. der aktuelle GA-Wert auch ohne Logik bei einem Request gesendet. Ich halte dies zwar für Schwachsinn (der Wert schwirrt ja eh auf dem Bus herum, denn irgendwann musste die GA ja mal gesetzt worden sein), aber dieses Feature wurde ja schon mehrfach gewünscht...