start4.elf kann nicht gelesen werden!?

[Lioncar]

@Thomas-Braun
Also Buster lite ist drauf... läuft...
Dann PIVCCU gemäß Deinem link gestartet, bis einschließlich punkt 5 alles paletti, jedoch bei punkt 6 stockt es.
Brauche die Option 1: Disabled bluetooth (prefered).
Folgendes Resultat:

code_text

pi@raspberrypi:~ $ sudo bash -c 'cat << EOT >> /boot/config.txt dtoverlay=pi3-di         sable-bt EOT'
bash: Warnung: Das in der Zeile 0 beginnende Here-Dokument geht bis zum Dateiend         e (erwartet wird `EOT').
cat: 'dtoverlay=pi3-disable-bt': Datei oder Verzeichnis nicht gefunden
cat: EOT: Datei oder Verzeichnis nicht gefunden
pi@raspberrypi:~ $

code_text

So wie ich die Befehle verstehe wird wird hier Bluetooth von einem PI3 deaktiviert, we muss der Befehl beim PI4 lauten?

[Thomas Braun]

@Lioncar
Keine Ahnung.
Vermutlich mit
dtoverlay=disable-bt
statt
dtoverlay=pi3-disable-bt

[Lioncar]

@Thomas-Braun

pi@raspberrypi:~ $ sudo bash -c 'cat << EOT >> /boot/config.txt dtoverlay=disable-bt EOT'
bash: Warnung: Das in der Zeile 0 beginnende Here-Dokument geht bis zum Dateiende (erwartet wird `EOT').
cat: 'dtoverlay=disable-bt': Datei oder Verzeichnis nicht gefunden
cat: EOT: Datei oder Verzeichnis nicht gefunden
pi@raspberrypi:~ $

Auch nicht besser, was sagt mir denn die Antowort? "Datei oder Verzeichnis nicht gefunden" hört sich nicht nach einem Erfolg an!?

[Thomas Braun]

@Lioncar
Du machst das wohl falsch.
Den ganzen Block kopieren und dann (bei meiner shell funktioniert das mit der rechten Maustaste) in die Kommendozeile pasten.
Sieht dann so aus:

pi@raspberrypi:~ $ sudo bash -c 'cat << EOT >> /boot/config.txt
> dtoverlay=pi3-disable-bt
> EOT'
do systemctl disable hcipi@raspberrypi:~ $ sudo systemctl disable hciuart.service
Removed /etc/systemd/system/multi-user.target.wants/hciuart.service.

[Lioncar]

@Thomas-Braun
Für den Punkt der entscheidende Tip.
Habe dann bis einschließlich Punkt 8 ("Update your config. (Replace eth0 if necessary)"), dann reboot und über Putty keine Chance mehr, so als wenn LAN aus ist!?

So doof mit copy/past kann ich doch nicht sein...

[Thomas Braun]

@Lioncar
In Punkt 8 wird ja auch am Netzwerk herumgemacht.
Da wird ja eine bridge br0 auf eth0 installiert.

Eigentlich sollte die sich dann per DHCP eine neue IP von deinem Router holen.
Der Pi ist aber schon per Netzwerkkabel angeschlossen? Oder funkt der per WLAN herum?

[Lioncar]

@Thomas-Braun
Ne ist per LAN dran.

Ich fange gerade nochmal komplett von vorn an. Glaube, dass das Bluetooth abschalten doch noch nicht so funzt wie Du geschrieben hast! Dann gucke ich mal was Ounkt 8 sagt und poste es.

[Thomas Braun]

@Lioncar
Auf meinem PI4 'funzt' das aber einwandfrei. Eben ausprobiert.

[Lioncar]

@Thomas-Braun
die ganze Installation der PIVCCU??

[Lioncar]

@Thomas-Braun
Zwischenstand Ab Punkt 6 der Beschreibung, bevor ich Punkt 8 weiter mache:

pi@raspberrypi:~ $ sudo bash -c 'cat << EOT >> /boot/config.txt
> dtoverlay=pi3-disable-bt
> EOT'
pi@raspberrypi:~ $ sudo systemctl disable hciuart.service
Removed /etc/systemd/system/multi-user.target.wants/hciuart.service.
pi@raspberrypi:~ $ sudo sed -i /boot/cmdline.txt -e "s/console=serial0,[0-9]\+ //"
pi@raspberrypi:~ $ sudo sed -i /boot/cmdline.txt -e "s/console=ttyAMA0,[0-9]\+ //"
pi@raspberrypi:~ $ sudo ip link show | cut -d' ' -f2 | cut -d: -f1 | grep -e '^e.*'
eth0
pi@raspberrypi:~ $

In Zeile 4 sieht es nicht so aus wie bei Dir!? "do systemctl disable pi@raspberrypi" fehlt!?

[Thomas Braun]

@Lioncar

Womöglich habe ich hier andere Versionen drauf.
Ich werde den weiteren Verlauf aber auf meinem System nicht mehr nachstellen, das ist mir zu viel Veränderung am Netzwerk, dafür dass ich keine CCU hierlaufen habe.

[Thomas Braun]

@Lioncar

Ich habe das jetzt mal auf einem zweiten Raspberry4 nachgestellt.

Im Punkt 8 wird da das Netzwerk umgefummelt, ich verstehe aber nicht warum.
Ich habe dann nach dem Punkt per lokalem login auf dem Pi das Netzwerkinterface wieder hochgefahren und konnte dann wieder per SSH auf das Testsystem.
Danach habe ich dann die ganze Hardware als Software-Emulation konfiguriert. Er hat dann wegen der fehlenden Bridge gemeckert, br0 gibt es in der Tat nicht auf meinem System...
Edit: War wohl ein Copy&Paste fehler. Bei einem zweiten Versuch das sauber zu installieren hat das einwandfrei funktioniert. (Halt den erwarteten IP-Wechsel berücksichtigen).

Jedenfalls meldet sich die pivccu aber wie folgt zurück:

pi@raspberrypi:~ $ sudo pivccu-info
piVCCU version: 3.53.34-49
Kernel modules: Available
Raw UART dev:   Available
Rasp.Pi UART:   Assigned to GPIO pins
HMRF Hardware:  FAKE_HMRF
 Connected via:  (/dev/)
 Board serial:  FKE4531762
 Radio MAC:     0xff0906
HMIP Hardware:  FAKE_HMRF
 SGTIN:         3014F711A061A7D5699DAB52
 Radio MAC:     0xff0906
State:          RUNNING
PID:            1530
CPU use:        0.57 seconds
BlkIO use:      20.00 KiB
Link:           vethpivccu
 TX bytes:      5.74 KiB
 RX bytes:      4.44 KiB
 Total bytes:   10.18 KiB

Warum das Netzwerk da so umgefummelt und eine Bridge eingerichtet werden soll wird weiß ich allerdings nicht. Wird wohl mit dem lxc zusammenhängen.

Den ioBroker konnte ich aber natürlich dann noch daneben setzen:

pi@raspberrypi:~ $ iobroker status
iobroker is running on this host.

At least one iobroker host is running.

Objects type: file
States  type: file

[Edit:] Ich habe nachträglich nochmal die Befehle aus Punkt 8 ausgeführt, jetzt steht die Bridge auch, natürlich läuft der Pi nun unter einer anderen IP im Netz. Ggfls im Router nachschauen, welche das nun ist.
Oder per

ip a

lokal aus dem System heraus.

Die Interfaces sehen grob nun so aus:

pi@raspberrypi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether  brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether  brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether  brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.XY/24 brd 192.168.178.255 scope global dynamic br0
       valid_lft 862575sec preferred_lft 862575sec
    inet6  scope global dynamic mngtmpaddr
       valid_lft 7042sec preferred_lft 3442sec
    inet6  scope link
       valid_lft forever preferred_lft forever
6: vethpivccu@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether  brd  link-netnsid 0
    inet6  scope link
       valid_lft forever preferred_lft forever

Kurzzusammenfassung:
Die Befehlsfolge aus
https://github.com/alexreinert/piVCCU/blob/master/docs/setup/raspberrypi.md
genau kopieren und ausführen; dann den ioBroker per Einzeiler noch hinterherwerfen:

curl -sL https://iobroker.net/install.sh | bash -

Fertig ist das Kombipaket aus ioBroker und pivccu.

[Lioncar]

@Thomas-Braun
EDLICH!! Es hat geklappt, aber ich weiß glaube ich warum nicht.
Mit ist aufgefallen, dass Du das Funkmodul während der INstallation als Simulation ausgewählt hast, richtig?

HMRF Hardware:  FAKE_HMRF

Ich hatte da immer das reale gewählt, obwohl ich es noch nicht eingebaut hatte, da ich meine laufende CCU3 nicht deaktivieren wollte.

TAUSEND DANK für Deine Mühen!!!!

[Homoran]

@Lioncar sagte in start4.elf kann nicht gelesen werden!?:

ch hatte da immer das reale gewählt, obwohl ich es noch nicht eingebaut hatte

dann startet piVCCU nicht

[Thomas Braun]

@Lioncar Nein, die Fake Hardware habe ich gewählt, weil ich keine reale Hardware zur Hand habe.

[Lioncar]

@Thomas-Braun
Wie gesagt, das dachte ich mir.
Jetzt hänge ich beim nächsten Problem, was aber die PIVCCU betrifft, deswgen nutze ich zu dem Thema das GitHub-Forum von Alex Reinert.

link text

[Homoran]

@Lioncar sagte in start4.elf kann nicht gelesen werden!?:

deswgen nutze ich zu dem Thema das GitHub-Forum von Alex Reinert.

Naja, ein Forum ist das nicht.
Der Weg ist gedacht zum Melden von "echten" Fehlern