Hallo Zusammen,
aufgrund einer notwendigen Parametrierung meiner MDT KNX Heizungssteuerung möchte / muss ich aus Symcon ein DPT 275.100 Element beschreiben - dieses bildet als Kombiobjekt Sollwerte für verschiedene Betriebsarten (Komfort, Nacht, Frost, Standby) ab. Leider scheint Symcon diesen DPT out of the Box nicht zu unterstützen - gibt es hier Optionen oder Workarounds? Nach meiner Recherche bildet es einen 4x2 Byte Float für „Temperatur Sollwert Einstellung für 4 HLK Modi“ ab.
Gruß
Luca
Aktuell unterstützen wir den DPT leider nicht, da es bisher kaum Anfragen gab und er sehr komplex ist. @DerStandart hatte diesen DPT auch schon mal angefragt.
Theoretisch kannst du ein PHP Modul bauen, welches die Bytes sendet. Oder evtl. einen DPT mit passender Bytefolge nutzen um die Daten besser zu kodieren.
paresy
Danke für die Rückmeldung! So ein befallen über ein Script / anderen DPT schwebte mir als Workaround auch vor - dazu fehlt mir jedoch einfach die Kenntnis - alleine schon zum Aufbau des DPT. Könnte mir hier jemand etwas Starthilfe verschaffen? Ergebnisse teile ich hier am Ende natürlich gerne!
Gruß
Musst du wirklich dieses (etwas exotische) Kombiobjekt verwenden? Warum?
Tatsächlich lässt MDT bei der Verwendung als Kombiregler (Heizen und Kühlen) leider keine Einzelobjekte zu…
Ich würde mich gerne mal an die entsprechende Konvertierung der Daten in das entsprechende Format für KNX rantasten, mir fehlt aber noch die Info, wie ich die Daten dann ohne eine DPT Instanz auf den Bus schicken kann - möglichst erstmal aus einem Script ohne Modul. Wie wäre da der Ansatz? Ausgangspunkt ist ja ein in meinem Script berechneter Hex Wert bzw. eine Zeichenkette, die ich an eine GA schicken will?
Könnte schwieriger werden als ein Modul, weil du per Script nicht auf den internen Datenfluss zum KNX Splitter zugreifen kannst.
Michael
Oje, voraussichtlich werde ich also nicht drum herum kommen mich mit Modulentwicklung zu befassen? Sieht jemand einen anderen Ansatz? Leider bin ich kein Entwickler…
Anderen Aktor verwenden 
Aber so war die Frage vermutlich nicht gemeint. Hast du mal den DPT 213.100 angeschaut? Das sind auch 4 x 16 bit als Signed Integer zur Sollwertvorgabe von Raumtemperaturen. Diesen Datentyp unterstützt IPS.
Vielleicht kann man sich irgendwas bauen um die 4 x 2 Byte passend für deinen Aktor als Float umcodieren und unter falscher Flagge als DPT 213.100 codiert versenden. In meiner ETS5.7.7 ist der DPT275.100 auch nur bescheiden unterstützt, da muss man offenbar die 4 x 2 Byte auch händisch codieren.
Perfekt, danke, genau sowas habe ich gesucht - ich versuche mich mal an der Umrechnung. Mir ist aber folgendes Fragezeichen aufgekommen - bezieht sich dein DPT213 wirklich auf 4 Integer Werte? Das Popup im Script Editor gibt nämlich auch hier Float an:
Ja in IP Symcon ist es ein Float und wird dann in einen Signed Int umgewandelt.
Oben im Protokoll siehst du eine Range von -273 bis 655,34°C.
Viel wichtiger ist aber der kleine Teil da drunter, diese 0,02°C Resolution.
Das heißt jeder Int Wert wird als 0,02 Schritt erkannt.
Also eine Änderung um 1 Grad wären eine Wert Änderung des DPTs um 50. (1°C = 50x 0,02°C)
Diesen Schritt macht aber Symcon schon intern, damit es leserlich und Verständlich bleibt.
Danke für die Aufklärung - ich versuche die Umrechnung (erstmal nur das Verständnis für den DPT212) gerade nachzuvollziehen:
Ich habe ja in den Rohdaten 16 Bit, ergibt durch 2^16 erstmal 65536. Da jeder Zahlwert dieses Integers nach der Spezifikation oben aber ja 0,02° Schritte abdeckt, ergibt sich ein Zahlenbereich von 0 bis 65536*0,02=1310,72. Da ich mit der Temperatur nun nach Spezifikation nicht bei 0 beginne, sondern bei -273°, würde sich somit nach meiner Rechnung eine Range von -273° bis 1037,72° ergeben. Woher kommt die angegebene Range in der Spec von -273 bis 655,34?
Ich denke wenn ich das nachvollzogen haben sollte der nächste Schritt die Umrechnung in den DPT275 sein…
Gruß
Deine Umrechnung ist leider komplett falsch.
Oben in der Grafik ist doch sogar die Formel beschrieben.
M Bits mal 0,01 alles mal 2 hoch E Bits.
Und nein, ich werde das nicht versuchen umzusetzen 
Michael
Hallo Michael,
es geht mir erstmal darum die Umrechnung des DPT213 innerhalb Symcon nachzuvollziehen (vom Float Value zum Integer) - darauf bezog sich meine Rechnung oben. Du beziehst dich schon auf den DPT275, oder? Am Beispiel hier natürlich jetzt nur für einen der vier Parameter im DPT213, also quasi die Umrechnung für einmal 2 Byte.
Gruß
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