Easy KNX-App (IOS) fragen...

[gbglace]

Kann aber such schief gehen, jenes KO welches diese GA empfängt muss dann aber diese GA exklusiv verbunden haben oder zumindest als erste GA, sonst hat man alles mögliche da angezeigt.

Bei dem MDT PM wird es wohl passen, an der Stelle wohl genau dieses KO die Existenz der GA begründet.

[Theees]

Guten Morgen zusammen,

also ich habe das jetzt mal getestet und dem KO90 ein L Flag gesetzt. "Wert Rückmeldung" hab ich dann die gleiche GA gegeben. Dann ist allerdings der Button eingefrohren beim Umschalten (mit grauem Punkt).
Wenn ich jetzt wie in der Anleitung der App die Zwangswertrückführung einschalte und den Wert auf die 2s (kürzer geht nicht) setze dann friert der Button die 2sec ein und dann wird er wieder grün und weiss nun auch worauf er steht.

Ist das so der richtige Weg? Erstmal wäre das schon OK solange mir noch der MDT Dämmerungssensor fehlt der aber wohl bei der nächsten Order im Warenkorb landet.

Danke und gruß!

[gbglace]

Ist das so der richtige Weg?

Der Aktor/Sensor (welches Gerät auch immer KO90 hat) sendet halt nicht aktiv wenn er einen neuen Zustand Tag/Nacht einnimmt. Das L-Flag führt halt nur dazu das dieses KO und der Wert im Speicher des KO abgerufen werden kann.
Bei einem Schaltaktor sendet der Aktor halt bei jeder Schaltung aktiv seinen Status und dann bekommt die App das auch per Telegramm mit der GA für "Wert Rückmeldung" aktiv mit das etwas passiert ist.

Das mit der Zwangswertrückführung schaue Dir aber mal genauer im Busmonitor an, nicht das da jetzt alle 2s ein Lesetelegramm mit der Tag/Nacht GA gesendet wird und dann darauf folgend eine entsprechende Antwort vom KO90 kommt. Sowas müllt den Bus schnell mal voll.

was verstehst eigentlich unter gleiche GA?

[willisurf]

Ja, das ist Normal. Wenn der Schalter verändert wird, wartet er ausgegraut die 2sec, bevor er einen ReadRequest sendet und dann die Schalterstellung aktualisiert.

Aber beobachten im Gruppenmonitor ist immer gut.

[Theees]

Busmonitor sieht unauffällig aus

Mit „gleiche GA“ meinte ich nur das ich keine RM GA angelegt hab. Es gibt ja kein KO das diese verwendet. Daher in der App bei RM die gleiche GA wie für den Schalter.

[willisurf]

Ja, es ist durchaus üblich da an beiden Stellen die gleiche GA zu verwenden.

[Theees]

Hallo zusammen,

ich packe das mal hier in meinen Thread. Ich habe gestern einen IP-Router in Betrieb genommen und jetzt vier Shellys ans Laufen gebracht.

Jetzt habe ich das Problem, dass in der App die Schalter relativ lange keine Rückmeldung aus der ETS bekommen und somit nicht bedienbar sind.
Ich habe das ganze im Busmonitor aufgezeichnet.
Bei Zeile 12 und Zeile 22 öffne ich die App wodurch sie anscheinend einen read request ausführt von 1.1.255 auf die jeweiligen RM-GA´s.
Was hier auffällig ist das danach DIREKT die Quelladresse 1.2.4 (was mein Dummy für die IP-Verbindung ist) die Meldung auf die 1/1/15 abgibt. Somit ist mein Schalter für den LED Strip am Schrank sofort bedienbar.
Die drei anderen Rückmeldungen kommen unregelmäßig irgendwann später.

Ich hätte jetzt vermutet das es am Shelly im WLAN liegt. Wenn ich aber die Leuchten aus dem Busmonitor direkt ansteuere (0/7/2 ist eine Zentralfunktion für Ambiente Wohnzimmer) dann erfolgt die RM von allen Shellys direkt (Bild 2).

Jemand eine Idee woran es liegt? (hier noch ein paar Bilder der Konfiguration)

Rückmeldung.jpg
rm sofort.jpg

[mumpf]

Ich kann Dir zwar zum eigentlichen Problem nicht helfen, aber mir sind 2 Sachen aufgefallen, die für zukünftige Analysen helfen (oder vielleicht gar falsche Vorstellungen geradebiegen).

Jetzt habe ich das Problem, dass in der App die Schalter relativ lange keine Rückmeldung aus der ETS bekommen

Nur falls es nicht klar ist: Die ETS hat nichts mit der Kommunikation der Geräte untereinander zu tun. Die macht hier gar nichts.

wodurch sie anscheinend einen read request ausführt

Tue Dir einen Gefallen und blende die Spalte "Typ" im Gruppenmonitor ein. Dann musst Du nicht raten sondern siehst, ob es ein GroupValue_Read ist. Für komplexere Analysen ist da eine notwendige Spalte. Ferner ist es immer hilfreich, die Spalten "Hop Count", "DPT" und "Info" da zu haben, wogegen "Dienst", "Flags" und "Prio" häufig nicht relevant sind.

Warum die Shellies so antworten, weiß ich nicht, ich bin mir noch nicht mal sicher, ob das wirklich GroupValue_Response-Telegramme sind (hast Du ja nicht eingeblendet ). Könnten auch Statusmeldungen sein. Normalerweise muss ein Gerät innerhalb einer Sekunde auf einen GropValue_Read antworten.

Gruß, Waldemar

[Theees]

Warum die Shellies so antworten, weiß ich nicht, ich bin mir noch nicht mal sicher, ob das wirklich GroupValue_Response-Telegramme sind (hast Du ja nicht eingeblendet ). Könnten auch Statusmeldungen sein. Normalerweise muss ein Gerät innerhalb einer Sekunde auf einen GropValue_Read antworten.

Danke Dir für die Tipps! Ich habe den Gruppenmonitor angepasst. Es ist jetzt etwas kompliziert da ich mit zwei Problemen in zwei Threads parallel kämpfe, aber Du hattest mir ja auch in dem Thread zu meiner Filtertabelle geraten auch einen Dummy auf die TP Linie zu packen. Das habe ich jetzt gemacht und nun habe ich hier mit der App ganz neue Effekte

Also alle Leuchten im Wohnzimmer sind an. Ich öffne die App und 1.1.255 sendet einen GroupValue_Read 😉
Zeile 23: Es kommt der Response für den Stripe am Schrank -> App zeigt sofort den richtigen Status an.
Ab jetzt wird es komisch...
Zeile 24: GroupValue_Write Status mit $00 Inaktiv... hä, was bedeutet das? Die Lampe geht jedenfalls aus.
Zeile 25 und 26 schaltet dann auch die anderen Lampen aus.
Zeile 24 - 28 gehen ohne jegliches zutun einfach beim öffnen der App.
Ab Zeile 29 habe ich die Leuchten dann über die App nacheinander wieder eingeschaltet.

Puh, irgendwie blicke ich so langsam nicht mehr durch... Evtl. hat ja noch jemand einen Hinweis 🤯

Edit: Was mir noch aufgefallen ist. Warum hat 1/1/11 den DPT Status und die anderen RM den DPT Schalten? Muss ich den GAs ihren Status manuell geben? Ich kann mich jedenfalls nicht daran erinnern da selbst etwas eingestellt zu haben.




Diagramm.jpg

[mumpf]

Hi, das ist nicht ganz so leicht zu interpretieren...

Erstmal die Frage: Benutzt Du den Gruppenmonitor auf der IP-Seite? Also über Multicast der ETS? Falls nein, dann verstehe ich die Hop Counts gar nicht. Aber das ist nur eine sekundäre Frage.

Was Du siehst (ab Zeile 19) ist das Standardverhalten von EasyKNX: Beim Aufruf einer Seite holt sie sich erstmal den Zustand aller Objekte auf der Seite. Das sind die 4 Reads (19-22). In Zeile 23 wird die 1/1/15 mit einem Response beantwortet. Soweit sogut.

In Zeile 24 wird aber der Shelly von der 1.2.2 ausgeschaltet! Das ist ja kein Response sondern ein Write. Es ist also vollkommen OK, dass die Lampe dann ausgeht. Du musst also schauen, wie Deine GA-Verknüpfungen bei den Shellies sind, dass ein Read oder ein Response zum Ausschalten führt.
Setz einfach (in der gleichen Konstellation, alle Lichter sind an) ein Read auf die 1/1/11 über die ETS ab. Oder ein Read auf die 1/1/15. Man kann nicht sehen, welcher Read ursächlich für das Ausschalten ist. Es könnte auch der Response in Zeile 23 sein (wäre mein Favorit derzeit).

Zeile 27 und 28 verstehe ich auch nicht, außer Du hast die selbe GA 2 mal auf der Seite in EasyKNX.

Wichtig: Das hat nichts mit den Dummies zu tun, ich würde Wetten, da ist noch was schief bei den Shellies, aber die kenne ich nicht. Und keiner sagt, dass sich die Dinger KNX-konform verhalten müssen...

Warum hat 1/1/11 den DPT Status und die anderen RM den DPT Schalten?

Das Thema "sauber gepflegter DPT" ist in der ETS ein längeres Thema. Und es ist nicht die Schuld der ETS sondern die Tatsache, dass verschiedene DPT die gleiche technische Auswirkung haben (dazu zählen alle DPT1).

Die ETS nimmt für eine neue GA als DPT den DPT von dem KO, das zuerst mit dieser GA verbunden wurde. Solange Du das selbst nicht änderst, bleibt das so, auch bei weiteren Verknüpfungen.

Gruß, Waldemar

[MarcoLanghans]

Ich verstehe auch nicht so ganz warum du zwei Adressen beim Switch Object vergeben (eventuell Normales Schalten und Zentrales AN/AUS ? ) hast, normal ist da eine zum Schalten und einen für den Status ausreichend. Oder ist der Screenshot im anderen Thread ein anderer? weil die Adressen passen auch irgendwie nicht zu denen hier.
Alles weitere machst du dann auf ebene der Gruppenadressen.


image.png

Wie Waldemar schon geschrieben hat, prüfe mal welche Geräte diese GA in der ETS verwenden, dann sollte sich das Problem schnell finden lassen.

[gbglace]

Und manche Hersteller haben auch an ihren KOs eine schlechte Auswahl an DPT1 Subtypen gewählt.

Diese Erscheinungen sind eben der große Nachteil der bisherigen Shelly-KNX Integration, es fehlt der gesamthafte Überblick in der ETS welche Gaa wo verbunden ist.

Jetzt bleibt Dir nur übrig nochmal überall ganz genau zu schauen wo die GA alles verbunden ist. Einzig das die Shellies alle eine eigene PA haben hilft Dir den Verursacher des Telegramms #24 schneller zu identifizieren.


Mehrere GA an EingangsKO an Aktoren zu haben ist absolut legitim und ein Sehr sinnvolles Konzept vom KNX und eine Alternative zu Szenen, gerade wenn man nur mal Lichter gruppieren will.

[willisurf]

Und noch ein anderer Aspekt. Wenn der Aufruf von EasyKNX ungewollt Aktionen auslöst, kann es an den ReadRequests liegen, wenn bei einigen Eingängen das A-Flag gesetzt ist. Die Antwort (ReadResponse) wird bei gesetztem A-Flag am Eingang als Botschaft ausgewertet.

Ich musste bei mir mit intensivem Einsatz von EasyKNX an vielen Eingängen das A-Flag entfernen. Man musss dabei nur beachten, das das A-Flag benötigt wird, um beim Startup die Werte einzulesen (das passiert ja genau über ReadRequest / ReadResponse). Also jeweils abwägen und entscheiden.

[Theees]

Guten Morgen,

Benutzt Du den Gruppenmonitor auf der IP-Seite?

Die Auswahl steht auf "Automatisch"

Setz einfach (in der gleichen Konstellation, alle Lichter sind an) ein Read auf die 1/1/11 über die ETS ab. Oder ein Read auf die 1/1/15.

Aus der ETS sieht alles gut aus... Keine Schaltvorgänge.

Read 11-29.jpg

Response in Zeile 23 sein (wäre mein Favorit derzeit)

Response auf alle RM-GA´s aus der ETS, ebenfalls mMn unauffällig:

rm write.jpg

ETS nimmt für eine neue GA als DPT den DPT von dem KO, das zuerst mit dieser GA verbunden wurde.

Danke für die Erklärung. Es würde also Sinn machen, zumindest für die Übersichtlichkeit, RM DPT´s auf 1.011 Status zu ändern.

eventuell Normales Schalten und Zentrales AN/AUS ?

Genau, die 0/7/2 wollte ich als Zentral Ein/Aus verwenden. Aber auch dafür müsste ich ja dann einen Dummy anlegen oder die GA auf "nicht Filtern" stellen.
Ich habe die GA mal in den vier Shellys, und den Schalter in der App, gelöscht. Aber es ändert auch nichts.

Jetzt bleibt Dir nur übrig nochmal überall ganz genau zu schauen wo die GA alles verbunden ist.

Ich kann hier nichts auffälliges sehen 🤔

Verknüpfungen.jpg

Ich musste bei mir mit intensivem Einsatz von EasyKNX an vielen Eingängen das A-Flag entfernen. Man musss dabei nur beachten, das das A-Flag benötigt wird, um beim Startup die Werte einzulesen (das passiert ja genau über ReadRequest / ReadResponse). Also jeweils abwägen und entscheiden.

Danke für den Hinweis. Wie man an obigen Bild sehen kann ist das A-Flag niergends gesetzt. Ich habe es auch testweise mal auf alle das A-Flag gesetzt. Es hat sich an dem Problem leider nichts geändert. Mich irritiert auch das der Status beim Stripe Schrank immer direkt gesetzt wird.

Vorläufiges Fazit: Ohne die Easy-KNX-App scheint alles unauffällig zu sein. Die App murkst rum. Warum auch immer.

Ich werde jetzt mal die GA´s auf einen noch rumliegenden Lingg Janke Taster legen und schaue mal ob sich etwas ändert.

[Theees]

Ich werde jetzt mal die GA´s auf einen noch rumliegenden Lingg Janke Taster legen und schaue mal ob sich etwas ändert.

Am Lingg Janke mMn absolut normales Verhalten. Taster schaltet mit UMschaltung problemlos da die RM auch korrekt zurück gegeben wird. (alle Lampen waren an und wurden in der Aufzeichnung ausgeschaltet)
Es scheint also als würde nur die Easy-KNX-App die Shellys ärgern.

schaltenmitlj.jpg