Hallo Fangemeinde, Ich habe meinen RasPi erst seit 3 Wochen und jeden Freitag zwangsweise neu aufgesetzt. Leider habe ich das neueste Image vom 4.1.2019 erst heute Abend entdeckt. Meine vorherigen Hauptprobleme waren, dass der Iobroker nur mit aktivem Eth0 LAN Kabel sich aktualisieren ließ. Mit dem im Forum angebotenen Update wurde dieses Problem gelöst, zumindest läuft der Iobroker jetzt im WLAN Betrieb auch mit aktuellen Versionen ohne Anzeige von 2 Adaptern auf einem Host. Mein Problem war eine effektive Datensicherung im laufenden Betrieb ohne laufendes NAS. Zum Glück mit USB Stick erfolgreicn gelöst. jetzt zu diesem Problem mit Javascript Mein genutztes Scribt für den Grünbeck SC18 brachte plötzlich keine Daten mehr. Im Log stand genau dieser Fehler. Ich habe in meiner Not den JS Adapter einfach gelöscht, die noch offizielle Version dann wieder neu installiert. Dadurch waren aber die gesamten Scribte und die eingerichteten Konfigurationen weg. Mit der Wiederherstellung vom IObroker lief auch das Scribt wieder. Als einziges Problem in meiner Version blieb derzeit. Ein Problem im Zugriff vom Tankerkönig. Er holt nur mit Lan Anschluss die Daten aus dem Internet, sonst bleiben die Preise konstant. Trotzdem bin ich sehr froh dieses Forum als erstes zur Fehlersuche nutzen zu können. Respekt , mir ist vor allem die effiziente offene Lösung ohne Cloud und Internetzugriff wichtig. Um zu wissen was zu Hause los ist, reicht der Adapterzugriff via VPN Verbindung mit der Fritzbox… Vielen Dank für Eure Antworten

https://github.com -> Registrieren mit Email, Name und einem Passwort, dann https://github.com/ioBroker/ioBroker.cloud/issues und dort "New issue" und Text eingeben. Fertig

Bitte readme zum Adapter lesen. Entweder das angegebene pcap Modul selbst mit apt-get installieren oder der Adapter muss als root installiert werden. Gesendet vom Handy …

Also regahss Einstellung sind angepasst. [image: 1058_bildschirmfoto_vom_2019-01-20_12-10-38.png] Im log von ioBroker sieht man leider nichts auffälliges. Es sind nur die komischen Einträge in der CCU-log. Die sind seit dem einbinden des IP-Gerätes vorhanden. Ich bin jetzt mal bei den beiden Adaptern auf hm-regahss 2.1.2 rpc 1.8.3 zurückgegangen und bei VIS auf die 1.1.7 Jetzt läuft es zumindest wieder richtig flüssig. Muss mal jeden einzelnen der drei Adapter nacheinander updaten und beobachten welcher das lagging in der VIS auslöst. Gruß Johnny

Danke, geht nun wieder. Gruß Axel

Das alte Diskimage habe ich wegbekommen, indem man sich mit dem Speichermedium verbindet (z.B. NAS) und zum Ordner "Images" Navigiert. Dort findet man die Datei Ich hab Sie dann einfach gelöscht. Jetzt ist es dann auch nicht mehr in Proxmox sichtbar. Und da es hier keine Daumen nach oben gibt… Vielen Dank noch mal @apollon77

Keiner ne Idee, wie ich rausfiden kann, woher die schaltbefehle kommen?

Soweit ich das sehe ist da alles okay Ich habe drei Instanzen hm-rpc.0 ist HM hm-rpc.1 ist HM-IP hm-rpc.2 ist CUxD Ich hab nichts verändert und die liefen bisher zuverlässig 3010_2019-01-18__1_.png 3010_2019-01-18__2_.png 3010_2019-01-18__3_.png

nachdem ich die ccu auf aktuellen Stand gebracht habe sind die "[KEEPALIVE] Connection timed out" nicht mehr vorhanden. Danke für den Hinweis

Alles klar. Dann weis ich ja was beim nächsten mal zu tun ist. Vielen Dank und gute Zeit… ;)

Hab auch das Problem das meine VIS (meiner ical-Tabelle) nicht aktualisert wird. Die Daten sind aktuell- jedoch wird die VIS (Widget) im Browser sowie in der App nicht aktualisiert. :(

Hallo, bei mir war das Problem, dass er nicht in mein Mesh-WLAN wollte. Habe eine Mesh-System von Tenda (MW6) und damit kommt das Teil nicht klar… Habe dann in der Fritzbox ein WLAN angemacht, wo nur er drin ist... Das auf nicht sichtbar gestellt nach dem koppeln und nun funkt nur er dort umher... Achso ich hatte den Pro...

ok, das entspricht dem, was Alex im https://forum.iobroker.net/viewtopic.php?f=34&t=5260&p=220194#p219622 gesagt hat. Wahrscheinlich hat armbian den dort erwähnten Fehler versucht zu beheben und es ist zu dem Fehler in 5.71 gekommen Gruß Rainer

@foxriver76: viewtopic.php?t=12091#p174616 ` Genau das wars! Vielen Dank! Verstehe zwar nicht, warum bzw. wie das passieren kann… Aber mit nur einem Befehl sudo getcap $(readlink -f $(which node)) wars erledigt... Grüße

Das Problem hat sich erledigt, es lag an den Allgemeinen MODBUS Adapter Einstellungen. Dort war der Haken "Aliases benutzen" gesetzt. Somit fragt er die falschen Register ab. :D

Ich muss diese Thema nochmal ausgraben. Ich habe jetzt ein Multihost-System aufgesetzt, doch leider startet jetzt der Slave nicht mehr automatisch iobroker bei restart systemctl status -l iobroker.service ● iobroker.service - ioBroker Server Loaded: loaded (/lib/systemd/system/iobroker.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2019-01-15 19:34:36 CET; 45s ago Docs: http://iobroker.net Main PID: 599 (code=exited, status=203/EXEC) Jan 15 19:34:36 raspberrypi systemd[1]: iobroker.service: Failed with result 'exit-code'. Jan 15 19:34:36 raspberrypi systemd[1]: iobroker.service: Service hold-off time over, scheduling restart. Jan 15 19:34:36 raspberrypi systemd[1]: Stopped ioBroker Server. Jan 15 19:34:36 raspberrypi systemd[1]: iobroker.service: Start request repeated too quickly. Jan 15 19:34:36 raspberrypi systemd[1]: Failed to start ioBroker Server. Jan 15 19:34:36 raspberrypi systemd[1]: iobroker.service: Unit entered failed state. Jan 15 19:34:36 raspberrypi systemd[1]: iobroker.service: Failed with result 'exit-code'. Ich glaube es hängt mit sudo iobroker setup custom ````zusammen. Ich habe in einem anderen Thema dazu gelesen, dass es bei einigen funktioniert hat, wenn sie es mit Enter durchbestätigen aber dann funktioniert ja der Multihost nichtmehr oder? Wie kann ich das Problem lösen?