Ja, aber wenn er über IPS schaltet, wie in meinem Beispiel oben, dann schaltet er ja von AUS auf AN. In dem Moment, wenn er anschaltet, gab es aufgrund der Zeitverzögerung noch keine Rückmeldung, in IPS steht aber AN, weil aus IPS heraus geschaltet wurde. Was nun?
Ich will nur vor Augen führen, dass eine realistische Darstellung, wie im ersten Beitrag gefordert wird, irgendwo immer einen Haken haben wird.
(Meine persönliche Meinung ist, dass in IPS hier nichts geändert werden muss. Wenn, dann höchtens optional).
Ah. Jetzt sehe ich es. Wenn Empfangen aus ist, simuliert IP-Symcon sofort die Wertänderung. Die Frage ist, wie viele „Empfangen“ auf AUS stellen und ob nicht ein besseres Verhalten wäre, wenn wir in diesem Zustand die Änderung nicht simulieren, sondern auf die tatsächliche Rückmeldung warten.
In KNX wäre ja ansonsten der andere Fall, dass Empfangen an ist und man den Zustand auf der Haupt GA weiter empfängt. (Dies entspricht ja deinem Use-Case)
Ich müsste mal schauen, warum wir dies überhaupt so gelöst haben. Aktuell kann ich den Wunsch von @integrator1 / @traxanos gut nachvollziehen und bin mir unsicher, was unser Beweggrund war den Wert zu simulieren - in KNX wird ja nämlich alles sauber bestätigt (auch sehr schnell!) und über das Empfangen Flag könnte man dan sauber entscheiden woher die Bestätigung kommen muss.
Hier ist die Frage, was meinst Du mit simulieren und sauber bestätigt? Meinst Du mit „bestätigt“ ein ACK auf dem Bus? Wenn ihr hier simuliert, anstatt auf ACK zu warten, dann fände ich das merkwürdig.
Ich gehe aber davon aus, dass die Rückmeldung des Status auf einer separaten GA gemeint ist. Alte Anlagen, in denen es keine Rückmeldungen gibt, sondern ausschließlich alles über eine Gruppenadresse geregelt wird, für die ist es so, wie es jetzt ist, genau richtig. Also die Aussage, dass alles sauber bestätigt (oder rückgemeldet) wird, kann man nicht pauschal stehenlassen. Außerdem sehe ich hier auch kein klassisches Simulieren wie z.B. bei HomeMatic wo der Status gesetzt wird, bevor er beim Gerät angekommen ist. KNX ist ja eigentlich nur ein Feuern von Telegrammen. Und sowie das Telegramm auf dem Bus mit ACK bestätigt wird, ist es irgendwo angekommen. Was dann hinten raus passiert kann IPS nicht wissen.
Ich würde am bisherigen Verhalten nichts ändern, sondern - wenn überhaupt - nur am Verhalten etwas ändern, wenn das Empfangen Flag deaktiviert wird.
Nur darum geht es. Das aktuell Verhalten bei Empfangen = AN ist definitiv korrekt. Dort warten wir übrigens nicht nur auf das ACK, sondern auf das echte „Echo“ vom Bus, dass die Schalt-GA geändert wurde.
Wenn Empfangen = AUS ist, warten wir nur auf das ACK und ändern die Variable sofort. Und dort kann ich die beiden verstehen, dass wir dieses Umschalten bei ACK deaktivieren könnten, um ein echtes Feedback auf der Status-GA zu erwarten.
Für deinen Use-Case (Empfangen = AN) würde sich nicht ändern.
Sehr gut. Aktuell sehe ich das Risiko als sehr gering, dass jemand auf das eher spezielle Empfangen = AUS Verhalten bewusst gesetzt hat und würde, sofern sich keiner „dagegen“ meldet dieses Umschalten bei ACK deaktivieren und schauen, ob jemand in der Beta Phase sich meldet, dass es Probleme gibt.
Insbesondere suggeriert die Beschreibung im Formular bereits genau das Verhalten - tut es aber nicht Ich bin ja selber darauf reingefallen und dachte wir unterstützen dies bereits und habe deshalb auch nicht verstanden was @integrator1 / @traxanos nicht erreichen können.
Hmm? Wieso? Wenn Empfangen an ist, dann reagiert die Instanz auf die Hauptadresse. Tut doch genau das, was da steht? Also irgendwie reden wir noch aneinander vorbei?
Die Frage ist halt wie sich eine KNX Instanz verhalten soll. Wenn eine Instanz lediglich ein dummes KO abbildet, dann macht IPS erstmal alles richtig. Dann verhält es sich, als würde man in der ETS ein KO (=Instanz) mehrere GAs zu weisen und nur auf die erste GA werden Daten gesendet. Dann sollte nach Lehrbuch wenn „Empfangen“ „aus“ ist, auf keiner Adresse irgendwas empfangen.
Bedeutet aber wenn man Status und Aktion sauberer Trennen möchte, wie bei modernen KNX Geräten, das man auch 2 Instanzen braucht, so als hätte man 2 KOs. Und diese im Zweifel auch mit der gleichen GA verknüpft. Das wäre natürlich absolut oversized in der Pflege und hätte nur selten Mehrwert.
Wenn man aber kombiniert denkt, wäre eine Instanz, welche zwischen Status und Aktion unterscheidet, meiner Meinung nach besser. Wie man das Umsetzt da gibt es viele Möglichkeit. Eine hatte ich ja schon gezeigt. Eine andere Möglichkeit könnte sein, die Trennung zwischen Haupt und „Weitere“-Liste aufzugeben und alles in einer Liste zu pflegen. So könnte man pro Adresse sagen Senden, Empfangen, Lesen… Dann wäre man flexible, hätte aber nicht die Komplexität wie in meinem Prototyp.
Das wäre dann auch Problemlos migrierbar ohne das jemand was anpassen muss und es hätte pflegetechnisch auch keine Nachteile.
Kleiner Nachtrag um auf das Problem von hier einzugehen:
Das würde also hier bedeuten, dass man auf auf der Control GA Senden aber kein Empfangen an hat und auf einer Status GA nur das Empfangen. Somit müsste IPS warten bis Feedback da ist.
Hätte ich Empfangen und Senden gleichzeitig an, so müsste er den Wert ohne Warten übernehmen.
Genau. Und sofern ich das richtig verstanden habe, ist dies euer Hauptwunsch, oder?
Das mit der Liste ist sicherlich eine gute Idee für Experten - ich sehe dort aber den simplen User, der damit echt überfordert sein könnte. Der ist ja Teilweise schon mit den Status GAs überfordert.
Richtig. Das ist eine Glaubensfrage. Für mich: Telegramm abgefeuert, fertig, nach mir die Sintflut.
Für Dich: Telegramm abgefeurt, bloß nix ändern, erst wenn der Aktor es rückmeldet.
Hat beides Vor- und Nachteile. Ich denke, paresy wird eine gute Lösung finden.
Das kommt auf die Situation an. Es gibt genügend GAs wo eine Unterscheidung nicht nötig ist.
Ich glaube nicht, dass dies wirklich ein Problem ist. Ich denke die Leute die keine Ahnung haben, nutzen den Importer und der setzt die Werte ja korrekt. Zusätzlich haben Sie die Probleme in der ETS auch und müssen Sich dann damit befassen.
Aber es gibt ja auch noch andere Möglichkeit, man könnte ja einen Expertenmodus bereitstellen. Sprich sobald die Checkbox aktiv ist, kommt der erweiterte Modus zum Vorschein.
Einer! Der andere ist das ich IPS als Master (Aktor) betreiben möchte. In diesen Fällen muss auf der Status GA (manuel z.B. KNXWriteDPT) gesendet werden und auf der Control GA empfangen. Wobei ich das durch drehen der GAs auch jetzt schon hinbekommen kann. Das ist aber Umständlich und unintutiv. Und ich glaube nicht, dass ich der einzige bin der IPS als Gateway zu anderen Systemen nutzt. Also hier geht es auch wieder um Usability.
Also alles was ich wirklich brauche bekomme ich auch jetzt schon hin nur halt umständlich und unintuitv.
Die eigentlich Änderung, bei der wir die Änderung des Status eingebaut haben war übrigens erst Mai 2016. Ich kann im Forum dazu aber keinerlei Diskussion finden und meine Commit Message sagt nur ich hätte einen Edge Case damit korrigiert. Somit überwiegt euer definitiv sinnvoller Use-Case.
Nein das bist du wirklich nicht.
Hier schwirren die Paket zwischen KNX und Homematik und Tasmota/ESP’s nur so hin und her.
Und auch hier im umgekehrten Weg setzte ich den Status in KNX ja auch erst, wenn nach dem Schalten eines Tasmota Devices to Rückmeldung kommt.
VG Doc
Traxanos hat die Lösung gefunden, warum es wichtig war, dass es diese Änderung gibt.
Zur 5.6 kommt somit eine Verbesserte Version von der ursprünglichen Implementation. Ihr könnt die neue Eigenschaft „Status emulieren“ (welche Standardmäßig aktiv ist und so gesehen 100% abwärtskompatibel!) dabei Deaktivieren und den Zustand erreichen, der in diesem Thema gewünscht ist.
Das erlaubt dann alle Use-Cases korrekt abzubilden.
Ich muss das Thema hier auch noch mal aufgreifen, da es zur 6.0 ja einige Änderungen gab und ich noch keine Zeit hatte, mein System entsprechend anzupassen.
Ich verwende auch bei nahezu allen Aktoren Rückmeldeadressen und habe mich bisher irgendwie damit arrangiert, dass das Zusammenspiel mit IPS nicht optimal ist und es dadurch in bestimmten Konstellationen zu einem falschen Status in IPS kommen kann.
Wenn ich nun das Empfangen für die Haupt-GA deaktiviere und die Instanzen (sowohl Legacy als auch DPT) trotzdem noch auf die Status-GA hören, ist das schon mal sehr gut!
Ich frage mich allerdings, ob ich in dieser Konstellation auch noch gezielt die Status-GA per Befehl (EIB_RequestStatus, KNX_RequestStatus) abfragen kann.
Es gibt Situationen, in denen ich den Bus aktiv abfrage (z.B. nach längerer Downtime des Servers), um einen konsistenten Status der KNX-Instanzen zu bekommen.
Funktioniert das in der oben beschriebenen Konstellation oder sind die Befehle dann nicht möglich bzw. wird dann doch wieder die Haupt-GA und nicht die Status-GA abgefragt?
Ich bin ja selber darauf reingefallen und dachte wir unterstützen dies bereits und habe deshalb auch nicht verstanden was 
