RaspberryMatic Installationsanleitung: vmWare ESXi, VirtualBox, Proxmox, Synology, QNAP, QEmu, HyperV

[neokalis]

Danke vorab mal für die Rückmeldung!

Das einspielen des Backup schlägt leider fehl: "Es ist kein Coprozessor verfügbar"

Diese Fehlermeldung kommt weil du vmtl. keine Funkhardware an deiner virtuellen RaspberryMatic angeschlossen hast und noch am testen bist. Sobald du ein HB-RF-USB oder HmIP-RFUSB angeschlossen hast sollte diese Fehlermeldung nicht mehr kommen.

Das verwunderliche war eben, dass der HMIP-RFUSB-TK während des Restores angeschlossen war. Ich habe dann zu späterem Zeitpunkt einen manuellen Reboot gemacht und interessanterweise waren dann die Inhalte aus meinem Backup plötzlich da, totzt der Fehlermeldung im Restore. Aber somit für mich kein Problem mehr.

Später habe ich dann noch das Update auf das Release vom 03.11. über das WebUI gemacht. Anfänglich hatte meine VM nur 256MB RAM - dort schlug das Update wiederholt fehl. Ich habe dann den RAM auf 1GB angehoben, dann ging es. Mann könnte also evtl. 1GB RAM als Mindestanforderung definieren. Ggf. geht es auch mit 512MB oder 768MB

Den fehlenden USB-Stick habe ich via zweiter virt. HDD an SATA0:1 gelöst. Gemountet wird über CuxD MOUNTCMD

Auch dafür wäre eine entsprechende Beschreibung sicherlich für andere sehr hilfreich weil das mounten auf /media/usb0 momentan noch nicht automatisch geht wenn man in der virtuellen RaspberryMatic kein USB Stick dafür reserviert angeschlossen hat.

hier mein Weg:

1. Im laufenden RaspberryMatic System setzt man auf der Konsole das Kommando

   Code: Alles auswählen

   fdisk -l

   
   ab und sichert sich den output (Kopie in TXT Datei, Screenshot)
2. Anschließend fährt man das RaspberryMatic System herunter
3. Über die Oberfläche des Hypervisors wird eine zweite virtual HardDisk erstellt und an den nächsen freien Controllerport gehängt. Hier kann man gut mit der ersten HDD vergleichen.
4. Man fährt das RaspMatic-System wieder hoch und macht auf der Konsole erneut ein

   Code: Alles auswählen

   fdisk -l

   Im Vergleich zum Output von 1) sollte nun eine weitere Platte angezeigt werden. Bei mir /dev/sdb
5. Als nächstes muss ein Filesystem auf die Platte gezogen werden. Dazu auf der Konsole des RaspMatic:

   Code: Alles auswählen

   mkfs.ext4 /dev/sdb

6. Der nächste Schritt dient nur dem temp. Test. - Einbinden der Platte:

   Code: Alles auswählen

   mount /dev/sdb /media/usb1
   cd /media/usb1
   touch test.txt
   ls -al

7. Wenn der Test erfolgreich war, also jedes einzelne Komando ohne Fehler durchgelaufen ist, dann muss noch dafür gesorgt werden, dass die Platte beim Boot automatisch eingebunden wird. Das kann man theoretisch über OS-Mittel machen, was aber evtl. das Risiko birgt, dass diese Config beim nächsten Update von RaspMatic weg ist. Deshalb empfhielt es sich hier auf das AddOn CuxD zurückzugreifen. Wenn dieses installiert ist, sieht man im Setup-Menü des CuxD eine Liste von Variablen.
   Dort sucht man sich MOUNTCMD= und passt es wie folgt an:

   Code: Alles auswählen

   MOUNTCMD=mount /dev/sdb /media/usb1

   Anschließend noch einen Klick auf speichern.
8. Nun kann man das System rebooten. Anschließend sollten z. B. im Bereich "Diagramme" der rote Hinweistext auf den fehlenden USB-Stick verschwunden sein. Testweise kann man auch auf der Konsole den Befehl

   Code: Alles auswählen

   mount

   
   absetzen. Hier sollte dann auch die Verbindung zwischen /dev/sdb und /media/usb1 auftauchen.

Die Bilder für die Anleitung zum Setup auf VMWare Player kann ich dann gerne im Laufe der nächsten Tage nachliefern.

[jmaus]

Diese Fehlermeldung kommt weil du vmtl. keine Funkhardware an deiner virtuellen RaspberryMatic angeschlossen hast und noch am testen bist. Sobald du ein HB-RF-USB oder HmIP-RFUSB angeschlossen hast sollte diese Fehlermeldung nicht mehr kommen.

Das verwunderliche war eben, dass der HMIP-RFUSB-TK während des Restores angeschlossen war. Ich habe dann zu späterem Zeitpunkt einen manuellen Reboot gemacht und interessanterweise waren dann die Inhalte aus meinem Backup plötzlich da, totzt der Fehlermeldung im Restore. Aber somit für mich kein Problem mehr.

Später habe ich dann noch das Update auf das Release vom 03.11. über das WebUI gemacht. Anfänglich hatte meine VM nur 256MB RAM - dort schlug das Update wiederholt fehl. Ich habe dann den RAM auf 1GB angehoben, dann ging es. Mann könnte also evtl. 1GB RAM als Mindestanforderung definieren. Ggf. geht es auch mit 512MB oder 768MB

Warum genau sollte man da bitte sparen?!? Du redest hier von einem virtuellen System bei dem auch der zugewiesene Arbeitsspeicher rein virtuell ist und nur soviel Speicher vom Hostsystem wirklich verbraucht/adressiert wird wie wirklich vom Gastsystem benötigt wird. Folglich kannst du da auch 4GB zuweisen und wenn das Gastsystem nur 1GB braucht wird dem Hostsystem auch nur soviel in dem Moment weggenommen.

Und so recht verwunderlich ist es doch nicht das 1GB RAM die Mindestanforderung ist, oder? Ein RaspberryPi bzw. eine CCU3 hat auch soviel und es gibt/gab ja auch einen Grund wieso ich in meinen Anleitungen und in der *.ovf Datei als Standard "2GB" angegeben habe, oder?

Auch dafür wäre eine entsprechende Beschreibung sicherlich für andere sehr hilfreich weil das mounten auf /media/usb0 momentan noch nicht automatisch geht wenn man in der virtuellen RaspberryMatic kein USB Stick dafür reserviert angeschlossen hat.

hier mein Weg:

1. Im laufenden RaspberryMatic System setzt man auf der Konsole das Kommando

   Code: Alles auswählen

   fdisk -l

   
   ab und sichert sich den output (Kopie in TXT Datei, Screenshot)

Danke für die Anleitung. Ich habe nun allerdings inzwischen in RaspberryMatic für ova direkt ein Mechanismus implementiert der die Diagramme auf der Hauptfestplatte dann unter /usr/local/ speichert, sodass man weder einen externen USB Stick noch eine zweite virtuelle Festplatte dafür mehr braucht. Ich denke das sollte die meisten Anwendungsfälle abdecken und es somit unnötig machen anhand deiner Anleitung mit manuellen Shell Befehlen händisch alles einrichten zu müssen.

Mehr dazu schreibe ich dann in meinem nächsten Beitrag.

Die Bilder für die Anleitung zum Setup auf VMWare Player kann ich dann gerne im Laufe der nächsten Tage nachliefern.

In der Tat wäre solch eine Anleitung für VMWare Player wirklich eine gute Sache da anscheinend einige Personen darauf zählen.

[jmaus]

Hallo,

wie angekündigt gibt es inzwischen wieder eine weitere Test/Betaversion der virtuellen RaspberryMatic. Die neue Version hat die Nummer 3.47.22.20191105 und ist wie die Versionen vorher über folgenden Link zu meinem Cloud-Verzeichnis erreichbar:

https://cloud.light-speed.de/s/mfMsM8S3kAHmJYo

Eine der Änderungen daher ist, das nun für die Diagrammfunktion kein externer USB Stick bzw. eine zweite virtuelle Festplatte mehr notwendig ist, sondern die Diagrammdaten einfach mit in /usr/local Partition gespeichert werden wie das früher der Fall war. Nur gibt es eben bei den virtuellen Festplatten keinerlei Grund mehr für diese Trennung weil diese eben virtuell sind und nicht auf einer SD Karte liegen die eine kurze Lebensdauer mit sich bringt und es daher potentiell kritisch ist die Diagrammdaten darauf zu speichern. Bei den virtuellen Festplatten unter einer Virtualisierungsumgebung kann man also getrost wieder /usr/local für das speichern der Diagrammdaten nutzen. Und so habe ich es nun in der 3.47.22.20191105 Version umgesetzt.

Wäre schön wenn soviele wie möglich diese neue Testversion testen könnten und berichten ob damit weiterhin alles gut funktioniert. Bestehende Installation am besten über die *.zip Datei via WebUI updaten. Aber bitte auch testweise eine frische neuinstallation via *.ova Datei testen!

[herbylfs]

Hallo,
muss man dann den CUL-Stick für CUx auch am Host durchreichen?
Damit werden noch sehr alte FS-20 Komponenten geschaltet.
Rollos, Steckdosen und FHT-Heizung.
Für die Mieter läuft für manche Aktionen noch eine alte F812 mit dem alten Homeputer (Anfang 2000) von Contronics.
Bewegungsmelder Flur, Bad, Eingang.
Es sind 4 Etagen, die gesteuert werden, die F812 schlägt sich noch immer wacker.
Deb und Rasp laufen jeweils auf Pi4 mit 64GB Karte.
Es ist im moment schön verteilt auf F812, CCU3, Debmatic und RaspberryMatic.
Jedes System hat seine Aufgaben.
Wenn das alles in einer Benutzeroberfläche wäre, ist das die Lösung.
Das Umrüsten ist ja auch nicht gerade billig.
Könnt Ihr beiden genialen Programmierer J. Maus x86 und A. Reinert mit Debmatic das nicht unter einen Hut bringen?
mfg
Herbert

[karlo enzo]

Hallo Jens,
ich habe wieder das RM-Update 1105 mit der zip-Datei in der Zentralen-Wartung unter Software-Update
hochgeladen und installiert. In der Konsole wurde auch wieder die neue Version (1105) angezeigt.
Aber RM startete nicht in die WebUi.
Eine neue VM mit Installation der ova (1105) dagegen läuft ohne Problem.
Mache ich da irgend etwas falsch beim update ???

lg Karl-Heinz

[onkeltommy]

Hi Jens

Update auf die neue Version hat geklappt (via WebUi). Lief einwandfrei durch

[jmaus]

Update auf die neue Version hat geklappt (via WebUi). Lief einwandfrei durch

Danke für die Info. Was mich allerdings interessieren würde wäre ob mit dieser version die Diagrammfunktion problemlos funktioniert.

[jmaus]

muss man dann den CUL-Stick für CUx auch am Host durchreichen?
Damit werden noch sehr alte FS-20 Komponenten geschaltet.

Ja, das muss man dann wohl. Einfach den CUL Stick an den Host anschliessen und auch noch der VM zuweisen dann sollte der beim Hochfahren vom System erkannt und für CUxD ganz normal nutzbar sein.

[Baxxy]

Hallo Jens,
auch bei mir lief das Update von 3.47.22.20191103 auf 3.47.22.20191105 problemlos über das WebUI (in ca. 4 Minuten) durch. Eine komplett frische VM 3.47.22.20191105 ging auch ruck zuck und läuft ohne erkennbare Fehler. Inzwischen verrichtet auch ein HB-RF-USB-TK mit HM-MOD-RPI-PCB an der vRM seinen Dienst.

ein Mechanismus implementiert der die Diagramme auf der Hauptfestplatte dann unter /usr/local/ speichert

Die Diagramme habe ich noch nicht gestestet aber die Backups und z.B. die CCU-Historian Datenbank werden entsprechend dort gespeichert.
Persönlich finde ich aber die Speicherung auf einer zweiten virtuellen Festplatte, wie von neokalis beschrieben, besser. So könnte man, gerade jetzt während des Testings, seine virtuelle Datenfestplatte, einfach in eine frische vRM einhängen und hätte alles gleich wieder parat.
So wie ich das gesehen habe hast du ja einen Mechanismus drin der nur nach /usr/local/ mounted wenn kein USB-Stick angeschlossen ist. Vielleicht lässt sich das ja auch mit einer zweiten virtuellen Festplatte (sdb) machen. Also wenn sdb vorhanden dann mounte sdb anstelle von /usr/local.

Kleiner Schönheitfehler wenn kein USB-Stick dran ist.

Code: Alles auswählen

Nov  6 09:41:14 homematic-raspi user.err monit[905]: Filesystem '/media/usb1' not mounted
Nov  6 09:41:14 homematic-raspi user.err monit[905]: 'usb1' unable to read filesystem '/media/usb1' state
Nov  6 09:41:14 homematic-raspi user.info monit[905]: 'usb1' trying to restart
Nov  6 09:41:32 homematic-raspi user.err monit[905]: Filesystem '/media/usb1' not mounted
Nov  6 09:41:32 homematic-raspi user.err monit[905]: 'usb1' unable to read filesystem '/media/usb1' state
Nov  6 09:41:32 homematic-raspi user.info monit[905]: 'usb1' trying to restart

Lässt sich aber mit...

Code: Alles auswählen

monit unmonitor usb1

erstmal ruhigstellen.

Beste Grüße
Baxxy

[jmaus]

Hallo Jens,
auch bei mir lief das Update von 3.47.22.20191103 auf 3.47.22.20191105 problemlos über das WebUI (in ca. 4 Minuten) durch. Eine komplett frische VM 3.47.22.20191105 ging auch ruck zuck und läuft ohne erkennbare Fehler. Inzwischen verrichtet auch ein HB-RF-USB-TK mit HM-MOD-RPI-PCB an der vRM seinen Dienst.

ein Mechanismus implementiert der die Diagramme auf der Hauptfestplatte dann unter /usr/local/ speichert

Die Diagramme habe ich noch nicht gestestet aber die Backups und z.B. die CCU-Historian Datenbank werden entsprechend dort gespeichert.
Persönlich finde ich aber die Speicherung auf einer zweiten virtuellen Festplatte, wie von neokalis beschrieben, besser. So könnte man, gerade jetzt während des Testings, seine virtuelle Datenfestplatte, einfach in eine frische vRM einhängen und hätte alles gleich wieder parat.

Nein, kannst du trotzdem nicht, denn die eigentlichen Konfigurationsdaten (*.regadom, Addons, etc.) der RaspberryMatic liegen trotzdem unter /usr/local und das ist in der eigentlichen virtuellen Festplatte. Also kommst du nicht drumherum trotzdem regelmäßig *.sbk Backups davon anzulegen (was aber mehr vorteil als nachteil ist).

Auch wenn ich den Ordnungsdrang hier wieder teilweise nachvollziehen kann, so kann ich ihn trotzdem leider nicht ganz verstehen. Bei virtuellen Systemen ist es absolut wurscht ob du jetzt eine festplatte machst oder zwei. Und ich bin ein Freund der Einfachheit und so halte ich es für mehr praktikabel und besser das auf eine virtuelle Festplatte zu beschränken.

So wie ich das gesehen habe hast du ja einen Mechanismus drin der nur nach /usr/local/ mounted wenn kein USB-Stick angeschlossen ist. Vielleicht lässt sich das ja auch mit einer zweiten virtuellen Festplatte (sdb) machen. Also wenn sdb vorhanden dann mounte sdb anstelle von /usr/local.

Könnte man machen. Verkompliziert aber IMHO alles nur unnötig und ist auch unnötig weil eben es egal ist ob das auf einer oder zweit festplatten ist. Wie gesagt, du kommst so oder so nicht drumherum *.sbk backups und separate backups der diagrammdaten zu machen wenn die dir wichtig sind.