Closed horchi closed 5 years ago
You can look at the docker logs: docker log ccu
You should also check if the /dev/raw_uart is there.
yes /dev/raw_uart exists.
the erroes are:
root@dashboard:~# docker logs ccu|grep -i err
mkdir: can't create directory '/var/lib/dbus': No such file or directory
chmod: /var/lib/dbus: No such file or directory
sed: /etc/config/hs485d.conf: No such file or directory
mknod: /dev/mmd_hmip: File exists
mknod: /dev/mmd_bidcos: File exists
killall: sshd: no process killed
killall: hs485d: no process killed
start-stop-daemon: warning: killing process 258: No such process
etc/config/addons/www/xmlapi/scripterrors.cgi
Detected Raspberry PI
sed: /etc/config/hs485d.conf: No such file or directory
Starting multimacd: .....ERROR
Starting HMIPServer: (/dev/mmd_hmip) .......................................................................................................................................................ERROR
Detected Raspberry PI
mknod: /dev/mmd_hmip: File exists
mknod: /dev/mmd_bidcos: File exists
Detected Raspberry PI
killall: sshd: no process killed
killall: hs485d: no process killed
start-stop-daemon: warning: killing process 247: No such process
Starting multimacd: .....ERROR
Starting HMIPServer: (/dev/mmd_hmip) .......................................................................................................................................................ERROR
Detected Raspberry PI
Detected Raspberry PI
sed: /etc/config/hs485d.conf: No such file or directory
Starting multimacd: .....ERROR
Starting HMIPServer: (/dev/mmd_hmip) .......................................................................................................................................................ERROR
mknod: /dev/mmd_hmip: File exists
mknod: /dev/mmd_bidcos: File exists
Detected Raspberry PI
killall: sshd: no process killed
killall: hs485d: no process killed
start-stop-daemon: warning: killing process 233: No such process
May be this is the interresting part?
Starting /etc/init.d/S11InitRFHardware
Identifying Homematic RF-Hardware: BidCos-RF: HM-MOD-RPI-PCB, HmIP: HM-MOD-RPI-PCB, OK
Starting /etc/init.d/S12UpdateRFHardware
Updating Homematic RF-Hardware: disabled
I assume the RF hardware is the radio module, am I right? But it looks like it is disabled. How I can enable it?
You can docker exec ccu
and check the script (sorry, flying so I have no access to my home setup).
Dissable means that not all required devices could be found within the container. If raw_uart is there then the second to check is e3q_loop.
The naming of the device files a a bit different here:
crw------- 1 root root 242, 0 Feb 12 08:19 /dev/raw-uart
root@dashboard:~# dir /dev/eq3loop
crw------- 1 root root 244, 0 Feb 12 08:19 /dev/eq3loop```
instead of raw_uart and e3q_loop as as mentioned
Here the scripts output:
root@dashboard:~# docker exec ccu /etc/init.d/S11InitRFHardware stop root@dashboard:~# docker exec ccu /etc/init.d/S11InitRFHardware start Identifying Homematic RF-Hardware: BidCos-RF: none, HmIP: none, OK
And thx for your help!
this did not work too:
root@dashboard:~# docker exec ccu /bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t HM-MOD-UART -c -v 2019/02/12 08:48:50.453 <Info> CCU2CommControllerMod::sendSystemCommand(): failed 2019/02/12 08:48:50.453 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state. 2019/02/12 08:48:52.455 <Info> CCU2CommControllerMod::sendSystemCommand(): failed 2019/02/12 08:48:52.455 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state. 2019/02/12 08:48:54.456 <Info> CCU2CommControllerMod::sendSystemCommand(): failed 2019/02/12 08:48:54.456 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state. 2019/02/12 08:48:55.455 <Error> CoprocessorUpdate::startApplication():Could not start Coprocessor application. 2019/02/12 08:48:55.455 <Error> Could not start Application, maybe no application on device, do update with dummy Version: 0.0.0
looks like the RF module is nor detected, did I need to load a kernel module for it?
Or should I gif this a try?
How to update to a new CCU firmware ./pull.sh ./deploy.sh
After updating the CCU firmware now change:
root@dashboard:~/build/docker-ccu# docker exec ccu /etc/init.d/S11InitRFHardware start Identifying Homematic RF-Hardware: BidCos-RF: none, HmIP: none, OK
May I should try this:
docker exec ccu /bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t HM-MOD-UART -u -f -d /firmware/HM-MOD-UART
I'm little afraid to damage the RF module, actually it is still working with my old raspberry setup :o. If it after the update is not working neither in the new and old setup I can't control my covers anymore
I checked this too now, the FW update seems to be worked - I don't got a error message. But unfortunately it'*s still not working. Also tried the CCU2 branch - even no luck with it.
Any ideas or tips what else i can check or try?
Hi,
after a test with the new RPI-RF-MOD I went back to the small HM-MOD-UART and run into the same issue as you: multimacd would not start.
I personally came into this problem because I flashed the wrong firmware.
To force the update you need to:
1.rm /var/rf_firmware_version
/etc/init.d/S12UpdateRFHardware start
/etc/init.d/S60multimacd restart
also no luck :(, here the output of the commands:
root@dashboard:~/build/docker-ccu# docker exec -it ccu sh
/ # rm /var/rf_firmware_version
/ # /etc/init.d/S12UpdateRFHardware stop
/ # /etc/init.d/S12UpdateRFHardware start
Updating Homematic RF-Hardware: no GPIO/USB connected RF-hardware found
/ # /etc/init.d/S60multimacd restart
Stopping multimacd: OK
Starting multimacd: .....ERROR
I hope i tried it the right way?
What is the content of your '/var/hm_mode ' and what type of radio module are you using (the old one or the new one with battery)?
Mine (with the old radio module) looks like:
/ # cat /var/hm_mode
HM_HMIP_DEV='HM-MOD-RPI-PCB'
HM_HMIP_DEVNODE='/dev/raw-uart'
HM_HMRF_ADDRESS='0xXXX'
HM_HMRF_DEV='HM-MOD-RPI-PCB'
HM_HMRF_DEVNODE='/dev/raw-uart'
HM_HMRF_SERIAL='XXXX'
HM_HMRF_VERSION='2.8.6'
HM_HOST='Unknown'
HM_HOST_GPIO_RESET=''
HM_HOST_GPIO_UART='/dev/raw-uart'
HM_LED_GREEN=''
HM_LED_GREEN_MODE1='none'
HM_LED_GREEN_MODE2='none'
HM_LED_RED=''
HM_LED_RED_MODE1='none'
HM_LED_RED_MODE2='none'
HM_LED_YELLOW=''
HM_LED_YELLOW_MODE1='none'
HM_LED_YELLOW_MODE2='none'
HM_MODE='NORMAL'
the values in my hm_mode are almost all empty. My radio module is ~3 years old without a byttery.
I now tested with your settings in /var/hm_mode with this result:
/var # rm /var/rf_firmware_version
/var # /etc/init.d/S12UpdateRFHardware start
Updating Homematic RF-Hardware: HM-MOD-RPI-PCB: =>2.8.6, forcing, ERROR (not != 2.8.6)
/var # /etc/init.d/S60multimacd restart
Stopping multimacd: OK
Starting multimacd: .....ERROR
/var # /etc/init.d/S11InitRFHardware stop
/var # /etc/init.d/S11InitRFHardware start
Identifying Homematic RF-Hardware: BidCos-RF: none, HmIP: none, OK
did you also use raspbian stretch? What are your dtoverlay settings and did you had to change the kernel commandline settings in /boot/cmdline.txt to get it working?
The values for /var/hm_mode are written by /etc/init.d/S11InitRFHardware start
and /etc/init.d/S12UpdateRFHardware start
. This includes reading the serial number from the device.
I am currently using an odroid HC1 with an USB adapter and armbian. Before I used an OrangePi with the same antenna as yours. Only initially I had a PI with raspbian used for Homematic.
It looks like the homematic tools are not able to communicate with the device and therefore the firmware update fails. You said that the /dev/raw-uart is present inside the docker, correct? If this the case then /etc/init.d/S11InitRFHardware start
should detect it. It is important no try to run the update while other homematic tools access the same device: did you create the container manually so that the entry script is not executed (you can double check with docker logs)?
What versions of the pivccu modules do you have? They should take care of configuring the cmdline and overlays correctly...
@horchi - I think I have found the issue: the realtime scheduler in the kernel. Without it the multimac module was not able to connect sucesfully to the antenna.
I have extended the deploy.sh script to enable the realtime scheduler. Could you please see if helps you?
In my case I also had problems with one of my antenna modules: I had managed to load a broken firmware so I had to manually load the firmware before it worked again: the CCU scripts spect to at least be able to query the version which is not possible when the firmware is damaged.
This is fixed in the latest deploy.sh script
Hi, I just cloned the docker-ccu master branch, called build.sh and deploy.sh on a raspberry 3b Then I imports the settings from my ols instaltion (also on a raspberry). After that i can see my devices and programms on the web interface :)
Then I shutdown and installes the homematic radio module (which I used before at the old raspberry) andd booted again.
After logging in to the web interface I get the Message:
The /dev/ttyS0 is present, the cmdline.txt looks like:
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=5f14d53a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles usbhid.mousepoll=0
and dtoverlay ist set to:
root@dashboard:/boot# grep dtov config.txt dtoverlay=pivccu-raspberrypi dtoverlay=pi3-miniuart-bt
Any hint what is going wrong? Is there someting like a homatic log file which can help? In the syslog i calt find a hint about the problem. May I have to use the ccu2 branch instead of master?
Thx and regards Jörg