openWB 2.0 Alpha 1 per Raspberry Emulation

[mth]

Hallo zusammen,

da ich noch keine OpenWB habe, und meine Anforderungen unbedingt v2.0 vorraussetzen, wollte ich mal einen eigenen Blick auf die SW werfen.
Natürlich habe ich auch keinen Raspberry, drum hab ich versucht, die OpenWB 2.0 Alpha1 auf einer QEMU Emulation unter Windows 10 zu verwenden.
Da mir das nach langem basteln gelungen ist, wollte ich das mit euch teilen - evtl. hat da ja jemand Verwendung für - hier also eine Anleizung dazu:

Zunächst brauchen wir QEMU für Windows - das gibt es hier: https://www.qemu.org/download/#windows - ich hab die qemu-w64-setup-20211215.exe verwendet.

Ich hab QEMU nach C:\qemu installiert. In dem Verzeichnis brauchen wir auch noch versatile-pb-bullseye-5.10.63.dtb und kernel-qemu-5.10.63-bullseye aus https://github.com/dhruvvyas90/qemu-rpi-kernel.

Auch das Image von OpenWB brauchen wir in dem Verzeichnis - also openWB-2-bullseye-alpha1.img.gz runter laden und z.B. mit 7-ZIP entpacken und nach C:\qemu kopieren.

Dann die Windows Eingabeaufforderung noch auf ANSI umstellen - wer mag - man muss das nicht machen ( die Linux Start-Meldungen haben dann einen grünen oder roten Status).
Dazu in einer CMD-Shell (=Eingabeaufforderung ) folgenden Befehl absetzen und die Eingabeaufforderung danach neu starten:

Code: Alles auswählen

reg add "HKEY_CURRENT_USER\Console" /v VirtualTerminalLevel /t REG_DWORD /d 1

Wenn wir schon eine Eingabeaufforderung offen haben, können wir gleich noch das OpenWB Image Rezizen - denn, für QEMU muss es 2,4,8 oder 16 GB groß sein - da es schon gut 3 GB hat, resizen wir es auf 4 GB:

Code: Alles auswählen

qemu-img resize -f raw openWB-2-bullseye-alpha1.img 4G

Als nächstes legen wir ein Start-Skript, z.B. "runOpenWB.cmd" in C:\qemu ab, mit dem wir openWB zukünftig starten können:

Code: Alles auswählen

@echo off
cd /d C:\qemu
mode con cols=200 lines=1999

qemu-system-arm -M versatilepb -m 256 -k de -nographic -cpu arm1176 -no-reboot -serial stdio ^
-kernel kernel-qemu-5.10.63-bullseye -dtb versatile-pb-bullseye-5.10.63.dtb ^
-device virtio-net,netdev=myowbnet ^
-netdev "user,id=myowbnet,ipv6=off,hostfwd=tcp::5022-:22,hostfwd=tcp::5080-:80,hostfwd=tcp::9001-:9001,hostfwd=tcp::1883-:1883,hostfwd=tcp::1884-:1884" ^
-drive "file=openWB-2-bullseye-alpha1.img,media=disk,format=raw" ^
-append "root=/dev/sda2 rootfstype=ext4 rw fsck.repair=yes rootwait panic=1 ipv6.disable=1"
pause

Wer den ANSI-Modus oben nicht setzen wollte, sollte hier statt "-serial stdio" das hier verwenden: "-serial mon:stdio" - ich hab das aber nicht ausprobiert, hatte aber vor dem ANSI setzen komische Steuer-Codes in der Ausgabe...
Zu dem "runOpenWB.cmd" Start-Skript hab ich mir eine Verknüpfung auf dem Desktop abgelegt.

Nun können wir die Emulation das erste mal starten. Man braucht etwas Geduld - wir verwenden nur eine CPU und max. 256 MB Ram - leider habe ich die nativen RPI-Simulationen von QEMU nicht stabil zum laufen bekommen (ich vermute, dass das hier der Grund dafür ist, bin mir aber nicht sicher: https://gitlab.com/qemu-project/qemu/-/issues/198).
Die Console, die sich öffnet, zeigt, wo man sich im Boot-Prozess befindet. . Nach etwa 60sec kann man sich anmelden. Ich würde mit diesem Fenster aber nicht arbeiten, denn ein "STRG-c" bricht sofort die ganze Emulation ab - wirkt also wie ein Stromausfall auf OpenWB...
Statdessen kann man z.B. per Putty eine SSH-Verbindung nach "localhost" mit dem Port 5022 öffnen.
Login ist, wie von OpenWB beschrieben, der User "pi" mit dem PW "openWB".
Auch beim Login braucht man etwas Geduld - dauert bei mir ca. 15 sec nach user/pw Eingabe, ehe der Linux Prompt erscheint...

Leider läuft OpenWB auf der QEMU Emulation nicht sofort - ich musste noch an zwei Stellen Anpassungen durchführen.
Das Python Modul RPi.GPIO bricht beim import mit dem Fehler "main.py[...]: RuntimeError: This module can only be run on a Raspberry Pi!" ab - das kann man in "/var/log/syslog" finden.
Um das zu umgehen, hab ich einen Patch erstellt - also z.B. mit nano oder vi (sind Text-Editoren) einen neuen Patch anlegen unter "~/GPIO_Emulation.patch" mit dem Inhalt:

Code: Alles auswählen

diff --git a/packages/modules/ripple_control_receiver.py b/packages/modules/ripple_control_receiver.py
index 2db4bec1..bd9ff960 100644
--- a/packages/modules/ripple_control_receiver.py
+++ b/packages/modules/ripple_control_receiver.py
@@ -1,4 +1,7 @@
-import RPi.GPIO as GPIO
+try:
+    import RPi.GPIO as GPIO
+except RuntimeError:
+    pass
 import time

 from helpermodules.log import MainLogger
@@ -7,6 +10,14 @@ from helpermodules.pub import Pub

 def read():

+    if "GPIO" not in dir():
+        Pub().pub("openWB/set/general/ripple_control_receiver/r1_active", False)
+        time.sleep(0.2)
+        Pub().pub("openWB/set/general/ripple_control_receiver/r2_active", False)
+        time.sleep(0.2)
+        return
+
+
     GPIO.setmode(GPIO.BCM)
     GPIO.setup(8, GPIO.IN, pull_up_down=GPIO.PUD_UP)
     GPIO.setup(9, GPIO.IN, pull_up_down=GPIO.PUD_UP)

Per Hand wird der Patch so aktiviert:

Code: Alles auswählen

cd /var/www/html/openWB
git apply ~/GPIO_Emulation.patch

Danach würde openWB zwar laufen, aber, ich habe am Windows PC, per Firefox, auf die URL http://localhost:5080 einen endlosen Ladebalken bekommen. Grund ist der "websocket" vom mosquitto-Service, der dafür nur IPv6 nutzt - welches am Emulator scheinbar nicht einfach so durch geht. Also habe ich die "/etc/mosquitto/conf.d/openwb.conf" per "sudo vi" oder "sudo nano" angepasst:

Code: Alles auswählen

listener 9001
socket_domain ipv4
protocol websockets
allow_anonymous true

listener 1883
socket_domain ipv4
protocol mqtt
allow_anonymous true

listener 1884
socket_domain ipv4
protocol websockets
allow_anonymous true
# prevent too many inactive connections from buggy clients
# closes inactive connections after 4 hours
persistent_client_expiration 4h

Je "listener" hab ich den "socket_domain" fest auf "ipv4" gestellt.

Vor dem finalen Reboot habe ich dann noch ein Update auf die neueste openWB gemacht - dazu habe ich den Update von "derNeueDet" (viewtopic.php?p=55192#p55192) unter ~/update.sh noch wegen dem Python Patch angepasst:

Code: Alles auswählen

cd /var/www/html/openWB && echo $PWD
sudo systemctl stop openwb2 && echo "Service angehalten"
[ -f ~/GPIO_Emulation.patch ] && git apply -R ~/GPIO_Emulation.patch
git stash
git pull --ff-only
[ -f ~/GPIO_Emulation.patch ] && git apply ~/GPIO_Emulation.patch
sudo systemctl start openwb2 && echo "Service gestartet"
sudo runs/atreboot.sh

Also, vor dem Update den Patch rückgängig gemacht, und nach dem Update den Patch wieder aktiviert.

Der erste Update dauert schon etwas - wenn alles fertig ist, kann man openWB mit "sudo shutdown now" sauber beenden (sollte man bei Linux eigentlich immer so machen). Ab dem nächsten Start sollte dann eigentlich alles klappen.

Wenn jemand Probleme hat, kann ich gerne noch hier oder da zwei Sätze mehr dazu schreiben - eine gewisse Grundkenntniss von Linux setze ich aber schon vorraus

Viel Spass damit

[hubecker]

Hallo,
Ich habe mir nach dieser Anleitung
https://www.technik22.de/d/51-raspberry ... stallieren
ein raspian unter proxmox intstalliert
Der download https://downloads.raspberrypi.org/rpd_x ... r-i386.isoist ein Debian Buster iso image.
Darauf dann openWB 1.9 oder openWB 2.0 von git installieren.
Funktioniert bestens.
Gruß

Hubert

[Flocki]

Ich habe mir ebenfalls das Image in eine Proxmox-VM geladen, dort ein Update auf Bullseye laufen lassen und dann OpenWB 2.0 installiert.

Bei der fehlenden RPi.GPIO-Bibliothek bin ich einen etwas anderen Weg gegangen und habe mir in das packages-Verzeichnis eine Dummy-Bibliothek gelegt, die nichts tut.

Code: Alles auswählen

BOARD = 1
OUT = 1
IN = 1

def setmode(a):
   pass
def setup(a, b):
   pass
def output(a, b):
   pass
def cleanup():
   pass
def setwarnings(flag):
   pass

Dann bin ich ebenfalls über den grauen Balken gestolpert und habe wie oben beschrieben die Mosquitto-Konfiguration angepasst. Zusätzlich musste ich noch in beiden Konfigurationsdateien alle "localhost" durch "127.0.0.1" ersetzen, damit läuft es auch bei mir.