Euer Problem verstehe ich, voll und ganz. Es ist aber auch das erste Mal wo ich wahrnehme, dass Ihr bewusst entschieden habt nicht der KNX-Definition zu entsprechen. Finde ich persönlich erstmal nicht gut. Wenn Ihr Euch irgendwann umentscheidet, schreien Nutzer auf, die den Datenpunkt schon nutzen.
Was ich aber dazu schade finde (und hier hoffe ich könnte ihr baldigst mit vertretbarem Aufwand nachbessern): Es gibt nach meinen Versuchen heute aktuell
keine Möglichkeit für User sich selber zu helfen.
StefanW hat geschrieben: ↑Mi Nov 17, 2021 1:12 pm
Man kann sich überlegen, für die speziellen DPT eine jeweiliges Logikmodul zu entwerfen, welches dann das Bitmuster in einzelne Objekte zerlegt.
Ja, genau das hatte ich vor und wäre mit den vorhandenen Möglichkeiten des Logikeditors (Binärmultiplexer, etc) wirklich einfach. Das würde natürlich nur 2% der Anwender verstehen, aber es wäre ein einfaches eine zusätzliche Kategorie "Konverter für komplexe Datenpunkte" in der Auswahl der Logik-Module zu schaffen und dort nach und nach mit jedem Update Konverter nachzuliefern, wenn Nutzer das wünschen. Dies würden dann sicher >=80% der Nutzer verstehen.
Gerne stelle ich davon auf die Schnelle ein paar zusammen, zum Beispiel den 225.001 oder einen für 10.001 ohne Informationsverlust.
ABER, dafür müsstet Ihr eine Möglichkeit schaffen, wie man 3-byte KNX-Datenpunkte als vorzeichenloses Integer in den TWS bekommt.
Ich glaube aber, dass ihr das bereits heute könntet, ohne dass die Applikation in der ETS geändert werden muss.
IST Stand:
- Mit den heutigen Möglichkeiten kann ein User in der ETS als Datenpunkt eines TWS-Objektes den Eintrag 10.xx wählen:
- Diesen Datenpunkt kann man in ETS mit einer GA eines beliebigen 3-byte Typs verknüpfen. Man erhält dort einen Hinweis, kann das aber "abnicken".
- Beim Import in den TWS spuckt der Log einige Hinweise und vor allem auch Errors aus, was ich für übertrieben halte (müsste nicht sein, Warnungen reichen hier). Aber auch das stört erstmal nicht weiter, der TWS arbeitet trotz "Error" anschließend dennoch mit den GA's. Das war auch meiner Erwartung. Zu den Log-Meldungen, siehe unten.
- ABER leider behandelt der TWS Objekte vom Typ 10.xx im Moment (V3.0 IP3) exakt genauso wie die vom 10.001 - Einige der bits eines Telegrammes werden schlichtweg ignoriert, es ist also keine 3byte Wert mehr.
Und an diesem Punkt sitzt
meine Hoffnung:
Der TWS erkennt ja ganz offensichtlich einen Unterschied zwischen der Einstellung einer DPT und einer
DPTS. Dann müsstet Ihr auch das Verhalten dabei mit sehr geringem Aufwand ab einer beliebigen Version ändern können. Gleiches gilt dann natürlich auch für alle anderen DPT (4-byte,etc.). Damit schafft Ihr die Möglichkeiten wichige
DPTS z.B. für Beleuchtungsapplikationen zu nutzen. Eine direkte Unterstützung aus der ETS heraus und ohne Alarme oder Fehler, ist natürlich besser...aber mal ehrlich: Da wird auch noch ein wenig Wasser die Elbe herunterfließen, bis das verfügbar sein wird.
Es wird sich kein User beschweren, dass bei Einstellung 10.xx anschließend im TWS einfach nur ein Integerwert erscheint, der nicht im Einklang ist mit dem Ergebnis bei 10.001. Es beschwert sich bisher ja auch keiner, dass 10.001 nicht der KNX-Konvention entspricht. Und für 10.xx ist meines Wissens auch keine Formatierung definiert - aber da mag ich mich irren, habe es nicht geprüft. Wer 10.xx nutzt bekommt Warnungen und Errors und würde die heute ignoriert haben...da kann man sich dann noch viel weniger bescheren:
18.11.2021 10:50:23;Objekt Fehler: Objekt 1166 (1.0.101) hat ein unvollständige DPT 10;error
18.11.2021 10:50:23;GA Warning: GA 14/5/1, unvollständige DPT 10;warning
18.11.2021 10:50:24;Objekt 1166 (PA 1.0.101) wurde aktiviert mit DPT 10.000 in den Ressourcen, aber in der Projektdatei mit DPT 10;warning
18.11.2021 10:50:24;DPT 10.000 von Objekt 1166 (PA 1.0.101) wie gegeben in den Ressourcen ist anders als die DPT (10) von dem GA (14/5/1);error
