UNSOLVED ioBroker auf RPI 3 installiert, WebO antwortet nicht
-
Systemdata ioBroker auf RPI 3 B+ installiert, WebOberflaeche antwortet nicht Hardwaresystem: Pi3 B+ Arbeitsspeicher: 1GB Festplattenart: SD-Karte 32GB Betriebssystem: Ubuntu Node-Version: 12.20.0 Nodejs-Version: 12.20.0 NPM-Version: 6.x.x Installationsart: Skript/Manuell Image genutzt: Ja/Nein Ort/Name der Imagedatei: Link Ich habe gerade ein neues RPI 3 B+ und wollte den ioBroker installieren.
Ich habe alles gemacht wie hier in Forum beschrieben.
Am Ende des Installationsprozesses ergibt sich ein paar Warnings/Fehler:Installing ioBroker (3/4) ========================================================================== In file included from ../../nan/nan.h:56, from ../src/main.cpp:3: /home/pi/.cache/node-gyp/12.20.0/include/node/node.h:737:43: warning: cast between incompatible function types from ‘void (*)(v8::Local<v8::Object>)’ to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type] (node::addon_register_func) (regfunc), \ ^ /home/pi/.cache/node-gyp/12.20.0/include/node/node.h:771:3: note: in expansion of macro ‘NODE_MODULE_X’ NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage) ^~~~~~~~~~~~~ ../src/main.cpp:42:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(diskusage, Init) ^~~~~~~~~~~ In file included from ../../nan/nan.h:56, from ../src/unix_dgram.cc:5: /home/pi/.cache/node-gyp/12.20.0/include/node/node.h:737:43: warning: cast between incompatible function types from ‘void (*)(v8::Local<v8::Object>)’ to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type] (node::addon_register_func) (regfunc), \ ^ /home/pi/.cache/node-gyp/12.20.0/include/node/node.h:771:3: note: in expansion of macro ‘NODE_MODULE_X’ NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage) ^~~~~~~~~~~~~ ../src/unix_dgram.cc:404:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(unix_dgram, Initialize) ^~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Open(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:78:69: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Open, (uv_after_work_cb)EIO_AfterOpen); ^~~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Update(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:135:71: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Update, (uv_after_work_cb)EIO_AfterUpdate); ^~~~~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Close(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:175:70: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Close, (uv_after_work_cb)EIO_AfterClose); ^~~~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Flush(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:215:70: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Flush, (uv_after_work_cb)EIO_AfterFlush); ^~~~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Set(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:270:68: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Set, (uv_after_work_cb)EIO_AfterSet); ^~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Get(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:314:68: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Get, (uv_after_work_cb)EIO_AfterGet); ^~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE GetBaudRate(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:363:76: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_GetBaudRate, (uv_after_work_cb)EIO_AfterGetBaudRate); ^~~~~~~~~~~~~~~~~~~~ ../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Drain(Nan::NAN_METHOD_ARGS_TYPE)’: ../src/serialport.cpp:409:70: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Drain, (uv_after_work_cb)EIO_AfterDrain); ^~~~~~~~~~~~~~ ../src/serialport.cpp: At global scope: ../src/serialport.cpp:430:28: warning: unnecessary parentheses in declaration of ‘ToParityEnum’ [-Wparentheses] SerialPortParity NAN_INLINE(ToParityEnum(const v8::Local<v8::String>& v8str)) { ^ ../src/serialport.cpp:449:30: warning: unnecessary parentheses in declaration of ‘ToStopBitEnum’ [-Wparentheses] SerialPortStopBits NAN_INLINE(ToStopBitEnum(double stopBits)) { ^ In file included from ../../../nan/nan.h:56, from ../src/./serialport.h:6, from ../src/serialport.cpp:1: /home/pi/.cache/node-gyp/12.20.0/include/node/node.h:737:43: warning: cast between incompatible function types from ‘void (*)(Nan::ADDON_REGISTER_FUNCTION_ARGS_TYPE)’ {aka ‘void (*)(v8::Local<v8::Object>)’} to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type] (node::addon_register_func) (regfunc), \ ^ /home/pi/.cache/node-gyp/12.20.0/include/node/node.h:771:3: note: in expansion of macro ‘NODE_MODULE_X’ NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage) ^~~~~~~~~~~~~ ../src/serialport.cpp:483:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(serialport, init); ^~~~~~~~~~~ ../src/serialport_unix.cpp: In function ‘int setup(int, OpenBaton*)’: ../src/serialport_unix.cpp:176:60: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 1005 [-Wformat-truncation=] snprintf(data->errorString, sizeof(data->errorString), "Error %s Cannot open %s", strerror(errno), data->path); ^~~~~~~~~~~~~~~~~~~~~~~~~ ../src/serialport_unix.cpp:176:13: note: ‘snprintf’ output 20 or more bytes (assuming 1043) into a destination of size 1024 snprintf(data->errorString, sizeof(data->errorString), "Error %s Cannot open %s", strerror(errno), data->path); ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/serialport_unix.cpp: In function ‘void EIO_Open(uv_work_t*)’: ../src/serialport_unix.cpp:86:60: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 1003 [-Wformat-truncation=] snprintf(data->errorString, sizeof(data->errorString), "Error: %s, cannot open %s", strerror(errno), data->path); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/serialport_unix.cpp:86:13: note: ‘snprintf’ output 22 or more bytes (assuming 1045) into a destination of size 1024 snprintf(data->errorString, sizeof(data->errorString), "Error: %s, cannot open %s", strerror(errno), data->path); ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ATTENTION: Error reporting via Sentry will be activated on next start of ioBroker ioBroker wants to make sure to deliver the most stable smart home system. To allow this we decided to implement an automatic error and crash reporting solution into the js-controller and also into adapters. THIS REPORTING WILL BE ENABLED WITH THE NEXT START OF YOUR IOBROKER! For any error that leads to the crash of the js-controller or one of the relevant adapters the error details are send to a server. For the js-controller and core adapters this server is located and operated in germany. For community adapters please check the Github Readme of the affected adapter for details which Sentry server is used. If you want to disable the error reporting you can use the command 'iobroker plugin disable sentry' This command will also make sure that no adapter that runs on this host will send crash reporting data to sentry. ========================================================================== Finalizing installation (4/4) ========================================================================== Enabling autostart... Autostart enabled! Fixing directory permissions...Trotzallem, wurde der ioBroker erfolgreich installiert und zeigt am Ende:
========================================================================== ioBroker was installed successfully Open http://192.168.178.41 192.168.193.5:8081 in a browser and start configuring! ==========================================================================Welche Adresse soll man in dem Fall eigentlich nutzen?
http://192.168.178.41 ? Zeigt: This site can't be reached.
http://192.168.178.41:8081? This site can't be reached.
192.168.193.5:8081? This site can't be reached.
RPI 3 und der Rechner befinden sich in dem gleichem Netwerk. Der RPI 3 ist abrufbar und man kann alles einstellen.
Der ioBroker scheint also auf dem RPI3 zu laufen.PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1465 xrdp 20 0 35192 24116 8164 S 31.4 2.5 0:22.05 xrdp 1496 pi 20 0 269940 61208 36360 S 7.9 6.5 0:11.64 Xorg 25494 pi 20 0 86060 28092 21832 S 4.0 3.0 0:18.02 lxterminal 2525 iobroker 20 0 138228 51476 27940 S 2.0 5.4 0:21.43 node 444 mosquit+ 20 0 11304 6688 5200 S 1.3 0.7 0:14.49 mosquitto 2851 iobroker 20 0 133276 47236 27772 S 1.3 5.0 0:20.69 node 3531 iobroker 20 0 135228 48584 27868 S 1.3 5.1 0:20.83 node 16732 pi 20 0 10760 2916 2500 R 1.0 0.3 0:07.72 top 24441 pi 20 0 21984 13600 7392 S 0.7 1.4 0:10.02 python3 9 root 20 0 0 0 0 S 0.3 0.0 0:01.05 ksoftirqd/0 505 root 20 0 202196 37520 25064 S 0.3 4.0 0:12.38 Xorg 872 lightdm 20 0 119704 42624 19600 S 0.3 4.5 0:10.26 pi-greeter 1776 pi 20 0 63224 15400 12492 S 0.3 1.6 0:00.81 openbox 1782 pi 20 0 436024 32628 26084 S 0.3 3.4 0:03.94 lxpanel 2462 iobroker 20 0 133516 44768 28076 S 0.3 4.7 0:04.43 node 1 root 20 0 34812 8344 6488 S 0.0 0.9 0:07.18 systemdWas mache ich falsch?
Ich bin leider nur ein Anfaenger. Ich werde mich auf eure Unterstützung freuen.
Danke! -
-
@solargy sagte in ioBroker auf RPI 3 installiert, WebO antwortet nicht:
Der RPI 3 ist abrufbar
unter welcher IP?
-
@Homoran
unter 192.168.178.41Danke!
-
@Thomas-Braun
welche Ausgaben des "ip a" Befehles sollte man hier einreichen um auch keine Sicherheitsrisiko für mein Netzwerk darzustellen?2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:xx.xx.xx.xx brd ff:ff:xx:xx:xx:xx inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0 valid_lft 835833sec preferred_lft 727833sec inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0 valid_lft forever preferred_lft forever inet6 2003:d4:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 7197sec preferred_lft 1797sec inet6 fe80::15a8:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b8:27:xx:xx:xx:xx brd ff:ff:xx:xx:xx:xxReicht das aus oder bräuchte man mehr Info?
Vielen Dank!
-
@solargy Komplette Ausgaben bitte.
Mit deinen intern vergebenen IPs kann hier keiner was anfangen. -
pi@raspberrypi:~ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:95:65:e9 brd ff:ff:ff:ff:ff:ff inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0 valid_lft 833560sec preferred_lft 725560sec inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0 valid_lft forever preferred_lft forever inet6 2003:d4:ff17:bb00:1415:526f:748d:10f0/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 7197sec preferred_lft 1325sec inet6 fe80::15a8:912a:6647:7793/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b8:27:eb:c0:30:bc brd ff:ff:ff:ff:ff:ff -
@solargy Warum hast du da zwei IPv4 auf dem gleichen Interface?
Was ist 192.168.193.x für ein Netz?
Das andere 192.168.178.x ist deine Fritzbox. -
@Thomas-Braun
Ich habe keine Ahnung woher kommt dieser komplett neuer IP Bereich xx.xx.193.xx. -
@solargy Ist ja dein Netz, solltest du also kennen.
Von uns kann das keiner wissen.
Da scheinen zwei Geräte IP-Adressen zu vergeben, das ist halt etwas schräg. -
Komisch...
Interessant ist dass wenn ich von RPI3 Terminal die IP Adresse 192.168.193.5 aufrufe, dann scheint dieses Device zu antworten:pi@raspberrypi:~ $ ping 192.168.193.5 PING 192.168.193.5 (192.168.193.5) 56(84) bytes of data. 64 bytes from 192.168.193.5: icmp_seq=1 ttl=64 time=0.144 ms 64 bytes from 192.168.193.5: icmp_seq=2 ttl=64 time=0.135 ms 64 bytes from 192.168.193.5: icmp_seq=3 ttl=64 time=0.133 ms 64 bytes from 192.168.193.5: icmp_seq=4 ttl=64 time=0.132 ms 64 bytes from 192.168.193.5: icmp_seq=5 ttl=64 time=0.138 msWenn ich von meinem Rechner gas gleiche in CMD eingebe dann scheint diese Adresse Tod.
C:\Users\ndb\ping 192.168.193.5 Pinging 192.168.193.5 with 32 bytes of data: Request timed out Request timed out Request timed out Request timed out -
@solargy Der Windows Rechner ist halt nicht in dem 193er Netz drin.
Und selber kann der Pi sich natürlich pingen. Der kann ja auch die 127.0.0.1 pingen. -
Danke fuer deine Antwort.
Wie kann es sein dass der RPI in dem 193er integriert ist?
Scheint ja etwas mit der Kombination RPI - Fritzbox schräg zu sein.
Da habe ich keine andere Geraete die IP Addresse vergeben koennen. -
@solargy
pihole oder sonst irgendwas in einem Docker oder so kaufen? -
@Thomas-Braun
Hallo Alle,Ich denke mal ich habe die Ursache meines Problemes wo beim "ip a", zwei IP unterschiedliche IP Addresse angezeigt werden, gefunden:
inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0 valid_lft 833560sec preferred_lft 725560sec inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0Ich habe mein RPI3 komplett neu mit Raspi OS Lite ausgestattet und erstmal nur ioBroker wie hier ofizielle beschrieben installiert. Da scheint alles einwandfrei zu funktionieren.
Beim "ip a" ergibt sich nur eine192.168.178.41IP Adresse.Um meine PV Anlage (mit Kostal Plenticore 10 und Kostal SEM) mit der GO-ECharger Wallbox zu integrieren und PV Ueberschuss ins Auto zu laden habe ich auf dem RPI3 auch openWB Software installiert. Die Installation wurde wie hier beschrieben (https://openwb.de/main/wp-content/uploads/2019/07/install_openWB_v2.pdf Ab dem Punkt In der Schell folgendes eingeben) durchgefuehrt.
Wenn die Installation fertig ist dann faengt die Hoelle an. Weder der ioBroker ist in der WebOberflaeche erreichbar noch die openWB WebOberflaeche.
Beim "ip a" scheint die Installation der openWB Netzwerk Aenderungen vorzunehmen/vorgenommen zu haben. Da erscheint diese zwei IP Adresse, wie hier in den vorherigen Threads gezeigt wurde.
inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0Hat jemanden Ahnung was ist passiert geworden?
Oder habt ihr eine Idee wo konnte man mehr Info dazu bekommen.Vielen Dank!
-
@solargy Die Frage ist halt was da für ein Kram in dem Installer-Skript passiert.
Installier doch mal anders herum. Zuerst ein Debian Buster Lite, dann der openwb-Kram und zuletzt den ioBroker. Dann könnte es funktionieren, der ioBroker fummelt jedenfalls nicht tief im Netzwerksetup herum.
-
@Thomas-Braun
Hier ist der openWB Installer-Skript: https://raw.githubusercontent.com/snaptec/openWB/master/openwb-install.sh
Es scheint also der Skript voll mit Checks und Installation Schritte der jeweiligen Software Komponenten zu sein.
Ich habe gestern es anderesrum installiert. openWB zuerst und dann ioBroker. Daher habe ich diesen Thread hier erzeugt.Ich werde dann mit dem Debian Buster Lite probieren, da mit dem Raspberry Pi OS die aktuelle Problemen erscheinen.
Ist der Debian Buster Lite so unterschiedlich?Danke nochmal fuer die kompetente Unterstützung!
-
@solargy Nein, ich meinte damit Rasbian OS. Basiert halt auf Debian.
-
Hallo Thomas,
Das ist gar nicht notwendig da ich gestern erstmal openWB auf dem RPI3 hatte und dann den ioBroker dazu einholen wollte. Nach einer unspektakulären Scheiterung habe ich diesen Thread aufgestellt. Es scheint also dass die Präsenz der openWB auf dem RPI3 den ioBroker zu beeinträchtigen. Die openWB fummelt komischerweise im Netzwerksetup herum.
Vielen Dank
-
@solargy Nee, die Installation von dem OpenDingsbums beeinträchtigt das Netzwerksetup, wie mir scheint. Wie sieht denn die Ausgabe von
ip aunmittelbar nach der Installation von dem Ding aus?
