Habe mir schon ein Wolf gesucht aber nichts gefunden.
Bei einem meiner KNX-Aktoren ist sowohl eine Ein- als auch eine Ausschaltverzögerung programmiert.
Diese möchte ich realistisch darstellen, d.h. nur wenn der Verbraucher geschaltet ist soll IPS es auch anzeigen. Leider zeigt mir IPS aber auch zusätzlich die Schaltanforderung (Schalt-GA) an. Kann man es einstellen das IPS nur auf die Status-GA reagiert?
traxanos hat gerade etwas gebaut, was diese Aufgabentellung lösen kann:
Hi
wie @volkerm arbeite ich gerade genau an einer solchen Lösung, weil das genau so ein Problem ist was ich auch hatte. Darf ich aus Neugier wofür du das nutzt?
Na klar … ich bin Privat-Bierbrauer und habe mir einen automatischen Gär- und Klimaschrank gebaut.
Jeweils wenn die Heizung oder Kühlung geschaltet wird, werden die Lüfter ein- und ausschaltverzögert eingeschaltet.
Wo kommst du her hehe 
Spass bei Seite. Geiles Hobby.
@integrator1 Magst du mal schauen, ob das mit der Rückmelde GA bei dir geht, wenn du die CheckBox „Empfangen (Empfange Wertänderungen vom Bus auf Hauptadresse)“ deaktivierst. Dann sollte die Instanz ausschließlich auf die Rückmelde GAs reagieren. Ist es das, was du unter anderem gesucht hat?
paresy
OK … werde es probieren und berichten💪
OK … wie ich vermutet habe, so geht das nicht.
Der Weg muss anders herum gehen. Die Anzeige muss nur auf die Rückmeldeadresse hören.
Der Schaltbefehl wird über die Hauptadresse ausgelöst aber der Aktor in sich hat eine Verzögerung und schaltet dementsprechend später. Erst dann meldet die Rückmeldeadresse.
Wie würde Dr.Niels sagen die beiden Adressen sind nicht konsistent😁 … nicht schlagen der Ball lag auf dem Elfmeterpunkt😇
Situation: Aktor mit Einschaltverzögerung ist Aus. IPS zeigt den Zustand „Aus“ korrekt an. Du möchtest den Aktor einschalten, die Rückmeldung in IPS aber erst haben, wenn der Aktor wirklich an ist. Dies passiert durch die Einschaltverzögerung aber erst z.B. nach 10 Sekunden.
Dein Wunsch: IPS soll nur auf die Rückmeldeadresse hören.
Frage: Was soll dann passieren, wenn Du in IPS auf „Ein“ klickst, also das Gerät einschalten möchtest? Ich fände es ziemlich blöd, wenn ich dann auf „Ein“ drücke (im WebFront oder in der App) und dann nix passiert, weil ja noch keine Rückmeldung kam. Ich weiß also nicht, habe ich den Ein-Button getroffen, oder nicht? Wie siehst Du das?
Genau das soll aber diese Option. Tun. Wir senden auf der Haupt GA und wenn die Checkbox aus ist, sollte nicht auf Haupt GA gelauscht werden sondern nur auf die Adressen die unter „Mehr“ stehen.
paresy
Wenn er „Empfangen“ deaktiviert, dann passt es in IPS, wenn er die Schalthandlung von wo anders auslöst. Das Auslösen ändert in IPS nichts, erst die Rückmeldung durch den Aktor. Das passt also.
Wenn er aber durch IPS schaltet, dann läuft er in den Zustand den ich oben hinterfragt habe.
Wenn er über IPS schaltet, sollte doch der Status korrekt gesetzt werden sobald das Gerät zurück gemeldet hat. Und das ist doch genau, was er möchte, oder?
paresy
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.
paresy
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.
paresy
Perfekt! Vielen Dank!
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.
paresy
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.