Openhab KNX2 Binding DPT 5.010

[snowy]

Hallo zusammen,

ich habe Probleme mit OH2.4 und dem KNX2 Binding den DPT 5.010 zu schreiben. Die Konfiguration hat mit dem KNX1.X Binding funktioniert und seit KNX2 geht es nicht mehr.

 Type    number  :       HVAC_Lunos_WZ              "Channel 1"   [ ga="5.010:4/3/0" ]

Hat jemand eine Idee, wie ich das unter KNX2 zum laufen bekomme?

DANKE

[udo1toni]

Hast Du schon mal einen Blick in events.log und openhab.log geworfen? Eventuell ist openHAB hier übereifrig und wandelt den Integer Wert fälschlicherweise in Float um.
Der aktuelle Milestone OH2.5M3 könnte hier eventuell Besserung bringen.

[Shoko]

Ich bin da ebenfalls darauf reingefallen, auf der Visu wurde immer 0 angezeigt. Hat etwas gedauert, bis ich drauf kam, dass der aus den Prozentwerten plötzlich Gleitkommazahlen macht und statt 30% 0.3 anzeigen will (was dann wegen der Rundung als 0 angezeigt wurde) ...

[HSorgYves]

udo1toni Was hat sich in OH2.5M3 bzgl. KNX geändert? Plug-In überarbeitet?

[udo1toni]

Das Problem mit dem fehlerhaften Umrechnung von Int nach Float besteht schon eine Weile, soweit ich weiß, wurde da auch was geändert.

[HSorgYves]

OK, versuche mal mich in den Source Code reinzulesen...

[snowy]

Bin mir jetzt nicht sicher, hab das event.log angeschaut... Sieht eigentlich gut aus:

2019-10-15 20:19:22.696 [vent.ItemStateChangedEvent] - HVAC_Lunos_WZ changed from 1 to 0

Oder muss ich das auf dem KNX Bus prüfen?

[snowy]

Früher hat er auch bei ein postUpdate auf dem Bus geschrieben, was seit KNX2 wahrscheinlich nicht mehr der Fall ist (kann mir das nur so erklären)-

switch receivedCommand {        
        case 0: { 
                     postUpdate(HVAC_Lunos_WZ, 0)
                }

Keine Ahnung was geändert wurde aber ich habe das jetzt wie folgt lösen können:

sendCommand(HVAC_Lunos_WZ, (receivedCommand as DecimalType).intValue)

[udo1toni]

Ja, das ist aber auch korrekt. sendCommand() geht allgemein auf den Addon-Bus, postUpdate() geht auf den openHAB-Bus. Ein sendCommand() löst default ein postUpdate() aus, aber nicht andersrum.
knx1 hatte da ein paar Mängel, was vor allem daran lag, dass es in knx keinen zwingenden Unterschied zwischen Befehl und Status gibt.
In knx2 gibt es hingegen eine Unterscheidung durch die Konfiguration. Dabei wird unterschieden, ob openHAB als normaler Teilnehmer oder als Aktor auftritt.
Der Unterschied ist, dass openHAB als Aktor per Definition den Status liefert und auf Befehle reagiert, während er als normaler Teilnehmer Befehle sendet und den Status empfängt.
Deshalb triggert openHAB bei normalen knx Items bei einem Schaltbefehl vom Bus auch nicht mehr auf received command, sondern nur noch auf received update oder changed. Wenn man den Channel als *.control anlegt, dreht sich das Ganze um, aber eben komplett.

Übrigens ist es besser, die Methode statt der Action zu verwenden, also
HVAC_Lunos_WZ.sendCommand((receivedCommand as Number).intValue) statt sendCommand(HVAC_Lunos_WZ, (receivedCommand as Number).intValue)
Der Unterschied macht sich erst bemerkbar, wenn man versucht, ein Primitive als Value zu nutzen. Die Action kann nur mit Strings umgehen, während die Methode Item-abhängig verschiedene Routinen für verschiedene Datentypen anbietet. Übergibt man ein Objekt, wird openHAB immer versuchen, dies passend zu interpretieren, .toString steht für jedes Objekt zur Verfügung. Primitives sind aber keine Objekte, deswegen geht's dann schief.

[snowy]

Danke für die ausführliche Erklärung!
Wieder was gelernt....