x86-CCU 3.47.10
Moderator: Co-Administratoren
- deimos
- Beiträge: 5403
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 958 Mal
- Kontaktdaten:
Re: x86-CCU 3.47.10
Hi,
Viele Grüße
Alex
Wie löst du das Problem, dass man unter LXC keine Kernel Module nachladen kann?
Viele Grüße
Alex
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: x86-CCU 3.47.10
Kernel Module muessen am Host eingebunden werden, da kommt man nicht drum rum.
Das eigentliche Problem war, dass die virtuellen devices dynamisch erst zur Laufzeit des multimac erstellt werden.
Die koennen also nicht beim Start der CCU durchgreicht werden weil da noch keine existieren.
Im Moment mache in den Ansatz, dass ich die virtuellen Geraete in einem Unterordner via multimac config erstellen lasse. z.b. /dev/hmip/
Auch wenn der Ordner am Anfang leer ist, kann Proxmox den kompletten leeren Ordner durchreichen.
Wenn nun multimac im lxc-container die devices erstellt (devices werden am Host erstellt) auch wenn multimac im Container lauft, werden die devices durch den Trick mit dem /dev/hmip/ Ordner dynamisch weitergereicht.
Das eigentliche Problem war, dass die virtuellen devices dynamisch erst zur Laufzeit des multimac erstellt werden.
Die koennen also nicht beim Start der CCU durchgreicht werden weil da noch keine existieren.
Im Moment mache in den Ansatz, dass ich die virtuellen Geraete in einem Unterordner via multimac config erstellen lasse. z.b. /dev/hmip/
Auch wenn der Ordner am Anfang leer ist, kann Proxmox den kompletten leeren Ordner durchreichen.
Wenn nun multimac im lxc-container die devices erstellt (devices werden am Host erstellt) auch wenn multimac im Container lauft, werden die devices durch den Trick mit dem /dev/hmip/ Ordner dynamisch weitergereicht.
- deimos
- Beiträge: 5403
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 958 Mal
- Kontaktdaten:
Re: x86-CCU 3.47.10
Hi,
ok, das funktioniert dann aber nur für das eq3_char_loop. Die dynamische Ansteuerung des rpi_rf_mod_led und des dummy_rx8130 kannst du erst machen, nachdem du weißt, welches Funkmodul aufgesteckt ist. Und ohne diese funktioniert die Ansteuerung der LED vom RPI-RF-MOD nicht.
Und natürlich muss man auch noch dafür sorgen, dass die Kernel Module im Host installiert sind.
Viele Grüße
Alex
ok, das funktioniert dann aber nur für das eq3_char_loop. Die dynamische Ansteuerung des rpi_rf_mod_led und des dummy_rx8130 kannst du erst machen, nachdem du weißt, welches Funkmodul aufgesteckt ist. Und ohne diese funktioniert die Ansteuerung der LED vom RPI-RF-MOD nicht.
Und natürlich muss man auch noch dafür sorgen, dass die Kernel Module im Host installiert sind.
Viele Grüße
Alex
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: x86-CCU 3.47.10
Mit der Led-Steuerung habe ich mich noch nicht auseinandergesetzt, das kommt im Anschluss.
Der LXC Kram wird sowieso nicht ohne Handanlegen am Host passieren koennen. Daher, wenn ein User bereit ist sich darauf einzulassen, setze ich vorraus dass er weiss welches Modul er verwendet. Von Modul/Service autodetect-Funktionen bin ich kein Fan.
Ich versuche nur den LXC-Container/Nativ-VM bereits auf alle Eventualitaeten vorzubereiten, dass der einfach alles schluckt was man ihm vorwirft.
Den Host-Teil werde ich dann mit Anleitungen hier im Forum erschlagen.
Der LXC Kram wird sowieso nicht ohne Handanlegen am Host passieren koennen. Daher, wenn ein User bereit ist sich darauf einzulassen, setze ich vorraus dass er weiss welches Modul er verwendet. Von Modul/Service autodetect-Funktionen bin ich kein Fan.
Ich versuche nur den LXC-Container/Nativ-VM bereits auf alle Eventualitaeten vorzubereiten, dass der einfach alles schluckt was man ihm vorwirft.
Den Host-Teil werde ich dann mit Anleitungen hier im Forum erschlagen.
-
- Beiträge: 2497
- Registriert: 13.02.2012, 20:23
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 307 Mal
- Danksagung erhalten: 121 Mal
Re: x86-CCU 3.47.10
nach dem update ist keins meiner gerate mehr erreichbar, alle erscheinen in Servicemeldungen als nicht erreichbar. nach einem Neustart sieht es ein wenig besser aus aber es sind noch 17 gerate nicht erreichbbar.
habe es jetzt zwei mal durch gespielt immer das gleiche
laufende Version: 3.45.7 angebotene version 3.45.10.X.X.X
habe es jetzt zwei mal durch gespielt immer das gleiche
laufende Version: 3.45.7 angebotene version 3.45.10.X.X.X
-
- Beiträge: 2497
- Registriert: 13.02.2012, 20:23
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 307 Mal
- Danksagung erhalten: 121 Mal
Re: x86-CCU 3.47.10
Ja waren nur bitcos, ja das usb gateway war dran.
Therotisch könnte ich noch mal testen; update ccu runterfahren, gateway komplett vom esx ab und dann wieder alles hochfahren
Therotisch könnte ich noch mal testen; update ccu runterfahren, gateway komplett vom esx ab und dann wieder alles hochfahren
-
- Beiträge: 518
- Registriert: 20.01.2011, 14:39
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 4 Mal
Re: x86-CCU 3.47.10
Ja bitte testen.Therotisch könnte ich noch mal testen; update ccu runterfahren, gateway komplett vom esx ab und dann wieder alles hochfahren
Zur Sicherheit noch die Frage, du hattest keine weitere CCU am Start. Zweite VM oder so die kollidieren koennte.
Hast den HM-CFG-USB?
Der ist eigentlich am unproblematischsten von der Konfiguration.
Oder den HmIP-RFUSB?
Der hat mit bidcos nix zu tun, selbst wenn der Probleme haette, muesste bidcos einwandfrei laufen.
Hast du HMIP generaell aktiviert? Wenn nein, faellt mir da noch was ein was ich testen kann.