Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[invidianer]

@wendy2702
Ja, sorry für das Wirrwarr!
Heute früh waren erneut Meldungen des hue-Adapters drin, weiterhin viele "reconnect ..." meiner Tasmota-Gosunds und der ioBroker war extrem langsam, "stockte" zwischendrin immer wieder sekundenlang, wenn man auf der Weboberfläche klickte.

Folgende Meldung hat mich besonders stutzig gemacht:

2021-03-06 08:30:24.562 - info: host.raspberrypi Updating repository "stable" under "http://download.iobroker.net/sources-dist.json"

Daraufhin habe ich eben folgendes getan:

iobroker backup
iobroker stop
ps -ef | grep broker | grep -v grep
sudo apt-get update
sudo apt-get full-upgrade
node -v
iobroker update
iobroker upgrade self
curl -sL https://iobroker.net/fix.sh | bash -
sudo reboot

Leider ist der Fehler aber immer noch da.

Außerdem folgende:

2021-03-06 08:34:43.500 - error: hue.0 (1526) Could not poll all: read ECONNRESET
2021-03-06 08:35:00.082 - info: host.raspberrypi instance system.adapter.dwd.0 started with pid 1954
2021-03-06 08:35:02.040 - info: dwd.0 (1954) starting. Version 2.7.5 in /opt/iobroker/node_modules/iobroker.dwd, node: v12.21.0, js-controller: 3.2.16
2021-03-06 08:35:10.629 - info: sonoff.0 (848) Client [Tischlampe] connection closed: closed
2021-03-06 08:35:11.127 - info: sonoff.0 (848) Client [Stehlampe Wohnzimmer EG] connection closed: closed
2021-03-06 08:35:11.178 - info: sonoff.0 (848) Client [TV] connection closed: closed
2021-03-06 08:35:11.754 - info: sonoff.0 (848) Client [PlayStation 4] connection closed: closed
2021-03-06 08:35:12.165 - error: dwd.0 (1954) Empty or invalid JSON: Cannot read JSON file: Error: getaddrinfo EAI_AGAIN www.dwd.de
2021-03-06 08:35:12.170 - info: dwd.0 (1954) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2021-03-06 08:35:12.707 - info: host.raspberrypi instance system.adapter.dwd.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2021-03-06 08:35:16.105 - info: sonoff.0 (848) Client [LED-Strahler] connection closed: closed
2021-03-06 08:35:18.562 - info: sonoff.0 (848) Client [SONOS] connection closed: closed
2021-03-06 08:35:28.974 - error: hue.0 (1526) Could not poll all: connect EHOSTUNREACH 192.168.2.51:443
2021-03-06 08:35:34.095 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 1(Big-Block-Max/EE:0D:DF:22:09:99):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:37.212 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 2(BuroPod/58:D3:49:1C:AA:75):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:40.332 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 3(DGPod-1/E0:2B:96:B2:D6:0B):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:42.093 - error: hue.0 (1526) Could not poll all: connect EHOSTUNREACH 192.168.2.51:443
2021-03-06 08:35:43.452 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 4(DGPod-2/58:D3:49:36:58:0C):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:46.572 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 5(Drucker/D8:0F:99:46:A5:B9):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:49.692 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 6(EGPod-1/E0:2B:96:AB:84:7C):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:52.812 - warn: tr-064.0 (1471) forEachConfiguredDevice: in GetSpecificHostEntry 7(EGPod-2/58:D3:49:14:58:47):Error: sendSOAPActionRequest Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: - {"code":""}
2021-03-06 08:35:52.957 - info: mqtt.0 (1343) Client [shelly1-E098068D096C] connection closed: timeout

[wendy2702]

@invidianer Steht der PI noch immer direkt neben der Fritzbox?

Läuft das Mesh mittlerweile? Wenn nicht würde ich erstmal das gerade ziehen.

Und, tue dir selber einen gefallen und schliesse den iobroker Server per Kabel an.

[invidianer]

@wendy2702
Jepp, steht noch genau da.
Da Mesh läuft, der AVM Repeater 3000 ist seit gestern Abend drin und fliegt scheinbar auch nicht mehr raus.
Pi ans Kabel bedeutet neue IP-Adresse (also ich hatte ihn mal am Kabel -ich weiß nicht mehr, warum, vermutlich zum Gosund-Flashen) und er hat eine andere IP-Adresse dafür, die ich dann bei allen Gosunds usw. eintragen müßte.
Also langfristig okay, aber jetzt für dieses Problem wird es ja wohl eher nicht helfen.

mrbungle schrieb oben, es gäbe gerne mal Probleme mit Repeatern. Ich werde den 3000er mal wieder aus dem Mesh rausschmeißen und ihn ausschalten. Mal schauen.

Der nächste Schritt wäre dann, die 7590 wieder rauszuschmeißen und meine gute, alte 7490 per Sicherung auf Stand letzte Woche zu setzen, dann wäre alles wieder beim Alten.

Oder was meint ihr?

[wendy2702]

@invidianer Stell den PI mal paar Meter weg von der Fritte.

Ist das ein PI3 oder 4 und steckt da noch irgendein USB Stick dran?

[invidianer]

@wendy2702
Ist ein Pi4 B, kein USB-Stick.
Hmm, Du meinst, weil die 7590 stärker "WLAN strahlt", als die 7490, und sich der Pi nun "überrannt" fühlt?
Habe sehr das Gefühl (weil es ja nahezu alle Adapter betrifft, welche Fehlermeldungen schmeissen), daß es irgendwelche Probleme im Netzwerk gibt, Timing, Timeouts uw.
Eben mal testweise per Handy Licht im Keller eingeschaltet, hat zwar funktioniert, aber:

2021-03-06 09:17:24.825 - error: shelly.0 (2305) Error in function state.coap.http_cmd for state SHSW-1#E098068D096C#1.Relay0.Switch and request{"url":"http://192.168.2.10/relay/0","timeout":5000,"qs":{"turn":"on","timer":0}} for 192.168.2.10 (shelly1 / shelly1-E098068D096C / SHSW-1#E098068D096C#1) (Error: ETIMEDOUT)
2021-03-06 09:17:26.285 - error: shelly.0 (2305) Error in function state.coap.http_cmd for state SHSW-1#E098068D096C#1.Relay0.Switch and request{"url":"http://192.168.2.10/relay/0","timeout":5000,"qs":{"turn":"off","timer":0}} for 192.168.2.10 (shelly1 / shelly1-E098068D096C / SHSW-1#E098068D096C#1) (Error: ETIMEDOUT)

[wendy2702]

@invidianer PI4 erzeugt Störstrahlung, das kann man im Internet zu hauf finden.

Wenn er zu nah an der WLAN Quelle steht kann das neben den AVM Typischen WLAN Problemen noch zu ganz anderen effekten führen.

Stell das Teil doch zum testen mal paar Meter weg und gucke dann mal.

[invidianer]

@wendy2702
Okay, erledigt! Mal abwarten und Daumen drücken ...

[wendy2702]

@invidianer Daumen Drück....

Aber langfristig --> Kabel dran

[invidianer]

@wendy2702
Okay, das habe ich ja kapiert und mache es auch! ;)
Nun, falls es jetzt wirklich erledigt sein sollte mit den Fehlermeldungen, kann es denn sein, daß der Pi die 7590 so extrem stört, er aber der 7490 dagegen absolut nichts "anhaben" konnte?

[wendy2702]

@invidianer Möglich das die Störstrahlung des PI auf die neue Fritte einen grösseren hat.

Das kann auf Bauteil Ebene passieren oder aber auch einfach nur das WLAN.

Bekommt man eigentlich nur mit etwas aufwendigerer Messtechnik genauer analysiert.

[da_Woody]

@invidianer said in Massive Probleme nach Austausch von Router und Mesh Repeater:

Pi ans Kabel bedeutet neue IP-Adresse (also ich hatte ihn mal am Kabel -ich weiß nicht mehr, warum, vermutlich zum Gosund-Flashen) und er hat eine andere IP-Adresse dafür, die ich dann bei allen Gosunds usw. eintragen müßte.

stimmt so nicht. du kannst die IP an die "neue" MAC vergeben, dann ändert sich gar nichts.

[invidianer]

@da_woody
Oh, das klingt interessant!!
Da würde ich, wenn ich wieder genug „Mut“, habe, etwas umzustellen, gerne nochmal draufzurückkommen, wie man das macht!

[invidianer]

@wendy2702
Okay, das wäre eine Erklärung! Danke nochmals!
Bis jetzt bist Du übrigens mein Held! 😃
Ich beobachte weiter und berichte, positiv wie auch negativ.
Die Meldung wegen „... Updating repository stable ...“ (siehe unten) kommt aber immer noch.
War mir früher nie aufgefallen, vielleicht ist es ja normal.

2021-03-06 08:30:24.562 - info: host.raspberrypi Updating repository "stable" under "http://download.iobroker.net/sources-dist.json"

[wendy2702]

@invidianer sagte in Massive Probleme nach Austausch von Router und Mesh Repeater:

http://download.iobroker.net/sources-dist.json

ISt nicht normal.

Kannst du mal auf dem PI das machen:

ping repo.iobroker.live

Mal so 10-15 Zeilen laufen lassen dann mit "STRG-C" abbrechen und hier posten.

[da_Woody]

@invidianer hehe, mut kann man nicht kaufen! ;)
wie es bei dem fritten zeuch genau funktioniert, kann ich dir nicht sagen. aber im grunde musst du den aktuellen lease auflösen und die alte IP an die MAC des lan-anschlusses vergeben. nennt sich dann DHCP reservierung. ich habe für neue geräte nur einen kleine freie IPrange offen wo sich ein neues gerät anmelden kann. dort sage ich dann IP reservieren, weise dem gerät die gewünschte IP zu, neustart, das gerät nimmt an hand der MAC die neu IP an und gut ists.
ist sowieso die bessere lösung, da auch nach einem stromausfall sicher gestellt ist, daß die selbe IP sicher vergeben wird.

[invidianer]

@wendy2702

pi@raspberrypi:~ $ ping repo.iobroker.live
PING repo.iobroker.live.cdn.cloudflare.net (104.21.88.137) 56(84) bytes of data.
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=1 ttl=56 time=22.9 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=2 ttl=56 time=23.0 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=3 ttl=56 time=21.7 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=4 ttl=56 time=21.8 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=5 ttl=56 time=21.5 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=6 ttl=56 time=21.4 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=7 ttl=56 time=22.8 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=8 ttl=56 time=21.10 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=9 ttl=56 time=21.6 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=10 ttl=56 time=22.6 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=11 ttl=56 time=21.0 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=12 ttl=56 time=21.1 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=13 ttl=56 time=22.2 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=14 ttl=56 time=21.8 ms
64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=15 ttl=56 time=22.2 ms
^C
--- repo.iobroker.live.cdn.cloudflare.net ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 35ms
rtt min/avg/max/mdev = 21.048/21.971/23.007/0.634 ms

[wendy2702]

@invidianer Die Antwort Zeiten vom Server sind schon relativ hoch. Liegt zu 99% am Netzwerk oder der Internet Verbindung.

Meine Zeiten liegen deutlich unter 20ms.

Kannst du das auch mal von einem anderen Rechner aus machen der per Kabel an der Fritzbox hängt?

[invidianer]

@da_woody
Danke, aber ich habe allen Geräten, bei denen es möglich ist, sowieso eine feste IP gegeben, DHCP nutze ich nur, wenn es nicht anders geht.

@wendy2702
Wenn ich den Pi per LAN-Kabel anschließe und WLAN deaktiviere, ist es dann trotzdem sinnvoll, ihn paar Meter von der 7590 zu positionieren und ist das dann egal? Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?

[invidianer]

@wendy2702
Hmm, komisch.
Ich mache das vom Mac aus, der hat ein LAN-Kabel zur FritzBox (allerdings ist an ihm auch WLAN aktiviert, z.B. um Airdrop usw. nutzen zu können).
Meinst Du, die langen Antwortzeiten haben etwas mit der Meldung "... Updating repository stable ..." zu tun? Diese ist übrigens nach dem neu Positionieren des Pis (weit weg von der Fritte) um 09:38 Uhr nur noch ein einziges Mal aufgetaucht, nämlich um 10:19 Uhr.

[Thomas Braun]

@invidianer WLAN kann man nicht abstellen auf dem Pi, der funkt immer durch die Gegend. Auch wenn das WLAN nicht konfiguriert ist oder per overlay softwareseitig ausgeknipst ist.

Updating repository stable kommt, wenn z.B. im Info-Adapter die Liste der Adapter neugeladen wird.