Hallo,
ich habe es nun passend über die Variable angepasst,
dies funktioniert nun, aber die Daten können vom KNX Bus nicht empfangen bzw. gesendet werden.
Ursache siehe Bild.
Vg.
Magst du mal schauen, was die ETS anzeigt?
paresy
Ergänzend, analog ein ähnliches Thema,
DPT auf 13… float m³/h ausgewählt, aber leider kommen in IPS ganz andere Werte an.
Ets zeigt alles korrekt an, nur leider nicht IPS.
Sorry konnte meinen vorhergehenden Beitrag nicht editieren.
Vg.
Oben schriebst du DPT20, hier lese ich DPT 201
Das muß schon genau passend zum ETS-Datentyp eingestellt werden.
Hallo Volkerm,
das ist richtig, aber schaue mal bitte in meinen ETS Screenshot, hier war das Beispielt mit DPT13.002 für flow m³/h, leider erhalte ich im Symcon immer den Wert 66 und im ETS jedoch korrekt.
Eine Idee?
Vg und Danke.
Dann zeig mal, was du in IPS als Datentyp (DPT oder EIS) eingestellt hast.
Ich habe bisher in Dutzenden solcher Fälle immer genau eine Ursache gesehen: Nutzer hat unterschiedlichen Datentyp an beiden Enden der Kommunikation gewählt. Die Interpretation der Daten auf den Bus hängen nur vom Datentyp ab, der selbst aber nicht übertragen wird. Der Busmonitor ETS hat natürlich immer den richtigen Datentyp, den du an anderer Stelle im ETS-Projekt verknüpft hast. IPS nutzt das, was du in IPS einstellst, und wenn das nicht passt wird aus einem float auch ein unsigned integer oder sonstwas. Auf den Bus sind das einfach 2 Bytes.
Hi Volkerm,
siehst du im Screenshot zuvor DPT 13
detailliert 13.002 flow.
Vg.
Ich sehe von dir keinen IPS-Screenshot mit erkennbarer Datentyp-Zuweisung, daher habe ich es nun hier nachgebaut.
Tatsächlich sieht das nach Bug aus:
Mit EIB-Instanz und dem richtigen Integer-Datentyp (EIS11 entspricht DPT13) kommt mein Testwert 1234 korrekt an, mit KNX-Instanz vom Typ DPT13 kommt anstelle des Integerwertes 1234 ein falscher Float(!?)wert in IPS an.
Rufen wir mal @paresy, damit das gefixt wird.
Sehr gut, besser hätte ich den Bug nicht wiedergeben können… :-). Vielleicht wird er ja schnell behoben.
@volkerm: Ich bin gerade an dem Problem dran und hätte da eine Rückfrage… Laut DPT Datenblatt sollte der 13.002 eine Auflösung von 0,0001 haben. Wenn ich mir die ETS ansehen, wird jedoch eine Auflösung von 1 genutzt und soweit ich das sehe würdet ihr bzw. eure Geräte dies ebenfalls so erwarten? (Ansonsten können wir alle Werte als Integer abbilden, anstatt wie aktuell als Float)
paresy
Hi paresy,
selbst habe ich kein solches Gerät, auch nur das Datenblatt. Demnach ist DPT13 kein Float, sondern ein 4 Byte Integer. Ich würde das Datenblatt so verstehen, daß 1 einem Schritt von 0,0001 m3/h entspricht. Schau doch mal, ob das in der ETS so passt.
Edit: Ich sehe dein Dilemma, nach meinem eigenen Screenshot (04D2 = 1234 m3/h) wäre die Schrittweite 1 m3/h. Da brauchen wir @nickknx mit seiner Hardware.
Nochmaledit: Nach Screenshot in #10 ist’s wohl so: Schrittweite 1 m3/h
Viel Erfolg wünscht
Volker
Das muss ein Fehler in den KNX DPT Specs sein. Es hält sich zumindest keiner dran. Ich baue das DPT somit um, sodass es sauber Integer Variablen nutzt.
paresy
Ich habe eine Anfängerfrage:
Bisher habe ich einfach die durch den OPC Import erzeugten Instanzen vom Typ EIB Group verwendet. Erst als mir Floatwerte meines Strommessaktors falsch angezeigt wurden, hab eich entdeckt, dass ich händisch Instanzen mit dem DPT Typ aus der ETS anlegen kann.
Wie ist denn grundsätzlich das beste Vorgehen? Ich hab das Gefühl, dass ich mit den DPT Instanzen irgendwie genauer die KNX Objekte wiedergebe, aber es ist natürlich mega umständlich, die Instanzen auch noch von Hand zu erzeugen. Wie handhabt ihr das?
Bisher den OPC Export verwenden und per DPT die fehlenden Dinge hinzufügen. Wir haben einen KNXProj Importer bereits auf unserer ToDo-Liste - Ich kann dir aber noch nicht sagen, wann dieser verfügbar sein wird.
paresy
Wenn ich neue Projekte anlege, importiere ich zuerst den OPC Export und erzeuge dann mit einem Skript die passenden DPT Instanzen. Gleichzeitig werden die Instanzen vom Typ „EIB Device“ gelöscht.
Du führst ein Skript aus und er macht das für alle Instanzen in deinem Import? Kannst du das Skript teilen? Das klingt sehr interessant.
Was passiert mit den Variablen? Die logge ich ja schon seit längerem. Bräuchte ich da neue Variablen?
Bestehende Scripte muss ich wohl anpassen, überall wo auf eine Instanz-ID verwiesen wird.
Wenn ich Systeme für Kunden neu einrichte, importiere ich als erstes den OPC Export. Dann lasse ich mein Skript laufen. Das Skript liest alle Instanzen vom Typ „EIB Device“ ein. Da ich in den Gruppenadressen die Namensgebung verwende, wie sie von der KNX Association empfohlen werden, ist in den Adressen ein Schema erkennbar. Für die Deckenlampe im Wohnzimmer heißt die Gruppenadresse beispielsweise „L.Wohnzimmer-Deckenlampe.E/A“. Ich suche also nach allen Gruppenadressen, die mit „L.“ beginnen und auf „E/A“ enden, erstelle eine neue Instanz vom Typ DPT 1, bennene die genau so wie die ursprüngliche Instanz, verlinke die hörende Gruppenadresse (Gruppenadresse E/A + 1 bei normalen nicht dimmbaren Lichtern) und verschiebe dann die Gruppenadressen (E/A und Status E/A) in einen Ordner „temp“. Das wars.
Für Temperaturen, dimmbares Licht, Statusmeldungen, Betriebsarten bei der Heizung etc. gibt es dann natürlich wieder eigene Skripte. Ich lasse bei einer Neuinstallation also alle meine Skripte einmal durchlaufen und bin dann fertig.
Nein. Das Skript hat für mich kommerziellen Wert und ich habe nichts zu verschenken.
Das finde ich auch.
Für bestehende Systeme ist mein Skript eher ungeeignet, da - wie bereits von Dir erwähnt - die IDs der Variablen geändert werden.
Coole Sache. Was kostet es, einmal meine Gruppenadressen und IPS Instanzen auf Vordermann zu bringen? 
Dazu kann ich keine pauschale Aussage tätigen.