EIB RGB: invalid string position

Hallo,

ich habe ein Problem mit mehreren KNX-RGB-Aktoren, welches nun schon seit längerer Zeit besteht. Genauer seit irgendeinem größeren IPS-Update, wo einiges an KNX umgebaut wurde. Bisher habe ich es ignoriert, weil trotzdem fast alles funktioniert.

Ich habe mehrere EIB-RGB-Instanzen, die mit einer DPT 232.600 (RGB 3 Byte) GA verbunden sind. Darüber konnte ich schon immer die LEDs schalten und bekam auch immer den aktuellen Status mit.

Seit besagtem Update (ich weiß leider nicht mehr die genaue Version) kann ich immer noch schalten, aber es werden keine Farben mehr aktualisiert, wenn sich auf dem Bus etwas ändert. Stattdessen bekomme ich jetzt bei jeder Änderung folgende Warnung:

Wenn ich Farbverläufe auf den Aktoren laufen habe, bekomme ich tausende dieser Warnungen, was echt nervt. Meine Frage ist nun warum? So wie es in der Warnung aussieht, verarbeitet die Instanz scheinbar 4 Byte statt 3 Byte (80 vor dem eigentlichen RGB-Wert). Das war früher nicht so, da hat alles funktioniert.

Es liegt aus meiner Sicht auch nicht an den Telegrammen. Die selbe GA arbeitet beispielsweise mit der DPT232.X-Instanz einwandfrei. Dort kommen keine Wanrungen und die Werte werden auch korrekt aktualisiert, wenn sich auf dem Bus was ändert.

Kann es sein, dass die EIB-RGB-Instanz seit diesem einen Update irgendwie fälschlicherweise als RGBW (4 Byte) arbeitet?

Bevor jemand fragt:
Ja, ich könnte natürlich prinzipiell mit den neuen DPT-Instanzen arbeiten.
Würde ich auch gerne, aber da mein System historisch bedingt fast komplett mit den alten EIS-Instanzen arbeitet und es keine Möglichkeit der Migration gibt, kommt das leider nicht in Frage. Dann müsste ich nahezu mein ganzes System neu aufsetzen, weil sich ja sämtliche Instanz-IDs ändern würden. Der Aufwand dafür wäre einfach viel zu groß.

Gruß
Slummi

Ist das Gateway nicht das selbe und du kannst für neue Instanzen auch die DPT verwenden?

Zudem eine Idee für die Migration: Voraussetzung Backup und die interne Datenstruktur ist gleich (kann man mal mit IPS_GetConfiguration()) prüfen. ModuleID in der Settings.json anpassen und vorher IP-Symcon aus- und danach einschalten.

Natürlich sind dann immernoch alle Scripte falsch. Aber bei denen reicht ggf. ein automatisches suchen-/ersetzen der alten gegen die neue Funktion.

Ja, das Gateway ist dasselbe. Für neue Instanzen nutze ich auch DPT. Aber der Großteil ist eben alter EIB-Bestand.

Ich habe auch schon öfter daran gedacht, die Settings manuell anzupassen. Aber das ist mir zu riskant und zu aufwändig. In dem konkreten Fall würde es vielleicht noch gehen, aber wenn würde ich gerne das komplette alte EIB-Zeug migrieren und das sind ein paar hundert Instanzen. Und ich bin mir ziemlich sicher, dass da auch die Datenstruktur unterschiedlich ist und es nicht nur mit dem Tausch der Modul-ID getan ist.

Aber trotzdem Danke für deinen Tipp!

Das sieht nach einem simplen Fehler aus, den wir beim Umbau gemacht haben.

Fix ist fertig und kommt Morgen früh in den Beta-Kanal. Ich freue mich auf dein Feedback!

@Slummi Eine Migration von den EIS auf die DPT Instanzen ist nicht wirklich simpel möglich, da sich die Idents und Properties auch geändert haben. Da müsste man schon recht viel manuell Hand anlegen und genau wissen, was man tut :slight_smile:

Zum konkreten Problem für dich: wie viele RGB Instanzen hast du und kannst du das kurzfristig mit umstellen auf DPT lösen?

Zum Generellen: wie viel Aufwand wäre es ein Migrationsscript anzubieten, welches einerseits alle Scripte überarbeitet und anderseits die Instanzen umstellt? Ggf. nur für die Standardinstanzen (Jalousie, Ein/Aus, Temperatur).

Kannst du mal eine Aufstellung der verwendeten EIS Instanzen machen? Ggf. hilft dir dabei das „Auslesescript“ auf dieser Seite ganz unten: EIB/KNX — IP-Symcon :: Automatisierungssoftware
Statt „RequestStatus“ halt eine Zählvariable hochzählen.

Wow, das ging fix!
Ich werde es testen und gebe dir Feedback. Danke! :slightly_smiling_face:

Das konkrete Problem mit dem RGB hat sich ja scheinbar schon dank paresy gelöst.

Muss ich die Tage mal auslesen, welche EIS-Instanzen ich nutze. Ich glaube aber eine Migration wird nicht reibungslos funktionieren. Es sind ja nicht nur die Skripte. Da hängt ja auch eine Vielzahl von Ereignissen dran. Und es gibt ja streng genommen auch keine Notwendigkeit für eine Umstellung, solange die alten Instanzen korrekt arbeiten.

Es gab halt zufällig in den letzten Tagen die Diskussion die EIB Instanzen „abzuschaffen“. Daher die Frage ob man sich diese Entscheidung einfacher machen könnte, gäbe es einen Automatismus sowas umzustellen.

Fix ist jetzt online.

paresy

Super, mit dem Fix funktioniert wieder alles normal. Keine Warnungen mehr und die Werte werden auch wieder korrekt vom Bus empfangen. Vielen Dank! :smiley:

Die Diskssion habe ich gar nicht mitbekommen. Hatte die letzten Tage keine Zeit, das Forum zu verfolgen. Kam die Diskussion von den Usern? Dem Symcon-Team dürfte ja klar sein, dass das Abschaffen der EIB-Instanzen einen riesen Impact für ältere KNX-Systeme bedeuten würde. Wenn so ein Schritt wirklich in Erwägung gezogen würde, würde ich auch eine offizielle Migrations-Lösung erwarten. Da gibt es einfach so viel, was man bei der Migration beachten muss. Es ist ja nicht damit getan, einfach nur neue Instanzen anzulegen, die Einstellungen zu übernehmen und ein paar IDs in den Skripten zu ändern. Daher kann ich mir eigentlich nicht vorstellen, dass das ernsthaft in Erwägung gezogen wird.

Gruß
Slummi

Es ging ausschließlich darum die Namen auf KNX zu ändern und EIB aus den Namen zu ändern. (Was funktional keinen Unterschied macht)

Wir haben keine Pläne die alten Instanzen zu entfernen. :slight_smile:

paresy

Dann bin ich ja beruhigt. :slightly_smiling_face:

Nennen könnt ihr die von mir aus, wie ihr wollt. :wink:

Einen schönen Sonntag!

Ich halte die Namensänderung trotzdem für nicht durchdacht. In den Instanzen stecken die alten EIS-Datentypen aus EIB-Zeiten. Momentan ist das also irgendwie schlüssig: die „alten“ EIB-Instanzen sind in jeder Hinsicht auf einem alten Stand, die neuen KNX-Instanzen entsprechen den heutigen Standards. Das ist doch eine klare Abgrenzung, daran würde ich nicht rütteln.

Einzig die Idee, den OPC-Import mit einen Hinweis zu versehen daß es eine moderne Alternative gibt, fände ich hier sinnvoll.

my 2 cents
Volker