Hallo Zusammen,
ich wollte heute nach sehr langer Zeit die Homebridge aktualisieren:
root@cubietruck:~# npm -g outdated
Package Current Wanted Latest Location
homebridge 0.4.16 0.4.20 0.4.20 /usr/local/lib > homebridge
homebridge-fhem 0.2.71 0.3.7 0.3.7 /usr/local/lib > homebridge-fhem
npm 2.15.9 4.5.0 4.5.0 /usr/local/lib > npm
Über den Wiki Eintrag habe ich alles gefunden, was dafür nötig war.
Zunächst die Homebridge und Homebridge-fhem:
root@cubietruck:~# npm -g update homebridge
|
> curve25519-n2@1.1.3 install /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519-n2
> node-gyp rebuild
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/4.5.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519-n2/.node-gyp"
make: Entering directory '/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519-n2/build'
CXX(target) Release/obj.target/curve/node_curve.o
SOLINK_MODULE(target) Release/obj.target/curve.node
COPY Release/curve.node
make: Leaving directory '/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519-n2/build'
> mdns@2.3.3 install /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/mdns
> node-gyp rebuild
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/4.5.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/mdns/.node-gyp"
make: Entering directory '/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/mdns/build'
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_sd.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_browse.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_enumerate_domains.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_get_addr_info.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_process_result.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_ref.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_ref_deallocate.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_ref_sock_fd.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_register.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_resolve.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_update_record.o
CXX(target) Release/obj.target/dns_sd_bindings/src/mdns_utils.o
CXX(target) Release/obj.target/dns_sd_bindings/src/network_interface.o
CXX(target) Release/obj.target/dns_sd_bindings/src/socket_watcher.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_ref.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_create.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_deallocate.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_set_value.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_get_length.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_buffer_to_object.o
SOLINK_MODULE(target) Release/obj.target/dns_sd_bindings.node
COPY Release/dns_sd_bindings.node
make: Leaving directory '/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/mdns/build'
> ed25519@0.0.4 install /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/ed25519
> node-gyp rebuild
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/4.5.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/ed25519/.node-gyp"
make: Entering directory '/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/ed25519/build'
CC(target) Release/obj.target/ed25519/src/ed25519/keypair.o
CC(target) Release/obj.target/ed25519/src/ed25519/sign.o
CC(target) Release/obj.target/ed25519/src/ed25519/open.o
CC(target) Release/obj.target/ed25519/src/ed25519/crypto_verify_32.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_double_scalarmult.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_frombytes.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_scalarmult_base.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_precomp_0.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p2_0.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p2_dbl.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p3_0.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p3_dbl.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p3_to_p2.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p3_to_cached.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p3_tobytes.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_madd.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_add.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_msub.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_sub.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p1p1_to_p3.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_p1p1_to_p2.o
CC(target) Release/obj.target/ed25519/src/ed25519/ge_tobytes.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_0.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_1.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_cmov.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_copy.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_neg.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_add.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_sub.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_mul.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_sq.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_sq2.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_invert.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_tobytes.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_isnegative.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_isnonzero.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_frombytes.o
CC(target) Release/obj.target/ed25519/src/ed25519/fe_pow22523.o
CC(target) Release/obj.target/ed25519/src/ed25519/sc_reduce.o
CC(target) Release/obj.target/ed25519/src/ed25519/sc_muladd.o
CXX(target) Release/obj.target/ed25519/src/ed25519.o
SOLINK_MODULE(target) Release/obj.target/ed25519.node
COPY Release/ed25519.node
make: Leaving directory '/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/ed25519/build'
/usr/local/bin/homebridge -> /usr/local/lib/node_modules/homebridge/bin/homebridge
homebridge@0.4.20 /usr/local/lib/node_modules/homebridge
├── semver@5.0.3
├── commander@2.8.1 (graceful-readlink@1.0.1)
├── chalk@1.1.3 (escape-string-regexp@1.0.5, ansi-styles@2.2.1, supports-color@2.0.0, has-ansi@2.0.0, strip-ansi@3.0.1)
├── node-persist@0.0.8 (q@1.1.2, mkdirp@0.3.5)
└── hap-nodejs@0.4.25 (buffer-shims@1.0.0, ip@1.1.5, fast-srp-hap@1.0.1, debug@2.6.6, node-persist@0.0.11, curve25519-n2@1.1.3, mdns@2.3.3, ed25519@0.0.4)
root@cubietruck:~# npm -g update homebridge-fhem
homebridge-fhem@0.3.7 /usr/local/lib/node_modules/homebridge-fhem
└── request@2.81.0 (aws-sign2@0.6.0, forever-agent@0.6.1, oauth-sign@0.8.2, is-typedarray@1.0.0, tunnel-agent@0.6.0, stringstream@0.0.5, caseless@0.12.0, aws4@1.6.0, isstream@0.1.2, safe-buffer@5.0.1, json-stringify-safe@5.0.1, extend@3.0.1, performance-now@0.2.0, uuid@3.0.1, qs@6.4.0, combined-stream@1.0.5, tough-cookie@2.3.2, mime-types@2.1.15, form-data@2.1.4, hawk@3.1.3, http-signature@1.1.1, har-validator@4.2.1)
NMP bliebt nach den vorhergehenden über,
root@cubietruck:~# npm -g outdated
Package Current Wanted Latest Location
npm 2.15.9 4.5.0 4.5.0 /usr/local/lib > npm
sodass ich auch dieses aktuallisiert habe:
root@cubietruck:~# npm -g update
/usr/local/bin/npm -> /usr/local/lib/node_modules/npm/bin/npm-cli.js
npm@4.5.0 /usr/local/lib/node_modules/npm
root@cubietruck:~# npm -g outdated
Package Current Wanted Latest Location
npm 4.5.0 4.6.1 4.5.0
Danach habe ich meinen Cubietruck einmal neugestartet, womit auch die Probleme begangen. Meine FHEM startet zwar und läuft auch offenbar die ganze Zeit, jedoch lässt sich die GUI nicht mehr öffnen. Ansonsten habe ich nichts verändert. Kann sich jemand dieses Verhalten erklären und mir bei der Lösung helfen?
Sowohl Fhem als auch Homebridge laufen auf meine Cubietruck mit aktuellem ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 4.10.12-sunxi.
Fhem nutze ich mit configDB und DBLog.
Anbei noch ein Log Auszug des Startens von FHEM:
2017.05.13 18:34:07 2: Perfmon: ready to watch out for delays greater than one second
2017.05.13 18:34:08 3: telnetPort: port 7072 opened
2017.05.13 18:34:08 3: WEB: port 8083 opened
2017.05.13 18:34:09 3: WEBphone: port 8084 opened
2017.05.13 18:34:09 3: WEBtablet: port 8085 opened
2017.05.13 18:34:29 2: eventTypes: loaded 5414 events from ./log/eventTypes.txt
2017.05.13 18:34:29 3: Opening nanoCUL868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4035XBY-if00-port0
2017.05.13 18:34:29 3: Setting nanoCUL868 serial parameters to 38400,8,N,1
2017.05.13 18:34:32 3: nanoCUL868: Possible commands: BCFiAZEGMKUYRTVWXefltx
2017.05.13 18:34:32 3: nanoCUL868 device opened
2017.05.13 18:34:32 2: Switched nanoCUL868 rfmode to MAX
2017.05.13 18:34:32 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2017.05.13 18:34:35 3: Opening nanoCUL433 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4035XGY-if00-port0
2017.05.13 18:34:35 3: Setting nanoCUL433 serial parameters to 38400,8,N,1
2017.05.13 18:34:38 3: nanoCUL433: Possible commands: BCFiAGMKUYRTVWXefLltx
2017.05.13 18:34:38 3: nanoCUL433 device opened
2017.05.13 18:34:38 1: PERL WARNING: "my" variable $host masks earlier declaration in same scope at ./FHEM/30_MilightBridge.pm line 72.
2017.05.13 18:34:42 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
2017.05.13 18:34:42 3: Opening nanoCUL868hm device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600CZUB-if00-port0
2017.05.13 18:34:42 3: Setting nanoCUL868hm serial parameters to 38400,8,N,1
2017.05.13 18:34:45 3: nanoCUL868hm: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2017.05.13 18:34:45 3: nanoCUL868hm device opened
2017.05.13 18:34:45 2: Switched nanoCUL868hm rfmode to HomeMatic
2017.05.13 18:34:46 3: WifiLight: requested bridge bridge-V3 at 192.168.188.32 already in use by Farbkugel, copy llCmdQueue
2017.05.13 18:34:46 1: HMLAN_Parse: hmusb new condition disconnected
2017.05.13 18:34:46 3: Opening hmusb device 127.0.0.1:1234
2017.05.13 18:34:46 1: HMLAN_Parse: hmusb new condition init
2017.05.13 18:34:46 3: hmusb device opened
2017.05.13 18:34:47 3: DbLog DBLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2017.05.13 18:34:47 3: DbLog DBLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.05.13 18:34:47 3: WifiLight: requested bridge bridge-V3 at 192.168.188.32 already in use by Farbkugel, copy llCmdQueue
2017.05.13 18:34:47 3: WifiLight: requested bridge bridge-V3 at 192.168.188.32 already in use by SZ.Ledstripe.Schrank, copy llCmdQueue
2017.05.13 18:34:51 3: Departure_Define (myDeparture) - defined with interval 90 (sec)
2017.05.13 18:34:52 3: DLCD LCDD has been defined
2017.05.13 18:34:57 3: DLCD LCDD: Line1 (22) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line1: attr dlcdLine1 %time1%
2017.05.13 18:34:57 3: DLCD LCDD: Line2 (22) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line2: attr dlcdLine2 %time1%
2017.05.13 18:34:57 3: DLCD LCDD: Line3 (22) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line3: attr dlcdLine3 %time1%
2017.05.13 18:34:57 3: DLCD LCDD: Line4 (22) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line4: attr dlcdLine4 %time1%
2017.05.13 18:34:57 3: DLCD LCDD: Line2 (24) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line2: attr dlcdVal1 unreadable
2017.05.13 18:34:57 3: DLCD LCDD: Line3 (24) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line3: attr dlcdVal2 unreadable
2017.05.13 18:34:57 3: DLCD LCDD: Line4 (24) is longer than display (20), ignoring some data
2017.05.13 18:34:57 3: DLCD LCDD: Line4: attr dlcdVal2 unreadable
2017.05.13 18:34:59 3: Device BZ.Fenster added to ActionDetector with 002:50 time
2017.05.13 18:34:59 3: Device BZ.Klimasensor added to ActionDetector with 000:10 time
2017.05.13 18:34:59 3: Device FL.Haustur added to ActionDetector with 002:50 time
2017.05.13 18:34:59 3: Device FL.Klimasensor.Aussen added to ActionDetector with 000:10 time
2017.05.13 18:34:59 3: Device FL.Klimasensor.Innen added to ActionDetector with 000:10 time
2017.05.13 18:34:59 3: Device HM_567899 added to ActionDetector with 000:20 time
2017.05.13 18:34:59 3: Device Ku.Fenster added to ActionDetector with 002:50 time
2017.05.13 18:34:59 3: Device Ku.Klimasensor added to ActionDetector with 000:10 time
2017.05.13 18:35:00 3: Device SZ.Balkontur added to ActionDetector with 002:50 time
2017.05.13 18:35:00 3: Device SZ.Klimasensor added to ActionDetector with 000:10 time
2017.05.13 18:35:00 3: Device UM.Klimasensor added to ActionDetector with 000:10 time
2017.05.13 18:35:00 3: Device WZ.Balkontur added to ActionDetector with 002:50 time
2017.05.13 18:35:00 3: Device WZ.Fenster.links added to ActionDetector with 002:50 time
2017.05.13 18:35:00 3: Device WZ.Klimasensor added to ActionDetector with 000:10 time
2017.05.13 18:35:01 3: HarmonyHub: connected
2017.05.13 18:35:01 3: DLCD LCDD initialized
2017.05.13 18:35:05 3: Opening PRESENCE_rr_***** device 192.168.188.2:5333
2017.05.13 18:35:05 3: PRESENCE_rr_***** device opened
2017.05.13 18:35:05 3: Opening PRESENCE_rr_**** device 192.168.188.2:5333
2017.05.13 18:35:05 3: PRESENCE_rr_**** device opened
2017.05.13 18:35:05 1: usb create starting
2017.05.13 18:35:06 1: usb create end
2017.05.13 18:35:06 0: Featurelevel: 5.8
2017.05.13 18:35:06 0: Server started with 269 defined entities (fhem.pl:14252/2017-05-12 perl:5.020002 os:linux user:fhem pid:1792)
2017.05.13 18:35:07 1: Perfmon: possible freeze starting at 18:34:08, delay is 59.17
2017.05.13 18:35:07 3: telnetForBlockingFn_1494693307: port 45049 opened
2017.05.13 18:35:07 3: DbRep DBlog_DbRep - connected
Hi,
war da nicht vor Kurzem dasselbe Problem?
Hast Du alle drei Ports (8083, 8084 und 8085) ausprobiert?
Gruß,
Thorsten
Danke für deine Antwort.
Keiner der Ports funktioniert.
Hi,
hast Du mal versucht, einen ganz anderen Port zu setzen?
Ich weiß nicht, wie das mit ConfigDB geht, wenn man nicht auf FHEMWEB kommt, habe aber irgendwo gelesen, dass es da Möglichkeiten gibt.
Gruß,
Thorsten
Sind möglicherweise andere Änderungen (firewall o.ä) Schuld, die beim restart aktiv wurden?
Zitat von: Thorsten Pferdekaemper am 14 Mai 2017, 11:24:05
hast Du mal versucht, einen ganz anderen Port zu setzen?
Ich weiß nicht, wie das mit ConfigDB geht, wenn man nicht auf FHEMWEB kommt, habe aber irgendwo gelesen, dass es da Möglichkeiten gibt.
Nein, die Standardports habe ich nicht verändert. Ich habe aber mit dieser Anleitung
https://forum.fhem.de/index.php/topic,46538.msg382805.html#msg382805 (https://forum.fhem.de/index.php/topic,46538.msg382805.html#msg382805)
versucht, ältere Konfiguration meines FHEM zu laden. Die minimal Konfiguration lässt sich aktivieren und auch ohne Probleme über den Browser aufrufen. Sämtliche meiner Konfigurationen hingehen lassen sich nicht starten, unabhängig davon, ob ich eine Version von gestern, von vor einer Woche oder sechs Monaten lade. Dabei hat bis vor dem Update der Homebridge alles funktioniert. ???
Zitat von: KernSani am 14 Mai 2017, 11:34:48
Sind möglicherweise andere Änderungen (firewall o.ä) Schuld, die beim restart aktiv wurden?
Daran habe ich zumindest bewusst nichts verändert.
Läuft die Homebridge denn? Was passiert, wenn du den Homebridge Service beendest?
Zitat von: Spezialtrick am 14 Mai 2017, 11:48:23
Nein, die Standardports habe ich nicht verändert.
Na dann ändere sie halt mal...
Gruß,
Thorsten
Zitat von: KernSani am 14 Mai 2017, 11:56:21
Läuft die Homebridge denn? Was passiert, wenn du den Homebridge Service beendest?
Ich meine, dass sie nicht korrekt läuft:
fhem@cubietruck:~$ sudo service homebridge status
● homebridge.service - LSB: Start daemon at boot time for homebridge
Loaded: loaded (/etc/init.d/homebridge)
Active: active (exited) since Sun 2017-05-14 21:03:05 CEST; 1s ago
Process: 1922 ExecStop=/etc/init.d/homebridge stop (code=exited, status=0/SUCCESS)
Process: 2071 ExecStart=/etc/init.d/homebridge start (code=exited, status=0/SUCCESS)
May 14 21:03:05 cubietruck su[2074]: Successful su for fhem by root
May 14 21:03:05 cubietruck su[2074]: + ??? root:fhem
May 14 21:03:05 cubietruck su[2074]: pam_unix(su:session): session opened for user fhem by (uid=0)
May 14 21:03:05 cubietruck homebridge[2071]: Homebridge starting
May 14 21:03:05 cubietruck homebridge[2071]: Homebridge is not running
May 14 21:03:05 cubietruck systemd[1]: Started LSB: Start daemon at boot time for homebridge.Fhem hingegen schon:
fhem@cubietruck:~$ sudo service fhem status
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem)
Active: active (running) since Sun 2017-05-14 21:00:15 CEST; 4min 45s ago
Process: 1605 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/fhem.service
├─1639 /opt/hmcfgusb/hmland -d -p 1234 -r 0
└─1715 perl fhem.pl configDB
May 14 21:00:09 cubietruck fhem[1605]: Starting fhem...
May 14 21:00:10 cubietruck fhem[1605]: Daemon with PID 1639 started!
May 14 21:00:15 cubietruck systemd[1]: Started LSB: FHEM server.Zitat von: Thorsten Pferdekaemper am 14 Mai 2017, 12:06:50
Na dann ändere sie halt mal...
Gruß,
Thorsten
Ich schaue nun mal nach einer Möglichkeit, die ConfigDB ohne Fhem zu ändern.
ich würde sicherheitshalber mal die homebridge killen:
ps -ef | grep homebridge
falls da noch was auftaucht den Prozess killen, dann FHEM stoppen und neu starten...dann wissen wir zumindest mit Sicherheit, ob es an der homebridge liegt...
Zitat von: KernSani am 14 Mai 2017, 23:19:20
ich würde sicherheitshalber mal die homebridge killen:
ps -ef | grep homebridge
falls da noch was auftaucht den Prozess killen, dann FHEM stoppen und neu starten...dann wissen wir zumindest mit Sicherheit, ob es an der homebridge liegt...
Ich habe es gerade mal probiert:
root@cubietruck:~# killall homebridge
root@cubietruck:~# ps -ef | grep homebridge
root 1874 1845 0 11:05 pts/0 00:00:00 grep homebridge
Fhem lässt sich leider weiterhin nicht aufrufen. :-\
EDIT:Lösche ich meine configDB aus /opt/fhem und lasse FHEM mit der Standard configDB starten, funktioniert es einwandfrei - unabhängig davon, ob die Homebridge läuft oder nicht.
Hat keiner eine Idee?
Lässt sich die ConfigDB irgendwie reparieren?
Da müsstest Du mal im entsprechenden Forenbereich nachfragen.
Gruß,
Thorsten
An welchen Bereich denkst du? Sonstiges?
Könnte man das Thema verschieben?
Zitat von: Spezialtrick am 15 Mai 2017, 22:12:54
An welchen Bereich denkst du? Sonstiges?
Laut https://fhem.de/MAINTAINER.txt ist das wohl richtig.
Zitat
Könnte man das Thema verschieben?
"Man" kann nicht, aber Du kannst. Die Taste ist links unten.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 15 Mai 2017, 22:31:22
"Man" kann nicht, aber Du kannst. Die Taste ist links unten.
Entschuldige meine Blindheit. ::)
So langsam verzweifle ich und meine besser Hälfte steigt mir aufs Dach, wenn ich Fhem nicht bald wieder ans Laufen bekommen. :-\
Ich habe nun anhand diesem Beitrag
https://forum.fhem.de/index.php?topic=46538.0 (https://forum.fhem.de/index.php?topic=46538.0)
versucht die Config Version vor dem Homebridge Update zu laden. Leider verhält sich diese Version genauso wie die aktuellste und startet Fhem, jedoch geht es ab einem bestimmten Punkt nicht weiter:
2017.05.16 09:37:18 2: Perfmon: ready to watch out for delays greater than one second
2017.05.16 09:37:19 3: telnetPort: port 7072 opened
2017.05.16 09:37:19 3: WEB: port 8083 opened
2017.05.16 09:37:19 3: WEBphone: port 8084 opened
2017.05.16 09:37:19 3: WEBtablet: port 8085 opened
2017.05.16 09:37:20 2: eventTypes: loaded 5411 events from ./log/eventTypes.txt
2017.05.16 09:37:20 3: Opening nanoCUL868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4035XBY-if00-port0
2017.05.16 09:37:20 3: Setting nanoCUL868 serial parameters to 38400,8,N,1
2017.05.16 09:37:24 3: nanoCUL868: Possible commands: BCFiAZEGMKUYRTVWXefltx
2017.05.16 09:37:24 3: nanoCUL868 device opened
2017.05.16 09:37:24 2: Switched nanoCUL868 rfmode to MAX
2017.05.16 09:37:24 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2017.05.16 09:37:27 3: Opening nanoCUL433 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4035XGY-if00-port0
2017.05.16 09:37:27 3: Setting nanoCUL433 serial parameters to 38400,8,N,1
2017.05.16 09:37:30 3: nanoCUL433: Possible commands: BCFiAGMKUYRTVWXefLltx
2017.05.16 09:37:30 3: nanoCUL433 device opened
2017.05.16 09:37:30 1: PERL WARNING: "my" variable $host masks earlier declaration in same scope at ./FHEM/30_MilightBridge.pm line 72.
2017.05.16 09:37:33 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
2017.05.16 09:37:33 3: Opening nanoCUL868hm device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600CZUB-if00-port0
2017.05.16 09:37:33 3: Setting nanoCUL868hm serial parameters to 38400,8,N,1
2017.05.16 09:37:37 3: nanoCUL868hm: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2017.05.16 09:37:37 3: nanoCUL868hm device opened
2017.05.16 09:37:37 2: Switched nanoCUL868hm rfmode to HomeMatic
2017.05.16 09:37:37 3: WifiLight: requested bridge bridge-V3 at 192.168.188.32 already in use by Farbkugel, copy llCmdQueue
2017.05.16 09:37:37 1: HMLAN_Parse: hmusb new condition disconnected
2017.05.16 09:37:37 3: Opening hmusb device 127.0.0.1:1234
2017.05.16 09:37:37 1: HMLAN_Parse: hmusb new condition init
2017.05.16 09:37:37 3: hmusb device opened
2017.05.16 09:37:38 3: DbLog DBLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2017.05.16 09:37:38 3: DbLog DBLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.05.16 09:37:38 3: WifiLight: requested bridge bridge-V3 at 192.168.188.32 already in use by SZ.Ledstripe.Schrank, copy llCmdQueue
2017.05.16 09:37:38 3: WifiLight: requested bridge bridge-V3 at 192.168.188.32 already in use by Farbkugel, copy llCmdQueue
2017.05.16 09:37:41 3: Departure_Define (myDeparture) - defined with interval 90 (sec)
2017.05.16 09:37:42 3: DLCD LCDD has been defined
2017.05.16 09:37:47 3: DLCD LCDD: Line1 (22) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line1: attr dlcdLine1 %time1%
2017.05.16 09:37:47 3: DLCD LCDD: Line2 (22) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line2: attr dlcdLine2 %time1%
2017.05.16 09:37:47 3: DLCD LCDD: Line3 (22) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line3: attr dlcdLine3 %time1%
2017.05.16 09:37:47 3: DLCD LCDD: Line4 (22) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line4: attr dlcdLine4 %time1%
2017.05.16 09:37:47 3: DLCD LCDD: Line2 (24) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line2: attr dlcdVal1 unreadable
2017.05.16 09:37:47 3: DLCD LCDD: Line3 (24) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line3: attr dlcdVal2 unreadable
2017.05.16 09:37:47 3: DLCD LCDD: Line4 (24) is longer than display (20), ignoring some data
2017.05.16 09:37:47 3: DLCD LCDD: Line4: attr dlcdVal2 unreadable
2017.05.16 09:37:49 3: Device BZ.Fenster added to ActionDetector with 002:50 time
2017.05.16 09:37:49 3: Device BZ.Klimasensor added to ActionDetector with 000:10 time
2017.05.16 09:37:49 3: Device FL.Haustur added to ActionDetector with 002:50 time
2017.05.16 09:37:49 3: Device FL.Klimasensor.Aussen added to ActionDetector with 000:10 time
2017.05.16 09:37:49 3: Device FL.Klimasensor.Innen added to ActionDetector with 000:10 time
2017.05.16 09:37:50 3: Device HM_567899 added to ActionDetector with 000:20 time
2017.05.16 09:37:50 3: Device Ku.Fenster added to ActionDetector with 002:50 time
2017.05.16 09:37:50 3: Device Ku.Klimasensor added to ActionDetector with 000:10 time
2017.05.16 09:37:50 3: Device SZ.Balkontur added to ActionDetector with 002:50 time
2017.05.16 09:37:50 3: Device SZ.Klimasensor added to ActionDetector with 000:10 time
2017.05.16 09:37:50 3: Device UM.Klimasensor added to ActionDetector with 000:10 time
2017.05.16 09:37:50 3: Device WZ.Balkontur added to ActionDetector with 002:50 time
2017.05.16 09:37:50 3: Device WZ.Fenster.links added to ActionDetector with 002:50 time
2017.05.16 09:37:50 3: Device WZ.Klimasensor added to ActionDetector with 000:10 time
2017.05.16 09:37:51 3: HarmonyHub: connected
2017.05.16 09:37:51 3: DLCD LCDD initialized
2017.05.16 09:37:54 3: Opening PRESENCE_rr_***** device 192.168.188.2:5333
2017.05.16 09:37:54 3: PRESENCE_rr_***** device opened
2017.05.16 09:37:54 3: Opening PRESENCE_rr_**** device 192.168.188.2:5333
2017.05.16 09:37:54 3: PRESENCE_rr_**** device opened
2017.05.16 09:37:54 1: usb create starting
2017.05.16 09:37:56 1: usb create end
2017.05.16 09:37:56 0: Featurelevel: 5.8
2017.05.16 09:37:56 0: Server started with 267 defined entities (fhem.pl:14284/2017-05-14 perl:5.020002 os:linux user:root pid:2003)
2017.05.16 09:37:56 1: Perfmon: possible freeze starting at 09:37:19, delay is 37.736
2017.05.16 09:37:56 3: telnetForBlockingFn_1494920276: port 44159 opened
Diese Verhalten ändert sich auch nicht, wenn ich eine deutlich ältere oder auch die älteste von ca. 450 vorhanden Versionen lade.
Lösche ich hingegen allerdings meine ConfigDB aus /opt/fhem und kopiere die Basis ConfigDB aus /opt/fhem/contrib/configDB/ nach /opt/fhem lässt sich Fhem starten und ist auch über die GUI erreichbar.
Hat irgendwer eine Idee ?
Hi,
vielleicht als erstes mal den Thread-Titel ändern (nicht nur den Titel eines Posts). So sieht das momentan so aus, als ob sich der Thread hierher verirrt hat.
Also wenn das jetzt in der fhem.cfg wäre, dann würde ich sagen mal Einträge rauswerfen/auskommentieren bis es wieder geht und dann wieder reinnehmen, bis es nicht mehr geht. Wie das mit der configDB geht, keine Ahnung. Vielleicht gibt es ja einen Weg, die configDB wieder in fhem.cfg zu konvertieren und dann damit zu arbeiten.
Gruß,
Thorsten
Wenn ich das richtig sehe, hängt FHEM doch mit einem Telnet auf Port 44159. Versuch doch mal den Process rauszukriegen, der am Port 44159 hängt und diesen mit kill zu beenden. Dann sollte der BlockingCall doch zurück kommen.
Mit
netstat -anp | less
kannst Du Dir die geöffneten Ports und die dazugehörigen Processe ansehen.
Danke für den Hinweis, hier zwei Ausgaben:
2017.05.16 17:50:08 3: telnetForBlockingFn_1494949808: port 34321 opened
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:34321 0.0.0.0:* LISTEN 1640/perl
tcp 68 0 127.0.0.1:34321 127.0.0.1:43264 CLOSE_WAIT -
2017.05.16 18:03:39 3: telnetForBlockingFn_1494950619: port 45877 opened
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:45877 0.0.0.0:* LISTEN 1596/perl
tcp 68 0 127.0.0.1:45877 127.0.0.1:60962 CLOSE_WAIT -
Wenn ich nun Perl beende, wird in der Folge ja auch Fhem beendet, allerdings wird noch einiges geloggt:
root@cubietruck:~# tail -f /opt/fhem/log/fhem-2017-05.log
2017.05.16 18:09:30 1: [Alarm 1] has undefined save data , disarming
2017.05.16 18:09:30 1: [Alarm 2] has undefined save data , disarming
2017.05.16 18:09:30 1: [Alarm 3] has undefined save data , disarming
2017.05.16 18:09:30 1: [Alarm 4] has undefined save data , disarming
2017.05.16 18:09:30 1: [Alarm 5] has undefined save data , disarming
2017.05.16 18:09:30 1: [Alarm 6] has undefined save data , disarming
2017.05.16 18:09:30 1: [Alarm 7] has undefined save data , disarming
2017.05.16 18:09:30 0: Server shutdown
2017.05.16 18:09:32 1: BlockingInformParent (BlockingStart): Can't connect to localhost:45877: IO::Socket::INET: connect: Connection refused
2017.05.16 18:09:32 1: BlockingInformParent (FRITZBOX_Readout_Done): Can't connect to localhost:45877: IO::Socket::INET: connect: Connection refused
Zitat von: Spezialtrick am 16 Mai 2017, 18:20:38
Wenn ich nun Perl beende,
Wie hast Du das gemacht, also mit welchem Befehl genau?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 16 Mai 2017, 18:26:50
Wie hast Du das gemacht, also mit welchem Befehl genau?
Gruß,
Thorsten
Mit:
pkill perl
Und wenn du dich einfach mal mit Telnet an den Port verbindest ? Kommt da irgendwas ?
Das killt wahrscheinlich jeden Perl-Prozess... Du solltest das mit "kill <PID>" machen. Also in Deinem ersten Beispiel
kill 1640
...und wenn der Prozess das überlebt, dann
kill -9 1640
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 16 Mai 2017, 18:30:18
Das killt wahrscheinlich jeden Perl-Prozess... Du solltest das mit "kill <PID>" machen. Also in Deinem ersten Beispiel
kill 1640
...und wenn der Prozess das überlebt, dann
kill -9 1640
Gruß,
Thorsten
Habe den entsprechenden Prozess nun mit
kill 1634beendet. Dies beendet Fhem jedoch auch:
2017.05.16 18:38:52 3: telnetForBlockingFn_1494952732: port 38273 opened
2017.05.16 18:38:52 3: DbRep DBlog_DbRep - connected
2017.05.16 18:40:52 1: [Alarm 0] has undefined save data , disarming
2017.05.16 18:40:52 1: [Alarm 1] has undefined save data , disarming
2017.05.16 18:40:52 1: [Alarm 2] has undefined save data , disarming
2017.05.16 18:40:52 1: [Alarm 3] has undefined save data , disarming
2017.05.16 18:40:52 1: [Alarm 4] has undefined save data , disarming
2017.05.16 18:40:53 1: [Alarm 5] has undefined save data , disarming
2017.05.16 18:40:53 1: [Alarm 6] has undefined save data , disarming
2017.05.16 18:40:53 1: [Alarm 7] has undefined save data , disarming
2017.05.16 18:40:53 0: Server shutdownHängt wahrscheinlich damit zusammen, dass einige andere Verbindungen auch unter diese Prozess fallen:
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 1634/perl
tcp 0 0 0.0.0.0:8084 0.0.0.0:* LISTEN 1634/perl
tcp 0 0 0.0.0.0:8085 0.0.0.0:* LISTEN 1634/perl
tcp 1497 0 127.0.0.1:49034 127.0.0.1:1234 ESTABLISHED 1634/perl
tcp 0 0 192.168.188.2:48930 108.59.13.232:443 ESTABLISHED 1634/perl
tcp 61 0 192.168.188.2:33852 192.168.188.2:5333 ESTABLISHED 1634/perlZitat von: papa am 16 Mai 2017, 18:29:32
Und wenn du dich einfach mal mit Telnet an den Port verbindest ? Kommt da irgendwas ?
Wie stelle ich das genau an? :-\
Mit configDB hat das jedenfalls nichts zu tun. Und kaputt ist die configDB mit 99.99% Wahrscheinlichkeit auch nicht, deshalb gibt es da auch nichts zu reparieren.
Das hier:
2017.05.16 09:37:56 1: Perfmon: possible freeze starting at 09:37:19, delay is 37.736
2017.05.16 09:37:56 3: telnetForBlockingFn_1494920276: port 44159 opened
ist das Problem und das wird definitiv nicht von der configDB verursacht. Entweder (1) Du hast in Deiner Konfiguration ein device, das sich nicht anlegen läßt oder (2) ein device versucht auf Hardwareebene irgendeine Komponente Deines Cubietrucks anzusprechen, was nicht korrekt funktioniert. (Dann wäre (1) die logische Folge aus (2))
Starte FHEM mit configDB im rescue Mode und schau Dir die vorherigen Versionen an.
Mit "configdb list %% 2" kannst Du Dir beispielsweise die komplette Konfiguration "2" komplett anzeigen lassen.
Ich vermute initialUsbCreate als Bösewicht.
Zitat von: betateilchen am 16 Mai 2017, 19:04:22
Mit configDB hat das jedenfalls nichts zu tun. Und kaputt ist die configDB mit 99.99% Wahrscheinlichkeit auch nicht, deshalb gibt es da auch nichts zu reparieren.
Das beruhigt mich schon mal ungemein. :)
Zitat von: betateilchen am 16 Mai 2017, 19:04:22
Das hier:
2017.05.16 09:37:56 1: Perfmon: possible freeze starting at 09:37:19, delay is 37.736
2017.05.16 09:37:56 3: telnetForBlockingFn_1494920276: port 44159 opened
ist das Problem und das wird definitiv nicht von der configDB verursacht. Entweder (1) Du hast in Deiner Konfiguration ein device, das sich nicht anlegen läßt oder (2) ein device versucht auf Hardwareebene irgendeine Komponente Deines Cubietrucks anzusprechen, was nicht korrekt funktioniert. (Dann wäre (1) die logische Folge aus (2))
Ich könnte mir nur vorstellen, dass es sich um das interne Bluetooth des Cubietrucks handelt, dass eigentlich nicht angesprochen werden sollte, weil ich in der Fhem Definition einen externen Bluetooth Dongle verlinkt habe. Kann es sein, dass auf Systemebene Hci0 und Hci1 gewechselt haben und nun das falsche Bluetooth Device angesprochen wird? Ansonsten habe ich nur CULs, einen HM-USB und ein 20x4 Display am Cubie hängen, die jedoch seit Monaten keinerlei Probleme gemacht haben.
Zitat von: betateilchen am 16 Mai 2017, 19:04:22
Starte FHEM mit configDB im rescue Mode und schau Dir die vorherigen Versionen an.
Mit "configdb list %% 2" kannst Du Dir beispielsweise die komplette Konfiguration "2" komplett anzeigen lassen.
Ich vermute initialUsbCreate als Bösewicht.
Das habe ich hinbekommen. Wonach schaue ich nun genau?
Kannst Du die Konfiguration jetzt in eine Datei schreiben ? Dann könnte man die einzelnen Sachen Schritt für Schritt an bzw. abschalten.
Im Prinzip ja, allerdings ist die Auflistung vollkommen ungeordnet, sodass man alles sortieren müsste, bevor Fhem überhaupt startet.
Zitat von: betateilchen am 16 Mai 2017, 19:04:22
Ich vermute initialUsbCreate als Bösewicht.
Ich habe tatsächlich
define initialUsbCheck notify global:INITIALIZED usb create
in meiner Konfiguration. Daher habe ich es aus meiner ConfigDB gelöscht. Leider startet Fhem weiterhin nicht richtig und bleibt an der selben Stelle stehen wie zuvor. So langsam gebe ich es auf... :'(
Hi,
kannst Du "attr global verbose 5" irgendwie am Anfang machen? Dann würde man ggf. etwas mehr sehen.
Gruß,
Thorsten
Hallo Thorsten,
ich habe mich nun dazu entschieden, meinen Cubietruck komplett zu löschen und alles neu aufzusetzen. Es wird zwar seine Zeit dauern, aber von der ConfigDB verabschiede ich mich nun endgültig.
Vielen Dank für deine Hilfe!