piVCCU3 with HM-MOD-RPI-PCB stop communication after some minutes

[franki29]

Hi, I have piVCCU3 successful running on a OrangePI with Armbian. All seems to work fine, but after some minutes, the communication between the HM-MOD-RPI-PCB and the CCU3 seems to stop working.
Looking at pivccu-info, all looks fine.

The messages log file shows
Interface HmIP-RF http port 32010 connected
Dec 8 09:57:12 ccu3-webui daemon.info node-red[691]: [ccu-connection:localhost] Interface VirtualDevices http port 39292 connected
Dec 8 09:57:13 ccu3-webui daemon.info node-red[691]: [ccu-connection:localhost] metadata saved to /usr/local/addons/redmatic/var/ccu_localhost.json
Dec 8 09:57:14 ccu3-webui daemon.info node-red[691]: [ccu-connection:localhost] regadata saved to /usr/local/addons/redmatic/var/ccu_rega_localhost.json
Dec 8 10:00:23 ccu3-webui daemon.info ntpd[270]: Listen normally on 5 eth0 [2001:16b8:1c4d:a800:585e:19ff:fe8a:1a2b]:123
Dec 8 10:02:06 ccu3-webui daemon.info ntpd[270]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Dec 8 10:05:24 ccu3-webui local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"00129B33939A47:1","SET_POINT_TEMPERATURE",18.000000}, result: [faultCode:-1,faultString:"Generic error (TIMEOUT)"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Dec 8 10:05:24 ccu3-webui local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1009, params: {"00129B33939A47:1","SET_POINT_TEMPERATURE",18.000000}) [CallSetValue():iseXmlRpc.cpp:1505]
Dec 8 10:05:24 ccu3-webui local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 00129B33939A47:1 [WriteValue():iseDOMdpHSS.cpp:76]
Dec 8 10:20:26 ccu3-webui local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"00129B33939A47:1","SET_POINT_TEMPERATURE",18.000000}, result: [faultCode:-1,faultString:"Generic error (TIMEOUT)"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Dec 8 10:20:26 ccu3-webui local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1009, params: {"00129B33939A47:1","SET_POINT_TEMPERATURE",18.000000}) [CallSetValue():iseXmlRpc.cpp:1505]
Dec 8 10:20:26 ccu3-webui local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 00129B33939A47:1 [WriteValue():iseDOMdpHSS.cpp:76]

After restart the pivccu.service it works again, but after some minutes same problem.

piVCCU version: 3.53.34-50
Kernel modules: Available
Raw UART dev: Available
HMRF Hardware: HM-MOD-RPI-PCB
Connected via: GPIO (/dev/raw-uart)
Board serial: QEQ0412760
Radio MAC: 0x6D1650
HMIP Hardware: HM-MOD-RPI-PCB
SGTIN: 3014F711A061A7DA498FB458
Radio MAC: 0xB13AA2
State: RUNNING
PID: 8059
IP: 192.168.2.103
IP: 2001:16b8:1c4d:a800:585e:19ff:fe8a:1a2b
CPU use: 2680.52 seconds
BlkIO use: 7.75 MiB
Memory use: 185.89 MiB
KMem use: 7.82 MiB
Link: vethpivccu
TX bytes: 4.18 MiB
RX bytes: 1.68 MiB
Total bytes: 5.85 MiB

Any hints where to look for?

Thanks and best regards
Frank

[alexreinert]

Generic error (TIMEOUT) does not neccessarily mean, that the communication with the HM-MOD-RPI-PCB is erroneous, it could be some radio trouble, too.

[franki29]

Ich denke in Deutsch geht die Kommunikation hier auch :-) :

Hatte ich auch erst gedacht und habe dann einen nicht verbauten Fensterkontakt direkt an mein OrangePi gehalten, leider ohne Erfolg, keine Kommunikation, erst wieder nach dem Restart des Service

[alexreinert]

Wie sieht der DutyCycle aus?

Ein weiterer Versuch wäre es, die Datei /var/lib/piVCCU3/rootfs/etc/crRFD.conf anzupassen und dort die Zeile
Lan.Routing.Enabled=true durch Lan.Routing.Enabled=false ersetzen.

[franki29]

Der DutyCycle ist bei max 3%, ich habe auch zur Zeit nur ein Heizkörperthermostat und den Fensterkontakt drin.
Das Lan.Routing hat leider auch nichts gebracht.
Habe auch versucht verschieden Dienste unter /etc/init.d neu zu starten, auch ohne Erfolg.
Nur der Neustart des gesamten System bringt die Kommunikation für ein paar Minuten zurück.
Sehe ich das richtig, das der Port 32010 für die Kommunikation zum HM-MOD-RPI-PCB genutzt wird?

[alexreinert]

Vielleicht sollten wir nochmal einen Schritt zurück: Welche Kommunikation meinst du denn konkret?

Das HM-MOD-RPI-PCB direkt wird vom multimacd per Kernel Modul direkt über den UART der GPIO Leiste angesprochen. der multimacd stellt wiederrum zwei Dev-Nodes ebenfalls per Kernel Modul bereit, welche dann vom rfd (für BidCos) und vom hmserver (für HmIP) genutzt werden. Erst ab dieser Stelle wird dann Kommunikation über TCP eingesetzt, u.A. auch auf Port 32010, aber das kommt drauf an, welche Services miteinander reden.

[franki29]

Danke für die Infos, ist jetzt klarer wie die Kommunikation funktioniert. Habe allerdings nichts negatives in den Log's feststellen können. Einzig dass multimacd meistens als Rückmeldung ein ACK bekommt. Muss ich allerdings nochmals näher anschauen. Gibt es noch etwas wo ich drauf achten sollte?

[alexreinert]

Nochmal die Frage: Woran machst du die gestörte Kommunikation fest? Ist es in der WebUI, ist es bei Programmen, externes System wie ioBroker, openhab, fhem, ...?

[franki29]

Erst mal im WebUI, dann dass mein Fensterkontakt erst Gelb dann Rot leuchtet sobald man den Kontakt öffnet/schließt und auch in Domoticz, wo die Kommunikation als gestört gemeldet wird. Und natürlich im Log von der CCU. Wie schon beschrieben, nach einem Neustart funktioniert für kurze Zeit alles normal. Vielleicht ist es auch ein Hardware Problem. Ich versuche mal ein anders Board (Banana Pi Zero).

[franki29]

Das mit dem Bananapi Zero war nix, der wird als inkompatibel Hardware abgestempelt. Daher habe ich einen Reset auf meiner vorhandenen Installation vorgenommen und vorher ein Backup über das WebGUI gemacht.
Nach dem Neustart sprang der Duty cyle auf 8, anschließend dann auf 11% hoch, vorher war er immer um die 3%.
Ein wenig gewartet aber keine Kommunikationsprobleme mehr. Ich hatte vorher noch Redmatic drauf, der Link im GUI ging aber nicht mehr. Also Redmatik nachinstalliert und schon nach kurzer Zeit Kommunikationsprobleme. Komischerweise waren im RedMatic noch meine alten Paletten (Tasmota) drin. Also Redmatic deinstalliert danach wieder neu Installiert.

Jetzt scheint alles wieder zu laufen.

Aus meiner Sicht muss nach dem letzten Update der Software etwas schief gelaufen sein, anscheinend bei Redmatic.

Vielen Dank für die Hilfe

Mfg

Frank