RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

MathiasZ
Beiträge: 2295
Registriert: 29.03.2015, 09:54
Wohnort: München
Hat sich bedankt: 91 Mal
Danksagung erhalten: 59 Mal

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von MathiasZ » 09.01.2021, 16:10

Ist es möglich, 2 Container mit je einer RaspberryMatic zu erstellen?
Ich spiele mit dem Gedanken, z. B. die LAN-Platine einzusetzen, auch wenn das jetzt noch Zukunftsmusik ist. Dann würde mir als Backup-System ein PI4/4 GB RAM reichen, zzgl ein PI4/4GB RAM für die IObroker-Installation. Diese sollen anlaufen, wenn der Server (Proxmox) ausfällt, damit ein reibungsloser Übergang gewährleistet ist.
Das lesen vom WebUI Handbuch hilft bei Problemen ungemein!
Zum Download des Handbuchs:
https://www.eq-3.de/Downloads/eq3/downl ... h_eQ-3.pdf
Skript-Dokumentation 1. Teil v2.2:
https://www.eq-3.com/Downloads/eq3/down ... g_V2.2.pdf

Benutzeravatar
jmaus
Beiträge: 6915
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 132 Mal
Danksagung erhalten: 601 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von jmaus » 09.01.2021, 16:42

MathiasZ hat geschrieben:
09.01.2021, 16:10
Ist es möglich, 2 Container mit je einer RaspberryMatic zu erstellen?
Na klar, du kannst theoretisch undendlich viele RaspberryMatic Docker Container auf deinem System nutzen. Die sollten halt nur nicht parallel auf das gleiche /etc/config zugreifen weil sonst ja quasi zwei ReGaHss auf die gleiche regadom Datei zugreifen. Aber wenn du jetzt z.B. ein NAS hast auf dem du das gesamte /usr/local zur Sicherheit ablegst dann kannst du als ausfallsicherheit quasi zwei oder mehrere Maschinen haben die dann als Fallbacksystem agieren und im Falle des Falles dann eben einen Fallback Docker-Container starten. Der Phantasie dann quasi fast keine Grenzen gesetzt. Das ist ja das schöne an diesen Docker Umgebungen.
RaspberryMatic 3.53.34.20201121 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

deimos
Beiträge: 4159
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 64 Mal
Danksagung erhalten: 425 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von deimos » 09.01.2021, 17:03

Hi,

du hast das leider nicht zu Ende gedacht, Jens. Zumindest wenn man die eq3_char_loop Kernel Module verwenden will (also immer, wenn man das Funkmodul in irgendeiner Weise nutzen will), dann kann man nur eine Instanz pro Kernel laufen lassen. Und da bei Docker der Kernel des Host genutzt wird (Stichwort Paravirtualisierung), wird man nur einen Docker Container aktiv nutzen können.

Viele Grüße
Alex

Benutzeravatar
jmaus
Beiträge: 6915
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 132 Mal
Danksagung erhalten: 601 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von jmaus » 09.01.2021, 17:19

deimos hat geschrieben:
09.01.2021, 17:03
du hast das leider nicht zu Ende gedacht, Jens. Zumindest wenn man die eq3_char_loop Kernel Module verwenden will (also immer, wenn man das Funkmodul in irgendeiner Weise nutzen will), dann kann man nur eine Instanz pro Kernel laufen lassen.
Sagen wir es mal so, ich hab versucht nicht zu sehr ins Detail zu gehen. Der Fragesteller wollte ja im Grunde nur wissen ob man mehr als einen Container erstellen kann, und da kann man sehr wohl die Frage mit ja beantworten. Nur kann ich eben jetzt nicht 20 parallel laufen lassen. 1x muss man dann eben 20 verschiedene /usr/local irgendwo vorhalten und natürlich hast du vollkommen recht geht das mit dem momentanen eq3_char_loop kernel modul nicht da es nur ein einziges /dev/eq3loop erstellt das nur ein Docker Container exklusiv nutzen kann. Wenn man aber nun eben z.B. einen Pi oder ein OVA gerade nutzt dann sollte es zumindest zu Fallback-Zwecken möglich sein schnell dann einen RaspberryMatic Docker Container zu starten der dann übernehmen kann - oder eben umgedreht.
deimos hat geschrieben:
09.01.2021, 17:03
Und da bei Docker der Kernel des Host genutzt wird (Stichwort Paravirtualisierung), wird man nur einen Docker Container aktiv nutzen können.
Wenn wir schon dabei sind. Spricht eigentlich deiner Expertise nach irgendwas dagegen wenn man das eq3_char_loop kernel modul dahingehend erweitert, das es möglich wird mehr als ein /dev/eq3loop zu erhalten das man dann von mehr als einer instanz nutzen könnte?
RaspberryMatic 3.53.34.20201121 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

deimos
Beiträge: 4159
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 64 Mal
Danksagung erhalten: 425 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von deimos » 09.01.2021, 18:48

Hi,
jmaus hat geschrieben:
09.01.2021, 17:19
Wenn wir schon dabei sind. Spricht eigentlich deiner Expertise nach irgendwas dagegen wenn man das eq3_char_loop kernel modul dahingehend erweitert, das es möglich wird mehr als ein /dev/eq3loop zu erhalten das man dann von mehr als einer instanz nutzen könnte?
Ja, das Kernel Module hat ja nicht nur /dev/eq3loop, sondern es hat ja bis zu drei Block Devices, für welche dann der multimacd die notwendigen Dev Nodes anlegt unter /dev/mmd_*. Und das passiert meines Wissens nach fix mit den Minors 1-3.

Viele Grüße
Alex

Benutzeravatar
jmaus
Beiträge: 6915
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 132 Mal
Danksagung erhalten: 601 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von jmaus » 09.01.2021, 23:17

deimos hat geschrieben:
09.01.2021, 18:48
jmaus hat geschrieben:
09.01.2021, 17:19
Wenn wir schon dabei sind. Spricht eigentlich deiner Expertise nach irgendwas dagegen wenn man das eq3_char_loop kernel modul dahingehend erweitert, das es möglich wird mehr als ein /dev/eq3loop zu erhalten das man dann von mehr als einer instanz nutzen könnte?
Ja, das Kernel Module hat ja nicht nur /dev/eq3loop, sondern es hat ja bis zu drei Block Devices, für welche dann der multimacd die notwendigen Dev Nodes anlegt unter /dev/mmd_*. Und das passiert meines Wissens nach fix mit den Minors 1-3.
Ah ok, danke für den Hinweis. Dann müsste ich das mal mit eQ3 bequatschen ob man das ggf. anpassen bzw. konfigurierbar machen könnte. In der multimacd.conf stehen ja zumindest schonmal konfig einträge für das master und die zwei slave devices (bidcos, hmip). Aber wenn er natürlich immer einen festen major/minor erwartet bzw. die so anlegt ist einem natürlich nicht geholfen. Sollte sich doch aber ändern/anpassbar machen. Sonst noch etwas was dir diesbzgl. auffällt?

EDIT:
Hab mir gerade nochmal die eq3_char_loop Quellen angeschaut. Abgesehen von dem fixen /dev/eq3loop device name sollte das doch eigentlich bereits alles gehen, oder? Das eq3loop device wird doch mit dem folgenden "device_create()" angelegt und da wird ja MAJOR+MINOR dynamisch vergeben: https://github.com/jens-maus/RaspberryM ... oop.c#L962. Und die beiden slave devices werden ja dann entsprechend in Zeile 779 mit dem gleichen MAJOR und jeweils hochgezähltem MINOR angelegt. Und multimacd sollte dann doch einfach die beiden slave devices via des kernel modules anlegen lassen. Dann sollte das doch eigentlich (bis auf dem umstand das es nur ein /dev/eq3loop gibt) funktionieren. Dann müsste man ja doch vielleicht einfach das eq3 kernel modul so umbauen das es in die Lage versetzt wird mehr als nur ein eq3loop device anzulegen. Oder übersehe ich da wieder etwas?
RaspberryMatic 3.53.34.20201121 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

deimos
Beiträge: 4159
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 64 Mal
Danksagung erhalten: 425 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von deimos » 10.01.2021, 00:24

Hi,
jmaus hat geschrieben:
09.01.2021, 23:17
Hab mir gerade nochmal die eq3_char_loop Quellen angeschaut. Abgesehen von dem fixen /dev/eq3loop device name sollte das doch eigentlich bereits alles gehen, oder? Das eq3loop device wird doch mit dem folgenden "device_create()" angelegt und da wird ja MAJOR+MINOR dynamisch vergeben: https://github.com/jens-maus/RaspberryM ... oop.c#L962. Und die beiden slave devices werden ja dann entsprechend in Zeile 779 mit dem gleichen MAJOR und jeweils hochgezähltem MINOR angelegt. Und multimacd sollte dann doch einfach die beiden slave devices via des kernel modules anlegen lassen. Dann sollte das doch eigentlich (bis auf dem umstand das es nur ein /dev/eq3loop gibt) funktionieren. Dann müsste man ja doch vielleicht einfach das eq3 kernel modul so umbauen das es in die Lage versetzt wird mehr als nur ein eq3loop device anzulegen. Oder übersehe ich da wieder etwas?
Ja, du übersiehst was: Das /dev/eq3_char_loop und die /dev/mmd_* gehören zusammen, alles was in /dev/eq3_char_loop reingeht wird an die /dev/mmd_* gesendet, alles, was von den /dev/mmd_* kommt wird an /dev/eq3_char_loop gesendet. Das ist jetzt stark vereinfach ausgedrückt, weil da noch Priorisierung vorgenommen wird, so dass einzelne /dev/mmd_* Datenaussendungen von anderen abbrechen können, wenn sie eine höhere Prio haben und da noch ein paar Sachen mehr drin sind.
Man müsste also noch eine Zuordnung haben, welches eq3_char_loop zu welchen mmd_* gehört. Zusätzlich muss man dann aufpassen, dass es keine doppelten Devices im Host gibt, d.h. man braucht /dev/eq3_char_loop1, /dev/mmd_bidcos1 und /dev/mmd_hmip2 für Container 1, /dev/eq3_char_loop2, /dev/mmd_bidcos2 und /dev/mmd_hmip2, usw. und der jeweilige Container muss wissen, mit welchem Suffix er arbeiten soll um dann alle Configs entsprechend umschreiben zu können.

Zusammen mit dem nicht wirklich trivialen Waitlocks und Barriers ist mir das zu viel Aufwand und deutlich zu heiß für den an sich extrem begrenzten Mehrwert, mit vollvirtualisierten VMs hat man ja eine Lösung am Start, welche das Problem elegant umgeht.

Viele Grüße
Alex

MathiasZ
Beiträge: 2295
Registriert: 29.03.2015, 09:54
Wohnort: München
Hat sich bedankt: 91 Mal
Danksagung erhalten: 59 Mal

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von MathiasZ » 10.01.2021, 07:17

bevor ich mich in etwas verrenne:
Ist es überhaupt möglich, dass eine RaspberryMatic die LAN-Platine HB-RF-ETH inkl. der RPI-RF-MOD einer
anderen Installation übernimmt, sobald es die Treiber gibt?
Das lesen vom WebUI Handbuch hilft bei Problemen ungemein!
Zum Download des Handbuchs:
https://www.eq-3.de/Downloads/eq3/downl ... h_eQ-3.pdf
Skript-Dokumentation 1. Teil v2.2:
https://www.eq-3.com/Downloads/eq3/down ... g_V2.2.pdf

Benutzeravatar
jmaus
Beiträge: 6915
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 132 Mal
Danksagung erhalten: 601 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von jmaus » 10.01.2021, 11:18

MathiasZ hat geschrieben:
10.01.2021, 07:17
Ist es überhaupt möglich, dass eine RaspberryMatic die LAN-Platine HB-RF-ETH inkl. der RPI-RF-MOD einer
anderen Installation übernimmt, sobald es die Treiber gibt?
Wenn es die Treiber des HB-RF-ETH in RaspberryMatic gibt, dann ja. Dann kann man das Funkmodul natürlich beliebig zwischen den Zentrale "herumreichen".
RaspberryMatic 3.53.34.20201121 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

deimos
Beiträge: 4159
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 64 Mal
Danksagung erhalten: 425 Mal
Kontaktdaten:

Re: RaspberryMatic – Neue Docker/Container-Alpha-Testversion

Beitrag von deimos » 10.01.2021, 11:46

Hi,
jmaus hat geschrieben:
10.01.2021, 11:18
MathiasZ hat geschrieben:
10.01.2021, 07:17
Ist es überhaupt möglich, dass eine RaspberryMatic die LAN-Platine HB-RF-ETH inkl. der RPI-RF-MOD einer
anderen Installation übernimmt, sobald es die Treiber gibt?
Wenn es die Treiber des HB-RF-ETH in RaspberryMatic gibt, dann ja. Dann kann man das Funkmodul natürlich beliebig zwischen den Zentrale "herumreichen".
Damit hier keine falschen Erwartungen geweckt werden: Herumreichen != (Gleichzeitig) Teilen.

Viele Grüße
Alex

Antworten

Zurück zu „RaspberryMatic“