openhabforum.de

Hallo,

ich habe jetzt noch einmal umgebaut und der Fehler kommt wieder. Was für Informationen muß ich sammeln, damit wir das melden können? Ich habe mal eine Konfiguration hier zusamengefasst:

ITEM: KNX_send_import_energy vom Type: Number:Energy

Modus Thing Verknüpfung mit dem ITEM KNX_send_import_energy
KNX Thing:
Type number-control: ABB_Gesamt_import_energy "ABB gesamt import energy" [ ga="13.013:4/3/4" ]
Verknüpfung mit ITEM KNX_send_import_energy

Dann kommt folgender Fehler im Log:
2023-04-20 11:05:25.751 [DEBUG] [nx.internal.client.AbstractKNXClient] - Value '23936.68 kWh' could not be sent to KNX bus using datapoint 'command DP 4/3/4 'knx:ip:bridge', DPT 13.013, low priority': 13.013 Active energy in kWh: wrong value format: 23936.68. Will retry.
2023-04-20 11:05:25.752 [WARN ] [nx.internal.client.AbstractKNXClient] - Value '23936.68 kWh' could not be sent to KNX bus using datapoint 'command DP 4/3/4 'knx:ip:bridge', DPT 13.013, low priority': 13.013 Active energy in kWh: wrong value format: 23936.68. Giving up now.
2023-04-20 11:05:25.754 [WARN ] [.internal.handler.DeviceThingHandler] - An error occurred on channel knx:device:bridge:generic:ABB_Gesamt_import_energy: 13.013 Active energy in kWh: wrong value format: 23936.68
tuwien.auto.calimero.KNXFormatException: 13.013 Active energy in kWh: wrong value format: 23936.68
at tuwien.auto.calimero.dptxlator.DPTXlator.newException(DPTXlator.java:537) ~[bundleFile:?]
at tuwien.auto.calimero.dptxlator.DPTXlator.newException(DPTXlator.java:542) ~[bundleFile:?]
at tuwien.auto.calimero.dptxlator.DPTXlator4ByteSigned.toDPT(DPTXlator4ByteSigned.java:249) ~[bundleFile:?]
at tuwien.auto.calimero.dptxlator.DPTXlator.setValue(DPTXlator.java:193) ~[bundleFile:?]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:364) ~[bundleFile:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:553) ~[bundleFile:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.writeToKNX(AbstractKNXClient.java:513) ~[bundleFile:?]
at org.openhab.binding.knx.internal.handler.DeviceThingHandler.lambda$7(DeviceThingHandler.java:253) ~[bundleFile:?]
at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:148) [bundleFile:?]
at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:142) [bundleFile:?]
at org.openhab.binding.knx.internal.handler.DeviceThingHandler.handleCommand(DeviceThingHandler.java:248) [bundleFile:?]
at jdk.internal.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy280674.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:85) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemFollowProfile.onStateUpdateFromItem(SystemFollowProfile.java:60) [bundleFile:?]
at jdk.internal.reflect.GeneratedMethodAccessor595.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

DPT 13 ist ein 4-Byte-Zähler, also ganzzahlig. Eine Gleitkommazahl reinschreiben führt dann wohl zu der Exception.

Hast du das item als Number:Energy definiert?

Gesendet von meinem HD1900 mit Tapatalk

Vielleicht ist es auch der Datentyp.

Du hast offensichtlich ein Abb-Gerät. Meine Abb-Energieaktoren liefern Energie in Wh. Das wäre DPT13.010

Gesendet von meinem HD1900 mit Tapatalk

In dem Fall läuft es ja andersrum, der Wert soll in Richtung knx Bus gesendet werden. Eigentlich würde ich erwarten, dass das knx Binding den Wert rundet, statt sich zu beschweren, dass die Zahl keine Ganzzahl ist. Insbesondere ist DPT 13.013 in openHAB durchaus bekannt: https://raw.githubusercontent.com/openh ... oc/dpt.txt

Ich bin nicht sicher, ob die Erwartung richtig ist.

Bei einer impliziten Typkonvertierung geht fast immer Genauigkeit verloren. Und dann stellt sich die Frage, ob man rundet oder abschneidet, und wenn man rundet, bei x,5 die deutsche Variante oder die weit verbreitete, auf die nächste gerade Zahl zu runden?

Als Binding-Entwickler würde ich diese Entscheidung dem Nutzer überlassen und mit einer Exception darauf hinweisen, dass das Binding eine solche Konvertierung eben nicht implizit durchführt.

Daher würde ich zunächst prüfen, welcher DPT der richtige ist, und nur ganze Zahlen gen KNX schicken. Wenn es dann immer noch zu Problemen kommt, muss tatsächlich der Entwickler ran.

Ja, ich bin bei Dir, das Ding ist aber, es gibt ja gar keine Möglichkeit, zu definieren, was passieren soll.

Es gibt keine "deutsche Variante" beim Runden. Für einen Wert x,y (wobei für x und y gilt, dass es sich um ganze Zahlen handelt, und für y, dass diese positiv und einstellig ist (bzw. nur die erste Stelle berücksichtigt wird), gelten folgende Regeln:
Runden(x,y) liefert für Werte y >= 5 exakt vz(x) * |x| + 1
Runden(x,y) liefert für Werte y < 5 exakt vz(x) * |x|
Integer(x,y) liefert für jeden Wert y exakt vz(x) * |x| (Im deutschen spricht man deshalb auch von Abrunden.)
vz(x) ist für alle positiven x 1, für alle negativen x -1
Es gibt (oder gab?) ja in Indiana ein Gesetz, welches bestimmt, dass π = 4 sei (ich gehe davon aus, dass dieses Gesetz keine Anwendung findet).
Ansonsten wird aber meines Wissens international beim mathematischen Runden immer zur nächsten ganzen Zahl gerundet (im deutshcen Sprachraum ist auch "kaufmännisches Runden" gebräuchlich), nur beim Abrunden wird (ebenfalls international) immer zur vom Betrag nächstkleineren Zahl gerundet.

Man kann natürlich verschiedener Ansicht sein, ob man bei einem Verbrauchswert eher am ganzzahligen Anteil interessiert ist, oder am mathematisch nächsten ganzzahligen Wert, aber einfach gar nichts auszugeben ist auch nicht richtig.
Und gezwungenermaßen den Umweg über eine Rule gehen zu müssen ist extrem unbefriedigend, zumal gerade das knx Binding systematisch aus Inetegerwerten Floatwerte erzeugt und umgekehrt (DPT 17.001 - das ist ein Fehlverhalten)

Ich hatte das Problem mit der systematischen Umwandlung von integer nach float und zurück bei DPT 5.
Das konnte ich durch Nutzung von Number:Dimensionless beseitigen. Dann hat das Binding nur noch mit Integern gearbeitet.

Edit: Das war eine Täuschung. openHAB zeigt im Logging zwar keine Nachkommastellen an. Es ist aber dennoch intern ein float, kein Integer.
Mea culpa.

Dennoch:

Ich würde in der Doku des ABB-Geräts nachschauen, ob es nicht doch Wh statt kWh sind, und ggf. den DPT anpassen (DPT 13.010 statt 13.013). Vielleicht ist es damit erledigt.

Number:Power ist W, kW, mW
Number:Energy ist J, Wh, kWh

9.024 ist "Power" also W, kW, mW
Für "Energy". gibt es in DPT9 keinen Untertyp.

Für Energy käme 13.010 (oder was anderes aus DPT13) in Frage, wenn es ein integer ist, oder 14.031, 14.080 in Frage.

Hallo Zusammen,

es ist kein ABB Gerät. Ich sende lediglich die Energiewerte über den KNX BUS (historisch bedingt). In diesem Fall nimmt ein Loxone Server die Werte über KNX entgegen. Ich habe im Moment leider nicht so viel Zeit Tests durchzuführen, aber ich denke evtl. würde es mit einem Item funktionieren welches vom Type Number ist.
Im Moment funktioniert bei mir folgende Konstellation:
- obenhab Modbus Thing -> Item (vom Type Number:Energy)
- über eine Rule das Item (vom Type Number:Energy) in ein Item vom Type Number speichern (Type Number:Energy funktioniert nicht)
- das Item vom Type Number ist mit KNX - Thing DPT 13.013 verbunden

Aber wichtig ist doch die Frage ob es mit der Konstellation, in der ich einen Fehler bekomme, funktionieren sollte?
Oder ob ich hier irgend etwas nicht richtig mache (Datentype, ...).

Grüße
Schrobbl

Wie gesagt, meine Erwartung wäre, dass das knx Binding entweder rundet oder abrundet, aber keinen Fehler wegen Typverletzung wirft.

Es ist zu erwarten, dass ein Number:Energy Item mit einem number-control Channel verknüpft wird, der mit DPT13.013 konfiguriert ist - dafür sind diese Channel gedacht.
Und DPT13.013 ist in knx ein gültiger Typ für Energy, insofern sollte das Binding das auch umrechnen - man kann sich darüber streiten, ob es nun runden oder abrunden soll, aber die Arbeit zu verweigern ist in meinen Augen ein Fehlverhalten.

Deine Konfiguration sieht komplett richtig aus, ich denke, das ist eher ein interner fehler.