Nach Update auf OH 3.4 KNX Datentyp Problem

[SaschaQ]

Hallo zusammen,

ich habe meine PV Anlage mittels OH Binding von Kostal angebunden. Bislang habe ich die PV Leistung aus den beiden PV Strings errechnet und mittels OH auf eine KNX GA gesendet um diesen auch im KNX verwenden zu können.

Seit der Umstellung auf OH 3.4 erhalte ich folgende Fehlermeldung:

Code: Alles auswählen

An exception occurred converting type 242.1813278199 kWh to dpt id 9.024: error message=incompatible types: kWh, kW

KNX Thing:

Code: Alles auswählen

Type number-control        : th_au_pv_leistung   "Leistung PV Anlage" [ ga="9.024:X/X/X" ]

Item:

Code: Alles auswählen

Number:Energy                 solaranlage_DEVICE_LOCAL_PV_POWER "Aktuelle Leistung der Photovoltaikanlage"                 <solarplant> (gSolaranlage) {channel="knx:device:bridge:generic:th_au_pv_leistung" [profile="follow"],autoupdate="false" }

Item zum berechnen der Leistung aus den beiden PV Strings:

Code: Alles auswählen

Number:Energy                 solaranlage_DEVICE_LOCAL_PVSTRING_1_POWER "Aktuelle Leistung des Photovoltaikstrings 1"                 <solarplant> (gSolaranlage) { channel="kostalinverter:XXXXXXXX:deviceLocalPVString1Power"}

Number:Energy                 solaranlage_DEVICE_LOCAL_PVSTRING_2_POWER "Aktuelle Leistung des Photovoltaikstrings 1"                 <solarplant> (gSolaranlage) { channel="kostalinverter:XXXXXXXX:deviceLocalPVString2Power"}

Rule zur Berechnung:

Code: Alles auswählen

rule "PV Leistung"
when
    Item solaranlage_DEVICE_LOCAL_PVSTRING_1_POWER changed or
	Item solaranlage_DEVICE_LOCAL_PVSTRING_2_POWER changed
then
    if( ! (solaranlage_DEVICE_LOCAL_PVSTRING_1_POWER.state instanceof Number) ) {return;}
    if( ! (solaranlage_DEVICE_LOCAL_PVSTRING_2_POWER.state instanceof Number) ){return;}

    solaranlage_DEVICE_LOCAL_PV_POWER.postUpdate((solaranlage_DEVICE_LOCAL_PVSTRING_1_POWER.state as Number) + (solaranlage_DEVICE_LOCAL_PVSTRING_2_POWER.state as Number))
end

Jemand eine Idee? Ich habe mit den Datentypen schonmal ein bisschen rumgespielt, aber bisher ohne Erfolg.

[int5749]

Hi Sascha,

ich habe mal schnell gegooglet und laut KNX Doku ist 9.024 für Power, was doch A sein sollte? Evtl. probierst Du mal 13.013 (V32 DPT_ActiveEnergy)
Quelle: KNX Standard Interworking Datapoint Types

[SaschaQ]

Danke für den Input, das hatte ich auch schon versucht.

Dann bekomme ich die folgende Fehlermeldung:

Code: Alles auswählen

2023-01-05 11:30:13.405 [WARN ] [nx.internal.client.AbstractKNXClient] - Value '327.9158172608 kWh' could not be sent to KNX bus using datapoint 'command DP X/X/X 'knx:ip:bridge', DPT 13.013, low priority': 13.013 Active energy in kWh: wrong value format: 327.9158172608. Giving up now.

2023-01-05 11:30:13.408 [WARN ] [.internal.handler.DeviceThingHandler] - An error occurred on channel knx:device:bridge:generic:th_au_pv_leistung: 13.013 Active energy in kWh: wrong value format: 327.9158172608

tuwien.auto.calimero.KNXFormatException: 13.013 Active energy in kWh: wrong value format: 327.9158172608

	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.GeneratedMethodAccessor171.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.$Proxy1857.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.GeneratedMethodAccessor170.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) [?:?]

[udo1toni]

Also, bezüglich UoM und knx: Ist die Unterstützung schon offiziell? Mir wäre da noch nichts bekannt. Ich weiß aber, dass daran gearbeitet wird. Nur, ob das dann von heute auf morgen problemlos funktioniert, wage ich zu bezweifeln.

Zu den DPT: 9.xxx ist 2-Octet Float, 13.xxx ist 4-Octet Signed, Du kannst nicht einfach irgendwelche DPT nehmen. Das KO bestimmt das Datenformat (Vorkommaanteil). Wenn Dein KO also zwei-Byte-Float will, muss vorne die 9 stehen.

Wenn Du vorher den Messwert so übertragen hast, wäre mein Vorschlag, zwei Items zu nehmen, das, welches nach knx sendet machst Du dann als Item ohne UoM, also nur Number. Da man beliebig Items verlinken kann, sollte es dennoch "einfach so" funktionieren, nur werden halt keine Einheiten mehr berücksichtigt.
Funktioniert das nicht, musst Du auf eine Rule ausweichen, welche die Einheiten strippt und die Daten explizit in das Item hineinschreibt.
Immer dran denken: number-control sendet die Daten, wenn sie als postUpdate geschrieben werden. Das Follow-Profile ist so oder so unnötig.

[SaschaQ]

Danke für deinen Ansatz. Wie meinst du das mit den zwei items? Kannst du mir das anhand meiner Konstellation erklären?

[SaschaQ]

HAbe es gelöst, danke

[schrobbl]

Hallo Zusammen,
ich habe das gleiche Problem mit aktuell openhab 3.4.2. Das Item welches ich übertragen will ist auf Number gestellt und ich sehe auch keine Nachkommastellen. Doch beim Übertragen macht OpenHAB immer eine .0 an die Zahl hinzu:

[WARN ] [.internal.handler.DeviceThingHandler] - An error occurred on channel knx:device:bridge:generic:ABB_Gesamt_export_energy: 13.013 Active energy in kWh: wrong value format: 44510.0 tuwien.auto.calimero.KNXFormatException: 13.013 Active energy in kWh: wrong value format: 44510.0

Was mache ich da noch falsch, oder ist das ein Bug?

Grüße

[udo1toni]

Wenn Du 13.013 als DPT angibst, musst Du jetzt auch den passenden Itemtyp verwenden (Also Number:Energy). Dafür wird dann die Einheit automatisch mit übernommen.

Ich hatte das ja schon zwischen den Zeilen am 5. Januar angedeutet knx kann nun auch UoM.

[schrobbl]

Hallo udo1toni,

danke für Deine Rückmeldung.

in meinem war es so ...
1. ich hatte von einem Modbus gelesenen Wert direkt an ein Item (Number:Energie) verknüpft -> vorher gepusteter Fehler
2. ein extra Item (Number:Energie) für das Senden über KNX erzeugt und durch eine Rule aktualisiert (gerundeter Wert) -> weiterhin Fehler
3. das extra Item vom Type auf Number geändert -> Fehler weg
4. zum verifizieren den Type wieder auf Number:Energy gestellt -> Fehler wieder vorhanden

Entweder ich mache da etwas falsch, aber ganz klar ist es für mich nicht das der Fehler mit dieser Konfiguration weg ist.

[udo1toni]

Also der Wert kommt per ModBus in openHAB an und soll an knx weitergeleitet werden?

Dann sollte der Channel bei knx eigentlich vom Typ number-control sein.
Wenn die GA mit 13.013:a/b/c angegeben ist (a/b/c ist die konkrete GA), sollte es dann ausreichen, den number-control Channel mit dem Item zu verlinken, welches auch mit dem ModBus Channel verlinkt ist. Wichtig: NICHT noch zusätzlich das follow-Profile aktivieren, das wird hier nicht gebraucht!

Sollte es dann weiterhin Fehlermeldungen geben, müssten wir das rückmelden, denn dann stimmt irgendwas im Addon selbst nicht. DPT 13.013 ist BigInteger mit Vorzeichen (also 32 Bit Ganzzahl) und das Addon weiß das auch und muss entsprechend umrechnen. Wie gesagt kann es aber sein, dass es in der aktuellen Version die Einheit benötigt.