Installation auf Raspi2 macht viele Probleme

[tis-cs]

Wenn ich auf einem aktuellen Stretch (Version:March 2018 Release date:2018-03-13 Kernel version:4.9) nach einem update und upgrade den Autoinstaller starte, läuft alles durch, der Container wird erstellt, die Bridge erzeugt und ich komme auf die CCU2. Allerdings fällt hier bereits auf, dass der Container ca. 5-10 Minuten zum booten braucht, was er sonst nie so lange tat. Was dann sofort auffällt ist, dass das HM MOD RPI PCB nicht erkannt wird und somit sämtliche Fehlermeldungen kommen (BidCos-RF, VirtualDevices und HmIP-RF nicht erreichbar).

Ich habe dann testweise mal ein "sudo yahm-module -m pivccu-driver enable" und reboot durchgeführt, aber auch hier keine Besserung.

Was mich am meisten wundert ist, wenn ich via yahm-ui den Container lösche und einen neuen anlegen will, kommt im Prozess die Meldung "ERROR: Can not find yahm container" und es wird auch keiner angelegt! Ich bekomme nur einen neuen Container gebaut, indem ich erneut den automatischen QuickInstall starte.

Was ausgeschlossen werden kann ist, dass es eine falsche FW auf dem Modul ist, da ich es zuvor mehrere Monate immer mit YAHM betrieben habe. Ebenfalls wurde die serielle Console nicht via raspi-config deaktiviert. Ebenfalls habe ich drei absolut verschiedene Karten ausprobiert.

Grund für meinen Reinstall war, dass mir plötzlich alle HM-IP Wandthermostate fehlten und alle Programme, in denen sie vorkamen plötzlich "keine Bedingungen" hatten. Ebenfalls hatte sich das WebIf beim umbenennen eines Programmnamens aufgehängt und nicht mehr geantwortet. Habe ich eine defekte microSD angenommen und wollte frisch installieren. Oder ist dies ein anderes bekanntes Problem?

[tis-cs]

Mal eine kurze Verständnisfrage: Ist es aktuell richtig, dass nur das pivccu-driver Modul installiert ist?

Bei dem Versuch die FW des Modul upzudaten kommt nämlich folgender Fehler:

Detecting actual firmware version
start-stop-daemon: warning: killing process 351: No such process
Existing firmware version: 0.0.0
Downloading firmware files
Newest firmware version: 2.8.6
WARNING: Trying to update the module firmware to the newest version including homematic-ip support. To cancel this operation type CTRL+C you have 5 seconds...
... too late ;)
Updating firmware this cat take some time, please dont turn off your device
2018/04/13 13:26:56.152 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
.
.
.
.
.
2018/04/13 13:27:01.178 <Error> CoprocessorUpdate::startApplication():Could not start Coprocessor application.

2018/04/13 13:27:01.178 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2018/04/13 13:27:01.179 <Error> Could not start Application, maybe no application on device, do update with dummy Version: 0.0.0

2018/04/13 13:27:01.179 <Info> Update necessary, installed: 0.0.0, avaiable 2.8.6

[tis-cs]

Habe gerade noch herausgefunden, dass bei mir auf dem Host die Devices

/dev/mmd_bidcos
/dev/ttyS0

nicht angelegt wurden.

Habe dann im YAHM mit /etc/init.d/S60multimacd restart versucht dies zu korrigieren, was folgende Errors warf:

Joining LXC container, you are now inside yahm
/ # /etc/init.d/S60multimacd restart
Stopping multimacd: OK
Starting multimacd: 
Could not open SPI device: No such file or directory
Could not open SPI device: No such file or directory
2018/04/13 17:23:01.446 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
firmware update disabled
Waiting for multimacd to get ready.sh: 543: unknown operand
.sh: 543: unknown operand
.sh: 543: unknown operand
.sh: 543: unknown operand
.sh: 543: unknown operand
Timeout while waiting for multimacd to get ready.

[tis-cs]

nachdem ich weiter Foren durchsucht habe, habe ich folgendes gefunden und ausgeführt:

in der /boot/config.txt stand dtoverlay=unsupported drin. Habe dann

sed -i /boot/config.txt -e 's/dtoverlay=unsupported/dtoverlay=pivccu-bcm2835/' ausgeführt, sodass die config (aktuell testweise auf einem Pi3) nun so aussieht:

dtoverlay=pivccu-bcm2835

# Allow the normal UART pins to work
dtoverlay=pi3-miniuart-bt
enable_uart=1
force_turbo=1

Nun taucht das Modul wieder auf und ich konnte es auch wieder flashen.

Vielleicht sollte dies noch gefixed werden, damit der manuelle Eingriff nicht mehr notwendig wird.

[Yattien]

Danke für den Tipp! Ich hatte das selbe Verhalten mit einer frischen Installation von

Raspbian Stretch Lite Minimal image based on Debian Stretch Version: June 2018 Release date: 2018-06-27 Kernel version: 4.14

Nach Ausführen von sed -i /boot/config.txt -e 's/dtoverlay=unsupported/dtoverlay=pivccu-bcm2835/' und anschließendem Reboot funktionierte das Funkmodul (obwohl ich kurz zuvor raspberryMatic verwendet habe). Das manuelle Anlegen des Containers ist jedoch auch fehl geschlagen.