Fehler bei CUxD Gerät "(28) System"

Moderator: seppy

Antworten
s.berg
Beiträge: 1
Registriert: 24. Mär 2020 16:54

Fehler bei CUxD Gerät "(28) System"

Beitrag von s.berg »

Seitdem ich auf der Raspberrymatic ein CuXD-Gerät vom Typ "(28) System" angelegt habe, erscheint in openhab.log immer folgender Fehler:

Code: Alles auswählen

2020-03-24 16:33:52.186 [ERROR] [mematic.internal.handler.HomematicThingHandler] - -4 Unknown parameter (sending getValue()
CUX2801002:1
CMD_RETL
)
java.io.IOException: -4 Unknown parameter (sending getValue()
CUX2801002:1
CMD_RETL
)
	at org.openhab.binding.homematic.internal.communicator.parser.RpcResponseParser.parse(RpcResponseParser.java:51) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:82) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:94) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.client.BinRpcClient.sendMessage(BinRpcClient.java:70) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.client.RpcClient.getDatapointValue(RpcClient.java:356) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.client.RpcClient.setChannelDatapointValues(RpcClient.java:221) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.client.RpcClient.setChannelDatapointValues(RpcClient.java:198) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.setChannelDatapointValues(AbstractHomematicGateway.java:517) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.CcuGateway.setChannelDatapointValues(CcuGateway.java:108) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.loadChannelValues(AbstractHomematicGateway.java:488) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.handler.HomematicThingHandler.loadHomematicChannelValues(HomematicThingHandler.java:397) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.handler.HomematicThingHandler.updateChannelState(HomematicThingHandler.java:376) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.handler.HomematicThingHandler.updateDatapointState(HomematicThingHandler.java:353) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.handler.HomematicBridgeHandler.onStateUpdated(HomematicBridgeHandler.java:284) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.lambda$1(AbstractHomematicGateway.java:742) ~[bundleFile:?]
	at org.openhab.binding.homematic.internal.misc.DelayedExecuter.start(DelayedExecuter.java:65) [bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.eventReceived(AbstractHomematicGateway.java:739) [bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleEvent(RpcResponseHandler.java:98) [bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleMethodCall(RpcResponseHandler.java:51) [bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleMethodCall(RpcResponseHandler.java:68) [bundleFile:?]
	at org.openhab.binding.homematic.internal.communicator.server.BinRpcResponseHandler.run(BinRpcResponseHandler.java:54) [bundleFile:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Bei anderen CuxD-Geräten wie z.B. "(40) 16 Kanal Universalsteuerung" passiert das nicht. Es muss wohl mit dem Gerätetyp zusammenhängen.
Der Gerätetyp "(28) System" dient dazu auf der CCU ein Shellscript aufzurufen. Man kann zwei verschiedene Script-Aufrufe hinterlegen, je nachdem ob das Gerät auf ON oder OFF geschaltet wird.
Aus der CUxD-Dokumentation ergibt sich, dass der Zugriff auf die o.g. Datenpunkte CMD_RETS und CMD_RETL (es handelt sich hierbei um Rückgabewerte) nur möglich ist, wenn zuvor der Datenpunkt CMD_QUERY_RET auf 1 gesetzt wurden. Wenn man diesen Datenpunkt mit einem Item verknüpft und per openHAB Script sofort nach dem Zugriff auf den STATE des CUxD-Geräts auf 1 setzt, so schafft man es wenigstens, dass das zu dem Gerät gehörige openHAB Thing überhaupt auf ONLINE geht. Eine Dauerlösung ist das aber auch nicht, denn sobald entweder openHAB oder die RaspberryMatic neu gestartet werden, erscheint wieder der gleiche Fehler. Daher gehe ich davon aus, dass es sich hierbei um einen Bug in dem Homematic-Binding handelt. Man kann den Fehler leicht reproduzieren, dazu braucht man nur in CUxD ein Gerät vom Typ 28 anlegen, es in der CCU fertigstellen und dann in der PaperUI erkennen lassen. Schon erscheint der o.g. Fehler im Log.

Antworten