Hallo zusammen,
seit einiger Zeit habe ich das Phänomen, dass nach einem shutdown restart FHEM nicht mehr automatisch neu gestartet wird. Ich behelfe mir dann immer damit, dass ich mich per SSH auf meinen RPI einlogge und ihn komplett neu starte. Das ist aber schon etwas nervig und ich frage mich, warum der Restart aus FHEM heraus nicht wie gewohnt funktioniert?
Hat jemand hierzu eine Idee?
hast du mal ins Log geschaut, ob da irgendwas verdächtiges drin steht?
Hier mal ein Auszug aus dem Log. Da scheint in der Tat etwas nicht ganz in Ordnung zu sein. Bin mir nicht sicher, warum Port 8083 zunächst geöffnet werden konnte, es dann aber nach einem Neustart des RPi funktioniert hat.
2017.05.02 20:41:28 1: update finished, "shutdown restart" is needed to activate the changes.
2017.05.02 20:41:28 1:
2017.05.02 20:41:29 1: fheminfo server response: ==> ok
2017.05.02 20:41:29 1: in UPDATE
2017.05.02 20:41:29 1: in UPDATE
2017.05.02 20:41:29 1: in UPDATE
2017.05.02 20:41:40 1: in SHUTDOWN
2017.05.02 20:41:40 1: in SHUTDOWN
2017.05.02 20:41:40 1: in SHUTDOWN
2017.05.02 20:41:40 0: Server shutdown
2017.05.02 20:41:43 1: Including fhem.cfg
2017.05.02 20:41:43 1: Can't locate Socket6.pm in @INC (you may need to install the Socket6 module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM) at (eval 12) line 1.
BEGIN failed--compilation aborted at (eval 12) line 1.
2017.05.02 20:41:43 1: WEB: Can't load INET6, falling back to IPV4
2017.05.02 20:41:43 1: WEB: Can't open server port at 8083: Address already in use. Exiting.
2017.05.02 20:46:11 1: Including fhem.cfg
2017.05.02 20:46:12 1: Can't locate Socket6.pm in @INC (you may need to install the Socket6 module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM) at (eval 12) line 1.
BEGIN failed--compilation aborted at (eval 12) line 1.
2017.05.02 20:46:12 1: WEB: Can't load INET6, falling back to IPV4
2017.05.02 20:46:12 3: WEB: port 8083 opened
2017.05.02 20:46:12 3: telnetPort: port 7072 opened
2017.05.02 20:46:12 3: WEBphone: port 8084 opened
2017.05.02 20:46:12 3: WEBtablet: port 8085 opened
2017.05.02 20:46:12 2: eventTypes: loaded 2815 events from ./log/eventTypes.txt
da haben wir doch schonmal Ansätze für die Forumssuche... das IP6-Problem: https://forum.fhem.de/index.php/topic,32388.msg247917.html#msg247917
Ich glaube allerdings, da steht noch was anderes schief... Läuft auf deinem Raspi noch irgendwas anderes, was sich 8083 schnappen könnte?
Was passiert wenn du den Raspi nicht neu startest, sondern nur den fhem service?
Hi,
ich würde mal vermuten, dass das Hauptproblem der shutdown ist. Kann es sein, dass FHEM nicht wirklich beendet wird?
Probier mal einfach ein shutdown und prüfe danach ob FHEM noch läuft, z.B. mit ps.
Gruß,
Thorsten
Zitat von: KernSani am 02 Mai 2017, 22:29:43
da haben wir doch schonmal Ansätze für die Forumssuche... das IP6-Problem: https://forum.fhem.de/index.php/topic,32388.msg247917.html#msg247917
Ich glaube allerdings, da steht noch was anderes schief... Läuft auf deinem Raspi noch irgendwas anderes, was sich 8083 schnappen könnte?
Was passiert wenn du den Raspi nicht neu startest, sondern nur den fhem service?
Ich hatte mal mit IPv6 herumgespielt, bin aber auf IPv4 zurückgekehrt. Insofern würde ich gerne alle IPv6 Leichen in FHEM / RPi beseitigen. Was ist hierbei zu tun?
Ich hatte auch mal SmartVisu installiert, bin damit aber nicht so richtig warm geworden. Habe die entsprechenden Komponenten innerhalb FHEMs jetzt mal wieder deinstalliert. Und jetzt scheint es zu funktionieren:
2017.05.02 23:03:03 0: Server shutdown
2017.05.02 23:03:05 1: Including fhem.cfg
2017.05.02 23:03:05 1: Can't locate Socket6.pm in @INC (you may need to install the Socket6 module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM) at (eval 12) line 1.
BEGIN failed--compilation aborted at (eval 12) line 1.
2017.05.02 23:03:05 1: WEB: Can't load INET6, falling back to IPV4
2017.05.02 23:03:05 3: WEB: port 8083 openedSchön wäre es jetzt noch, wenn mir jemand sagen könnte, wie ich die nicht mehr benötigten Pakete für SmartVisu wieder von meinem RPi deinstallieren kann. Hier bin ich noch nicht so fit. Ich hatte es damals anhand dieser Anleitung installiert: http://www.meintechblog.de/2015/06/smartvisu-mit-fhem-die-perfekte-visualisierung-teil-1-basics/ (http://www.meintechblog.de/2015/06/smartvisu-mit-fhem-die-perfekte-visualisierung-teil-1-basics/)
Zitat von: Thorsten Pferdekaemper am 02 Mai 2017, 22:36:56
Hi,
ich würde mal vermuten, dass das Hauptproblem der shutdown ist. Kann es sein, dass FHEM nicht wirklich beendet wird?
Probier mal einfach ein shutdown und prüfe danach ob FHEM noch läuft, z.B. mit ps.
Gruß,
Thorsten
Der Shutdown funktioniert jetzt einwandfrei. Ein sudo /etc/init.d/fhem status liefert mir "fhem is not running" :-)
Ich beobachte dasselbe.
Fhem auf rpi2 und Jessie. Wenn fhem paar Tage läuft geht shutdown restart ins Leere. Nach nur kurzer fhem uptime geht der shutdown restart.
Hab mich nie genauer damit befasst. Nach einem Update starte ich immer das gesamte System neu per sudo reboot.
Gesendet von meinem S3_32 mit Tapatalk
Zitat von: KraxelHuber am 02 Mai 2017, 23:06:56
Ich hatte es damals anhand dieser Anleitung installiert: http://www.meintechblog.de/2015/06/smartvisu-mit-fhem-die-perfekte-visualisierung-teil-1-basics/ (http://www.meintechblog.de/2015/06/smartvisu-mit-fhem-die-perfekte-visualisierung-teil-1-basics/)
Dann wird es jetzt wohl Zeit, das Popcorn auszupacken ;-)
Aber wenn's jetzt läuft is' ja gut...
Bei mir besteht im Ergebnis das gleiche Problem - zu dem das Topic hier eröffnet wurde.
FHEM läuft auf Ubuntu. Restart von FHEM klappt nicht. Ubuntu reboot via konsole behebt das Problem.
Die letzte Änderung am System war die Installation von Alexa Connector. Nach etwas Fummelei läuft "diese".
Zitat
: update finished, "shutdown restart" is needed to activate the changes.
2020.07.18 12:50:07 1:
2020.07.18 12:50:07 1: Please consider using the global attribute sendStatistics
2020.07.18 12:50:44 1: Server shutdown delayed due to alexa for max 10 sec
2020.07.18 12:50:46 3: alexa: read: end of file reached while sysread
2020.07.18 12:50:46 3: alexa: stopped
2020.07.18 12:50:47 0: Server shutdown
2020.07.18 12:50:47 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2020.07.18 12:50:51 1: Including fhem.cfg
2020.07.18 12:50:51 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.
2020.07.18 12:54:10 1: Including fhem.cfg
2020.07.18 12:54:10 3: telnetPort: port 7072 opened
2020.07.18 12:54:11 3: WEB: port 8083 opened
2020.07.18 12:54:11 3: WEBphone: port 8084 opened
2020.07.18 12:54:11 3: WEBtablet: port 8085 opened
2020.07.18 12:54:11 2: eventTypes: loaded 1263 events from ./log/eventTypes.txt
Hallo Sammy51,
Du kanst im Terminal FHEM mit sudo systemctl start fhem.service neu starten.
Ich habe das gleiche Problem. Habe mich aber noch nicht um eine Lösung gekümmert, da es nur ein Testsystem bei mir ist.
Viele Grüße
Jürgen
Danke für den Tipp - so wesentlich praktischer als "sudo reboot" über die ssh konsole ist das leider auch nicht. Oder?
Siehe hier: https://forum.fhem.de/index.php/topic,82602.msg747512.html#msg747512
+ hier https://forum.fhem.de/index.php/topic,82602.msg748421.html#msg748421
Da fhem als Daemon läuft, reagiert ja shutdown restart nicht wie beim manuellen Start in der Console
Zitat von: Sammy51 am 18 Juli 2020, 23:12:48
Danke für den Tipp - so wesentlich praktischer als "sudo reboot" über die ssh konsole ist das leider auch nicht. Oder?
Naja... um Fhem neu zu starten, braucht man nicht den ganzen Rechner neu zu booten!
Zitat von: juemuc am 18 Juli 2020, 13:48:27
Du kanst im Terminal FHEM mit sudo systemctl start fhem.service neu starten.
Das klappt bei mir scheinbar nicht.
Nochmal: wenn dein Fhem als Dienst läuft, reicht nw ein "shutdown" in Fhem. Wenn Du die standard Installation hast, sollte der Dienst automatisch nach stop wieder starten.
Ansonsten musst Du natürlich zuerst stoppen, dann neu starten. Entweder
sudo systemctl stop fhem.service
sudo systemctl start fhem.service
oder
sudo service fhem stop
sudo service fhem start
Nur ein start wenn es schon läuft bringt natürlich nichts.
Vorgeschichte ist ein "shutdown restart" Versuch aus FHEM. Das führt zu einem shutdown ohne restart.
Danach probierte ich dann den start wie oben beschrieben.
FHEM läuft bei mir auf Ubuntu 16.04 LTS
Die Frage wäre, wie Deine SystemD eEnstellung zu fhem aussieht.
Normalerweise zu finden unter: /etc/systemd/system/fhem.service
cat /etc/systemd/system/fhem.service
cat: /etc/systemd/system/fhem.service: Datei oder Verzeichnis nicht gefunden
Auf welches OS hast du aufgesetzt?
cat /etc/os-release
Wie hast du fhem installiert?
Weil wenn Buster (sollte!! Und wenn schon: Lite! Ohne Desktop!) und die Installation nach: debian.fhem.de -> "the easy way", dann sollte da was kommen...
Bzw. zeig doch mal:
ls -la /etc/systemd/system
und
ls -la /etc/init.d
Gruß, Joachim
Gerne danke :)
PRETTY_NAME="Ubuntu 16.04.7 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
insgesamt 60
drwxr-xr-x 15 root root 4096 Jun 5 22:19 .
drwxr-xr-x 5 root root 4096 Okt 30 08:55 ..
drwxr-xr-x 2 root root 4096 Mär 19 2018 bluetooth.target.wants
drwxr-xr-x 2 root root 4096 Jun 5 19:41 cloud-final.service.wants
lrwxrwxrwx 1 root root 37 Mär 19 2018 dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service
lrwxrwxrwx 1 root root 36 Jun 5 22:19 dbus-org.freedesktop.thermald.service -> /lib/systemd/system/thermald.service
drwxr-xr-x 2 root root 4096 Mär 19 2018 default.target.wants
drwxr-xr-x 2 root root 4096 Mär 19 2018 final.target.wants
drwxr-xr-x 2 root root 4096 Mär 19 2018 getty.target.wants
drwxr-xr-x 2 root root 4096 Mär 19 2018 graphical.target.wants
lrwxrwxrwx 1 root root 38 Mär 19 2018 iscsi.service -> /lib/systemd/system/open-iscsi.service
drwxr-xr-x 2 root root 4096 Jul 16 06:30 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Mär 19 2018 network-online.target.wants
drwxr-xr-x 2 root root 4096 Jun 5 22:19 open-vm-tools.service.requires
drwxr-xr-x 2 root root 4096 Mär 19 2018 paths.target.wants
drwxr-xr-x 2 root root 4096 Mär 19 2018 sockets.target.wants
lrwxrwxrwx 1 root root 31 Mär 19 2018 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x 2 root root 4096 Jul 20 2019 sysinit.target.wants
lrwxrwxrwx 1 root root 35 Mär 19 2018 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Jun 5 19:37 timers.target.wants
insgesamt 356
drwxr-xr-x 2 root root 4096 Okt 30 08:55 .
drwxr-xr-x 104 root root 4096 Okt 30 08:55 ..
-rwxr-xr-x 1 root root 2243 Feb 9 2016 acpid
-rwxr-xr-x 1 root root 8087 Apr 5 2016 apache2
-rwxr-xr-x 1 root root 2210 Apr 5 2016 apache-htcacheclean
-rwxr-xr-x 1 root root 6223 Mär 3 2017 apparmor
-rwxr-xr-x 1 root root 2964 Sep 25 17:37 apport
-rwxr-xr-x 1 root root 1071 Dez 6 2015 atd
-rwxr-xr-x 1 root root 2968 Mär 1 2016 bluetooth
-rwxr-xr-x 1 root root 1275 Jan 19 2016 bootmisc.sh
-rwxr-xr-x 1 root root 3807 Jan 19 2016 checkfs.sh
-rwxr-xr-x 1 root root 1098 Jan 19 2016 checkroot-bootclean.sh
-rwxr-xr-x 1 root root 9353 Jan 19 2016 checkroot.sh
-rwxr-xr-x 1 root root 1343 Apr 4 2016 console-setup
-rwxr-xr-x 1 root root 3049 Apr 5 2016 cron
-rwxr-xr-x 1 root root 937 Mär 28 2015 cryptdisks
-rwxr-xr-x 1 root root 896 Mär 28 2015 cryptdisks-early
-rwxr-xr-x 1 root root 2813 Dez 2 2015 dbus
-rw-r--r-- 1 root root 1194 Okt 30 08:55 .depend.boot
-rw-r--r-- 1 root root 1348 Okt 30 08:55 .depend.start
-rw-r--r-- 1 root root 1434 Okt 30 08:55 .depend.stop
-rwxr-xr-x 1 root root 1442 Mär 19 2018 fhem
-rwxr-xr-x 1 root root 1105 Jan 24 2018 grub-common
-rwxr-xr-x 1 root root 1336 Jan 19 2016 halt
-rwxr-xr-x 1 root root 1423 Jan 19 2016 hostname.sh
-rwxr-xr-x 1 root root 3809 Mär 12 2016 hwclock.sh
-rwxr-xr-x 1 root root 2372 Apr 11 2016 irqbalance
-rwxr-xr-x 1 root root 1503 Mär 29 2016 iscsid
-rwxr-xr-x 1 root root 1804 Apr 4 2016 keyboard-setup.dpkg-bak
-rwxr-xr-x 1 root root 1300 Jan 19 2016 killprocs
-rwxr-xr-x 1 root root 2087 Dez 21 2015 kmod
-rwxr-xr-x 1 root root 695 Okt 30 2015 lvm2
-rwxr-xr-x 1 root root 571 Okt 30 2015 lvm2-lvmetad
-rwxr-xr-x 1 root root 586 Okt 30 2015 lvm2-lvmpolld
-rwxr-xr-x 1 root root 2378 Nov 9 2017 lxcfs
-rwxr-xr-x 1 root root 2541 Dez 7 2017 lxd
-rwxr-xr-x 1 root root 2365 Okt 9 2017 mdadm
-rwxr-xr-x 1 root root 1199 Jul 16 2014 mdadm-waitidle
-rwxr-xr-x 1 root root 703 Jan 19 2016 mountall-bootclean.sh
-rwxr-xr-x 1 root root 2301 Jan 19 2016 mountall.sh
-rwxr-xr-x 1 root root 1461 Jan 19 2016 mountdevsubfs.sh
-rwxr-xr-x 1 root root 1564 Jan 19 2016 mountkernfs.sh
-rwxr-xr-x 1 root root 711 Jan 19 2016 mountnfs-bootclean.sh
-rwxr-xr-x 1 root root 2456 Jan 19 2016 mountnfs.sh
-rwxr-xr-x 1 root root 5449 Mär 6 2018 mysql
-rwxr-xr-x 1 root root 4771 Jul 19 2015 networking
-rwxr-xr-x 1 root root 1988 Sep 24 2018 nmbd
-rwxr-xr-x 1 root root 1581 Okt 16 2015 ondemand
-rwxr-xr-x 1 root root 2503 Mär 29 2016 open-iscsi
-rwxr-xr-x 1 root root 1846 Mär 22 2018 open-vm-tools
-rwxr-xr-x 1 root root 1366 Nov 15 2015 plymouth
-rwxr-xr-x 1 root root 752 Nov 15 2015 plymouth-log
-rwxr-xr-x 1 root root 1192 Sep 6 2015 procps
-rwxr-xr-x 1 root root 6366 Jan 19 2016 rc
-rwxr-xr-x 1 root root 820 Jan 19 2016 rc.local
-rwxr-xr-x 1 root root 117 Jan 19 2016 rcS
-rw-r--r-- 1 root root 2427 Jan 19 2016 README
-rwxr-xr-x 1 root root 661 Jan 19 2016 reboot
-rwxr-xr-x 1 root root 4149 Nov 23 2015 resolvconf
-rwxr-xr-x 1 root root 4355 Jul 10 2014 rsync
-rwxr-xr-x 1 root root 2796 Feb 3 2016 rsyslog
-rwxr-xr-x 1 root root 1266 Mär 9 2016 samba
-rwxr-xr-x 1 root root 2342 Sep 24 2018 samba-ad-dc
-rwxr-xr-x 1 root root 1226 Jun 9 2015 screen-cleanup
-rwxr-xr-x 1 root root 3927 Jan 19 2016 sendsigs
-rwxr-xr-x 1 root root 597 Jan 19 2016 single
-rw-r--r-- 1 root root 1087 Jan 19 2016 skeleton
-rwxr-xr-x 1 root root 1971 Sep 24 2018 smbd
-rwxr-xr-x 1 root root 4077 Mär 16 2017 ssh
-rwxr-xr-x 1 root root 1154 Jan 29 2016 thermald
-rwxr-xr-x 1 root root 6087 Apr 12 2016 udev
-rwxr-xr-x 1 root root 2049 Aug 7 2014 ufw
-rwxr-xr-x 1 root root 2737 Jan 19 2016 umountfs
-rwxr-xr-x 1 root root 2202 Jan 19 2016 umountnfs.sh
-rwxr-xr-x 1 root root 1879 Jan 19 2016 umountroot
-rwxr-xr-x 1 root root 1391 Apr 20 2017 unattended-upgrades
-rwxr-xr-x 1 root root 3111 Jan 19 2016 urandom
-rwxr-xr-x 1 root root 1306 Nov 30 2017 uuidd
-rwxr-xr-x 1 root root 2757 Nov 10 2015 x11-common
EDIT: Wenn es sinnig scheint könnte ich versuchen das upzudaten oder ein backup erstellen und es neu aufsetzen?
Aber eigentlich hab ich die Zeit nicht - und wenn dann wäre zu überlgen auf einen RAspi3 umzusteigen und HMLAN (wird langsam alt) durch ein Homematic HAT für den Raspi zu ersetzen (Teile liegen irgendwo zum löten).
Ok.
Ubuntu 16.04 vgl.bar Jessie (wenn ich richtig liege)
Ist aber auch schon (lange) "out of service"...
Daher auch das "Startscript" unter /etc/init.d (wäre gut gewesen, wenn auch der Aufruf mit gepostet worden wäre, so muss man sich das "erraten" ;) )...
Damit sollte aber "shutdown restart" kein Problem sein...
...bzw. nicht das "übliche" "serviced-Autostart-Problem"...
Ein Umzug sollte mit einem fhem-Backup und Restore funktionieren...
...plus evtl. zusätzlich notwendiger Pakete (hoffentlich Notizen vorhanden, ansonsten: nach Umzug fhem-Log kucken ;) )...
...wenn du wirklich willst...
EDIT: bzw. sollte IMMER ein Backup-/Restore-Konzept vorhanden sein! Und (meiner Meinung nach) eines, welches UNABHÄNGIG von der unterlagerten Plattform ist (eigentlich sogar unabhängig ob Windows oder Linux)... Daher halte ich von: VMs kopieren (o.ä.) oder auch SD-Karten-Komplett-Abzügen nicht wirklich viel... Mir reicht ein fhem-Backup und meine Notizen. Maximal muss ich halt sehen, wie gewisse Dinge (oder notwendige Pakete etc.) auf der neuen Plattform umzusetzen sind aber das sollte anhand meiner Notizen funktionieren (außer nat. die neue [HW-]Plattform unterstützt gewisse nötige Dinge nicht [direkt], dann ist es einfach die falsche Plattform ;) Z.B. Umzug von einem PI mit besagtem Aufsteck-Funkmodul auf einen "PC" wird halt einfach so nicht gehen, da muss entweder was mit WLAN/LAN oder USB "gebastelt" werden. Aber der Rest von "meinem" Backup bzw. Restore läuft ganz normal... :) )
https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html
Es gibt auch einige Threads bzgl. Backup/Restore und System- bzw. fhem-Umzug...
Gruß, Joachim
Naja 16.04 wird offiziell noch bis Apr. 2021 gepflegt, solange es auf das neueste 16.04.7 LTS upgedatet wurde (Wie hier). trotzdem sollte man sich zeitnah um ein Update kümmern. Solange "nur" FHEM drauf läuft, könntest Du es auch mit "do-release-upgrade" (BACKUP!!!). Vor allem, da nur das "Kernsystem" solange updates bekommt.
Warum aber fhem mit shutdown restart probleme hat, ist mir aktuell ein Rätsel.
Zitat von: Wernieman am 30 Oktober 2020, 10:42:28
Naja 16.04 wird offiziell noch bis Apr. 2021 gepflegt, solange es auf das neueste 16.04.7 LTS upgedatet wurde (Wie hier). trotzdem sollte man sich zeitnah um ein Update kümmern. Solange "nur" FHEM drauf läuft, könntest Du es auch mit "do-release-upgrade" (BACKUP!!!). Vor allem, da nur das "Kernsystem" solange updates bekommt.
Jep, da hast du recht...
Aber bis man kuckt ist April ;)
Und bei einem Release-Upgrade bleibt alles (also fhem) unter init.d
Ist an sich ja kein Problem...
...aber da aktuell ja systemd ist, sind halt Hilfestellungen erst mal (wie hier zu Beginn ja auch) erst mal in die "falsche Richtung" unterwegs... ;)
Ich bin (siehe Backup-/Restore-Konzept) eher für: Aufsetzen eines neuen Systems und sauberer Umzug... ;)
Ich werfe dabei auch immer einige Dinge über Board, von denen ich gemerkt habe bzw. beim "Umzug" ja wieder drüber stolpere (aha, diese Schritte jetzt wegen DEM. Brauche ich das überhaupt noch? Nein, dann: Schritt weglassen und auch DAS nicht übernehmen ;) )...
Und wenn er eh auf einen PI will, ist neu Aufsetzen eh ratsam... ;)
EDIT: wobei, wenn die Plattform gut läuft etc. warum dann einen PI!? SD-Problem und SSD per USB usw. (nicht, dass ich das nicht mag, ich "laufe" ja selber [mehrfach] so ;) )... Und wenn es nur wegen dem Funkmodul ist: das geht auch per LAN/WLAN und USB: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Ich habe es beispielsweise seit einigen Jahren per USB an einem PI ;) hängen / weil auf meinem Hauptsystem (aktuell noch mit HM-CFG-USB, den es ja leider nicht mehr gibt) der Steckplatz mit einem EnOcean-Modul belegt ist und ich aber schon mal für den "Ausfall-Fall" vorbereitet sein will :)
Zitat von: Wernieman am 30 Oktober 2020, 10:42:28
Warum aber fhem mit shutdown restart probleme hat, ist mir aktuell ein Rätsel.
Jep, leider bei mir auch.
Steht denn etwas im fhem Log bei shutdown/restart!?
Gruß, Joachim
Danke Euch für die Tipps.
Bin erstmal für die einfachste Lösung weil es echt an Zeit mangelt (heute mal frei aber auch noch viele ToDos bevor die Kinder aus der Kita kommen).
do-release-upgrade klingt nicht schlecht. FHEM Backup ist an sich ja einfach (ein restore hab ich bislang noch nicht gemacht oder es ist ewig her seit dem umzug vom raspi1 auf den nuc). Zudem ist inzwischen z.b. alexa intalliert was recht hakelig war und nicht allein mit dem backup rückgestellt werden könnte (aber das wäre im Fall der fälle ja nicht das allerschlimmste).
Umzug auf Raspi ist nicht zwingend schien mir nur eine gute idee da ich bislang für homematic keine andere lösung kenne als den hat auf dem raspi + raspimatic - zudem wäre dann der nuc frei für andere Nutzung. So aufwändiges stelle ich aber auch gerne zurück. Wäre nur blöd wenn plötzlich der hmlan ausfällt (letzens einmal schon rot geblinkt .. on/off half).
Zitat von: Sammy51 am 30 Oktober 2020, 11:33:17
do-release-upgrade klingt nicht schlecht. FHEM Backup ist an sich ja einfach (ein restore hab ich bislang noch nicht gemacht oder es ist ewig her seit dem umzug vom raspi1 auf den nuc). Zudem ist inzwischen z.b. alexa intalliert was recht hakelig war und nicht allein mit dem backup rückgestellt werden könnte (aber das wäre im Fall der fälle ja nicht das allerschlimmste).
Naja Backup ohne Restore ist kein Backup ;)
Nutzt du (schon) den alexa-fhem Connector?
https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa
Der geht ja wirklich einfach!
EDIT: allerdings ist dazu ein neues System notwendig, weil eine (halbwegs) aktuelle node Version benötigt wird... ;)
Wenn du von einer bestehenden Installation (also "früher" wo man noch einiges bei Amazon machen musste, Port offen [EDIT: der kann dann auch zu :) ] usw.), dann bei Umstieg auf DEMSELBEN System: ALLES ALTE LÖSCHEN!! (seht aber auch im Wiki)
Und: es hat sich der "Filter" geändert. Früher war es -> Geräte in den den "room alexa" schieben / "heute" ist es -> "einen alexaName vergeben"...
Benutzt du den Custom Skill oder "nur" den Smart Home Skill!?
Wenn noch nicht auf dem Connector: steig um :)
EDIT: oder hast du sowas wie "ha-bridge"!? Dann: steig erst recht um :)
Zitat von: Sammy51 am 30 Oktober 2020, 11:33:17
Umzug auf Raspi ist nicht zwingend schien mir nur eine gute idee da ich bislang für homematic keine andere lösung kenne als den hat auf dem raspi + raspimatic - zudem wäre dann der nuc frei für andere Nutzung. So aufwändiges stelle ich aber auch gerne zurück. Wäre nur blöd wenn plötzlich der hmlan ausfällt (letzens einmal schon rot geblinkt .. on/off half).
Du verwendest aber aktuell CUL_HM zur Einbindung in fhem!?
Mit der von dir genannten Variante wäre das aber HMCCU!!!
GANZ ANDERE BAUSTELLE!!
Alle vorhandenen Geräte etc. NEU!!!
Notify/DOIF bzgl. Homematic: NEU!!
Also ich würde ja: eine vccu einrichten (wenn noch nicht gemacht)
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
(NICHT verwechseln mit piVccu, debmatic, ...)
Dann das HMOD-PCB (entweder beim PI direkt drauf oder beim NUC per LAN[WLAN] oder USB) ebenfalls der vccu hinzufügen...
Solange der HMLAN tut: alles gut, wird er eben mit benutzt (oder auch nicht, entscheidet die vccu ;) )
Wenn der kaputt ist: auch ok. Dann einfach löschen und gut...
Weil: die vccu hat ja noch ein IO (HMOD-PCB :) )...
Gruß, Joachim
Es ist schon der neue alexa connector ... fummelig war node korrekt upzudaten das war jedenfalls einer der Punkte bei dem es klemmte.
Klemmt inzwische aber scheinbar an mehreren Stellen. Habe den Eindruck das Backup klappt nicht. Auch finden sich ein paar andere eher "negative" Meldungen im Logfile.
2020.10.30 11:48:00 2: backup include:
2020.10.30 11:48:00 2: Backup with command: tar czf ./backup/FHEM-20201030_114800.tar.gz "./demolog" "./GPL_V2.txt" "./README_DEMO.txt" "./www" "./backup_cfg-state" "./fhem.pl" "./FHEM" "./alexa-fhem.cfg.previous" "./lib" "./log" "./contrib" "./unused" "./CHANGED" "./MAINTAINER.txt" "./restoreDir" "./fhem.cfg" "./SonosSpeak" "./configDB.pm" "./alexa-fhem.cfg" "./docs" "./fhem.cfg.demo"
2020.10.30 11:48:00 3: telnetForBlockingFn_1604054880: port 40414 opened
Ein done oder ähnliches kommt nicht.
Beim HMLAN wird "owner_CCU vccu" angezeigt.
Wird denn unter /opt/fhem/backup eine Datei angelegt?
Ansonsten den im Log stehenden "tar-Befehl" auf der Console ausführen...
Entweder als User fhem oder mit sudo...
Naja, wenn du ein aktuelles Sytem hast (am einfachsten tatsächlich PI mit Raspbian Buster Lite ;) aber auch ein aktuelles Ubuntu), sollte das mit nodejs auch kein Akt sein... ;)
EDIT: zumindest auf Raspbian Buster ist das ganz fix, einfach nehmen was mit apt mitkommt...
EDIT: die Schlüssel unter /opt/fhem/.ssh nicht vergessen... Oder Skill in der Alexa-App "deaktivieren" und neu (mit den neu generierten) Schlüsseln verknüpfen (also nat. nur, wenn du das System wechselst/neu machst / Aber ansinsten brauchst du ja auch kein Backup ;) )
Hmmm, dann hast du schon eine vccu?
Zitat
list model=CCU-FHEM
Sollte Klarheit schaffen...
Wenn ja, dann ist der "Umzug" auf ein anderes Funkmodul einfach...
Gruß, Joachim
Bzgl. DAtei muss ich später mal gucken. Zur Not sollte ich wohl ein BAckup von vor wenigen Monaten haben -seitdem wenig bis nichts geändert glaube ich.
Bzgl. VCCU (viele HMlan Teile habe ich derzeit nicht ... danben etwas enocean und etwa zwave)
DEF 29A490
FUUID 5d028802-f33f-826a-5276-3b5c240c23ca7f51
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG E688D2D,0000,015483AA,FF,FFA0,C2A610688D2D65106406010000
HMLAN1_RSSI -96
HMLAN1_TIME 2020-10-30 11:53:09
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1
NAME vccu
NOTIFYDEV global
NR 54
NTFY_ORDER 50-vccu
STATE HMLAN1:ok
TYPE CUL_HM
assignedIOs HMLAN1
chanNo 01
READINGS:
2020-10-30 11:43:26 IOopen 1
2020-10-30 11:43:26 state HMLAN1:ok
2020-07-18 10:05:16 unknown_31A8E5 received
2019-07-22 21:40:53 unknown_468584 received
2019-06-06 14:51:36 unknown_4C344B received
2020-03-08 19:41:58 unknown_5B43F6 received
2019-06-06 14:29:46 unknown_5B4DC0 received
2020-10-30 10:11:53 unknown_5F5A83 received
2020-10-26 16:36:16 unknown_601408 received
2019-07-04 20:22:27 unknown_651064 received
2020-10-30 11:23:31 unknown_6629C5 received
2020-10-30 11:53:09 unknown_688D2D received
2020-10-30 11:30:06 unknown_6912D2 received
2020-10-30 09:44:29 unknown_691315 received
2020-10-30 11:07:05 unknown_6B57EA received
2020-10-30 07:24:11 unknown_6F2AFE received
2020-10-23 07:48:30 unknown_87F643 received
2019-12-30 20:22:13 unknown_8B8568 received
2020-03-29 14:15:33 unknown_8BFDDE received
2020-10-30 09:03:05 unknown_8D4BE0 received
2020-10-12 08:04:33 unknown_B89B90 received
helper:
HM_CMDNR 12
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
cmds:
TmplKey :no:1604054606.51165
TmplTs 1604054606.51165
cmdKey 1:1:1::vccu::01:
cmdLst:
assignHmKey noArg
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
raw -data- [...]
reset noArg
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt ,G1.4Sw.Sw3.n3,G1.4Sw.Sw4.n4,GT.Licht.Terassendielen,GT.Power.Quellstein1,HW.Licht.Decke,WZ.Licht.DeckeLed,WZ.Licht.DeckeNeon
tplDel
rtrvLst:
cmdList [({short}|long)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
ioList:
HMLAN1
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
IODev HMLAN1
IOList HMLAN1
expert defReg,rawReg
model CCU-FHEM
subType virtual
webCmd virtual:update
Kannts Du eine Anleitung empfehlen um ein aktuelles Ubuntu+ fhem oder raspi +fhem (evtl + raspi homematic modul) empfehlen?
Vielleicht sollte ich das neuaufsetzen tatsächlich mal kurzfristig angehen. für raspi 3 spräche das ich dann erstmal noch den nuc als backup hätte (solange der unverändert bliebe)
Zitat von: Sammy51 am 30 Oktober 2020, 11:33:17
Wäre nur blöd wenn plötzlich der hmlan ausfällt (letzens einmal schon rot geblinkt .. on/off half).
die mittlere led (status) leuchtet bei jeder gesendeten funk-message kurz rot auf.
du solltest dir also sorgen machen, wenn sie nicht mehr blinkt. ;)
Zitat von: Sammy51 am 30 Oktober 2020, 12:18:25
Bzgl. DAtei muss ich später mal gucken. Zur Not sollte ich wohl ein BAckup von vor wenigen Monaten haben -seitdem wenig bis nichts geändert glaube ich.
Ja, schau mal.
Wenn nicht, einfach manuell machen...
https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html
Zitat von: Sammy51 am 30 Oktober 2020, 12:18:25
Bzgl. VCCU (viele HMlan Teile habe ich derzeit nicht ... danben etwas enocean und etwa zwave)
Wunderbar. Dann ist das Hinzufügen bzw. (später) Entfernen eines IO kein Problem...
EDIT:
Zitat von: frank am 30 Oktober 2020, 13:14:52
die mittlere led (status) leuchtet bei jeder gesendeten funk-message kurz rot auf.
du solltest dir also sorgen machen, wenn sie nicht mehr blinkt. ;)
auch wenn wohl (erst mal) unnötig ;)
Bei Zwave (EnOcean weiß ich nicht) sind die angelernten Geräte (auch) im Funk-Modul gespeichert.
D.h. bei einem Umzug das Funkmodul mitnehmen...
...oder backup FW und Restore auf neues Funkmodul (Typ etc. beachten! Siehe ZWave Wiki / Forum)...
...oder neu anlernen...
EDIT: bei Homematic ist die HMID entscheidend! Die ist in den jeweiligen, angelernten Geräten hinterlegt (als "deren" Zentrale)... Also die mal merken! ;)
Zitat von: Sammy51 am 30 Oktober 2020, 12:18:25
Kannts Du eine Anleitung empfehlen um ein aktuelles Ubuntu+ fhem oder raspi +fhem (evtl + raspi homematic modul) empfehlen?
Vielleicht sollte ich das neuaufsetzen tatsächlich mal kurzfristig angehen. für raspi 3 spräche das ich dann erstmal noch den nuc als backup hätte (solange der unverändert bliebe)
Homematic-Funkmodul: eben das HMOD-PCB!
Siehe Link in einer meiner Antworten...
Anleitung zur Installation: debian.fhem.de -> "the easy Way" ;)
EDIT: bzgl. Raspbian halt Buster LITE! Die Anleitung ("the easy way") sollte auch für Ubuntu passen (ist ja auch Debian irgendwie)... Ab und an ein sudo hinzufügen! Oder die Installationsschritte (aber NICHT MEHR!!) als root ausführen "sudo su" und dann "exit" nicht vergessen!!
Gruß, Joachim
Da fällt mir unterwegs noch ein - eigentlich wäre es am effizientesten FHEM auf dem qnap zu installieren. Das unerstützt VMs und qnap liefert sogar ein Ubuntu Server als mehr oder weniger fertige VM.
Macht das Sinn
a) QNAP + VM
b) oder doch besser NUC evtl. mit neuer SSD Neuaufsetzen
c) oder den besagten Raspi 3
Backup Files wurden offenbar abgelegt:
FHEM-20201027_195045.tar.gz
FHEM-20201030_113836.tar.gz
FHEM-20201030_114800.tar.gz
Bzgl. rote Led beim HMLAN .. die leuchtete mal dauerhaft und das ding war nicht mehr verfügbar. Stromlos und wieder an half seitdem gings erstmal wieder.
Also die Entscheidung musst du (leider) selber treffen...
Es gibt (gefühlt) 1000+ Threads zu dem Thema: welche Plattform am besten für fhem u.ä. ;)
Meine persönliche Meinung:
Bei VMs (ich mache viel damit):
wenn du dich da auskennst auch bzgl. einbinden von Laufwerken, Netzwerkeinstellungen etc. und das Ding eh dauernd läuft -> warum nicht.
wenn du eher Anfänger bzgl. VMs etc. bist würde ich erst mal "üben" und das auf später "vertagen". Weil sonst kommen zu den "üblichen" fhem-Problemen/-Fragen auch noch "Probleme" bzgl. VM-Plattform. Bzw. musst du ja erst mal sehen, ob das Problem an der Plattform oder an fhem liegt ;)
(siehe: wenn du Ahnung hast ;) )
EDIT: eine ähnliche Meinung habe ich zu Docker. Ja es gibt Anwendungsfälle wo das sehr gut geeignet ist... Aber wenn ich dann immer hier höre: ich bin von fhem@PI auf Docker umgestiegen und nun geht das nicht mehr oder das ist schwierig und wie kriege ich den USB-Stick rein usw. Da frage ich mich: war denn nicht die Absicht, dass es danach leichter, einfacher, etc. geht. Naja bzgl. fhem und ähnlicher "Server-Anwendungen" bin ich (gut mag "altmodisch" sein ;) ) eher noch für "bare metal" :)
Bzgl. NUC:
naja so lange Linux drauf läuft ist es ja (sehr) ähnlich der PI Plattform ;)
(@andere: jaja nicht hauen! ;) ich meine nur im Vergleich zu beispielsweise Windows ;) )
Raspberry PI:
naja die meisten Anleitungen sind halt für die Plattform PI zu finden/gemacht...
Du hast GPIO (auch wenn die zu nutzen nicht unbedingt immer sinnvoll ist ;) )...
...außer eben besagtes Funkmodul (und andere Funkmodule), wobei das ja auch per USB an einen NUC (und eine VM -> Ahnung haben ;) ) geht...
EDIT: gut und dann eben die üblichen Dinge USB, SD, ... die eben nicht so toll sind...
Viel Erfolg, Joachim
P.S.: ich habe 4 fhem auf PI laufen. 2 "produktiv" (1x mit SSD / 1x [noch] mit SD) und 2 Testsysteme... :)
Zu Glück ist bei FHEM selber die Plattform ziemlich egal, solange Du die Hardware nicht direkt ansprichst (und es unter Linux läuft).
1.
Wenn Du dagegen direkt anzusprechende Hardware hast (GPIO (nicht empfehlenswert), USB-Sticks (Funkmodule) ....) ist VM und/oder Docker erstmal eine zusätzliche Hürde (Wie oben angesprochen). Wenn es dagegen reine Netzwerkmodule sind (CCUx, esp8266, diverse NetzGateways (z.B. ser2net....) dagegen macht es eine "Virtuallisierung (VM/Docker) eventuell sogar einfacher ....
Aber das ist nur meine Meinung
2.
Bezüglich VM auf NAS:
Habe mich hier dagegen entschieden. Abgesehen davon, das ich die Hardware habe, die NAS kann sich automatisch updaten und rebooten und es interessiert mich nicht. Zusätzlich können sich die Platten "schlafenlegen" und damit Stromsparender arbeiten, was bei VMs nicht mehr geht (laut I-Net-Berichten).
Aber das ist nur meine Meinung
3. Bezüglich Docker:
bei jeder Technik muß man sich erst einarbeiten. habe jetzt beruflich viel mit Docker zu tuen, aber sogar bei uns sind die Entwickler, welche eigentlich Beare-Metal "Freunde" sind, mittlerweile auf Produktiven Systemen auf Docker umgestiegen (oder wollen). Liegt aber mehr auch daran, das dann Entwicklersysteme=Produktivsystemen, was bei Beare-Matel meistens nicht zu gewährleisten ist. Auch ist es umkomplizierter (Wenn man es kann), dann mehrere Dienste Parallel zu fahren.
Hintergrund:
Dienst X will library LX nur in Version LZ1
Dienst Y will library LX nur in Version LZ2
Löse mal das Problem auf Beare-Metal. Lösbar aber bei jedem Update ein Logistisches Problem. Genau das eben bei Docker (und aufwendiger VM) eben nicht ...
Das der Micro-Service Gedanke noch andere Vorzüge hat (der FHEM-Docker-Container ist kein Micro-Service), ist hier nicht betrachtet.
Aber auch das ist nur meine Meinung
Hallo nochmal,
Vielen Dank für Eure Ausführungen, Hinweise und Tipps!!
Bin nicht sicher ob ich richtig schlussfolgere würde erstmal nochmal auf PI zurückgehen und mal getestete VM vom Qnpa schmeißen - HA-Bridge z.B. hab ich da vor Jahren nicht so recht hinbekommmen. Diesmal dann aber PI 3 statt PI1 - den ich vor längerm mal für das Homematic GPIO Modul besorgt hatte.
* Für Homematice hätte ich das GPIO Modul noch rumliegen - was spricht dagegen?
* Die erstmalige vorbereitung und Einrichtung mit USB Adapter daran scheint etwas aufwändiger - dafür ließe sich das natürlich besser positionieren.
* Die sonstige Hardware ist nämlich in einem 19" Blechschrank (obschon der Raspi theoretisch auch außen fixiert werden könnte).
Sehe ich das richtig das ich vom prinzip FHEM neu aufsetze nach einer Anleitung (z.B. eben auf dem raspi); dann das backup rücksichere (auch dafür habt ihr schon freundlich eine Anleitung genannt) - und dann (oder vorher) die USB Adaptter Enocean, Zwave anstecke (HMLAN ist ja eh im Lan und behält IP) und dann sollte es gehen wenn ich den Nuc abschalte und den Pi an?
Beste Grüße
Sammy
PS: Mit dem Fachmann sein ist so ein Problem ... war vor Jahren mal halbwegs fit mit dem Zeug dann konnte und musste ich Jahre nichts machen damit (Job, Familie, Haus ...) und ich bin fast wieder bei Null. Inzwischen gäbe es auch andere Systeme (Openhab z.B.) aber ob das besser ist ist unklar und manche Komponenten sind nicht mal eben neu anlernbar weil "tief verbaut". Außerdem wäre das noch deutlich mehr Aufwand. Also bleib ich wohl "hier" und bei FHEM (obwohl deutschsprachig kein Argument ist - aber wer weiß ob die Spezialisten anderswo genauso nett sind ;-). Tuts ja auch in der Regel wenn Routinen usw. erstmal eingerichtet sind :)
shutdown restart - klappt jetzt übrigens wieder (weiß leider nicht weshalb).
Erhalte beim Neustart aber u.a. folgende Fehlermeldungen (im logfile). Habt ihr eine Idee woran das liegen kann?
Wüßte nicht welche CUL das sein sollte. Gibt zwei per IP angebundene (HMLAN und HUE) und zwei USB via ID angebundene (enocean und zwave)
Im Voraus vielen Dank!
Beste Grüße
Sammy
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS0
2020.11.02 21:07:47 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 586.
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS0: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS1
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS1: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS10
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS10: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS11
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS11: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS12
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS12: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS13
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS13: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS14
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS14: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS15
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS15: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS16
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS16: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS17
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS17: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS18
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS18: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS19
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS19: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS2
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS2: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS20
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS20: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS21
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS21: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS22
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS22: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS23
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS23: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS24
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS24: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS25
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS25: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS26
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS26: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS27
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS27: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS28
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS28: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS29
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS29: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS3
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS3: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS30
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS30: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS31
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS31: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS4
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS4: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS5
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS5: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS6
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS6: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS7
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS7: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS8
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS8: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS9
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS9: Input/output error
Das ist (vermutlich) der initialUsbCheck, der prüft alles mögliche durch.
Wenn du keine CUL hast bzw. die die du evtl. hast "fix definiert" sind, dann kannst du das auch deaktivieren:
attr initialUsbCheck disable 1
Gruß, Joachim
Stimmt - das hat geholfen.
Darf ich andere Fehlermeldungen die Tage auch hier aufführen oder mach ich da besser mal ein neues Topic auf?
Beste Grüße
Sammy
Es ist dein Thread... ;)
Aber wenn Wernieman oder ich da dann nicht helfen können, wird sich verm. kein anderer Helfer hierher verirren... ;)
D.h. spät. dann wird es Zeit für einen neuen Thread...
Und andere mit einem Problem wie es jetzt kommt, werden dann halt verm. die Lösung nicht finden, da der Betreff ja nicht (mehr) passt...
Aber wenn das hier jetzt gelöst ist, trotzdem bitte ein [gelöst] vorne dran pappen...
Gruß, Joachim
Zitat von: MadMax-FHEM am 30 Oktober 2020, 12:10:49
EDIT: die Schlüssel unter /opt/fhem/.ssh nicht vergessen... Oder Skill in der Alexa-App "deaktivieren" und neu (mit den neu generierten) Schlüsseln verknüpfen (also nat. nur, wenn du das System wechselst/neu machst / Aber ansinsten brauchst du ja auch kein Backup ;) )
Nutze noch historisch sftp zum Zugriff auf den Server mit FHEM. Die Backups kann ich so auch problemlos herunterholen.
Aber auf .ssh will filezilla / der Server mich nicht zugreifen lassen?!
Fehler: Directory /opt/fhem/.ssh: permission denied
EDIT: Bezüglich des Homematic-Adapters "auf USB CP2102 Adapter" - empfiehlt sich da ein kleines Gehäuse? Was z.B. ?
Das ist normal. Nur der Besitzer kann auf seinem .ssh Verzeichnis zugreifen: dort liegen ggf die private Schlüssel, die niemand sonst sehen sollte. Das ist Sicherheit.
Du kannst nur mit "sudo" oder als root drauf, oder eh mit dem User fhem.
Zitat von: Sammy51 am 21 November 2020, 22:06:51
EDIT: Bezüglich des Homematic-Adapters "auf USB CP2102 Adapter" - empfiehlt sich da ein kleines Gehäuse? Was z.B. ?
Also ich habe das hier: https://de.elv.com/strapubox-kunststoff-gehaeuse-usb-1-abs-56-x-20-x-12-mm-schwarz-101670
Geht aber ziemlich eng zu... ;)
Und mal nachmessen, ob der Adapter wirklich auf 3,3V arbeitet.
Einer meiner (gut "Billig-China" ;) ) war zwar auf 3,3V "eingestellt" hat aber trotzdem 5V geliefert.
Fand der HM-Funk-Chip nicht so lustig...
Beim nächsten dann nachgemessen, seitdem alles gut. Ca. 2 Jahre jetzt im "Testbetrieb"...
Gruß, Joachim
Danke für den Tipp und die Fotos - das Gehäuse schau ich mir an. Hab auch schon überlegt nach etwas größerem zu schauen und das USB Verlängerungskabel mit dessen Buchse direkt mit "einzubauen".
Bzgl. root Zugriff für die SSH Files .. per SFTP klappt das testweise nicht mit admin/root entweder gibts die Kennung nicht oder ich weiß das PW nicht mehr.
Beste Grüße
Sammy
Vermutlich ist auch bei dir ein root-Login nicht möglich/gesperrt...
Ist auf vielen Linux-Sytemen so.
Drum gibt es sudo...
Auch ein Sicherheits-Feature...
Besser für die lange Zukunft ist daher wohl sich auf der Console "zurechtzufinden"...
Dateien eben dort hin zu transferieren (dann wenn es sein muss ;) auch mittels "Klicki-Programm") wo eben ein normaler User des Systens "darf" und dann lokal mittels sudo in Bereiche wo eben ein norm. User nicht darf und dann Besitzverhältnisse wieder "gerade rücken"...
EDIT: statt lokal Console gibt es wohl auch "Klicki-Programme" z.B. MidnightCommander? Also "mc". Den kann man dann wohl auch mittels sudo starten (also sudo mc) und dann Dateien "rumschubbsen"... Kenne ich aber nur vom "Hörensagen" ;)
Bei einer Standard-fhem-Installation:
sudo chown fhem: Pfad/Datei
Gruß, Joachim
Bei meinem 2017er Modul sind die Pin nicht beschriftet. Passt das so zur Skizze?
Davon verbinde ich dann nur ub+, gnd und über Kreuz rx und tx mit dem usb Adapter?
Ferrit Ding an raspi Power Kabel und fertig?
Im Prinzip ja und so läuft das bei mir auch.
Für die "Zwischenplatine" mit den Kondensatoren und Widerständen war bei mir bzw. bei meiner Gehäusewahl kein Platz, daher hab ich das weggelassen.
Läuft.
Habe aber auch schon gelesen, dass das dann irgendwann nicht mehr tun kann/soll...
Daher "rate" ich an der Stelle mal nicht dazu ;)
Wenn du Platz hast, dann ist es (verm.) besser die Zwischenplatine zu nutzen...
Wichtig: echt messen, dass der USB-Adapter wirklich mit 3,3V arbeitet!
(wie geschrieben, ich hab so schon ein Funkmodul "gegrillt" ;) )
Alles weitere sollte doch hier stehen: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Und auch prüfen, welche FW drauf ist!
Ich habe auch schon gelesen, dass die Funkmodule die jetzt neu geliefert werden schon die neuesete FW drauf haben sollen (obwohl eq3 da eher immer "langsam" war ;) ).
Die geht nicht mit CUL_HM/fhem!
Also "downgraden" (oder falls doch noch die "ganz alte" FW drauf ist: upgraden). Welche FW usw. steht (sollte) in dem Wiki...
Gruß, Joachim
Ok - danke für den Hinweis. Hab auch auch schon überlegt. Ist ja nicht zum Spaß dabei und stabilisiert vermutlich Spannungszufuhr. Die einfachste und billigste Lösung wäre natürlich die pink-durchsichtige Kunststoff-Verpackung des Raspi als Hülle für die USB Bastelei zu nehmen und alle großzügig mit Heißkleber darin zu fixieren (inkl. USB Verlängerungskabel buchse weiblich).
Dann passt auch die Zwischenplatine mit Stützkondenstoren und Wiederständen.
Firmware gucke ich mal was sich da findet. Neu ist meine bestimmt nicht da das Teil seit locker 2 Jahren in der Schublade liegt (so lange wie der damals neue Raspi 3b).
Hab jetzt erstmal parallel zum produktiven NUC den Raspi3b gemäß der Anleitung hier installiert.
Eine Schritt für Schritt Anleitung zum ersten Einrichten von FHEM hab ich zunächst nicht gefunden - oder benötige ich das gar nicht wenn ich das Backup vom FHEM/NUC einspiele?
Würde dann am liebesten erst Alexa und Sonos wieder einrichten (Anleitungen dafür suchen) bevor ich dann den NUC außerbetrieb nehme oder auch mal ein Upgrade auf das aktuelle ubuntu release dort teste.
Beste Grüße
Sammy
Doch du brauchst auch dann eine Basis-Installation von fhem, weil:
- Perl-Pakete
- fhem User
- fhem-Start
- usw.
Anleitung (hatte ich das noch nicht geschrieben): debian.fhem.de -> "the easy way" (sudo an den notwendigen Stellen "ergänzen")
EDIT: doch hatte ich ;)
EDIT: jetzt wird es aber "wildes Durcheinander", man weiß ja gar nicht mehr was geht/nicht geht und was du grad machst... ;)
Dann entweder komplett Backup einspielen oder per Raw-Definition "Stück für Stück" umziehen...
Wenn du ein komplett Backup einspielat macht es wenig Sinn alexa und Sonos vorher einzurichten...
EDIT: außer evtl. den Installations-Aufruf von alexa-fhem inkl. nodejs auf der Console. Aber der geht auch nachher... ;) Wenn du alexa-fhem schon mal laufen hattest: bei deiner Vorgehensweise ändern sich (verm.) die ssh-Schlüssel und der Proxy-Key, da wirst du den Skill noch mal neu verbinden müssen (und auch immer wieder, wenn du zwischen den Systemen "switched")...
Gruß, Joachim
Ja die Basis Installation hab ich doch. Fhem läuft. Ist aber leer und hat nichteinmal ein pw Schutz der Webiberfläche. Als Backup habe ich die Files die von "Backup" gesichert werden. Daneben die Option vom produktiven nuc noch weitere Dinge zu kopieren wenn das hilft.
Diverse Dinge/ Debian Pakete die Alexa und sonos benötigen sind nicht im obigen Backup dachte ich - so das eine neue Grundeinrichtung nötig sei.
Also im Standard-fhem-Backup sind keine OS-Pakete etc. enthalten.
Und eben auch nicht /opt/fhem/.ssh daher die Anmerkung bzgl. alexa-fhem und Skill-Verknüpfung.
Im fhem-Backup ist die fhem.cfg und /opt/fhem/FHEM enthalten.
Was genau steht im Backup-Befehl (wird bei Backup-Start angezeigt und geloggt)...
Daher musst du "nachinstallierte" OS-Pakete (für fhem-Module die du nutzt) ebenfalls selbst noch mal installieren.
Wie man rausbekommt was man so nachinstalliert hat:
- eigene Notizen
- Abfrage vom Paketmanager
- fhem Installer-Modul
- commandref/Wiki der genutzten Module
Weiteres bzgl. Backup/Restore hatte ich ja schon mal geschrieben: https://forum.fhem.de/index.php/topic,71451.msg1096625.html#msg1096625
Gruß, Joachim
Entschuldigung - ich bin zu blöd. Habe das .ssh verzeichnis inkl. inhalt nach /backuk/ssh kopiert.
Ich kann auch in dieses verzeichnis wechseln aber chown -hR sammy /ssh
Gibt chown: Zugriff auf '/ssh' nicht möglich: Datei oder Verzeichnis nicht gefunden
...zurück?
1) Wenn das erstmal geklappt haben sollte müsste ich es per sftp als user sammy kopieren können nach "lokal" richtig?
2) Was ist dann das Mittel der Wahl um es auf den Raspi zu transerieren (bislang hab ich dort glaube ich weder sftp noch samba oder sonstiges eingerichtet)?
3) Danach spiele ich dann das FHEM BAckup auf den Raspi (Dein Link oben)
4) Dann installiere ich noch das Paket für Alexa und node?
(elektrische Teile für den HM USB Adapter d.h. das zusätzliche USB Adapter Ding - sind jetzt übrigens da - hab nur vorhin das alte Multimeter nicht direkt gefunden und konnte für die Lötstation nicht auf den Speicher wegen schlafendem Kind)
es heist .ssh und nicht ssh .. man beachte den "."
Dass das chown nicht geht und auch warum steht doch in der Fehlermeldung:
/ssh != /opt/fhem/backup/ssh
(ich vermute mal, dass das mit "backuk/ssh" gemeint ist/war ;) )
Allerdings sind mit dieser Aktion die Besitzrechte etc. "kaputt"...
Besser tar oder gleich rsync nehmen...
Du brauchst doch keinen sftp/samba!
Du hast doch ssh -> scp nutzen :)
Aber trotz des "chown sammy" wird das u.U. nicht gehen, da ja sammy evtl. nicht im /opt/fhem/backup "arbeiten" darf...
EDIT: wenn du keine ssh-Zugriffe von fhem auf andere Rechner machst, dann brauchst du .ssh auch nicht transferieren. Für alexa-fhem einfach den Skill in der App "lösen" und mit dem neuen Key auf dem neuen Rechner wieder verbinden...
Gruß, Joachim
Ups fast schon logisch. Danke :-)
Ach das geht auch ssh scp muss ich mich schlau machen.
bzgl. tar .. Du meinst .ssh als root komprimieren und das tar file dann per ssh scp "rüberschieben"?
So wie begonnen tatsächlich umständlich dann müsste ich abschließend wieder chown => root machen.
JA genau das Verzeichnis meinte ich mit /backup/ssh
Ja so ungefähr.
Aber erst mal bzgl. Rechte/Besitzverhältnisse auf Linux einarbeiten!!
Sonst "vermurkst" du mehr als du gut tust... ;)
Und noch mal: wozu willst du .ssh transferieren!?
Gruß, Joachim
Zitat von: MadMax-FHEM am 24 November 2020, 21:33:39
Und noch mal: wozu willst du .ssh transferieren!?
Hi Joachim,
weil Du mir doch "oben" den Tipp gegeben hast an /fhem/.ssh zu denken (wegen Alexa). Zwischenzetlich gab es dann den Tipp chown zu verwenden. Auf der Basis hab ich mir den ersten Versuch zusammengereimt.
Beste Grüße
Sammy
Naja aber wenn es nur deswegen ist und du dich offenbar schwer tust mit dem Transferieren inkl. Beibehaltung der Zugriffs- und Besitzrechte, dann kannst du auch einfach alexa-fhem neu installieren (und definieren) und dann einfach den Skill neu verbinden (habe ich auch geschrieben)...
Hast du bereits Routinen angelegt?
Oder schon fleißig "gruppiert" in der Alexa-App?
Wenn nein: dann ist ein neues Verknüpfen des Skills wohl einfacher...
Gruß, Joachim
Schon - aber einen Datentransferweg benötige ich eh (für backup und wiederherstellen mindestens)
=> also scp (empfiehlt sich dafür ein Tool für Mac? Oder doch auch das per Commandozeile oder WinSCP?
Und wenn der rest vom Trick ein tar file des /fhem/.ssh Verzeichnisses als root ist - dann muss das doch machbar sein und will ich das lernen.
Vom Prinzip ist etwas Spaß an "so Zeug" und das Basteln bzw. "spielerisch lernen" ja auch ein Selbstzweck sonst wären fertige Kauflösungen effizienter (Zeitbedarf und spätestens wenn man die Zeit mit Euro bewertet - vermutlich auch wirtschaftlich).
EDIT: Aus dem fhem Verzeichnis in der Konsole macht
sudo su
tar -c .ssh -f fhem-ssh
eine Datei "fhem-ssh" scheinbar ohne Endung. Ist das jetzt ein Archiv was ich nach Transfer auf dem neuen Server mit -p entpacke?
Naja, wenn du mit scp kopieren willst ;)
Dann kannst du eigentlich nur vom Home des Users pi kopieren.
EDIT: root ist normalerweise "gesperrt" und der User fhem hat ebenfalls weder Passwort noch eine Login-Shell...
Also (als user pi auf der "Console" / ssh-Login):
sudo cp /opt/fhem/backup/BACKUP-DATEI.tar /home/pi/
Dann muss das nat. auch nicht mehr root (sudo) gehören, sondern eben dem User pi:
sudo chown pi:pi /home/pi/BACKUP-DATEI.tar
bzw. (kürzer):
sudo chown pi: /home/pi/BACKUP-DATEI.tar
Dann kannst du das mittels scp (ja WinSCP o.ä. geht nat.) kopieren...
Dann auf dem Zielsystem eben ent-taren, siehe Link zu Ottos-Blog...
EDIT: da das ent-taren ebenfalls per sudo gemacht wird, ist es egal "wem" die Backup-Datei "gehört" ;)
EDIT: wenn du einzelne Dateien von einem fhem (Linux/PI) zu einem anderen fhem (Linux/PI) kopieren willst, dann geht das wie oben mit der Backup-Datei gezeigt. Auf dem Zielsystem dann aber halt "Rückwärts": "sudo cp /home/pi/Transfer-Datei /opt/fhem/" bzw. (meist, z.B. für *.pm-Dateien ["manuelle" Installation von fhem-Modulen) "sudo cp /home/pi/Transfer-Datei /opt/fhem/FHEM/" und dann eben "sudo chown fhem: /op/fhem/Datei" bzw. "sudo chown fhem: /op/fhem/FHEM/Datei"...
Bzgl. .ssh geht das ebenso, also als root "taren" und dann die tar-Datei ebenso wie die Backup-Datei "behandeln".
Beim Entpacken musst du halt schauen, da kommt es drauf an was du wie "getared" hast...
Gruß, Joachim
Das hilft vermutlich. Der erste Teil schien bei mir auch anders zu gehen.
Auf den NUC habe ich SFTP Zugriff (für die backups genutzt). Dort ist der user sammy (nicht pi)
Habe im /fhem/ als root "sudo su":
tar -c .ssh -f fhem-ssh.tar
mv fhem-ssh.tar backup
Gemacht. Danach kann ich irgendwarum als sftp user sammy die Datei unverändert (bzgl. chown) runter kopieren.
Jetzt mal sehen ob ich es vom macbook auf den pi bekomme nach /fhem/.ssh (das Verzeichnis gibt es zunächst vermutlich nicht)
Per Console zumindest geht es vom MacBook auf den PI
scp fhem-ssh.tar pi@192.168.178.xx:/home/pi
Frei nach Otto dann entpacken (den Befehl muss ich jetzt absetzen vielleicht klappts ja)
sudo tar -xvzf /home/pi/fhem-ssh.tar -C /opt/fhem/
==> EDIT: Ne geht nicht; weiß natürlich nicht weshalb :(
tar -xvzf /home/pi/fhem-ssh.tar -C /opt/fhem/
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Evtl. das z zu viel als Parameter? ==> DAs wars scheinbar. Jetzt hats geklappt
sudo tar -xvf /home/pi/fhem-ssh.tar -C /opt/fhem/
.ssh/
.ssh/id_rsa.pub
.ssh/known_hosts
.ssh/id_rsa
Jetzt also das gleiche mit backup. Mir scheint nur das neue FHEM reagiert nicht auf "shutdown" ... kurz weg. Dann wieder "ereichbar"
EDIT: stop per konsole hingegen geht offenbar
Kommt drauf an auf welchem System...
Eine neuere Installation auf Systemen mit systemd haben einen "autostart"...
Gibt Threads im Forum dazu...
Wenn du da fhem stoppen willst, dann mittels systemctl...
sudo systemctl stop fhem
Oder
sudo systemctl stop fhem.service
(keine Garantie, ist "aus dem Kopf")
Gruß, Joachim
Ja hat geklappt - stand auch im Blog von Otto :)
Wenn ich dann node installiere und fhem-alexa wird dann das SSH Zeug auch nicht automatisch wider überschrieben?
https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa#node.js_installieren
hmm.. EDIT: rpi3b @Buster
pi@raspberrypi3b:~ $ node --version
v10.21.0
pi@raspberrypi3b:~ $ sudo npm install -g alexa-fhem
npm WARN npm npm does not support Node.js v10.21.0
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9.
npm WARN npm You can find the latest version at https://nodejs.org/
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
/usr/local/bin/alexa-fhem -> /usr/local/lib/node_modules/alexa-fhem/bin/alexa
+ alexa-fhem@0.5.57
added 63 packages from 71 contributors in 25.041s
Bei mir wurde bei noch keinem Umzug was überschrieben...
Bzw. selbst wenn: du hast doch das tar noch ;)
Starte doch alexa-fhem einfach mal (Alexa-Device aus Backup einspielen) und schau, ob sich alexa-fhem noch mit dem Skill verbindet...
Wenn nicht: entweder noch mal neu verknüpfen (oder eben aus dem tar einspielen)
Was willst du mir der "Installationsausgabe" mitteilen?
Sieht doch so aus, als wäre es installiert!?
Gruß, Joachim
Hat halt etwas rumgenörgelt die Installationsausgabe das irgendwas nicht geht oder vielleicht nicht geht.
Alexa Ist jetzt eingespielt soweit. Gemäß folgender Anleitung jedoch ohne die Schritte in FHEM - da es ja durch das Backup bereits definiert sein sollte. Richtig? Noch nicht getestet.
https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa)
Sonos auch nochmal eingerichtet - das klappt im Test erstmal nicht.
https://wiki.fhem.de/wiki/SONOS#Einbindung_von_Sonos_in_FHEM (https://wiki.fhem.de/wiki/SONOS#Einbindung_von_Sonos_in_FHEM)
Sollte ich jetzt vielleicht auch den NUC (jetzt merkt man das der raspi doch ein gutes stück langsamer ist; jedenfalls beim basteln darauf) erstmal abschalten bevor ich mit dem Raspi weiter mache und die enocean und zwave Sticks übernehme?
HMLAN und Hue kann er ja vermutlich schon ansprechen - aber doppelt verbunden geht zumindest mit HMLAN nicht ordentlich glaube ich.
Zu Sonos kann ich nichts sagen...
Ja, wenn ein Alexa-Device definiert war, kommt es aus dem.Backup (wie ja geschrieben)...
Ansonsten wie man halt umzieht...
Aktuelles System runterfahren, HW umstecken und Backup einspielen und das neue System mal starten...
Dann muss man halt sehen...
Wenn USB-Sticks etc. verwendet werden, sollten diese by-id eingebunden sein, sonst kann/wird es sein, dass die Defines auf dem neuen System nicht mehr stimmen...
EDIT: HMLAN kann nur eine Verbindung. HUE-Bridge (zumindest deCONZ) kann mehrere Verbindungen. Die Anmeldedaten sind ja (normalerweise) im Backup. Ansonsten halt noch mal verbinden (Knopf drücken bzw. Gateway "freigeben")...
Dies und andere Fehler im Log korrigieren...
Aber: was soll schon passieren?
Du hast ein Backup und das aktuelle System...
Gruß, Joachim
Zitat von: MadMax-FHEM am 26 November 2020, 23:01:25
Zu Sonos kann ich nichts sagen...
Wenn USB-Sticks etc. verwendet werden, sollten diese by-id eingebunden sein, sonst kann/wird es sein, dass die Defines auf dem neuen System nicht mehr stimmen...
Die USB Einbindung habe ich gemäß Eurer Tipps schon vor dem Backup auf dem NUC eingerichtet :)
Den NUC abschalten und RPI produktiv setzen könnte morgen klappen (mit etwas potentieller Zeit falls es zunächst wo klemmt; wenn das nur Sonos wäre für die Sprachausgabe wäre das im ersten Moment nicht dramatisch; aber unschön). Wenns direkt klappt ist die Zeit morgen dann fürs Löten des HM-Moduls angedacht.
==> Überlege es original zu verlöten um es prinzipiell auch auf dem Raspi nutzen zu können - dann aber per Stiftleiste und angelöteten Drähten an den USB-Adapter "zu stecken".
==> Dann bin ich flexibel (auch wenns nicht so elegant sein wird optisch wie die minimal USB-VAriante im Gehäuse).
==> zudem ist dann der Nutzen der Schutzwiderstände und der Stützkondensatoren gegeben.
Ich würde halt nicht zu lange (fliegende) Drähte nehmen, nicht dass sich das Funkmodul was "einfängt"...
Du kannst aber die USB-Variante auch am PI betreiben.
Hab ich auch...
Viel Erfolg, Joachim
Stimmt schon hab ich auch schon überlegt wär praktisch aber vermutlich zu quick-n-dirty praktisch einfach alles zu stecken mit 10cm Drähten zwischen USB und HM-Modul :o Das USB auch am RASPI geht ist klar aber häßlicher wirds, da mit Zusatzplatine kaum möglich es in ein USB-Stick-Gehäuse zu fummeln.
Kinder schlafen hab jetzt kurz getestet klappt ohne Problem mit raspi-3b jetzt produktiv.
==> Selbst Alexa läuft ohne Neueinrichtung durch Eure .ssh Tipps :-) 8)
==> Die Sonos tuns auch wieder inkl. Textausgabe (eigentlich das einzige was ich davon bislang via FHEM zum Spaß nutze). Soll wohl Leute geben die es blöd finden wenn "Die Tante sagt - Das Licht im Hauswirtschaftsraum ist seit 10min an" *g*
==> Was komisch ist .. einer der Sonos heißt in FHEM immer noch Schlafzimmer (vielleicht war das mal der Name)
==> Über Alexa und die Sonos App ist der seit längerem aber "Büro" ?!
==> Idee wie FHEM das aktualisiert?
Enocean ebenfalls noch nicht ganz rund - aber ansprechbar ist es:
EnOcean Cryptographic functions are not available.
2020.11.27 21:56:42 2: EnOcean XML functions available.
Na dann: gratuliere!
Zitat
2020.11.14 11:06:18 2: EnOcean Cryptographic functions are not available.
2020.11.14 11:06:18 2: EnOcean XML functions available.
Habe ich auch so...
...vermutlich: schon immer ;)
Ich schätze, dass das "nur" bedeutet, dass eben keine "verschlüsselte" Kommunikation unter den Komponenten möglich sein wird...
Aber fraglich, ob das in fhem überhaupt implementiert ist bzw. werden kann.
Ist bei ZWave ähnlich, da ist auch noch nicht alles bzgl. "verschlüsselter" Kommunikation implementiert...
Und bzgl. Sonos bleibe ich dabei: keine Ahnung ;)
Ich hatte ein ähnliches Problem mit meinen Echos.
Allerdings nicht in fhem sondern per Amazon-Sprache.
D.h. in fhem war alles ok (da heißen die Echos mit dem Echodevice-Modul eh ECHO_XXXXX / nur der alias ist dann der Name bei Amazon)...
...auch per Alexa-App.
Nur wenn ich per Sprache sagte: Alexa spiele Musik auf Büro
Spielte die Musik auf dem "Ex-Büro", der halt nun laut Alexa-App aber Schlafzimmer war...
"Lösung": zurücksetzen und neu anlernen...
Gruß, Joachim
P.S.: das ssh-tar ist bei mir fester Bestandteil des fhem-Backups. Dazu habe ich das ssh-tar im /opt/fhem Verzeichnis liegen mit Besitzer fhem (eh klar). Dadurch landet das tar in jedem fhem Backup ;)
ZitatSonos auch nochmal eingerichtet - das klappt im Test erstmal nicht.
Was klappt denn da nicht?
Alias sind doch doof. Ob ich alle löschen sollte? Ist ja inuitiver für Anpassungen, at notify watchdog und so sachen wenn man immer den "echten" Namen sieht.
Bzgl. der Sonos (EDIT:"Alte, verwirrende Namen") Thematik war es scheinbar nur ein Alias. Weiß nicht mehr ob ich die mal manuell gesetzt habe oder die ursprünglich automatisch übernommen wurden.
Enocean ohne Verschlüsselte Übertragung war auch bei der NUC Installation.
Auf Deinen Echos kannst Du aber keinen Sprache ausgeben - oder?
Zitat von: Otto123 am 27 November 2020, 22:42:53
Was klappt denn da nicht?
Die Testsprachausgabe ging gestern nicht. Heute gings. Geändert hab ich nichts nur den "alten" Server heruntergefahren und evtl. FHEM auf dem neuen nochmal neugestartet.
Zitat von: Sammy51 am 27 November 2020, 22:44:07
Alias sind doch doof. Ob ich alle löschen sollte? Ist ja inuitiver für Anpassungen, at notify watchdog und so sachen wenn man immer den "echten" Namen sieht.
Naja habe ja nicht ich gemacht, sondern macht das echodevice-Modul automatisch...
Wenn man umbenennt weiß ich nicht, ob das noch funktioniert (vermutlich ja).
Aber wenn man dann wieder "autocreate devices" ausführt, dann werden die "ID-Namen" ja wider angelegt...
Für mich ist das so ok...
Zitat von: Sammy51 am 27 November 2020, 22:44:07
Auf Deinen Echos kannst Du aber keinen Sprache ausgeben - oder?
Doch.
Mit dem echodevice-Modul: https://forum.fhem.de/index.php/topic,82631.msg747482.html#msg747482
Einfach: set ECHO_XXXX speak das ist ein Test
Gruß, Joachim
Ah cool .. vor Jahren ging das zunächst nicht mit Echo Devices :)
Bzgl. Alias sind doch doof meinte ich mich selbst - nicht dich.
Mein scheinbares Sonos Problem mit den verwirrenden Namen lag nur an falschen / nicht aktualisierten alias ::)
Zitat von: Sammy51 am 28 November 2020, 20:01:56
Bzgl. Alias sind doch doof meinte ich mich selbst - nicht dich.
Ich hab's auch nicht auf mich bezogen, sondern auf: "allgemein" aliase sind doof ;)
D.h. es geht jetzt alles was du wolltest?
Gruß, Joachim
Zunächst schon - danke :-) System in umgezogen und Betriebssystem dadurch aktualisiert. Was vorher ging geht wieder :-) Ubuntu auf dem Nuc werde ich dann testweise mal "hochziehen" um Erfahrung zu sammeln ob das gelingt (ohne grafische Oberfläche könnte es ja selbst per SSH klappen vielleicht).
* Darüber hinaus hab ich eine Zeitsteuerung für den Garten bislang immer manuell zwischen "Sommer" und "Wintermodus" umgestellt durch Ein bzw. Auskommentieren in der fhem.cfg. Das ist natürlich wenig elegant und fhem.cfg soll ja offenbar besser nie editiert werden. Besser wäre sicherlihc wenn zB. der Dummy mit dem ich diese Automatik an/ausschalte ":Sommer :Winter :off" als Buttons/Stati hätte und die Steuerung dann das eine oder das andere "at" verwenden würde.
Macht das Sinn so oder gibts noch bessere Varianten? Hab erstmal die Stati erweitert und versuche nun die "at" anzupassen mit Berücksichtigung von "Sommer" und "Winter" statt bislang "on"
Internals:
FUUID 5d028802-f33f-826a-d81b-c9b19c18744db32d
NAME GT.Power.NordPool_Automation
NR 138
STATE off
TYPE dummy
READINGS:
2020-11-28 21:52:41 state off
Attributes:
alexaName Pool Automatik
alias NordPool Automode
devStateIcon on:general_an_fuer_zeit@green off:general_aus_fuer_zeit@red
icon general_an_fuer_zeit
room Garten
setList Sommer Winter on off
webCmd Sommer:Winter:on:off
* Das HM RPI Modul hab ich soeben Standardmäßig verlötet bin noch unsicher ob ich es jetzt erstmal in der Schublade lasse solange HMLAN noch funktioniert oder ob ich es als RPI Hat Modul verwende oder den USB Adapter ausmesse (3,3 V und Verlöte). Mit etwas Muße ginge das statt mit Drähten evtl. auch mit einem Reststück Lochrasterplatine die noch in einer Bastelkiste liegen sollte. Kleiner macht es das natürlich auch nicht und es wäre vermutlich ne Skizze nötig um zu schauen wie dort verbunden/unterbrochen werden muss für die korrekte Verbindung der USB/RPI Stiftleisten. Aus der Übung mit so Zeug :(. Kurze Kabel wohl doch einfacher ;-)
* Ansonsten Vorbereitet (Kabel muss noch in Schaltschrank der Garage eingeführt und verdrahtet werden) ist noch ein Z-Wave Bewegungsmelder für außen mit Helligkeitssensor davon (also nur vom Dämmerungssensor) abhängig soll die Weihnachtsbeleuchtung und sonstige Dinge draußen geschaltet werden. Bewegungsmelder + Dämmerungssensor davon dann künftig für noch zu montierende Wegbeleuchtung.
====
EDIT: Achso da wäre noch was Grundsätzliches bzgl. des nun RPI3b betriebs mit SDCard ... war da nicht noch was zu konfigurieren damit LEse/Schreibzugriffe auf die KArte reduziert werden? Oder gibt es gar empfehlenswerte Ansätze das ohne SD-Karte oder mit ergänzender SSD an USB zu lösen? (der RPI3 hat wohl nur USB2 glaube ich)?
Die Variante von Beta USer scheint auch super mit dem "alten" Thin-Client als Basis .. aber jetzt läuft ja erstmal der RPI der zu lange in der Schublade lag :)
Beste Grüße
Sammy