Hallo,
ich wollte mal fragen wie die Erfahrungen sind mit fhem das auf einem NUC mit Proxmox installiert ist?
Wenn fhem dann auf einem NUC unter Proxmox läuft wie ist das dann mit dem HM Modul..ich habe fhem zur Zeit auf einem Pi installiert dazu das HM Modul aufgesteckt.....brauche ich dann die PiVCC separat?
Wie läuft das da dann?
Gibts dazu schon Erfahrungen?
Auch meine USB Sticks....den CUL422 und Zigbee Stick.....wenn man da Proxmox installiert hat...dann müssen die Sticks ja weitergeleitet werden-..richtig?
Oder ist es sinvoller fhem direkt auf die platte zu installieren?
Gruss
Moin,
FHEM äuft bei mir seit 4 Monaten stabil in einem Proxmox Container auf meinem NUC. Ich habe nur 1 Wire mit USB angeschlossen und durchgereicht. Das war etwas holperig, läuft aber letztendlich auch stabil. Ich würde es jederzeit wieder so machen.
Gruss
Enno
schön enno das es bei dir läuft ;)
da ich halt noch Homematic Produkte habe, ist zur zeit auf dem raspi ein HM Modul verbaut.....wie wäre dann der sachverhalt auf einem NUC???
Das HM Modul wäre ja dann überflüssig.....oder? Oder müsste ich mir dann zusätzlich HM VCC Zentrale zulegen?
Hi,
CUL wird per /dev/*** durchgereicht. Zigbee Stick soweit ich weiß auch. Ob du den PiVCC separat brauchst hängt von der Anforderung an.
Auf der einen Seite musst du dich entscheiden wie du FHEM in Proxmox installieren willst. Es gibt mehrere Möglichkeiten ...
Proxmox - LXC-Linux-Image z. B. Debian und Installation von FHEM nativ im LCX (Container)
Proxmox - VM-Linux-Image z. B. Debian und installation von Fhem nativ im VM (virual Machine)
Proxmox - LXC-Linux mit Docker Umgebung und Fhem als Docker-Container
Poxmox - VM-Linux mit Docker Umgebung und Fhem als Docker
Hierzu gibt es hier im Forum einige Posts.
Die Hardware reichst du dann über Proxmox an den LXC Container oder die VM durch. Wenn du Docker einsetzen willst reichst du hier ebenfalls die Hardware weiter.
Um mehre sagen zu können musst du sagen, wofür du die CUL + PiVCC einsetzen willst.
Am besten installierst du mal Proxmox auf dem NUC und legest jeweils eine VM und eine LXC an und spielst dich etwas damit. Docker ist optional, kannst dich mal informieren ob du damit überhaupt Vorteile hättest.
Ich persönlich habe Proxmox - LXC Debian - Docker und läuft stabil mit mehreren CUL. Das soll nur zeigen, dass es funktioniert.
ja irgendwas brauch ich ja wenn ich Homematic Produkte betreibe???
hast du einen fertigen pivcc? der läuft dann unabhängig vom Proxmox Setup und du müsstest weniger durchreichen, würde dann das nutzen statt cul für Homatic. Cul ist nicht so stabil wie eine VCC. Wieviele Protokolle willst du unterstützen, wofür hast du piVCC + CUL im Einsatz? Nur für Homematic?
sorry habe mich vertan...meine nicht piVCC sondern als Hardware die CCU2 von Homematic!!
ich habe den CUL433 für meine IT Steckdosen und das HM Modul aktuell für meine Homematic Geräte.....sowie einen Zigbee Stick
Zitat von: kadettilac89 am 21 März 2021, 12:57:00
Ich persönlich habe Proxmox - LXC Debian - Docker und läuft stabil mit mehreren CUL. Das soll nur zeigen, dass es funktioniert.
Das LXC braucht weniger Speicher als die eig. VM..das hab ich schon verstanden.
Wenn du schon eine externe Homematic Gateway hast würde ich das weiternutzen. Ansonsten die Hardware, CUL, wie jetzt auch.
Richtig, LXC braucht weniger Resourcen da es Kernel, Module ... vom Host mitnutzen kann. Hat auch Vorteile da auch Backup kleiner sind.
Docker musst du für dich entscheiden ob du das willst.
Ich würde an deiner Stelle einfach mal mit einem Testsystem anfangen und schaun was alles geht, oder eben nicht geht. Sehe bis jetzt für keines der 4 Setup-Möglichkeinten ein Problem. Am besten testest du gleich zu Beginn wie das Backup/Recovery geht. Dann kannst du wild rumspielen und dann verwerfen wenn was nciht mehr geht.
Zitat von: kadettilac89 am 21 März 2021, 13:19:44
Wenn du schon eine externe Homematic Gateway hast würde ich das weiternutzen. Ansonsten die Hardware, CUL, wie jetzt auch.
Neeeeein, lest doch bitte....ich habe zur zeit auf dem Pi ein HM-Modul und die Frage war wenn ich einen NUC mir hole dann brauche ich eine CCU oder?? Wie soll ich sonst meine HM Geräte sonst steuern..oder?
Zitat von: kadettilac89 am 21 März 2021, 13:19:44
Docker musst du für dich entscheiden ob du das willst.
nee Docker will ich nicht!
Ich könnte aber auch das Fhem system udn zb iobroker ganz normal wie auf dem Pi jetzt auf dem NUC installieren..nachteil...wenn was ist nmuss ich komplett image aufspielen wie jetzt auf dem Pi
Zitat von: Kusselin am 21 März 2021, 13:29:51
Neeeeein, lest doch bitte....ich habe zur zeit auf dem Pi ein HM-Modul und die Frage war wenn ich einen NUC mir hole dann brauche ich eine CCU oder?? Wie soll ich sonst meine HM Geräte sonst steuern..oder?
mach ich ja. Du hast einen Raspi mit HM-Modul was ein externes HM Gateway ist, den würde ich weiterhin als Gateway nutzen, zumindest zum Test. Dafür gibts piVCC als Image, den CUL und den Zigbee Stick schließt du an den Nuc an und schleifst durch. das piVCC musst du testen, habe selber noch nicht mit gearbeitet
Eine echte VCC2/3 oder andere HM-Gateway Hardware kannst dir dann immer noch kaufen wenn du den Rasperry für andere Zwecke nutzen willst und dein Setup läuft.
Damit du die HM Geräte nicht neu anlernen musst kannst du dir mal vccu ansehen. Damit kannst du das Gateway tauschen ohne neu anlernen zu müssen ... https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
ZitatNeeeeein, lest doch bitte....ich habe zur zeit auf dem Pi ein HM-Modul
Aus meiner Sicht hast Du unklar geschrieben: Verwendest Du derzeit CUL_HM oder HMCCU in FHEM?
Weil die Umstellung ist mMn erheblich ...
Wenn Du bisher mit CUL_HM arbeitest hast Du beim "virtuellen" Umzug zwei Optionen:
lass das Modul auf den Pi und mach aus dem quasi ein Langateway und binde es ser2net an.
Stecke das Modul an einen USB -serial Wandler und betreibe es an deinem NUC über USB.
Details gibt es im Wiki: http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Zitat von: kadettilac89 am 21 März 2021, 13:44:09
mach ich ja. Du hast einen Raspi mit HM-Modul was ein externes HM Gateway ist, den würde ich weiterhin als Gateway nutzen, zumindest zum Test. Dafür gibts piVCC als Image, den CUL und den Zigbee Stick schließt du an den Nuc an und schleifst durch. das piVCC musst du testen, habe selber noch nicht mit gearbeitet
Eine echte VCC2/3 oder andere HM-Gateway Hardware kannst dir dann immer noch kaufen wenn du den Rasperry für andere Zwecke nutzen willst und dein Setup läuft.
Damit du die HM Geräte nicht neu anlernen musst kannst du dir mal vccu ansehen. Damit kannst du das Gateway tauschen ohne neu anlernen zu müssen ... https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Super, jetzt klasse erklärt. Danke Dir
VCCU nutze ich schon aufm raspi
Zitat von: Otto123 am 21 März 2021, 13:52:40
Aus meiner Sicht hast Du unklar geschrieben: Verwendest Du derzeit CUL_HM oder HMCCU in FHEM?
Weil die Umstellung ist mMn erheblich ...
Wenn Du bisher mit CUL_HM arbeitest hast Du beim "virtuellen" Umzug zwei Optionen:
lass das Modul auf den Pi und mach aus dem quasi ein Langateway und binde es ser2net an.
Stecke das Modul an einen USB -serial Wandler und betreibe es an deinem NUC über USB.
Details gibt es im Wiki: http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Hi Otto, ich nutze CUL_HM
Danke Dir
...ich bins nochmal...
habe eben zufällig eine CCU2 bekommen..
Es gibt ja schon eine CCU3, aber mal ehrlich.....eine 2er würde doch für meine Zwecke schon langen oder?
Gruss
ccu2 ist mit netzwerk und hat kein wlan. wenn du nur das "alte" homematic nutzt reicht das. dann kannst den raspberry mit dem modul weiterlaufen lassen bis du umschaltest.
war homematic mit dem modul auf dem raspberry stabil, oder gab es damit probleme? möchte mir zum testen mal einen piVccu baun.
für die ccu2 bauch ich kein WLan...da ich diese an meinen switch einstecke...das meinst du doch oder?
Ja das HM Modul lüft absolut stabil...hat mir damals der Otto hier empfohlen.
ich will nur vermeiden das wir aneinander vorbei reden:
ZitatJa das HM Modul lüft absolut stabil.
kann ich bestätigen. Aber
Zitatmöchte mir zum testen mal einen piVccu baun.
offenbar hatte keiner eine davon - die hier geantwortet haben?!?
Kusselin und ich betreiben das Modul auf einem Pi und haben eine CUL_HM VCCU - und keine CCUx in irgendeiner Ausprägung.
(Außer meinem historischen "Problem" einer CCU1 wo bisher zu faul zum wegwerfen war und die der Grund für eine gewisse Skepsis bei mir war, was diesen Bereich der Homematic Geschichte betrifft :) )
passt schon. es gibt gerüchte dass durch wlan des raspberry das aufgesteckte hm modul gestört wird da beides auf selbem bus liegt oder selbe frequenz nutzt. hab mir die genauen details nicht weiter angesehen. wenn ihr beide das modul auf dem raspberry stabil auf laufen habt dann werde ich mal testen.... irgendwann .... sollte es probleme geben ist es sehr wahrscheinlich eine softwaresache.
Hallo, ich wollt emich zu einem Zwischenstand melden...
konnte heute erfolgreich proxmox installieren...weiter konnte ich zwei LXC Container erstellen mit iobroker und fhem...iobroker umzug hat sofort funktioniert (einspielen backup) und bei Fhem hat es auch soweit geklappt mit folgenden schritten: (voher die Sicherungsdatei in den ordner Backup kopiert den ich erstellt habe)
invoke-rc.d fhem stop
sudo tar -xvzf /opt/fhem/backup/Meine FHEM datei.tar.gz -C /opt/fhem/
invoke-rc.d fhem start
danach habe ich den Fhem container restartet......
Wenn ich jetzt die IP des Containers wie vorher eingebe :8083 komme ich nicht mehr auf das Fhem webinterface
Versuche ich per FTP zB Filezilla mit der IP zuzugreifen habe ich , komme ich drauf...
Woran kann das liegen??
Gruss
das ist der Status:
sudo systemctl status fhem
* fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: >
Active: active (running) since Thu 2021-03-25 21:03:55 UTC; 603ms ago
Process: 945 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=>
Main PID: 947 (perl)
Tasks: 1 (limit: 4915)
Memory: 35.2M
CGroup: /system.slice/fhem.service
`-947 /usr/bin/perl fhem.pl fhem.cfg
Mar 25 21:03:55 fhem-live systemd[1]: Starting FHEM Home Automation...
Mar 25 21:03:55 fhem-live systemd[1]: Started FHEM Home Automation.
Sieht doch gut aus
und
ls -la /opt/fhem/
total 808
drwxr-xr-x 12 fhem dialout 4096 Mar 25 20:35 .
drwxr-xr-x 3 root root 4096 Mar 25 20:03 ..
-rw-r--r-- 1 fhem dialout 359805 Mar 24 17:45 CHANGED
drwxr-xr-x 6 fhem dialout 36864 Mar 15 19:32 FHEM
-rw-r--r-- 1 fhem dialout 18092 Dec 24 14:04 GPL_V2.txt
-rw-r--r-- 1 fhem dialout 43040 Mar 15 19:32 MAINTAINER.txt
-rw-r--r-- 1 fhem dialout 935 Jul 9 2020 README_DEMO.txt
-rw-r--r-- 1 fhem dialout 311 Jul 9 2020 alexa-fhem.cfg
drwxr-xr-x 2 fhem dialout 4096 Mar 25 20:30 backup
drwxr-xr-x 3 fhem dialout 4096 Jul 9 2020 cache
-rw-r--r-- 1 fhem dialout 41434 Dec 24 14:04 configDB.pm
drwxr-xr-x 48 fhem dialout 4096 Jul 9 2020 contrib
drwxr-xr-x 3 fhem dialout 4096 Jul 9 2020 demolog
drwxr-xr-x 4 fhem dialout 4096 Jul 9 2020 docs
-rw-r--r-- 1 fhem dialout 66749 Mar 25 18:23 fhem.cfg
-rw-r--r-- 1 fhem dialout 25544 Jul 9 2020 fhem.cfg.demo
-rwxr-xr-x 1 fhem dialout 167290 Mar 15 19:32 fhem.pl
drwxr-xr-x 3 fhem dialout 4096 Jul 9 2020 lib
drwxr-xr-x 2 fhem dialout 4096 Mar 24 23:00 log
drwxr-xr-x 4 fhem dialout 4096 Jul 9 2020 restoreDir
drwxr-xr-x 10 fhem dialout 4096 Jul 9 2020 www
dem ersten export folgend läuft Fhem zumindest. Wird der Port auch benutzt ...
netstat -nlp | grep 8083
Was steht im FHEM-Log (/opt/fhem/log ...). Wird hier was angemeckert? ... Port already opened ... oder so?
Schau mal den Wiki-Beitrag zur Fehlersuche ... https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Wenn Fhem an sich keine Fehler hat. Hast du in Proxmox oder im Container die Firewall aktiv? Die könnte auch blocken. Würde aber erstmal Fhem selbst analysieren.
Hi, danke für deinen post.
Bin aufArbeit kann erst heute nachmittag schauen..
Beim anlegen des containers war der haken drin und ausgegraut bei ,,Firewall aktiv" das hab ich gesehen...
Im wiki hab ich schon gelesen..daraus auch die konsolen posts oben im 1. post.
Was mir noch aufgefallen ist....
Nach der Installation des nackten fhems konnte ich mit dem folgendem Befehl fhem sauber stoppen:
sudo systemctl stop fhem
Dann das einspielen
Danach wollte ich mit befehl
sudo systemctl start fhem
Fhem wieder starten was aber nicht ging..Kommando nicht gefunden..
Fhem log muss ich schauen...
Kann das ev. Mit telnet zusammenhängen?
Gruss
Zitat von: Kusselin am 26 März 2021, 09:01:50
Danach wollte ich mit befehl
sudo systemctl start fhem
Fhem wieder starten was aber nicht ging..Kommando nicht gefunden..
Fhem log muss ich schauen...
Kann das ev. Mit telnet zusammenhängen?
Wenn du die Meldung "Befehl nicht gefunden" siehst hast du dich vertippt. systemctl ist immer da ... wenn du die Meldung wirklich bekommst, ist mehr im Argen.
wenn fhem als servcie nicht mehr da wäre, würdest du irgen was mit "failed to start fhem ... service not found" ... als Meldung bekommen. Schau am Abend nochmal nach den Log und der genauen Fehlermeldung.
Telnet könnte es natürlich sein, dann würdest du im Servcie fhem einen Bootloop haben. Dein Fhem lief zum Zeitpunkt der Statusabfrage 603 ms. Das siest du aber normalerweise auch wieder im Fhem-Log.
Das log liegt ja in /opt/fhem/log
Da bin ich gestern schon mal drauf und hab mal geschaut...
Da stand dann halt drin das der Port 8083 opend ist und das halt verschiedene module gestsrtet werden... da war nix grosses mit eigentlichen systemfehlern von fhem zu sehen..
Ich schau aber heute abend nochmal und melde mich..Danke und gruss
Er wird das Commando sudo meinen denn das ist per default in einem Debian LX Container nicht dabei.
Was für einen LX Container hast Du denn genommen Kusselin?
Zitat von: CoolTux am 26 März 2021, 10:25:15
Er wird das Commando sudo meinen denn das ist per default in einem Debian LX Container nicht dabei.
Was für einen LX Container hast Du denn genommen Kusselin?
Zitat von: Kusselin am 26 März 2021, 09:01:50
sudo systemctl stop fhem
Dann das einspielen
Danach wollte ich mit befehl
sudo systemctl start fhem
Fhem wieder starten was aber nicht ging..Kommando nicht gefunden..
Gruss
Stoppen ging, bezeifle dass es am Sudo liegt. Das verschwindet nicht ohne Zutun.
Zitat von: CoolTux am 26 März 2021, 10:25:15
Er wird das Commando sudo meinen denn das ist per default in einem Debian LX Container nicht dabei.
Was für einen LX Container hast Du denn genommen Kusselin?
Danke Jungs für euer Engagement!!
Ui du fragst mich was :-) ..ha ich bin in Proxmox oben rechts auf ,,Erstelle lxc"...wies halt in den Anleitungen im netz steht..sorry wieder mal was neues..
Bist dir sicher?? Wieso konnte ich dann den Stop vorher erzwingen mit dem befehl aus dem wiki?
Kadettilac war schneller.....
aktuell ist es nur Raten. Poste mal das Log von Fhem wenn du wieder zu Hause bist.
Container - dann kannst ja nachsehen, was in der besagten Anleitung drin steht. ... Debian OK, ... Version, ... privileged, ... oder du postest mal die Anleitung der du gefolgt bist.
Du kannst ja mehrere Container erstellen, mach mal einen und nutze die test-Config von Fhem (fhem.demo) ob damit Fhem läuft.
Beim testen und rumspielen kann man auch wunderbar mit Snapshots arbeiten. Das ist ja das tolle an Virtualisierung.
Ohne jetzt Dir auf die Füße treten zu wollen würde ich behaupten das der STOP Befehl auch nicht geklappt hat und Du es nur überlesen hast. Oder Du hast einen bestimmten Container genommen der das sudo drin hat. Der Standard Debian Container hat es jedenfalls nicht
(10:53 marko@p-tuxnetwiki ~) > sudo
-bash: sudo: Kommando nicht gefunden.
Siehe hier. Erstellt aus einem Debian Container.
Leuts danke vorab mal..shit ich kann nicht do jetzt auch das schreiben auf dem iphone schwierig..ich melde mich heute abend
Doch der stop befehl hat funktioniert,da ich dann im Browser probiert habe und fhem nicht da war..bissl was bleibt schon hängen gell :-)
Und..snapshot habe ich auch gemacht..nackiges fhem installiert unddann snap gemacht..dann mein gesichertes fhem installiert(hier kam mir das kopieren sehr schnell vor) danach kein fhem mehr
Ich zurück per erstelltem snap was auch ging..aber dann nach reload der page kein nackiges fhem da :-(
Ich melde mich heute abend..danke vorab an Euch
Zitat von: kadettilac89 am 26 März 2021, 10:49:49
aktuell ist es nur Raten. Poste mal das Log von Fhem wenn du wieder zu Hause bist.
Container - dann kannst ja nachsehen, was in der besagten Anleitung drin steht. ... Debian OK, ... Version, ... privileged, ... oder du postest mal die Anleitung der du gefolgt bist.
Du kannst ja mehrere Container erstellen, mach mal einen und nutze die test-Config von Fhem (fhem.demo) ob damit Fhem läuft.
Hallo, ich bin nach dieser Anleitung vorgegangen:
https://www.meintechblog.de/2014/05/intel-nuc-als-smart-home-server-fhem-on-steroids/
wie gesagt wenn ich fhem nackt installiere lt wiki https://debian.fhem.de/ manuelle installation....klappt alles und wenn ich dann mit der Anleitung mein backup einspiele ( schaut mal das rödelt die konsole runter....passt das denn auch?)
Das kommt beim erstellen des Containers:
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
Logical volume "vm-220-disk-0" created.
WARNING: Sum of all thin volume sizes (121.00 GiB) exceeds the size of thin pool pve/data and the size of whole volume group (<118.74 GiB).
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: 4096/262144 done
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 9ee3de3e-f1de-436e-b240-3c3334dbc4b7
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: 0/8 done
Writing inode tables: 0/8 done
Creating journal (8192 blocks): done
Multiple mount protection is enabled with update interval 5 seconds.
Writing superblocks and filesystem accounting information: 0/8 done
extracting archive '/var/lib/vz/template/cache/ubuntu-20.10-standard_20.10-1_amd64.tar.gz'
Total bytes read: 655308800 (625MiB, 92MiB/s)
Detected container architecture: amd64
Creating SSH host key 'ssh_host_ecdsa_key' - this may take some time ...
done: SHA2565DWM root@fhem-test
Creating SSH host key 'ssh_host_ed25519_key' - this may take some time ...
done: StRIg root@fhem-test
Creating SSH host key 'ssh_host_dsa_key' - this may take some time ...
done: SHA25pDvwdzOiitC3nKo root@fhem-test
Creating SSH host key 'ssh_host_rsa_key' - this may take some time ...
done: SAIsqCk0MfcI root@fhem-test
TASK OKO.K. zurück zu fhem...ich glaub ich habe den fehler gefunden....bei der icherung also dem Backup da sichert fhem nicht alles...habe gerade die fhem.cfg von meiner sichernden datei angeschaut und der gesicherten....in der gesicherten ist gar nix drin :-) grins....
Das backup löse ich in der Fhem kommandozeile mit "backup" aus...ist schon richtig oder....
kommt denn dann auch eine Nachricht das es fertig ist?? das kam bei mir nicht..erst als ich ins log sah stand da "done"
Gruss
ZitatHallo, ich bin nach dieser Anleitung vorgegangen:
Diese Anleitung ist 7 Jahre alt :'(
ZitatDas backup löse ich in der Fhem kommandozeile mit "backup" aus...ist schon richtig oder....
kommt denn dann auch eine Nachricht das es fertig ist?? das kam bei mir nicht..erst als ich ins log sah stand da "done"
Es kommt eine Nachricht beim Start:
ZitatStarted the backup in the background, watch the log for details
In der Anleitung fehlt jeglicher Bezug zu Proxmox oder habe ich da was überlesen?
Ja das stimmt da fehlt der Bezug......zu proxmox....
Container ist installiert und fhem ist auch installiert...jetzt bin ich nochmal nach Ottos Anleitung vorgegangen....
http://heinz-otto.blogspot.com/2017/01/umzug-von-fhem.html
Wie gesagt fhem läuft nackt installiert...also ich komme aufs Webinterface. Im Log kann ich leider nicht finden
hier der letzte Eintrag:
1.03.26 19:58:13 1: Including fhem.cfg
2021.03.26 19:58:13 3: WEB: port 8083 opened
2021.03.26 19:58:13 2: eventTypes: loaded 4413 lines from ./log/eventTypes.txt
2021.03.26 19:58:13 3: Opening CUL433 device /dev/serial/by-id/usb-busware.de_CUL433-if00
2021.03.26 19:58:13 1: CUL433: Can't open /dev/serial/by-id/usb-busware.de_CUL433-if00: No such
2021.03.26 19:58:13 3: Opening Denon_AVR device 192.168.200.24:23
2021.03.26 19:58:16 1: Denon_AVR: Can't connect to 192.168.200.24:23: Connection timed out
2021.03.26 19:58:17 1: define Dream_7080 ENIGMA2 192.168.200.5: Please install Perl XML::Simple to use module ENIGMA2
2021.03.26 19:58:17 3: Opening CallMonitor device 192.168.200.1:1012
2021.03.26 19:58:17 2: FRITZBOX FritzBox_3490_Kueche: Define.254 Modul functionality limited because of missing perl modules: Net::Telnet Soap::Lite
2021.03.26 19:58:17 2: FRITZBOX FritzBox_3490_OG: Define.254 Modul functionality limited because of missing perl modules: Net::Telnet Soap::Lite
2021.03.26 19:58:17 2: FRITZBOX FritzBox_7590: Define.254 Modul functionality limited because of missing perl modules: Net::Telnet Soap::Lite
2021.03.26 19:58:17 2: FRITZBOX Fritzbox_3490_UG: Define.254 Modul functionality limited because of missing perl modules: Net::Telnet Soap::Lite
2021.03.26 19:58:17 3: NotdienstApotheke: interval is 0, no periodic updates will done.
2021.03.26 19:58:17 3: NotdienstApotheke: Defined with URL https://www.aponet.de/service/notdienstapotheke-finden/suchergebnis/0/69493.html featurelevel 6
2021.03.26 19:58:17 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2021.03.26 19:58:17 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2021.03.26 19:58:17 1: MQTT2: Can't open server port at 1883: Cannot assign requested address. Exiting.
2021.03.26 19:58:17 1: Including fhem.cfg
2021.03.26 19:58:18 3: WEB: port 8083 opened
2021.03.26 19:58:18 2: eventTypes: loaded 4413 lines from ./log/eventTypes.txt
2021.03.26 19:58:18 3: Opening CUL433 device /dev/serial/by-id/usb-busware.de_CUL433-if00
Otto schreibt hier:
sudo tar -xvzf /home/pi/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/
ich habe auf dem NUC aber kein /home/pi und habe es dann auf /opt/fhem/backup/.......geändert..
Diesmal hat das kopieren auch länger gedauert und die Fhem.cfg die kopiert wurde und die anderen ordner auch....
Leider das gleiche Problem ..ich komme nicht auf das Webinterface mehr danach.....:-(
ich glaube ich werde nachdem ich fhem suaber und frisch installiert habe alles neu aufsetzen.....und nehme den Rat von Mad-Max an....
Prozess:
ps aux | grep [f]hem
fhem 1121 0.0 0.9 43560 40188 ? S 20:05 0:00 /usr/bin/perl fhem.pl fhem.cfg
Telnet:
telnet localhost 7072
Trying ::1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
BINGO......telnet nicht mehr erriechbar.....kann man das kitten?
Laufen tut ja fhem:
fhem-live:~# service fhem status
* fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: >
Active: active (running) since Fri 2021-03-26 20:17:07 UTC; 908ms ago
Process: 1592 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status>
Main PID: 1594 (perl)
Tasks: 1 (limit: 4915)
Memory: 35.1M
CGroup: /system.slice/fhem.service
`-1594 /usr/bin/perl fhem.pl fhem.cfg
Mar 26 20:17:07 fhem-live systemd[1]: Starting FHEM Home Automation...
Mar 26 20:17:07 fhem-live systemd[1]: Started FHEM Home Automation.
Grüße und Danke
Bei meinem Artikel ging es um einen Umzug von einem Pi auf einen anderen - das ist quasi die gleiche Hardware! Das ist doch nicht mit Deiner Situation vergleichbar!
Aber Du liest schon die ganzen Fehler - über fehlenden Module, fehlende USB Schnittstellen usw.?
Du hast einen Zoo von Hardware und Modulen, das kannst Du nicht einfach mal so mit backup und restore umziehen.
Mach es Stück für Stück und zwar mit Tests und schreibe auf was Du tust, denn eine Doku fehlt Dir offenbar auch.
tar -xvzf /opt/fhem/backup/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/
Meinst Du das Du es so gemacht hast?
Das ist dann aber totaler Unsinn.
Ich meine es nicht, ja ich habe es so gemacht....
Mach jetzt neu wie Otto schon gesagt hat..
Zitat von: CoolTux am 26 März 2021, 23:17:32
tar -xvzf /opt/fhem/backup/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/
Meinst Du das Du es so gemacht hast?
Das ist dann aber totaler Unsinn.
Zitatich habe auf dem NUC aber kein /home/pi ...
Naja, nach wie vor wissen viele User nicht, wie sie eine Datei "zwischen den Welten" von a nach b kopieren sollen und benutzen dafür in Ihrer Verzweiflung unnötige Tools die sie nicht beherrschen. Die Sache wird durch Virtualisierung nicht einfacher :)
Ist ein ssh Weg vorhanden braucht man nur einen simplen Befehl
scp Dateiname user@host: Die Datei landet im Homedir und kann dann von dort weiterverarbeitet werden.
Das geht auch zwischen Windows und Linux - in beide Richtungen. :)
ich habe jetzt alles frisch gemacht....MadMax hat mir das eigentlich empfohlen....und mir tuts gut und ich bleib in Übung..
Konnte jetzt alles wieder einrichten...bis auf HM Geräte.....und es läuft auch alles!! Ja es läudt alles.....glaubt man nicht
Hier werde ich auch den Rat von MadMax befolgen und alles sauber entpairen und ich habe mich entschlossen mit der CCU2 zu arbeiten....denke hier arbeite ich nicht oft jetzt halt zum pairen und einrichten....
Was ich jetzt noch wissen müsste ist der Pfad des CUL433......
der ist ja unter unter dem PI in fhem wie folgt zu finden:
defmod CUL433 CUL /dev/serial/by-id/usb-busware.de_CUL433-if00@38400 1234
Im LXC Container unter Proxmox sieht das ja anders aus...ich habe herausgefunden das der angesteckte CUL433 im NUC "ttyACM1" heisst...
Habe dann mal beim Anlegen das probiert:
defmod CUL433 CUL /dev/ttyACM1@38400 1234 funzt es nicht......
Könnt ihr mir ev. hier noch den richtigen Pfad nennen...
Danke
Ich mache ja wenig (naja ich hab mal rumgespielt) mit Docker etc. (eben auch weil es immer eine weitere "Indirektion" ist: d.h. wo liegt das Problem. An der SW selbst oder an der Umgebung, dem Docker oder an der echten HW/OS ;) Das aber nur meine persönliche Meinung dazu)...
Egal: so wie ich es kenne hast du auf der "echten Maschine" (das ist deine Ausgabe!?) Devices und wenn du die in einem Container (oder wie das heißt) nutzen willst, dann müssen die dort erst mal "rein".
D.h. du musst deiner "Docker-Verwaltungs-SW" mitteilen, dass dieses Device eben in diesem Docker verwendet werden soll.
EDIT: es geht sogar (zumindest bei den Docker-Dingern wo ich mal rumgespielt habe), dass das Device "außen" anders heißt als "innen". D.h. du könntest es evtl. "innen" sogar (wieder) so nennen, wie es vorher auf dem PI geheißen hat und bräuchtest auch das define des CUL nicht geändert haben ;) / was kommt denn wenn du auf dem System ("außen", also da wo du jetzt /dev/ttyACMI... "gefunden" hast) ein ls -la /dev/serial/by-id eingibst?
Oder eben in der yaml eintragen (oder wie das heißt) bzw. musst du halt sehen wie das bei deinem Docker/Proxmox geht...
Also ich würde mich an deiner Stelle erst einmal mit Proxmox/Docker beschäftigt haben, bevor ich mein Produktiv-System dahin umziehe...
...aber: jeder wie er will ;)
Gruß, Joachim
Joachim....in iobroker konnte ich den Zigbee Stick auch einrichten.....
in der besagten .conf. des LXC ist ja alles eingetragen, es geht jetzt lediglich um das Anlegen in fhem generell..
ls -la /dev/serial/by-id
total 0
drwxr-xr-x 2 root root 80 Mar 27 10:46 .
drwxr-xr-x 4 root root 80 Mar 27 10:44 ..
lrwxrwxrwx 1 root root 13 Mar 27 10:46 usb-busware.de_CUL433-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Mar 27 10:44 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0018E32C4C-if00 -> ../../ttyACM0
soweit ich baer gelesen habe funzt das nicht so, habs auch mal ausprobiert..CUL bleibt auf disconnected:
/dev/serial/by-id/usb-busware.de_CUL433-if00@38400 1234
Wie hast du denn den Zigbee-Stick im IO-Broker "angelegt" oder sucht sich der den selber?
Aber wie geschrieben bin ich eher ein "Bare-Metal-Mensch" ;)
Also ich mache schon auch einiges mit VMs aber das ist ja wieder anders...
Aber CoolTux liest ja mit und hat (glaube ich auch) Proxmox...
Gruß, Joachim
Dein Versuch war aus meiner Sicht richtig, kenne mich aber in dem Proxmox nicht aus.
Alternativ nimmst Du was Du zeigst:
/dev/serial/by-id/usb-busware.de_CUL433-if00
Wenn das nicht geht, lässt der Proxmox den Stick nicht zu - oder es fehlt was anderes...
Oder was Du zeigst ist nicht inside Proxmox sondern aufm Host
Zitat von: Otto123 am 27 März 2021, 12:35:42
Dein Versuch war aus meiner Sicht richtig, kenne mich aber in dem Proxmox nicht aus.
Wollte ich auch schon schreiben ;)
Aber es war ja in dem Post kein "Schreibselfehler" und er hat ja geschrieben, dass es nicht klappt...
...daher hab ich es gelassen ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 27 März 2021, 12:35:32
Wie hast du denn den Zigbee-Stick im IO-Broker "angelegt" oder sucht sich der den selber?
Aber wie geschrieben bin ich eher ein "Bare-Metal-Mensch" ;)
Also ich mache schon auch einiges mit VMs aber das ist ja wieder anders...
Aber CoolTux liest ja mit und hat (glaube ich auch) Proxmox...
Gruß, Joachim
Im iobroker Zigbeeadapter musste ich dann nur noch in den Einstellungen /ttyACM0 auswählen speichern udn der rote punkt wurde grün..
ich bin wie schon gesagt nach dieser Anleitung vorgegangen...:
https://coldcorner.de/2018/07/12/proxmox-usb-passthrough-fuer-lxc-container-z-wave-uzb1/und genauso hab ichs im Fhem container gemacht...jetzt gehts halt nur noch drum wie ich den in lxc container von fhem einbinde????
wir schweifen aber ab......ich wollt nur wissen wie ich den CUL im Fhem Container einbinden muss....
Zitat von: Otto123 am 27 März 2021, 12:35:42
Dein Versuch war aus meiner Sicht richtig, kenne mich aber in dem Proxmox nicht aus.
Alternativ nimmst Du was Du zeigst:
/dev/serial/by-id/usb-busware.de_CUL433-if00
Wenn das nicht geht, lässt der Proxmox den Stick nicht zu - oder es fehlt was anderes...
Oder was Du zeigst ist nicht inside Proxmox sondern aufm Host
jaja..das /dev/serial/by-id/usb-busware.de_CUL433-if00 ist im root von Proxmox also ausserhalb......innerhalb kann ich das /serial by id gar nicht ausführen....
Waaas ich war auf dem richtigen Weg....mal was neues... 8)
Hätt ja auch mal klappen können gleich auf anhieb...aber das werde ich auch noch schaffen..der Zigbee stick ist ja auch durchgeschliffen...dann kanns doch mit dem CUL net mehr soweit sein!
Dann ist es aber Unsinn was Du zeigst!
Wieso kannst Du das nicht ausführen? Steht doch so in Deiner Anleitung?
Was zeigt Dir das in deiner FHEM Kommandozeile?
{qx(ls -lha /dev/ttyA*)}
Oder wie sieht Dein lxc Eintrag aus?
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
Wie gesagt ich habe keine Ahnung ich lese nur Deinen Link!
Gut es ist das (bei dir bekannte ;) ) lesen/schreiben Problem ;)
Es ist zwar ZWave und nicht ZigBee aber egal... ;)
Was hast du denn dann in die fhem-Container-Config eingetragen?
Poste doch mal die Zeile.
Also die vergleichbare Zeile wie für Zwave bei ioBroker...
EDIT: weil das ist das "durchreichen" von dem ich gesprochen habe. D.h. die verlinkte Anleitung zeigt wie du einen bestimmten USB-Stick des Hosts (deines Proxmox) eben "in" einen Container (ioBroker, fhem, ...) bekommst, damit er DORT auch auftaucht und (wie bei ioBroker) verwendet werden kann...
EDIT: drum schrieb ich ja. Ich würde mich erst mal mit der Umgebung beschäftigen (Proxmox, Container etc.) und "rumspielen" bevor ich da "in echt" umziehe...
Gruß, Joachim
das kommt auf root ebene proxmox:
ls -l /dev/ttyA*
crw-rw-rw- 1 root dialout 166, 0 Mar 27 12:52 /dev/ttyACM0
crw-rw---- 1 root dialout 166, 1 Mar 27 10:46 /dev/ttyACM1
das steht in der 210.conf
arch: amd64
cores: 1
hostname: fhem-live
memory: 2048
net0: name=eth0,bridge=vmbr0,hwaddr=AE:EB:84:8A:60:DA,ip=dhcp,ip6=dhcp,type=veth
ostype: ubuntu
parent: fhem270320211
rootfs: local-lvm:vm-210-disk-0,size=8G
swap: 1000
unprivileged: 1
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/005 dev/bus/usb/001/005 none bind,optional,cr$
lxc.cgroup.devices.allow: c 166:* rwm
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
Zitat von: Otto123 am 27 März 2021, 12:59:34
Dann ist es aber Unsinn was Du zeigst!
Wieso kannst Du das nicht ausführen? Steht doch so in Deiner Anleitung?
Was zeigt Dir das in deiner FHEM Kommandozeile?
{qx(ls -lha /dev/ttyA*)}
Oder wie sieht Dein lxc Eintrag aus?
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
Wie gesagt ich habe keine Ahnung ich lese nur Deinen Link!
Otto...hier:
crw-rw---- 1 nobody nogroup 166, 1 Mar 27 09:46 /dev/ttyACM1wo gebe ich diesen ein?
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=filein der Fhem kommandozeile kommt das:
Unknown command lxc.mount.entry:, try help.
o.k. dann hoffe ich das sich cooltux mal meldet wenn dieser auch proxmox und fhem im Container hat...läuft ja alles bis auf den Stick..und HM
Müssen die IT devices halt noch waretn
Also erst einmal (wie in der verlinkten Anleitung) welcher USB-Stick ist nun der CUL und welcher der ZWave-Stick (der ja im ioBroker schon verwendet wird)?
Also auf dem HOST, deinem Proxmox (bare-metal)?
Und die Zeile kommt eben in die jeweilige Konfigurations-Datei des entsprechenden Containers.
Also fhem oder ioBroker etc.
Für den ioBroker hast du das doch schon gemacht, oder!!?
So ist es doch in deinem verlinkten Beitrag zu lesen...
EDIT: deinen selbst verlinkten Beitrag hast du gelesen? Verstanden? Und auch (für ZWave und ioBroker) durchgeführt? Weil wenn ja: wo ist das Problem dasselbe eben für den CUL-USB-Stick und den fhem-Container zu machen?
Gruß, Joachim
Zitat von: Kusselin am 27 März 2021, 13:08:00
Otto...hier:
crw-rw---- 1 nobody nogroup 166, 1 Mar 27 09:46 /dev/ttyACM1
wo gebe ich diesen ein?
1. Ich meine: falsche Rechte nobody nogroup
2. es ist nicht mein Vorschlag! Es ist lediglich aus deiner Anleitung https://coldcorner.de/2018/07/12/proxmox-usb-passthrough-fuer-lxc-container-z-wave-uzb1/
Da steht drin was Du tun musst - ich habe keine Ahnung!
Zitat von: Otto123 am 27 März 2021, 13:11:51
1. Ich meine: falsche Rechte nobody nogroup
2. es ist nicht mein Vorschlag! Es ist lediglich aus deiner Anleitung https://coldcorner.de/2018/07/12/proxmox-usb-passthrough-fuer-lxc-container-z-wave-uzb1/
Da steht drin was Du tun musst - ich habe keine Ahnung!
Da kann ich mich (bzw. habe ich ja schon) leider nur "anschließen"...
Gruß, Joachim
Zitat von: MadMax-FHEM am 27 März 2021, 13:11:40
Also erst einmal (wie in der verlinkten Anleitung) welcher USB-Stick ist nun der CUL und welcher der ZWave-Stick (der ja im ioBroker schon verwendet wird)?
siehst doch auf dem Bild oben....von iobroker Einstellungen ;)
Zitat von: MadMax-FHEM am 27 März 2021, 13:11:40
Für den ioBroker hast du das doch schon gemacht, oder!!?
So ist es doch in deinem verlinkten Beitrag zu lesen...
Gruß, Joachim
verar....du mich jetzt?
Jaa, in iobroker habe ich es gemacht und der Zigbeesstick wird auch erkannt (siehe Bilder oben)
und genauso wollte/habe ich es in fhem dann auch einbinden wollen man so:
defmod CUL433 CUL /dev/ttyACM1@38400 1234 aber das geht auch nicht...ev. mit dem @ dann oder ?? ich weiss es nicht man dehalb frage ich doch hier!!!!!
wenn du es doch auch nicht weisst dann lass uns / mich doch warten bis einer hier ist der ev das weiss..so sparen wir uns unnoötige posts und ich muss mich nicht weiter......
ja ev. hängt es noch mit den rechten zusammen aber...
Zitat von: Kusselin am 27 März 2021, 13:27:42
siehst doch auf dem Bild oben....von iobroker Einstellungen ;)
verar....du mich jetzt?
Jaa, in iobroker habe ich es gemacht und der Zigbeesstick wird auch erkannt (siehe Bilder oben)
und genauso wollte/habe ich es in fhem dann auch einbinden wollen man so:
defmod CUL433 CUL /dev/ttyACM1@38400 1234 aber das geht auch nicht...ev. mit dem @ dann oder ?? ich weiss es nicht man dehalb frage ich doch hier!!!!!
Danke für die nette Art.
Der Screenshot ist ja im ioBroker oder in der Proyxmox Oberfläche oder sonstwo.
Die Frage war aber bzgl. deiner verlinkten Anleitung und dem Eintrag in die Container-Konfig-Datei!!!
Das muss ja wohl VORHER passiert sein, sonst würdest du im ioBroker ja (vermutlich) den USB-Stick nicht haben.
Und da war ganz schlicht die Frage: was hast du in die fhem-Container-Config eingetragen...
Aber ich weiß ja aus früheren Schlachten: lesen usw. ist nicht deine Stärke... ;)
EDIT: weil so verstehe ich Docker bzw. Container usw. Es gibt die echte HW mit dem "eigentlichen OS" da steckt der Stick ja erst mal dran und wird von dem tatsächlichen OS irgendwie erkannt und benannt /dev/ttyIRGENDWAS. Dann musst du im Container eintragen, dass eben /dev/ttyZWave ("tatsächliches OS") in den Container soll und dort z.B. /dev/ttyContainerZwave heissen soll (der Name kann nat. "innen" wie "außen" auch gleich sein / muss baer nicht). Dann kannst du den IM Container eben unter /dev/ttyContainerZWave "ansprechen". Und genau DANACH habe ich gefragt. Also wie hast du es beim Container ioBroker eingetragen und wie beim Container fhem. So wie eben in deinem SELBSTVERLINKTEN Betirag zu lesen ist. Weil mehr als ich hier beschrieben habe ist dort auch nicht beschrieben, außer eben mit Screen-Ausgaben eines echten Beispiel-Systems...
Viel Erfolg noch, Joachim
müssen die Rechte auf fhem - dialout verweisen?
Bingo ;D
Internals:
CFGFN
CMDS ABCEeFGhiKkLlMmRTtUuVWXxY
CUL433_MSGCNT 1
CUL433_TIME 2021-03-27 12:40:27
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/ttyACM1@38400 1234
DeviceName /dev/ttyACM1@38400
FD 25
FHTID 1234
FUUID 605f0f0d-f33f-b652-9e00-4f4bc6ffcbc0114c
NAME CUL433
NR 115
PARTIAL
RAWMSG omAAAAA8F7
STATE Initialized
TYPE CUL
VERSION V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUL433 (F-Band: 433MHz)
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2021-03-27 12:39:47 cmds A B C E e F G h i K k L l M m R T t U u V W X x Y
2021-03-27 12:40:27 state Initialized
Attributes:
alias CUL433
Zitat von: Kusselin am 27 März 2021, 13:28:44
wenn du es doch auch nicht weisst dann lass uns / mich doch warten bis einer hier ist der ev das weiss..so sparen wir uns unnoötige posts und ich muss mich nicht weiter......
ja ev. hängt es noch mit den rechten zusammen aber...
Wenn du immer wieder was schreibst/Fragen stellst wirst du verm. auch immer wieder was hören...
Da ist dann wenig (auch von deiner Seite) mit "warten wir doch" ;)
Ob die rechte fhem:dialout auch IN einem Container sein müssen oder ob die nobody in einem Container auch passen können: keine Ahnung.
Es sollte halt so sein, dass fhem das nutzen kann.
Aber was steht denn im Log?
Wenn fhem es bzgl. Rechten nicht nutzen kann, dann steht ja eine Fehlermeldung im Log...
Überhaupt nach/beim define des CUL schon mal da rein geschaut? ;)
Wie sieht denn der USB-Stick IM ioBroker Container aus?
(also wenn du IM ioBroker-Container auf DESSEN "OS-Ebene" schaust / wie der fhem-Befehl von Otto / wobei ich jetzt nicht weiß wie man das IN einem Proxmox-Container macht oder mit welchen ioBroker-Bordmitteln man das machen kann vergleichbar dem Aufruf von Otto)
Gruß, Joachim
Zitat von: Kusselin am 27 März 2021, 13:41:22
Bingo ;D
Bingo ging jetzt einfach oder Bingo du hast was gemacht und dann ging es?
Also nur interesehalber...
Gruß, Joachim
Zitat von: Kusselin am 27 März 2021, 13:37:06
müssen die Rechte auf fhem - dialout verweisen?
typischerweise sieht das so aus:
crw-rw---- 1 root dialout 166, 0 Mär 18 15:08 /dev/ttyACM0 Aber ich verstehe nicht was die ganzen Zahlen in Deiner Anleitung bedeuten. Aber die ganze Diskussion hat Dich ja nur genervt. Das nächste mal steig ich nicht wieder mit ein.
Kusselin, ich habe jetzt nicht alles verstanden. Du willst den CUL im LXC haben? Oder woran scheiterst du?
Poste mal die config (/etc/pve/nodes/pve/lxc/<container_ID>.cfg)
Dort musst du das Mapping der Mountpoints eintragen. Sobald das gemacht ist, solltest du den Ordner /dev/serial/by-id sehen.
Ich bin mir nicht mehr ganz sicher welche cgroup-ID du für die Devices brauchst. Welche Proxmox Version hast du, die aktuellste?
lxc.mount.entry: /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM2 dev/ttyACM2 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.cgroup.devices.allow: c 166:* rwm
Edit: hast du einen privilegierten Container oder unpriviligiert`? Siehst du in den Optionen "Unprivileged Container" Yes/No. Was hast du bei den Features aktiv, alles false?
Zitat von: kadettilac89 am 27 März 2021, 14:15:22
Kusselin, ich habe jetzt nicht alles verstanden. Du willst den CUL im LXC haben? Oder woran scheiterst du?
Poste mal die config (/etc/pve/nodes/pve/lxc/<container_ID>.cfg)
Dort musst du das Mapping der Mountpoints eintragen. Sobald das gemacht ist, solltest du den Ordner /dev/serial/by-id sehen.
Ich bin mir nicht mehr ganz sicher welche cgroup-ID du für die Devices brauchst. Welche Proxmox Version hast du, die aktuellste?
lxc.mount.entry: /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM2 dev/ttyACM2 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.cgroup.devices.allow: c 166:* rwm
Edit: hast du einen privilegierten Container oder unpriviligiert`? Siehst du in den Optionen "Unprivileged Container" Yes/No. Was hast du bei den Features aktiv, alles false?
Genau das wollte ich auch schon (mehrfach) wissen... ;)
Gruß, Joachim
Hallo,
um meinen signalduino an den LXC durchzureichen, habe ich folgende Anleitung benutzt:
https://forum.proxmox.com/threads/usb-device-an-lxc-durchreichen.81725/
Gruß
Jürgen K.
Zitat von: Otto123 am 27 März 2021, 14:09:27
Aber die ganze Diskussion hat Dich ja nur genervt. Das nächste mal steig ich nicht wieder mit ein.
Dito...
Maximal mitlesend... ;)
Gruß, Joachim
Echt krass..1. habe ich dich überhaupt nirgends angegriffen Otto..ich bin froh das du mir hilft aber ich merke mit einem Unterton das ihr immer draufkloppen müsst!!
Ihr helft zwar immer schön und gebt antworten aber nie die die man eigentlich haben will...
ich weis das mein Problem das lesen ist und das ich vieles nicht so verstehen will wie ihr udn ich immer fünfmal fragen muss...aber
ich kann jetzt auch mal ein bisschen stolz sein auf mich ich habe iobroker und fhem jetzt komplett umziehen können..nein HM fehlt noch..das schaff ich aber auch....
Nix für ungut...
Kussel
Zitat von: MadMax-FHEM am 27 März 2021, 13:45:05
Bingo ging jetzt einfach oder Bingo du hast was gemacht und dann ging es?
Also nur interesehalber...
Gruß, Joachim
ich hatte das hier vergessen:
chmod o+rw /dev/ttyACM1danach ging es
Zitat von: Kusselin am 27 März 2021, 14:43:24
ich hatte das hier vergessen:
chmod o+rw /dev/ttyACM1
danach ging es
Hatte ich vermutet...
Bleibt nur zu hoffen/wünschen, dass es nach einen Neustart des Containers bzw. des NUC "erhalten bleibt"...
(weil ich könnte/würde mir vorstellen [wollen] dass das auch ohne geht [gehen müsste])
Viel Spaß noch, Joachim
P.S.: dein (hast du ja selbst erkannt) anders lesen usw. "ermüdet" halt die Helferseite... ;)
P.P.S.: evtl. mal die Sache(n) (nächstes Mal) ruhiger angehen (hudeln macht's net besser ;) ) bzw. gut/besser "vorbereitet" (z.B. meine Anmerkung bzgl. Proxmox etc. ;) )
Das bleibt nicht erhalten nach einem neustart.
Hier mal eine Anleitung wie es bei mir super funktionierte
https://www.cooltux.net/doku.php?id=it-wiki:proxmox:usb_passthrough
Das meiste sollte bekannt vorkommen.
Zitat von: CoolTux am 27 März 2021, 14:49:51
Das bleibt nicht erhalten nach einem neustart.
Hier mal eine Anleitung wie es bei mir super funktionierte
https://www.cooltux.net/doku.php?id=it-wiki:proxmox:usb_passthrough
Das meiste sollte bekannt vorkommen.
Ich hol das mal wieder hoch.
Bei mir läuft FHEM seit neustem auch als LXC unter Proxmox. Ich war erstaunt, wie reibungslos der Umzug geklappt hat - bis auf die USB-Geschichte.
Ich bin genau nach der cooltux-Anleitung vorgegangen (id und vendor natürlich entsprechend angepasst).
Das Log mein aber, es gäbe Berechtigungsprobleme:
2022.05.13 08:19:22 3: Opening CUL_0 device /dev/SIGNALduino
2022.05.13 08:19:22 1: PERL WARNING: can't open file: /dev/SIGNALduino: Permission denied at FHEM/DevIo.pm line 611.
2022.05.13 08:19:22 1: CUL_0: Can't open /dev/SIGNALduino: Permission denied
Gruppe ist dialout und als Owner funtkioniert weder root noch fhem. Rechte sind 0666.
Hat jemand noch eine Idee?
Zitat von: Snake1980 am 13 Mai 2022, 08:22:38
Ich hol das mal wieder hoch.
Bei mir läuft FHEM seit neustem auch als LXC unter Proxmox. Ich war erstaunt, wie reibungslos der Umzug geklappt hat - bis auf die USB-Geschichte.
Ich bin genau nach der cooltux-Anleitung vorgegangen (id und vendor natürlich entsprechend angepasst).
Das Log mein aber, es gäbe Berechtigungsprobleme:
2022.05.13 08:19:22 3: Opening CUL_0 device /dev/SIGNALduino
2022.05.13 08:19:22 1: PERL WARNING: can't open file: /dev/SIGNALduino: Permission denied at FHEM/DevIo.pm line 611.
2022.05.13 08:19:22 1: CUL_0: Can't open /dev/SIGNALduino: Permission denied
Gruppe ist dialout und als Owner funtkioniert weder root noch fhem. Rechte sind 0666.
Hat jemand noch eine Idee?
Jetzt sehe ich gerade, dass nach jedem Neustart, der Besitzer wieder root ist und die Rechte 0000
Hm.... Blödes Linux-Halbwissen.....
Ich kapere den Thread mal für ein verwandtes Thema:
Ich möchte in einem LXC unter Proxmox eine fhem-Instanz einzig für SMAEM laufen lassen. Dafür ist folgende Umgebung gegeben:
Der Proxmox-Host (7.2) ist an einem gemanagtem Switch an einem Port angeschlossen, an dem alle VLANs anliegen. Der Host hat genau eine Netzwerkschnittstelle, konfiguriert mit vmbr0 mit einer IP-Adresse aus dem nativ anliegenden, ungetaggten VLAN. Die vmbr0 ist mit Haken bei VLAN-aware versehen.
Ich habe einen unpriviliged Container erstellt mit der Netzwerkkonfiguration VLAN-Tag 7 und einer passenden IP.
Grundsätzlich sehen sich alle Maschinen gemäß der geltenden FW-Regeln auf TCP/UDP-Basis und können pingen.
Das Problem: ich bekomme auf dem Host Multicast aus dem VLAN 7, in dem LXC kommt es aber nicht an. Ich habe schon das halbe Internet durchgelesen 8) und verschiedene Dinge probiert, jedoch keinen Durchbruch erzielt.
Hat jemand erfolgreich in einem LXC auf einem Proxmox-Node Multicast aus einem getaggten VLAN am Laufen?
Edit: Das Problem liegt nicht an Proxmox. Das Problem liegt am Unifi-Netzwerk. Multicast in einem getaggten VLAN wird nicht über mehrere Switche verteilt - warum auch immer, Bug oder Konfiguration?
Zitat von: CoolTux am 27 März 2021, 14:49:51Das bleibt nicht erhalten nach einem neustart.
Hier mal eine Anleitung wie es bei mir super funktionierte
https://www.cooltux.net/doku.php?id=it-wiki:proxmox:usb_passthrough
Das meiste sollte bekannt vorkommen.
Hallo CoolTux,
ich hab eine VM für Fhem in Proxmox definiert.
Die entsprechende conf habe ich identifizert:
/etc/pve/qemu-server/100.conf
enthält u.a.
usb0: host=1a86:7523
Wie geht es weiter? Deine Anleitung hast du für einen Container erstellt.
Die beiden Zahlen habe ich gefunden (in meinem Fall 189, 5), aber wie müssten diese Zeilen für eine VM aussehen?
lxc.cgroup.devices.allow: c 189:257 rwm
lxc.mount.entry: /dev/SIGNALduino dev/SIGNALduino none bind,optional,create=fileViele Grüße
Gisbert