Closed marcelser closed 4 years ago
Da ist dann noch ein uralter Kernel installiert mit alten Kernel Modulen.
Welches OS ist installiert (cat /etc/os-release
)?
Welches apt Repository wird für den Kernel verwendet? (cat /etc/apt/sources.list.d/raspi.list
)
also /etc/os-release ist:
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
und kernel repo ist:
deb http://archive.raspberrypi.org/debian/ stretch main ui
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ stretch main ui
vielleicht auch interessant hier der output von "uname -a": Linux pidesktop 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
Nach einem Vollbackup:
sudo apt-mark unhold raspberrypi-kernel raspberrypi-kernel-headers
sudo apt install --reinstall raspberrypi-kernel raspberrypi-kernel-headers
sudo dpkg-reconfigure pivccu-modules-dkms
Wenn das ohne Fehler durchläuft, dann einen Reboot.
Danke für die rasche Rückmeldung aber ich hatte vorher schon "apt-get install raspberrypi-kernel" gemacht und das lief anscheinend durch. Es gab zwar einige warnings aber nachher lief der neue Kernel. Ich hab dann auch nicht den "sudo dpkg-reconfigure pivccu-modules-dkms" gemacht aber einen erneuten install von "piccvu3". Jetzt scheint alles ok zu sein, zumindest schreibt piccvu-info:
piVCCU version: 3.47.22-32
Kernel modules: Available
Raw UART dev: Available
Rasp.Pi3 UART: Assigned to GPIO pins
HMRF Hardware: HM-MOD-RPI-PCB
HMIP Hardware: HM-MOD-RPI-PCB
Board serial: OEQ0606343
Radio MAC: 0x59d5a9
SGTIN: 3014F711A061A7D70992A887
State: RUNNING
PID: 2983
CPU use: 0.63 seconds
BlkIO use: 1.03 MiB
Memory use: 3.88 MiB
KMem use: 1.69 MiB
Link: vethpivccu
TX bytes: 2.79 KiB
RX bytes: 3.05 KiB
Total bytes: 5.85 KiB
handle ich mir trotzdem probleme ein wenn ich kein reconfigure von pivccu-modules-dkms gemacht habe?
Ausserdem hoffe ich dass ich das backup problemlos einspielen kann, es gab ja grad letzthin jemand bei dem das nicht ging der auch pivccu3 auf einem alten yahm system installiert hat.
Bei einem Reboot wird automatisch geprüft, ob die Kernel Module für den grade aktiven Kernel vorhanden sind und falls nicht, werden diese erstellt. Wenn sie aber bereits vorhanden sind, werden sie nicht neu erstellt. Der reconfigure sorgt dafür, dass die Kernel Module in jedem Fall nochmal neu erstellt werden (für den aktuell aktiven Kernel). Beim Einspielen des Backups: Mir sind keine grundlegeneden Probleme bekannt und mir ist nicht klar, auf welches Problem du abzielst. Allerdings muss man grade in Bezug auf Addons einiges beachten, wenn man von CCU2 auf CCU3 wechselt (unabhängig ob wir da jetzt von Original CCU reden oder von piVCCU). Beim Wechsel von YAHM kommt dazu, dass in YAHM die Configs in einer Art verändert wurden, welche nicht kompatibel mit einer Original CCU sind, daher muss man die Configs wieder sauber machen, siehe Doku.
Soweit so gut. Ich hab jetzt die piVCCU3 am laufen und das Backup eingspielt und configs entsprechend angepasst nach dem einspielen das Backups wie in der Readme beschrieben. Soweit scheint alles zu laufen.
Ich hab dann auch die WLAN Einstelllungen wie beschrieben (https://github.com/alexreinert/piVCCU/blob/master/docs/setup/wlan.md) gemacht und kann auf die Web Oberfläche über WLAN zugreifen. Auch die iptables regeln scheinen erfolgreicht erstellt worden zu sein zumidnest wenn man via netstat -t nat -L schaut sieht iptables wie folgt aus:
root@pidesktop:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:http to:192.168.20.2:80
DNAT tcp -- anywhere anywhere tcp dpt:1999 to:192.168.20.2:1999
DNAT tcp -- anywhere anywhere tcp dpt:cisco-sccp to:192.168.20.2:2000
DNAT tcp -- anywhere anywhere tcp dpt:2001 to:192.168.20.2:2001
DNAT tcp -- anywhere anywhere tcp dpt:2002 to:192.168.20.2:2002
DNAT tcp -- anywhere anywhere tcp dpt:search to:192.168.20.2:2010
DNAT tcp -- anywhere anywhere tcp dpt:8181 to:192.168.20.2:8181
DNAT tcp -- anywhere anywhere tcp dpt:8183 to:192.168.20.2:8183
DNAT tcp -- anywhere anywhere tcp dpt:8700 to:192.168.20.2:8700
DNAT tcp -- anywhere anywhere tcp dpt:8701 to:192.168.20.2:8701
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
Wo ich im Moment aber noch wie der Esel am Berg stehe ist dass offenbar unter der piVCCU3 ip keine anderen Daemons laufen (zumindest sehe ich keine Listening Ports im Netstat) und man kann sich auch nicht verbinden weder von aussen über das WLAN interface noch lokal auf dem RPI über telnet z.B. auf Port 2000 oder 2001. Ich krieg nur unendlich die Meldung "Trying 192.168.20.2...". Ich hab keine Ahnung was da los ist aber so ohne die ganzen daemons funktioniert die piVCCU3 nicht richtig denn ich möchte mich eigentlich via OpenHAB Homematic Bridge drauf verbinden (das ging vorher unter YAHM problemlos auch über das WLAN interface und die iptables Einträge sahen zu 99% gleich aus).
hast Du irgendeine Ahnung wieso die ganzen Ports tot sind und nur Port 80 funktioniert? Muss man die Daemons neuerdings irgendwo in der CCU aktivieren?
hier noch ein paar netzwerk infos:
root@pidesktop:~# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255
inet6 fe80::2025:60ff:fec8:1fcd prefixlen 64 scopeid 0x20<link>
ether fe:da:09:b6:e6:13 txqueuelen 1000 (Ethernet)
RX packets 3371 bytes 2450314 (2.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4407 bytes 1269795 (1.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:19:74:76 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 10 bytes 626 (626.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 626 (626.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethpivccu: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::fcda:9ff:feb6:e613 prefixlen 64 scopeid 0x20<link>
ether fe:da:09:b6:e6:13 txqueuelen 1000 (Ethernet)
RX packets 3371 bytes 2497508 (2.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4358 bytes 1266277 (1.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.64 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::ba27:ebff:fe4c:2123 prefixlen 64 scopeid 0x20<link>
inet6 fda6:7fef:b222:0:ba27:ebff:fe4c:2123 prefixlen 64 scopeid 0x0<global>
ether b8:27:eb:4c:21:23 txqueuelen 1000 (Ethernet)
RX packets 5859 bytes 1412464 (1.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4305 bytes 2696038 (2.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@pidesktop:~# cat /var/lib/piVCCU3/userfs/etc/config/netconfig
HOSTNAME=ccu3-webui
MODE=MANUAL
CURRENT_IP=192.168.20.2
CURRENT_NETMASK=255.255.255.0
CURRENT_GATEWAY=192.168.20.1
CURRENT_NAMESERVER1=8.8.4.4
CURRENT_NAMESERVER2=8.8.8.8
IP=192.168.20.2
NETMASK=255.255.255.0
GATEWAY=192.168.20.1
NAMESERVER1=8.8.4.4
NAMESERVER2=8.8.8.8
CRYPT=0
Bin Dir wirklich dankbar für jedwede Hilfe warum auf den Ports keine Daemons laufen
Fangen wir lieber vorne an: Kannst du vom Pi aus den Container anpingen?
Ja ein Ping auf 192.168.20.2 funktioniert genauso wie "telnet 192.168.20.2 80" und das Webinterface läuft auch von WLAN0 aus über die BR0 sauber zum container. Was nicht geht ist z.B. "telnet 192.168.20.2 2000" da hängt er unendlich. Wie weiter?
sudo pivccu-info
sudo pivccu-attach ifconfig
sudo pivccu-attach netstat -l
root@pidesktop:~# sudo pivccu-info
piVCCU version: 3.47.22-32
Kernel modules: Available
Raw UART dev: Available
Rasp.Pi3 UART: Assigned to GPIO pins
HMRF Hardware: HM-MOD-RPI-PCB
HMIP Hardware: HM-MOD-RPI-PCB
Board serial: OEQ0606343
Radio MAC: 0x59d5a9
SGTIN: 3014F711A061A7D70992A887
State: RUNNING
PID: 894
IP: 192.168.20.2
CPU use: 139.95 seconds
BlkIO use: 56.47 MiB
Memory use: 152.25 MiB
KMem use: 4.83 MiB
Link: vethpivccu
TX bytes: 2.68 MiB
RX bytes: 3.26 MiB
Total bytes: 5.95 MiB
root@pidesktop:~# sudo pivccu-attach ifconfig
eth0 Link encap:Ethernet HWaddr 2A:AD:6A:41:04:EC
inet addr:192.168.20.2 Bcast:192.168.20.255 Mask:255.255.255.0
inet6 addr: fe80::28ad:6aff:fe41:4ec/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11161 errors:0 dropped:0 overruns:0 frame:0
TX packets:7470 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3431850 (3.2 MiB) TX bytes:2821728 (2.6 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:50859 errors:0 dropped:0 overruns:0 frame:0
TX packets:50859 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7021173 (6.6 MiB) TX bytes:7021173 (6.6 MiB)
root@pidesktop:~# sudo pivccu-attach netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:31999 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:32001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:49292 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9292 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:41999 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1999 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:42000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:www 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:42001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:48181 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8181 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8183 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:42010 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2010 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:https 0.0.0.0:* LISTEN
tcp 0 0 :::32010 :::* LISTEN
tcp 0 0 :::49292 :::* LISTEN
tcp 0 0 :::9292 :::* LISTEN
tcp 0 0 :::9293 :::* LISTEN
tcp 0 0 :::41999 :::* LISTEN
tcp 0 0 :::1999 :::* LISTEN
tcp 0 0 :::42000 :::* LISTEN
tcp 0 0 :::2000 :::* LISTEN
tcp 0 0 :::www :::* LISTEN
tcp 0 0 :::42001 :::* LISTEN
tcp 0 0 :::2001 :::* LISTEN
tcp 0 0 :::48181 :::* LISTEN
tcp 0 0 :::8181 :::* LISTEN
tcp 0 0 :::42010 :::* LISTEN
tcp 0 0 :::2010 :::* LISTEN
tcp 0 0 :::https :::* LISTEN
tcp 0 0 :::39292 :::* LISTEN
udp 0 0 0.0.0.0:35587 0.0.0.0:*
udp 0 0 0.0.0.0:1900 0.0.0.0:*
udp 0 0 0.0.0.0:43438 0.0.0.0:*
udp 0 0 0.0.0.0:43439 0.0.0.0:*
udp 0 0 localhost:1998 0.0.0.0:*
udp 0 0 localhost:8182 0.0.0.0:*
udp 0 0 192.168.20.2:ntp 0.0.0.0:*
udp 0 0 localhost:ntp 0.0.0.0:*
udp 0 0 0.0.0.0:ntp 0.0.0.0:*
udp 0 0 :::39605 :::*
udp 0 0 :::52273 :::*
udp 0 0 fe80::28ad:6aff:fe41:4ec:ntp :::*
udp 0 0 ::1:ntp :::*
udp 0 0 :::ntp :::*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 15541 /tmp/eq3-services.uds
unix 2 [ ACC ] STREAM LISTENING 13620 /var/run/dbus/system_bus_socket
Gut, also sieht man, dass die Daemons doch alle laufen. Kann es sein, dass du die Firewall innerhalb der CCU aktiviert hast?
Ich wüsste nicht mal wie aber ich kann mal suchen
Wenn du von einer 2.31 kamst, hat er das beim ersten Zugriff auf die WebUI nach Einspielen des Backups abgefragt. Später kommt man da über die Systemsteuerung dran.
Er hat mich nur gewarnt ich soll keine Port Forwards verwenden. Aber es sieht so aus als ob die Firewall aktiv wäre. Steht bei RPC & Remote Zugriff auf "Kein Zugriff" und bei den IP Adressen nicht diejenigen die ich brauche. Aber obwohl ich als Admin eingeloggt bin kann ich dort nichts ändern. Egal was ich einstelle wenn ich die Einstellungen speichere und den wieder auf Firewall klicke zeigt er mir weiterhin die alten Daten an. Was ist denn das jetzt wieder? Interessant finde ich auch dass im Eingabefeld für die IP Adressen ne IPv6 Adresse drin steht, die CCU3 aber gar keine IPv6 akzeptiert
Kann es daran liegen dass kein Kennwort gesetzt ist?
Ich weiß, dass der Dialog früher etwas fragil auf Eingaben reagiert hat, keine Ahnung ob eQ-3 das mittlerweile verbessert hat. An einem fehlenden Passwort liegt es auf jeden Fall nicht. Kannst du das vielleicht einfach mal rein über das Dropdown umstellen?
keine Chance. Er akzeptiert keine Eingaben. Dass Problem ist dass ich die IPv6 löschen muss. Sonst kann ich gar nicht speichern
pivccu-attach ls -la /etc/config/firewall.conf
pivccu-attach cat /etc/config/firewall.conf
pivccu-attach ls -la /tmp/
Hmm spannend, die firewall.conf gibts nicht.
root@pidesktop:~# pivccu-attach ls -la /etc/config/firewall.conf
ls: /etc/config/firewall.conf: No such file or directory
root@pidesktop:~# pivccu-attach cat /etc/config/firewall.conf
cat: can't open '/etc/config/firewall.conf': No such file or directory
root@pidesktop:~# pivccu-attach ls -la /tmp/
total 4
drwxrwxrwt 8 root root 180 Dec 18 13:57 .
drwxr-xr-x 23 root root 4096 Dec 18 11:40 ..
drwxr-xr-x 4 root root 80 Dec 18 11:41 .vertx
drwxr-xr-x 2 avahi avahi 40 Dec 18 11:40 avahi-autoipd
drwxr-xr-x 2 root root 40 Dec 18 11:40 dbus
srwxr-xr-x 1 root root 0 Dec 18 11:41 eq3-services.uds
drwxr-xr-x 2 root root 100 Dec 18 14:11 event
drwxr-xr-x 2 root root 60 Dec 18 11:41 hsperfdata_root
drwxr-xr-x 2 root root 60 Dec 18 11:41 libNRJavaSerialv5_root_0
Was mir auch auffällt ist dass es ein CCU Update gibt: CCU-Update: | Firmware 2.49.18 ist verfügbar
sudo pivccu-attach ls -la /etc
sudo pivccu-attach ls -la /etc/config
sudo pivccu-attach mount
Das CCU Update gibt es seit dieser Woche, aber ich habe die Version noch nicht im stable APT Repository freigegeben, sondern warte damit immer ca. 2 Wochen ab, falls irgendwelche Issue in der Firmware auftauchen und ziemindest die letzten Versionen haben mir da recht gegeben, weil in jeder Major irgendein größeres Problem von eQ-3 versteckt oder offensichtlich war. Gemäß der Philosphie von piVCCU ändere ich aber so wenig wie möglich in der Firmware, so das der Update-Check gegen die Original Firmware läuft statt gegen die aktuelle stable piVCCU Version.
root@pidesktop:~# sudo pivccu-attach ls -la /etc
total 220
drwxr-xr-x 20 root root 4096 Dec 18 09:32 .
drwxr-xr-x 23 root root 4096 Dec 18 11:40 ..
-rw-r--r-- 1 root root 34 Apr 23 2019 HMServer.conf
-rw-r--r-- 1 root root 27 Apr 23 2019 SnapshotExclude.txt
lrwxrwxrwx 1 root root 9 Apr 23 2019 TZ -> config/TZ
drwxr-xr-x 2 root root 4096 Dec 18 09:32 avahi
lrwxrwxrwx 1 root root 23 Oct 10 15:53 config -> ../usr/local/etc/config
drwxr-xr-x 3 root root 4096 Dec 18 09:32 config_templates
-rw-r--r-- 1 root root 1460 Oct 10 14:00 crRFD.conf
-rw-r--r-- 1 root root 209 Oct 10 14:00 crontab.root
drwxr-xr-x 3 root root 4096 Dec 18 09:32 dbus-1
-rw-r--r-- 1 root root 2823 Apr 23 2019 de.kmap
lrwxrwxrwx 1 root root 14 Apr 23 2019 default -> config/default
-rw-r--r-- 1 root root 2823 Apr 23 2019 en.kmap
-rw-r--r-- 1 root root 289 Apr 23 2019 eq3services.ports.tcl
lrwxrwxrwx 1 root root 15 Oct 10 15:53 firmware -> ../lib/firmware
drwxr-xr-x 3 root root 4096 Dec 18 09:32 fonts
-rw-r--r-- 1 root root 143 Oct 23 10:39 fstab
-rw-r--r-- 1 root root 365 Oct 10 15:54 group
lrwxrwxrwx 1 root root 17 Apr 23 2019 hostname -> /var/etc/hostname
lrwxrwxrwx 1 root root 14 Apr 23 2019 hosts -> /var/etc/hosts
-rw-r--r-- 1 root root 6 Apr 23 2019 hs485d.port
drwxr-xr-x 2 root root 4096 Dec 18 09:32 ifplugd
drwxr-xr-x 2 root root 4096 Dec 18 09:32 init.d
-rw-r--r-- 1 root root 1060 Oct 23 10:39 inittab
-rw-r--r-- 1 root root 1180 Oct 10 14:28 inputrc
-rw-r--r-- 1 root root 16 Oct 10 15:53 issue
drwxr-xr-x 2 root root 4096 Dec 18 09:32 libnl
drwxr-xr-x 3 root root 4096 Dec 18 09:32 lighttpd
lrwxrwxrwx 1 root root 16 Oct 10 15:53 localtime -> config/localtime
-rw-r--r-- 1 root root 26 Apr 23 2019 logrotate.conf
drwxr-xr-x 2 root root 4096 Dec 18 09:32 logrotate.d
-rw-r--r-- 1 root root 812 Oct 10 14:36 mke2fs.conf
lrwxrwxrwx 1 root root 19 Oct 25 2018 mtab -> ../proc/self/mounts
-rw-r--r-- 1 root root 398 Apr 23 2019 multimacd.conf
drwxr-xr-x 6 root root 4096 Dec 18 09:32 network
-rw-r--r-- 1 root root 230 Oct 10 15:53 nsswitch.conf
-rw-r--r-- 1 root root 200 Apr 23 2019 ntp.conf
lrwxrwxrwx 1 root root 21 Oct 10 15:53 os-release -> ../usr/lib/os-release
-rw-r--r-- 1 root root 484 Oct 10 15:54 passwd
drwxr-xr-x 2 root root 4096 Dec 18 09:32 piVCCU3
-rw-r--r-- 1 root root 533 Apr 23 2019 profile
drwxr-xr-x 2 root root 4096 Dec 18 09:32 profile.d
-rw-r--r-- 1 root root 2744 Oct 25 2018 protocols
lrwxrwxrwx 1 root root 18 Apr 23 2019 random-seed -> config/random-seed
-rw-r--r-- 1 root root 3435 Apr 23 2019 rega.conf
-rw-r--r-- 1 root root 5 Apr 23 2019 rega_http.port
lrwxrwxrwx 1 root root 22 Oct 10 15:53 resolv.conf -> ../var/etc/resolv.conf
-rw-r--r-- 1 root root 6 Apr 23 2019 rfd.port
-rw-r--r-- 1 root root 10873 Oct 25 2018 services
lrwxrwxrwx 1 root root 13 Oct 10 15:53 shadow -> config/shadow
-rw-r--r-- 1 root root 8 Oct 10 15:53 shells
-rw-r--r-- 1 root root 6699 Oct 10 15:11 smartd.conf
drwxr-xr-x 2 root root 4096 Oct 10 15:11 smartd_warning.d
-rwxr-xr-x 1 root root 5847 Oct 10 15:11 smartd_warning.sh
drwxr-xr-x 2 root root 4096 Dec 18 09:32 snmp
drwxr-xr-x 2 root root 4096 Dec 18 09:32 ssh
drwxr-xr-x 6 root root 4096 Dec 18 09:32 ssl
lrwxrwxrwx 1 root root 15 Oct 10 15:53 timezone -> config/timezone
drwxr-xr-x 4 root root 4096 Dec 18 09:32 udev
drwxr-xr-x 4 root root 4096 Dec 18 09:32 usbmount
-rw-r--r-- 1 root root 4945 Oct 10 14:43 wgetrc
-rw-r--r-- 1 root root 296 Apr 23 2019 xinetd.conf
root@pidesktop:~# sudo pivccu-attach ls -la /etc/config
lrwxrwxrwx 1 root root 23 Oct 10 15:53 /etc/config -> ../usr/local/etc/config
root@pidesktop:~# sudo pivccu-attach mount
/dev/root on / type ext4 (rw,noatime)
none on /dev type tmpfs (rw,relatime,size=492k,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
proc on /proc/sys/net type proc (rw,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
tmpfs on /tmp type tmpfs (rw,relatime)
/dev/root on /var type ext4 (rw,noatime)
/dev/root on /media type ext4 (rw,noatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=16384k)
/dev/root on /usr/local type ext4 (rw,noatime)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
sudo pivccu-attach ls -la /usr/local/etc/config
root@pidesktop:~# sudo pivccu-attach ls -la /usr/local/etc/config
total 1248
drwxrwxr-x 11 root root 4096 Dec 18 14:41 .
drwxr-xr-x 4 root root 4096 Dec 18 09:51 ..
-rwxr-xr-x 1 root root 416 Dec 18 10:09 InterfacesList.xml
-rw-r--r-- 1 root root 45 Apr 23 2019 TZ
drwxr-xr-x 5 root root 4096 Dec 18 10:11 addons
drwxr-xr-x 3 root root 4096 Mar 11 2018 crRFD
-rw-r--r-- 1 root root 0 Mar 11 2018 crypttool.cfg
-rw-r--r-- 1 root root 106 Mar 13 2018 energyPrice
drwxr-xr-x 3 root root 4096 Mar 13 2018 eshlight
-rw-r--r-- 1 root root 491 Dec 18 10:11 hm_addons.cfg
-rw-r--r-- 1 root root 78 Mar 11 2018 hmip_address.conf
-rw-r--r-- 1 root root 585330 Dec 18 14:41 homematic.regadom
-rw-r--r-- 1 root root 585330 Dec 18 14:11 homematic.regadom.bak
drwxr-xr-x 2 root root 4096 Mar 11 2018 hs485d
-rw-r--r-- 1 root root 42 Mar 13 2018 ids
lrwxrwxrwx 1 root root 33 Dec 18 11:40 localtime -> /usr/share/zoneinfo/Europe/Berlin
-rw-r--r-- 1 root root 1220 Oct 10 15:45 log4j.xml
drwxr-xr-x 2 root root 4096 Mar 13 2018 measurement
-rw-r--r-- 1 root root 278 Dec 18 11:40 netconfig
-rw-r--r-- 1 root root 31 Mar 11 2018 ntpclient
drwxr-xr-x 2 root root 4096 Dec 18 10:11 rc.d
drwxr-xr-x 2 root root 4096 Dec 18 11:41 rfd
-rw-r--r-- 1 root root 710 Dec 18 11:41 rfd.conf
-rw-r--r-- 1 root root 0 Dec 18 10:09 securitySettingsMigrated
-rw-r--r-- 1 root root 2949 Dec 18 10:09 server.pem
-rw-r--r-- 1 root root 348 Apr 23 2019 shadow
drwxr-xr-x 2 root root 4096 Dec 18 10:09 snmp
-rw-r--r-- 1 root root 66 Mar 11 2018 syslog
-rw-r--r-- 1 root root 75 Mar 11 2018 time.conf
-rw-r--r-- 1 root root 14 Dec 18 11:40 timezone
-rw-r--r-- 1 root root 0 Dec 18 10:11 userAckSecurityHint
drwxr-xr-x 2 root root 4096 Mar 11 2018 userprofiles
Blöde Frage: Deinen Browsercache hast du aber schon geleert, bevor du auf die WebUI gegangen bist (idealerweise auch mit Strg+F5 nochmal wirklich frisch laden)
Sorry, musste vorhin erst weg. Aber ähm nö, den Browser Cache hab ich glaubs seit gefühlt 2 Jahren nicht mehr gelöscht egal für welche Web Oberfläche auch immer und ich entwickle selbst berufsmässig web applikationen für eine Firma mit Springboot & NodeJS und React aber selbst da gibts das eigentlich so gut wie nie, wir können unseren Kunden ja auch nicht sagen nach einem release Sie müssen mal den Browser Cache löschen.
Da hat eQ-3 offenbar ziemlichen Mist gebaut denn tatsählich nach dem löschen des Browser Caches kommt plötzlich auch der Wizard der mich nach den Sichheitseinstellungen bezügl. Ports & RPC fragt und mich zwingt ein Admin Passwort zu setzen, der war vorher schlicht inexistent. Wär mir wie gesagt nicht im Traum im den Sinn gekommen und wäre evtl. ein Punkt fürs README dass man den Browser Cache löschen muss beim upgrade von piVCCU zumindest von V2 auf V3 oder von YAHM auf V3.
btw bevor ichs vergesse. Vielen Dank für Deinen Support. Die Verbindung zu OpenHAB2 läuft jetzt wieder wie geschmiert. Er hat jetzt sogar auch noch den HM IP Gateway gefunden.
Den Browsercache soll man bei jedem Update der CCU Version löschen. War schon immer so. Dass man Webentwicklung auch intelligenter machen kann, kommt nur sehr schleppend in Ostfriesland an. :-(
Tja kann man nix machen bei EQ-3. Ich würds trotzdem noch ins Readme reinschreiben denn Du weisst das natürlich denn Du hast Dich ja auch eingehend damit beschäftigt. Aber Leute wie ich die selten bis nie die CCU benutzen wissen das leider nicht zumal ich die HomeMatic Geräte ja eh über RPC steuere und nicht in der CCU direkt. Ich brauch die CCU eigentlich nur um Geräte anzulernen und für die Kommunikation mit denselbigen sowie Bereitstellung der RPC Dienste. Der Rest läuft eh über OpenHAB2 dementsprechend wenig Erfahrung hab ich in Sachen CCU upgrading.
Ich würds reinschreiben denn es mag mehr Leute geben mit wenig Erfahrung und dann haste irgendwann den nächsten Thread und fängst wieder von vorne an mit der Fehlersuche. Aber das musst Du natürlich selber wissen.
Hallo,
Hab gerade die Schritte für YAHM zu piVCCU3 migration aus dem README.md durchgeführt und soweit lief auch alles gut bis zur installation von piVCCU3, am schluss kriege ich folgende Fehlermeldung.
wenn ich in /sys/class/raw-uart rein schaue gibts dort auch kein reset_radio_module.
Das Modul lief vorher unter YAHM mit folgenden Angaben:
Da ich das ganze von einer USB Bootable SSD laufen lasse lässt sich auch nicht so einfach ein frisches piVCCU3 image nutzen, es wäre toll wenn Du ne Ahnung hast was hier los ist.
Danke schon im voraus.
Gruss
Marc