Genau, Michael hat die Berechnug für die Float angeschaut, wie sie beim DPT 275 verwendet werden.
Beim DPT 213 ist es ein Signed Integer. Ich würde also von einem bit für das Vorzeichen ausgehen, dann bleiben 15 bit = 32768 Schritte zu je 0.02°C = 655,34 Grad positiv oder negativ.
Die Limitierung bei -273° dürfte nicht der Codierung sondern der Physik geschuldet sein, da liegt der absolute Nullpunkt und selbst der KNX-Standard wollte das nicht unterbieten 
Ich danke euch, mit den Ansätzen habe ich es zum Laufen bekommen! Das Vorzeichenbit hatte ich tatsächlich übersehen - bei dem absoluten Nullpunkt bei 0K hat es bei mir dann auch geklingelt. Hier mal mein sicherlich unschönes aber funktionales Script - funktioniert nun problemlos:
<?php
$komfort = 21;
$standby = 17;
$nacht = 20;
$frostschutz = 12;
function DPT275toDPT213($input)
{
$mantisse = decbin($input / 0.01 / 2);
$mantisse = str_pad($mantisse, 11, '0', STR_PAD_LEFT);
$bin = '0'.'0001'.$mantisse;
$dec = bindec($bin);
$float = $dec * 0.02;
return $float;
}
KNX_WriteDPT213(16404, DPT275toDPT213($komfort), DPT275toDPT213($standby), DPT275toDPT213($nacht), DPT275toDPT213($frostschutz));
?>
Den Exponenten habe ich mal statisch auf 1 gesetzt - mit dem Wertebereich der Mantisse lassen sich damit immer noch Temperaturen bis ca. 44 Grad abbilden - reicht für meine Anwendung also absolut aus und hält die Umrechnung etwas einfacher.
Danke und Gruß
EDIT: Das Vorzeichenbit habe ich auch statisch gesetzt - ich will ja keine negativen Temperaturen in meiner Heizung 
So exotisch ist das gar nicht. Seit MDT die Heizaktorik in der Verison 03 draußen hat, ist das durchaus üblich.
Ich persönlich würde es bevorzugen, und bin da auch mit Kollegen im Austausch, wenn das DPT 275.100 einfach nativ integriert werden würde. Ich habe jetzt innerhalb kürzester Zeit 2 Anfragen von Kunden, die mit ihrer Wärmepumpe Heizen und Kühlen wollen und in der Betriebsart „Heizen/Kühlen“ kommt man um DPT 275.100 nicht wirklich herum, wenn man es richtig komfortabel abbilden möchte. Mit irgend einer Skript-Basteil möchte ich da ehrlich gesagt nicht anfangen.
Ich würde es daher wirklich sehr begrüßen, wenn das DPT zeitnah nativ kommen würde @paresy
Grüße,
Christoph
Wenn genau ein Hersteller (MDT) einen solchen neuen DPT benutzt dann ist das mMn entgegen dem Kompatibilitätsgedanken von KNX. Es gibt ja bereits länger ein Sollwert-Kombinationsobjekt DPT213, das MDT hätte verwenden können (mit Integer anstatt Float).
Kompatibilitätsgedanke ist eine standardisierte Liste von Datentypen. Die gibt es ja nicht umsonst. MDT hat da ja nichts eigenes erfunden, sondern greift auf einen offiziellen Datentypen zurück.
Ob MDT da auch den DPT 213 hätte nehmen können, kann ich schlecht beurteilen. Es bringt uns aber auch nicht weiter, drüber zu diskutieren, was MDT hätte anders machen können. Sie haben nun den 275.100 genommen und daran werden wir nichts ändern können.
Leute,
einige Idealisten u.a. @DerStandart, Klaus Ott und ich unternehmen seit ein paar Jahren erhebliche Anstrengungen um Symcon/Symbox als KNX Visualisierung bekannt zu machen und als ernsthafte Alternative zu etablieren.
Das ist auch auf einem sehr guten Weg und selbst eingefleischte Gira-HomeServer oder X1 Jünger haben mehr und mehr eine Symbox daheim stehen (und sind überrascht was da geht) und es kommen auch mehr und mehr bei Kunden zum Einsatz.
Symcon hat einen sehr guten Job gemacht mit der KNX Integration und war auch vorne dabei bei KNX IP und Data Secure. Und ist KNX Member. Top!
Da kann es dann aber nicht sein, dass man sich bei jedem Datenpunkt rechtfertigen muss.
Wenn keiner danach fragt, kein Problem, dann wird er halt erstmal nicht unterstützt ABER sobald sich hier Bedarf auftut, würde ich doch sehr drum bitten dass mir Symcon da nicht empfiehlt mir halt ein Modul oder Skript zu basteln. Das ist für mich schlicht kein Weg.
Wir machen uns schon etwas lächerlich wenn es eine solche Empfehlung in eine FB oder sonstige Gruppe schafft.
Keinesfalls werde ich einem Kunden erklären, dass er mit MDT einen Exoten gekauft hat. Hat er nicht. Deren Heizaktor ist de facto Referenz als KNX Aktor. Wer in dem Segment gut unterwegs ist, weiss das eh.
Und da wir immer noch mehr Wärmepumpen sehen, nimmt auch heizen /kühlen weiter zu. Mittlerweile hab ich fast 2 Drittel der KNX Projekte mit Kühlfunktion über die WP.
Das ist mittlerweile fast normal es so zu machen. Und wer sich um sein KNX selbst kümmert und Preis/Leistung sieht, der kommt an MDT kaum vorbei.
Es gibt keine KNX Datenpunkte in der ETS die nicht durch das KNX Gremium laufen und der Prozess ist aufwendig. Sehe das gerade am kommenden BSS Fenstergriff der mal ein paar neue DPT braucht. Und auch bekommt. Aber ist er drin, braucht er auch Unterstützung.
Ich halte es für keinen überzogenen Wunsch an ein KNX Member dass wenn ein DTP von jemand gebraucht wird, der dann halt absehbar implementiert wird, wenn es eben nicht mit einem ähnlichen DTP und einem angepassten Profil getan ist, sondern da tiefer und umständlich (=fehlerfällig) agiert werden müsste.
Symcon ist da auf einem guten Weg mit KNX und hat deshalb aus der KNX Ecke einen Schwung neuer Unterstützer, lasst uns das Momentum nicht vertun.
Hier gehts nicht um einen Schnörkel an der Tile-Visu (die ich auch mag) sondern um Basis Funktion von Symcon.
Danke
Seppm
Ich weiß, daß es hier einige MDT-Fans gibt, aus gutem Grund. Andererseits stellt man bei MDT eine gewisse Tendenz zu „innovativen“ Lösungen fest, wo MDT durch ungewöhnliche Datenstrukturen erstmal nur zu MDT kompatibel ist und einen faktischen Vendor-Lockin schafft. Das wäre in vielen Fällen vermeidbar.
Für kombinierte Datentypen zur Sollwertverstellung gibt es seit über 10 Jahren (*) den DPT 213.100 (Signed Int mit 0,02° Auflösung), wie ihn unter anderem Hager verwendet. Den unterstützen auch viele Visus, nicht nur IPS. Nun unbedingt für exakt dieselbe Aufgabe einen anderen, neuen Datentyp nutzen zu wollen, der von anderen Herstellern und Visus noch nicht unterstützt wird, ist nicht im besten Interesse der Kunden. Da sollte man auch mal MDT ansprechen, ob das so sein muss.
(*) vgl. 03_07_02 Datapoint Types v01.08.02 AS.pdf
Ich kann und mag nicht beurteilen ob es mit 213.100 für MDT auch genau so gegangen wäre.
Fakt ist, 275.100 ist ein offizieller DTP, dann kann man den auch nehmen als Hersteller für ein KO.
Dass KNX bestmöglich interoperabel sein soll, da wird keiner widersprechen, aber wie sollen wir hier so ein Grundsatz Thema lösen, das wäre Job der KNX.org
Und wenn es ein Vendor-Lock-In sein soll, dann hat sich das MDT bei Gira, Jung, ABB, Hager und Co abgeschaut die seit Jahrzehnten ihren Kunden, auf dem einen oder anderen Weg, weiss machen wollen dass KNX am besten innerhalb eines Herstellers klappt.
Das ist auch einer der Gründe warum KNX so super langsam im Privat Bereich voran kommt. Die grossen Hersteller werden nicht müde klangvolle Namen für Ihr KNX Portfolio zu erfinden um den Kunden Angst zu machen sich überall zu bedienen. Auch genug Eli fallen auf den Mist herein.
Ich hab wohl kein KNX Projekt wo nicht 5-15 KNX Hersteller drin sind. Das klappt alles ohne Probleme.
Dann darf aber der Roadblock nicht Symcon sein wo ich dann hängen bleibe und Handstände brauche.
Cheers Seppm
Ich benötige bitte kurz Hilfe. Ich wollte das eben testen, aber die ETS bietet mir diesen Datenpunkt 213.100 gar nicht an:
Den 275.100 kann ich problemlos auswählen. Hat da jemand mal einen Wink für mich?
In der ETS bleibt es der 275, den 213er kann MDT ja nicht. Nur auf Symcon Seite wird es dann ein 213er. Da die Datentypen dann abweichen, klappt es in Symcon über den Konfigurator nicht —> DPT213 Instanz manuell anlegen und GA von der 275er aus der ETS eintragen.
Sollte das nicht helfen gerne kurz Bescheid geben, dann suche ich später mal Screenshots raus.
Guter Punkt, vielleicht hat MDT ihn deshalb nicht genutzt. Ich hatte in die Dokumentation der Datenpunkte (KNX.org) geschaut, dort ist DPT 213 ausführlich beschrieben.
In der Liste der ETS 5.7.7 fehlen so einige Datenpunkt in dem Zahlenbereich, obwohl die DPT-Nummern im KNX-Standard fast lücklenlos hochgezählt sind!?
Symcon bietet ihn an. Bringt mir ja aber nix, wenn die ETS ihn nicht anbietet.
Aber - laienhafte Frage - Zum 213.100 unterscheidet sich der 275.100 ja nicht so extrem? Oder? Kann nicht einschätzen, wie viel Arbeit das ist, den DPT einzubinden.
Ja, ich schätze den Aufwand in IPS auch als gering ein, weil der Unterbau für 4 kombinierte Sollwerte bereits komplett vorhanden ist und sich nur die Codierung (Signed Int vs. Float) unterscheidet.
Theoretisch könnte auch noch die Reihenfolge der 4 Werte abweichen, aber bei Lucas Eigenbau-Umcodier-Lösung scheint es ja zu passen.
Ich schaue mir das noch mal an. Habe gerade in die Specs geschaut und das sah recht einfach aus. Weiß gerade nicht warum ich das bei mir als kompliziert in Kopf abgespeichert habe.
paresy
Supi @paresy - Danke Dir!
Vlt. magst Dir dann den 14.080 auch ansehen?
Der ist dem 14.056 auch extrem ähnlich. Hab ich hier erläutert.
Merci Seppm
Scheinleitung hat die Einheit VA
Wirkleistung W
Blindleistung VAR
Also sollte alles richtig sein
Es geht hier um die Erkennung des KNX Datentyps in IPS. Der Subtyp 14.080 ist in IPS nicht bekannt, wenn man eine Instanz erstellen möchte bekommt man den Fehler
„Konnte Instanz nicht erstellen
Für diese Dimension existiert kein Profil (Code: -32603)“
Das kann man nur vermeiden wenn man in der ETS den Datentyp auf einen in IPS bekannten (aber für Wirkleistung formal falschen) Datentyp ändert und die Beschriftung per IPS-Profil korrigiert.
Folgende DPT kommen zum nächsten Update. Ich freue mich auf euer Feedback.
DPT 14.080
DPT 21.1002, 21.1200, 21.1201
DPT 205.103
DPT 275.100
paresy
Danke für „meine“ Zwei 
(14.080 und ich glaub den 275.100 hatte ich auch vermisst für Farbe)
Nun im entsprechenden Kanal gefunden und 14.080 getestet.
Scheinleistung VA geht damit nun korrekt. Prima!
Dabei fällt mir auf dass ich wohl die Blindleistung VAR vergessen habe.
Da weiss ich aber gerade den DTP nicht da die ETS schon zu ist und ich es mit Google echt nicht finde.
Danke und Gruss Seppm
Welcher DPT ist das? In der ETS 6.1.1 gibt es zumindest keine 14.081 
Gebt gerne Bescheid wenn noch etwas akut fehlt.
paresy
