Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[wendy2702]

@invidianer nicht alle Geräte reagieren da empfindlich drauf. Muss man im Einzel Fall testen

[invidianer]

@wendy2702
Okay!
Sicherheitshalber lege ich den Pi aber vermutlich doch in den Kabelkanal unter meinen Schreibtisch. Dort könnte er höchstens das WLAN meines Macs stören, der aber zusätzlich per LAN-Kabel angeschlossen ist (WLAN nur, damit ich AirDrop und andere „Apple-Dinge“ nutzen kann).

[invidianer]

Hmm, der hier will einfach nicht verschwinden:

2021-03-06 13:55:55.234 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connection closed: timeout
2021-03-06 13:56:04.519 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connected with secret 1615035364517_7910
2021-03-06 13:56:04.556 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.command"
2021-03-06 13:56:04.557 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.command"
2021-03-06 13:56:04.562 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.relay.0.command"

[wendy2702]

@invidianer Zu mqtt und Shelly kann ich leider nichts sagen.

Aber sind die Shelly nicht auch per WLAN im Netz?

[invidianer]

@wendy2702
Ja, sind sie. Aber außer dieser Meldung ist rein gar nichts in den Logs, nachdem ich Deinem Rat folgend den Pi weit weg von der FritzBox aufgestellt habe!
Daher muß es sich wohl um ein anderes Problem handeln.

Gut, die bekannten Meldungen vom DWD sind drin (kommen alle 5 Minuten), aber die sind wohl normal und nicht zu ändern (hatte ich schon immer):

2021-03-06 15:05:00.063 - info: host.raspberrypi instance system.adapter.dwd.0 started with pid 14085
2021-03-06 15:05:01.986 - info: dwd.0 (14085) starting. Version 2.7.5 in /opt/iobroker/node_modules/iobroker.dwd, node: v12.21.0, js-controller: 3.2.16
2021-03-06 15:05:06.859 - info: dwd.0 (14085) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2021-03-06 15:05:07.402 - info: host.raspberrypi instance system.adapter.dwd.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)

[wendy2702]

@invidianer Wenn du ja dein WLAN umgebaut hast. Kann es sinn machen den Shelly mal vom WLAN zu entfernen und neu anzumelden damit er einen Kanal und eine Quelle wählt die eventuell für ihn Empfangstechnisch besser ist.

[invidianer]

@wendy2702
Hmm, okay, das geht glaube ich über die Shelly App.
Später im Keller mal schauen. Danke!

Die DWD-Geschichte ist ja normal so, richtig?

[da_Woody]

@invidianer brauchst nur kurz dein wlan abdrehn, dann sollten sich die shellys neu anmelden.

[invidianer]

@da_woody
Hmm, dann kann ich sie ja auch einfach über die App rebooten lassen?
Drehe ich das WLAN ab, sind danach bestimmt wieder einige Geräte nicht an dem nächstgelegenen Router (trotz Mesh kommt es häufiger dazu bei mir).

EDIT: So, Shelly durchgestartet und dabei gleich mal die Firmware upgedated. Mal abwarten ...

EDIT 2: Bisher sieht es gut aus, keine weiteren Fehlermeldungen.

[wendy2702]

@invidianer drücke die Daumen das es so bleibt.

[invidianer]

@wendy2702
Danke Dir! Bisher topp! Habe den DWD-Adapter einfach mal deaktiviert, damit es im Log übersichtlicher ist. Bisher keine einzige Meldung.
Jetzt positioniere ich den Pi mal unter meinem Schreibtisch in dem Kabelkanal, dort könnte er höchstens mein MacBook und/oder die angeschlossene USB-Festplatte stören.

[Thomas Braun]

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

damit es im Log übersichtlicher ist.

Setz das log level doch für die Instanz einfach auf Error oder Warn. Dann sieht man die Info-Meldungen nicht mehr.

[wendy2702]

@invidianer Zum DWD Adapter: ändere den Schedule zur Abfrage auf einen höheren Wert.

Alle 5 Minuten ändert sich das eh nicht.

Oder wie @Thomas-Braun schreibt

[Thomas Braun]

Ich würde beides machen.
Abrufe seltener und Log Level auf Warn.

[invidianer]

@thomas-braun
Cool! Wußte nicht, daß das geht! Nur, wo stellt man das ein? Sorry, habe ich noch nie gesehen, diese Option.

[wendy2702]

@invidianer Hier:

[Thomas Braun]

@wendy2702 @invidianer
Dazu muss der Expertenmodus eingestellt werden. Erst dann wird die Spalte eingeblendet

[wendy2702]

@thomas-braun Stimmt. Ist bei mir quasi "default" deshalb habe ich das vergessen zu erwähnen.

[invidianer]

Supi, dankeschön! Habe das Intervall auf 15 Minuten erhöht und den Loglevel auf "warn".

[Dan.Master]

Hall Zusammen,
ich habe genau das gleiche Problem gehabt beim Umstieg von der 7490 auf 7590 zusammen im Mesh mit 1750e.
Einstellung von der 7490 gesichert und die 7590 eingespielt. (Das geht wirklich schnell).
Es gibt hier zwei Probleme die sich einstellen.

Bei manche der gespeicherten "Geräte" aus der Netzwerkliste, vor allem mit fest zugewiesener IP-Adressse via DHCP, die Geräte konnten sich teilweise nicht mehr einloggen.

Das zweite Problem ich habe alle IOT Geräte in einem anderen Subnetz gestellt 192.168.179.xxx
zusammen mit der Subnetzmaske 255.255.254.0, obwohl das alles bei dem wiederherstellen des "Backups" aus der 7490 mit genommen wurde wird die Maske aber nicht verteilt. Erst ein komplettes neu Parametieren nach Werkseinstellung hat hier die abhilfe geschaffen.
Eins ist aber geblieben, via VPN komme ich nicht an die 179er also die Subnetz via VPN liegt bei 255.255.255.0 was mich gezwungen hat den Broker als einziges in die aus dem IOT 179er in die 178er zu setzten.

Noch eine kleine Info wegen Störstrahlung:
Zitat aus der AVM Wissenensdatenbank:

WLAN- oder DECT-Störungen bei angeschlossenem USB-3.0-Gerät

Ein an der FRITZ!Box angeschlossenes USB-3.0-Gerät verursacht Störungen bei WLAN- oder DECT-Verbindungen zur FRITZ!Box. Die Reichweite der WLAN- oder DECT-Verbindungen wird dadurch deutlich reduziert.
1 USB-3.0-Gerät stört Funkverbindung

USB-3.0-Geräte mit ungenügender Abschirmung können Funkverbindungen von Geräten stören, die sich sehr dicht neben dem USB-3.0-Gerät bzw. dessen USB-3.0-Kabel befinden. Solche Störungen treten in der Regel nur selten und meist nur bei aktiver Datenübertragung über USB und schlecht isolierten USB-3.0-Kabeln auf, die wie eine Antenne wirken und die Abstrahlung des USB-3.0-Gerätes verstärken.

Bei Funkverbindungen verringert sich durch die Abstrahlungen eines solchen USB-3.0-Gerätes die Reichweite, Datendurchsatz und Qualität der Verbindungen. Bei WLAN-Verbindungen ist das 2,4-GHz-Frequenzband betroffen, das 5-GHz-Frequenzband hingegen nicht.

Dieser Effekt betrifft alle WLAN- und DECT-Geräte.

Hinweis:Weitere Informationen zu diesem Thema finden Sie in diesem Artikel der c't sowie in diesem White Paper von Intel auf der Internetseite des USB Implementers Forum.
Workaround

Die auf die FRITZ!Box einwirkenden Abstrahlungen lassen sich durch verschiedene Maßnahmen reduzieren. Führen Sie zuerst die Maßnahme durch, die für Sie am einfachsten umzusetzen ist:
Vergrößern Sie den Abstand zwischen USB-3.0-Gerät und FRITZ!Box. Falls möglich, schließen Sie das Gerät nicht direkt, sondern mit einem USB-3.0-Verlängerungskabel an die FRITZ!Box an.

Verändern Sie die Position des USB-3.0-Gerätes und -Kabels. Verbinden Sie das Gerät testweise auch mit dem anderen USB-Anschluss der FRITZ!Box.

Verwenden Sie ein anderes, besser abgeschirmtes USB-3.0-Kabel.

Ändern Sie den USB-Mode in der FRITZ!Box unter "Heimnetz > USB / Speicher > USB-Einstellungen" auf "Green Mode USB 2.0".

link text

Gilt auch für die 7490

Gruß
DerDani