Easy KNX-App (IOS) fragen...

[mumpf]

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

Das musst Du wissen. Ich finde es absolut widerlich, wenn mir ein Gerät, dem ich ein AUS sende, mit INAKTIV antwortet. Das musst Du wissen, ich mach alle RM-DPT wie die Schalt-DPT.

Der DPT 1.011 ist dafür gedacht, einen Schaltzustand zu charakterisieren, der ein Gerät/Kanal aktiviert oder deaktiviert. Hat also nicht mit einer Status-Rückmeldung zu tun. DPT geben den KO eine Bedeutung, deswegen gibt es ja DPT mit hoch/runter; true/false; ein/aus usw. alle mit den selben Werten 0/1. Und genau so wie ich kein "hoch" als Antwort für ein "aktiv" bekommen will, will ich auf ein "aus" kein "inaktiv" bekommen. Aber Du darfst das natürlich wollen .

nur die Easy-KNX-App die Shellys ärgern

Die App murkst rum

Nein, es sind die Shellies. Wenn auf ein Read als Antwort ein Write kommt, ist das nicht die Schuld der App. Mach mal folgenden Test:
Speichere die 4 Reads, die die App losschickt, im Gruppenmonitor ab und schick sie dann nochmal auf den Bus, über die ETS und nicht über die App. Schau mal, ob sich gleiches Verhalten zeigt. Und wenn ja, dann kommen die Shellies nicht mit schnellen Telegrammabfragen zurecht. Das wird dann sicherlich bei einem Systemstart zum Problem werden, denn da werden viele Reads benötigt.

Weiterer Test, den ich machen würde: Lass die App man über Routing und nicht über Tunneling mit KNX sprechen und schau, wie sich das verhält.

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

Das sind ja auch Writes, das hat schon vorher geklappt.

Am Lingg Janke mMn absolut normales Verhalten.

Auch hier, normale Writes. Du suchst an der falschen Stelle. Du hast das Problem, dass bei vielen GroupValue_Read nur der erste mit einem Response, die anderem mit einem Write beantwortet werden.

Aber auch dafür müsste ich ja dann einen Dummy anlegen

Nein, Du musst nur in einem Dummy die GA verknüpfen.

Wie man an obigen Bild sehen kann ist das A-Flag niergends gesetzt.

Leider ist das auch eine Fehlinterpretation bzw. das Bild sagt nichts aus: Das A-Flag am Dummy dient der reinen Dokumentation! Ein Dummy macht NICHTS, also sind auch dessen Flags wirkungslos. Hier müsste man klären, wie die Shellies auf ein GroupValue_Response reagieren.
Aber ich bin mir recht sicher, dass das nicht das Problem ist, weil ja gar keine Response, sondern Write-Telegramme kommen.

Gruß, Waldemar

[Theees]

Waldemar danke für deine unermüdliche Hilfestellung und Klarstellung von Anfängerfragen und Aussagen 😄

Speichere die 4 Reads, die die App losschickt, im Gruppenmonitor ab und schick sie dann nochmal auf den Bus, über die ETS und nicht über die App. Schau mal, ob sich gleiches Verhalten zeigt. Und wenn ja, dann kommen die Shellies nicht mit schnellen Telegrammabfragen zurecht. Das wird dann sicherlich bei einem Systemstart zum Problem werden, denn da werden viele Reads benötigt.

Hier das Ergebnis was deine Vermutung wahrscheinlich bestätigt. Die vier Reads habe ich gespeichert und wiedergegeben.
Das Fehlerbild, welches ich ja jetzt schon bestimmt 100x durchgespult habe ist immer das gleiche. Stripe Schrank ist sofort da, Stehleuchte WZ und Strip Schrank kommen dann verzögert aber fast zeitgleich und Stehleuchte EZ am Schluss.

Jetzt überlege ich wie ich das Thema geschickt umfahren könnte, aber so richtig fällt mir da nichts ein.
Vielleicht sollte ich das auch mal in einem neuen Thema anbringen mit einer Überschrift wo mehr User reinschauen die einen Shelly haben. Denn das Problem scheint ja jetzt wirklich nichts mit der Easy-KNX-App zu tun zu haben und ich habe auch das Gefühl das die App wenige Leute nutzen. (ich habe halt keinen Visuserver und finde die App für das Geld echt gut).

speichernundabspielen.jpg

[Theees]

Weiterer Test, den ich machen würde

Habe es getestet: IP Adresse des Routers vergeben und jetzt sind die beiden Stripes reproduzierbar sofort da und die beiden Stehleuchten werden nach längerer denkpause ausgeschaltet 😅
Edit: Doch nicht reproduzierbar. Gerade gleiches Verhalten wie vorher mit der IP des Interfaces.

iprouter.jpg

[mumpf]

Ok, es ist - wie ich vermutet habe - zu schnell für die Shellies.

Jetzt überlege ich wie ich das Thema geschickt umfahren könnte, aber so richtig fällt mir da nichts ein.

Aber mir... hast Du eventuell noch eine normale IP-Schnittstelle da? Dann könntest Du EasyKNX über die Schnittstelle mit dem Bus reden lassen. Damit würden die Telegramme erstmal auf KNX landen, bevor sie über den Router auf KNX-IP kommen. Das wäre dann deutlich langsamer.
Ich würde mir dafür jetzt keine Schnittstelle kaufen, aber vielleicht hast Du noch eine rumliegen oder kennst jemanden, der Dir mal eine leihen kann.

Gruß, Waldemar

[mumpf]

Weitere Möglichkeit: OpenKNX-Logikmodul als "Zwischenspeicher". Ein Kanal würde so aussehen:
OR mit einem Eingang, Eingang verbunden mit dem Status-KO vom Shelly, Eingang macht "Read beim Neustart". Ausgang sendet auf eine neue (andere) Status-GA. Diese Status-GA nutzt Du in EasyKNX.
Was passiert:

• Shelly sendet seinen Status, der wird 1:1 auf die neue GA weitergesendet
• Beim Neustart vom Logikmodul liest das alle GA für alle Eingänge. Wenn die Lesevorgänge zu schnell sind, kann man jedem Logikkanal eine Startup-Verzögerung geben und so die Lesetelegramme langsam genug absetzen.
• Eine EasyKNX-Seite liest ja nur die im bekannten GA, das sind aber die, die vom Logikmodul beantwortet werden.

Weiterer (kleiner) Vorteil: Du brauchst auch kein Dummy mehr auf der TP-Seite, denn jetzt hast Du einen echten Empfänger für die Shelly-GAs.

Gruß, Waldemar

P.S.: Dieser Workaround wird sicherlich klappen, Du brauchst aber für jede Shelly-Status-GA einen Logikkanal.

[Theees]

OpenKNX-Logikmodul als "Zwischenspeicher"

Danke für die Idee! Ich habe gerade versucht das umzusetzen. Hier mal meine Stehleuchte Wohnzimmer:

logikshelly.jpg

Die 1/1/11 ist mit Logikkanal 706 verbunden:

logik kanal.jpg
Ein Read auf die 1/1/11 zeigt das es so klappen sollte:

logik read.jpg
Gruppenadressen:

logik ga.jpg Wenn ich es so ausführe zeichne ich folgendes auf:
Schon mal erfolgsversprechend. Aber ein GroupValue_Read, und zwar von der Stehleuchte WZ, fehlt.

mitlogikohnezeitverzug.jpg
Ich habe dann versucht die Telegramme aus der Logik mit der Ein/Ausschaltverzögerung jeweils um 100ms zu verzögern. Dann passiert allerdings nach dem GroupValue_Read gar nichts mehr.

mitlogikmitzeitverzug.jpg Wenn ich jetzt versuche über die App die leuchten einzuschalten dann hängt sich der Schalter auf und die Lampe bleibt an. Wenn ich aber ausschalte dann aktualisiert sich der Status und die lampe geht auch aus.

Falls Du irgendwo einen Fehler siehst wäre ich um Info froh. Falls nicht dann würde ich das Thema RM in Verbindung der Shellys mit der Easy-KNX-App wohl auf Eis legen. Irgendwann in den nächsten 1-3 Jahren werde ich das wohl eh vernünftig auf KNX hoch gezogen haben :/

Edit: Und direkt nach schreiben dieses Posts habe ich es noch mal versucht mit einem korrektem Ergebnis (ohne Schaltzeitverzögerung). Also manchmal klappts manchmal nicht

mitlogikohnezeitverzug1.jpg

[mumpf]

Das mit 1/10s macht Sinn, und das funktioniert auch, Du hast nur diese "Kleinigkeit" vergessen:

Eingang macht "Read beim Neustart".

Du hattest die 1/10 Sekunde parametriert, und danach gleich die Reads abgeschickt. Wenn ein Logikmodulkanal aber noch nie was am Ausgang gesendet hat (dieser also initial ist), dann kann es auch keine Reads beantworten.
Wenn das Logikmodul aber beim Neustart seine Eingangswerte vom Bus liest (also vom Shelly), dann passt das wieder.

Gruß, Waldemar

[Theees]

Du meinst den Schalter "Eingangswert speichern und beim nächsten Neustart als Vorbelegung nutzen"?
Etwas anderes in der Richtung konnte ich jetzt nicht im Eingang finden.

[mumpf]

Ich meine in der Dropdown darunter "Wert vom Bus lesen" auswählen.

Gruß, Waldemar

[mumpf]

Und ich hab nicht aufgepasst... es bringt nichts, die Telegramme zu verzögern, vergiss das. Du musst 1:1 weiterleiten. Verzögerungen wirken nur auf das Senden, eine Antwort auf ein Read kann nicht verzögert werden. Aber den Read am Eingang, den brauchst Du.

Also manchmal klappts manchmal nicht

Gewöhn Dich dran, wenn Du ein smartes Haus haben willst: Genau solche Situationen musst Du erforschen, gerade jetzt am Anfang, bis Du sie verstanden hast. Denn nur dann hat man deterministisches Verhalten.

Hier lag es wie gesagt daran, dass nach dem Proggen vom Logikmodul so lange kein Read beantwortet wird, wie kein gültiger Wert am Ausgang liegt.
Es geht immer, wenn man für die korrekte Initialisierung sorgt.

Gruß, Waldemar

[Theees]

Danke Dir Waldemar. Schon wieder richtig viel gelernt die letzten Tage 😀
Ich beobachte das jetzt mal