Sperre vom MDT AKU lesen

[jcd]

Hi, ich habe ein komisches Verhalten beim MDT AKU-2416-03 beobachtet, dass ich mir nicht erklären kann.
Ich vermute, dass liegt eher an einem Fehler oder Missverständnis meinerseits, als am Aktor.

Ich würde gerne den Sperr-Status eines Kanals vom AKU lesen. Der AKU hat dafür leider kein dediziertes Rückmeldeobjekt, deshalb habe ich beim KO 170, einem Sperr-KO das "L"-Flag aktiviert. Gesetzt sind: K, L und S. Es ist nur die GA 29/3/66 mit dem KO 170 verbunden. Im Zuge meiner Tests habe ich alle anderen Verbindung der GA zu anderen Geräten entfernt, es kann also kein anderes Gerät mehr "dazwischen" funken.

Nun beobachte ich folgendes:
1) Ich sende über den Gruppenmonitor ein GroupValueRead für 29/3/66.
2) Das AKU antwortet mit $27 | Wahr.
3) Ich sende GroupValueWrite $00 | Falsch.
4) Auf das nächste GroupValueRead antwortet der AKU mit $00 | Falsch.
5) Auf ein weiteres GroupValueRead ca 30 Sekunden später antwortet der AKU wieder mit $27 | Wahr. Zwischenzeitlich gibt es keine Kommunikation mit dem AKU.

Was passiert hier? Wie kommt der Wert $27 in eine GA mit dem Datenytp 1.002?

[traxanos]

Wenn die Flags wirklich KLS sind und den Wert mit GroupValueWrite schreibst, sollte der Wert auch in der Aktor-Stack aus dem KNX-Stack übernommen worden sein. Sollte sich der Wert also nach 30se ändern, wurde der Wert doch nicht übernommen (z.B. durch eine art Sperre/Bedingung) oder aber hat sich im Aktor-Stack später geändert.

Da du das U Flag nicht gesetzt hast, siehst du eine solche Änderung nicht. Du solltest also auch das U-Flag aktivieren und nochmal testen.

[jcd]

Hab ich gemacht:

grafik.png
ändert aber nichts:

grafik.png
Der AKU hat keine Rückfallzeiten für die Sperre o.ä.


Ergänzung: Ich habe die Applikation eben nochmal vollständig neu übertragen und erneut getestet. Nach dem Schreiben von $00 habe ich auf GroupValueRead-Anforderungen alle paar Sekunden 7 mal $00 zurückbekommen, nach knapp 50s kam dann $27. Außer meinen Fragen und den Antworten gab es keine weitere Kommunikation mit 29/3/66.

[traxanos]

Dann wäre der nächste Schritt zu schauen welcher Wert stimmt. Sprich ist der Aktor korrekt ent-/ge-sperrt. Und ändert sich der Zustand auch nach 30s. Und dann mit der Erkenntnis sich an den Support wenden. Für mich sieht das nach einem Bug aus. Zumindest wenn keine Logik wie Rückfallzeiten oder Szenen den Status korrekterweise verändert. Aber selbst da, hätte ich durch das U-Flag ein Info erwartet.

[jcd]

Ich habe noch einen anderen Schritt zwischengeschoben und via DCA die Firmware von 5.1 auf 5.6 aktualisiert. Nun sendet der AKU direkt nach dem Programmieren bereits ein $00 (was richtig ist) statt $27 und behält - bisher - die Werte, die er haben soll, auch bei.


Ich hätte das Update besser schon eher gemacht, aber der Changelog in der DCA las sich vollkommen irrelevant und ich bin hinsichtlich Updates eher vorsichtig. Andererseits gab es nur zwei Einträge und war evtl. gar nicht vollständig?

Danke für deine Hilfe und die Bestätigung, dass es nicht an mir lag!

[traxanos]

Daher lautet mein Motto. Ich update immer und alles. Das gilt nicht nur für meinen Rechner oder meine andere Digitale-Consumerware Sondern auch für meine KNX-Geräte. Aber schön das der Fehler nun behoben ist.

[willisurf]

Ich update immer und alles

No risc, no fun
(allerdings bevor ich mich an den Support wende, wird natürlich auch der aktuellste Stand aufgespielt)


Also nach der Pleite mit der Gira Firmware 2.8.858 für den X1 und auch den GPA Pannen mit 5.x bisher sehe ich das etwas differenzierter. Insbesondere bei Gira bin ich jetzt super vorsichtig.
Achso Steinel TPTPM fasse ich auch nicht mehr an, das wird nicht mehr besser, nur noch anders.

Und selbst bei MDT habe ich schon Rückschritte erlebt, siehe
Da warte ich immer noch auf die Applikation 2.6 für die LED Dimmaktoren, damit der ursprüngliche Funktionsumfang wieder nutzbar ist.