Beiträge von StefLanT

Ich lasse in den letzten Wochen bei meinen Geräten die UDP Logs mitlaufen und kann Borstis Aufzeichnungen bestätigen.
(bei mir holen sich die Geräte ihre NTP Zeit von fritz.box)

Ergänzung:
- PlusSmoke: alle ~24h (beim täglichen "Aufwachen")
- PlusPlugS: alle ~30min
- Plus Bluetooth Gateway: alle ~30min

Eine typische Log-Zeile sieht dann so aus:

2025-12-18T22:03:39.189404+01:00 shellyblugw-xxxxxxxxxxxx 54987 306796.797 2 2|shos_time.c:58          Setting time from SNTP (1766091819.143 delta -0.926)#000shellyblugw-xxxxxxxxxxxx 54988 306796.797 2 2|shelly_sys.cpp:290      Time set to 306796.755357 from 1#000shellyblugw-xxxxxxxxxxxx 54989 306796.797 2 2|shelly_notification:164 Status change of sys: {"last_sync_ts":1766091819}#000shellyblugw-xxxxxxxxxxxx 54990 306796.797 2 2|shelly_notification:164 Status change of sys: {"time":"22:03","unixtime":1766091819}

Zitat von hajueschmitz

Was mir jetzt auffällt: öffentliches Netzwerk ?
Wlan wird als privat angezeigt, Ehternet als öffentlich.

Okay - könnte die Erklärung für die Einschränkungen bei der Kabelgebundenen Verbindung sein. Im unten verlinkten Artikel steht eine Anleitung, wie das geändert werden kann.

Offen bleibt, warum die DHCP Zuweisung der Fritzbox nicht richtig von W11 umgesetzt wird - bin da leider auch ratlos.

Microsoft-Erklärung zu öffentlich / privat:

Zitat

Ein Netzwerk öffentlich oder privat machen
Wenn Sie zum ersten Mal eine Verbindung mit einem Netzwerk in Windows 11 herstellen, wird dieses standardmäßig als öffentlich festgelegt. Dies ist die empfohlene Einstellung. Sie können sie jedoch je nach Netzwerk und gewünschter Vorgehensweise als öffentlich oder privat festlegen:

Öffentliches Netzwerk (empfohlen). Verwenden Sie dies für Netzwerke, mit dem Sie zu Hause, auf der Arbeit oder an einem öffentlichen Ort eine Verbindung herstellen. Sie sollten dies in den meisten Fällen verwenden. Ihr PC wird für andere Geräte im Netzwerk ausgeblendet. Daher können Sie Ihren PC nicht für die Datei- und Druckerfreigabe verwenden.

Privates Netzwerk. Ihr PC ist für andere Geräte im Netzwerk erkennbar, und Sie können Ihren PC für die Datei- und Druckerfreigabe verwenden. Sie sollten die Personen und Geräte im Netzwerk kennen und vertrauenswürdig sein.

Aus: https://support.microsoft.com/de-de/windows/…e0-73431160a1b9

Moin,

mir ist in der Unterhaltung aufgefallen, dass in der Ausgabe von ipconfig /all die Zuweisung der 169er IP Adresse als "Auto Konfiguration" und "Bevorzugt" gekennzeichnet ist. [IPv4-Adresse (Auto. Konfiguration): 169.254.5.198(Bevorzugt)]
Das deutet an sich darauf hin, dass das System entweder

• keine Adresse vom DHCP Server der Fritzbox zugewiesen bekommt und als Rückfall auf Auto. Konfiguration geht.. Kann viele Gründe haben:
  Windows-Firewall blockt,
  MAC der Netzwerkkarte in der Fritzbox blockiert (wenn diese mit Ubuntu läuft, scheint das nicht der Fall zu sein),
  irgendwelche Filter in einem (Smart-)Managed Switch (ICMP ist oft eine heiße Spur), etc..
• die Methode der Adressvergabe in Windows die Version "Auto Konfiguration" gegenüber "DHCP" bevorzugt.
  Mir ist aber nicht bewusst, wo man das in W11 ändern könnte...

Was macht der Laptop denn bei manueller Vergabe der IP? Lässt sich der Shelly per Ping/Tracert und über HTTPS erreichen?

Hier eine kleine Ergänzung für die Anwender, die die UDP Logs diverser Shellys auf ein Windows System bekommen und auswerten möchten:
Ich bin auf den "Visual Syslog Server for Windows" aufmerksam geworden und habe das Programm kurz getestet - es ist in der Lage die Logs von Plus2PM, PlusPlugS und PlugS Gen3 (wahrscheinlich auch aller anderen) zu empfangen.

Link: https://maxbelkov.github.io/visualsyslog/

Disclaimer: Ich habe nichts mit der Seite und dem Programm zu tun und leiste auch keinen Support dafür. Nutzung auf eigene Gefahr!

Update:

ich habe jetzt einen Plug S gen.3 seit gut 24 Stunden mit der Firmware 1.7.4-beta1 laufen - bisher keine Neustarts incl. Core Dumps vorgekommen.
Ich werde in den nächsten Tagen mal die anderen mit den Updates versorgen und berichten wie sie sich verhalten.

Nur der Vollständigkeit halber: Alles auf eigene Gefahr!

Ich kenne zur Zeit nur das folgende Vorgehen, eine Firmwaredatei herunterzuladen:

• Im Webinterface des Gerätes unter Diagnostics die Konsolen-Ausgabe für Debug Daten aktivieren.
• Unter Settings -> Firmware nach Updates suchen.
• In der Konsole steht nun irgendwo eine URL für deinen Shelly, die ähnlich dem Screenshot aussieht:
  (hier als Beispiel für einen PlugS gen3)
  
  Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
• URL in den Browser kopieren und aufrufen.
  Dort findest Du jetzt eine URL mit welcher Du eine Datei herunterladen kannst.
  
  Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
• Umbenennen in *irgendwas*.ZIP.
• Diese Datei solltest Du dann manuell flashen können.

Gruß, Stefan

Zitat von HKaufmann

zu #6 : -89 siehe Bild

zu #8-#9 : nur ein Router Vodafone TG3442DE.

Da treffen wohl mindestens zwei Probleme aufeinander...
Der Shelly PlugS gen3 hat ein anderes (weniger leistungsfähiges) Antennenlayout als die Vorgänger und der WiFi Teil der Vodafone Box ist auch besch... nicht der Beste.
Wenn sich bei Dir in der 2,4GHz Umgebung noch andere Nutzer tummeln, kommt es zu Verbindungsabbrüchen - wenn keine anderen WLAN Netze messbar sind, *kann* man auch bei einer Signalstärke bis -90dBm eine stabile Verbindung haben (ist heutzutage wohl eher selten).

Wenn Du die Möglichkeit hast einen AP zu leihen und diesen per Kabel an die Box anzuschließen, wäre das die Variante, die ich Testen würde...

Ich bin kein Programmierer, aber da sind ein paar Syntaxfehler drin - wie nicht geschlossene Klammern / geschweifte Klammern und die unvollständige Bedingung "if (Shelly.get<ctrl62>".

Ich muss zugeben, dass ich keine Ahnung habe, ob es möglich ist, alle möglichen Wege (zB. Schalter, API, Webhook) den Ausgang einzuschalten in einem Skript abzufangen und zu verzögern - vom Gefühl her tendiere ich daher dazu, das Senden des Einschaltbefehls zu kontrollieren.

Du könntest eine "Kette" erstellen, bei der Gerät(A) das Gerät(B) nach einer Verzögerung einschaltet, wenn eine bestimmte Last anliegt.
Bitte nur als Beispiel verwenden und selbst weiter entwickeln. Bestimmte Bedingungen (zB Gerät nicht online), oder das Ausschalten der Lichter muss man da noch einarbeiten.

Beispiel:

// Geräte-IP-Adressen
let deviceA_IP = "192.168.1.10";   // ANPASSEN AUF EIGENE IP - nur zur Info, nicht benötigt. Script läuft auf diesem Gerät (A)
let deviceB_IP = "192.168.1.11";   // ANPASSEN AUF EIGENE IP - Gerät (B), welches eingeschaltet werden soll

// Einstellungen
let threshold = 50;      // 50 W - bei dieser Last von Gerät (A) wird Gerät (B) eingeschaltet
let delay_ms = 500;       // 500 ms - Verzögerung
let pending = false;      // verhindert mehrfaches Auslösen

// Prüfen der Leistung von Gerät A
Timer.set(1000, true, function () {
  let status = Shelly.getComponentStatus("switch:0");
  let power = status.apower;

  if (power >= threshold && !pending) {
    pending = true;

    Timer.set(delay_ms, false, function () {
      Shelly.call(
        "HTTP.GET",
        { url: "http://" + deviceB_IP + "/rpc/Switch.Set?id=0&on=true" },
        function (resp, err) {
          if (err) {
            print("Fehler beim Einschalten von Gerät B:", err);
          } else {
            print("Gerät B wurde eingeschaltet.");
          }
          pending = false;
        }
      );
    });
  }
});

Moin Guido,
bist Du mit den Geräten auf dem neusten Firmwarestand?
Bei mir sieht der Status für die Cloud im Webinterface auf allen Shellys folgendermaßen aus:

Gruß, Stefan

Check vorher mal, dass Linux-System und Shellys die selbe Zeitzone haben - es kann Kopfschmerzen machen, wenn die Zeiten nicht übereinstimmen

Hi Schreckus,

...nicht so kompliziert denken

In einem Linux-System konfigurierst Du den rsyslog Dienst in der Datei /etc/rsyslog.conf. Um dem Dienst mitzuteilen, dass er Logeinträge auf dem Port 514 annimmt, fügst Du die Zeilen

module(load="imudp")
input(type="imudp" port="514")

dort ein und startest den Dienst (oder das System) neu. Jetzt nimmt rsyslog Logeinträge von jedem System an und schreibt sie in die Datei /var/log/syslog.

In deinen Shellys gehst Du im Web-Interface in Settings->Debug und trägst in Destination die <IP Adresse Deines Linux Systems>:514 ein

Auf Deinem Linux System kannst Du dann im Terminal live die Meldungen Deines Shelly mit dem Befehl

tail -n 9 -f /var/log/syslog | grep -e 'shelly'

verfolgen.

--Stefan

Moin Meierchen,

die HTTP Requests sind je nach Modell unterschiedlich - da ich in Deiner Frage keine Infos zu dem Gerät sehe, hier eine Übersicht mit allen Modellen:
https://shelly.guide/webhooks-https-requests/

Viel Erfolg!

Hallo zusammen,

vor einiger Zeit habe ich mir 2x 5 Stück Plug S gen.3 zugelegt, um Verbrauchsmessungen (oder -Schätzungen) zu machen und einige Zeitschaltuhren zu ersetzen.
Version der Firmware bei Auslieferung war 1.2.3, Update erfolgte erst auf den 1.6er Zweig, dann auf die 1.7 Version.

Bei einem Gerät fiel mit auf, dass "grundlos" das angeschlossenen mobile Klimagerät wiederholt plötzlich ausgeschaltet war. Der Unterschied in der Konfiguration von anderen Plugs war die Option "Standard-Einschaltzustand": bei dem Klimaerät "Off", bei anderen Geräten "letzten Zustand wiederherstellen". Zu diesem Zeitpunkt war schon die Firmware 1.7.0 installiert.

Aus Neugier habe ich den Standard-Einschaltzustand bei einem anderen Gerät (1.7.0) ebenfalls auf "Off" gesetzt, dauraufhin zeigte der Plug das selbe Verhalten.
Um herauszufinden habe ich die rsyslog des Linux-Systems in meinem OpenHAB Server aktiviert und als Ziel für die UDP Logs des ShellyPlugS eingestellt. Dort war dann zu sehen, dass in unregelmäßigen Abständen CoreDumps / Reboots aufgezeichnet wurden. Mein Wissen reicht nicht aus, um aus diesen Aufzeichnungen etwas herauszulesen, daher habe ich ein Ticket beim Shelly-Support geöffnet - der Support bat dann das UDP logging auf den Support Server umzustellen - seitdem gehen die Aufzeichnungen auf den Shelly Server.

In den letzten Wochen habe ich mit anderen Plugs und verschiedenen Firmwareversionen und unterschiedlichen Verbrauchern getestet (da 5x Weiß und 5x Schwarz vermute ich, dass die Geräte aus verschiedenen Produktionschargen stammen):
- 1.2.3 läuft stabil ohne Reboots/CoreDumps
- 1.7.0, 1.7.1-beta1 und 1.7.2-beta2 starten unregelmäßig neu und schreiben CoreDumps.
- Shelly Plus2PM und Shelly PlusPlugS mit Firmware 1.7.0 zeigen dieses Verhalten nicht.

Bei einer Suche im Internet habe ich nichts zu diesem Verhalten gefunden... Hat vielleicht hier jemand etwas gleichartiges wahrgenommen?
Ich überlege mittlerweile, ob ich eventuell in meinem Netzwerk eine Komponente haben könnte, die so ein Verhalten triggern könnte???

Gruß, Stefan

Hallo CP,

Ich habe seit Montag einen Plug S gen.3 mit Firmware 1.2.3 und aktiviertem UDP logging laufen - keine Core Dumps.

Gleichzeitig habe ich ein Gerät erst für 2 Tage mit 1.2.3 laufen lassen (keine Dumps) und diesen dann auf 1.7.1-beta1 geupdatete, ab da wurde mehrmals pro Tag ein CoreDump ins Log geschrieben.

Die Info habe ich an mein Ticket angehängt, aber bisher keine Reaktion. Vielleicht kommt ja nächste Woche was von Shelly....

Gruß, Stefan

Hallo Schreckus,

die Kurzfassung: Wenn Du ein Debian/Ubuntu basiertes Linux System hast, sammelt rsyslog dort alle Log Dateien zum System. In der Konfigurationsdatei /etc/rsyslog.conf kannst Du einstellen, dass rsyslog auch Daten von externen Systemen aufnimmt (Dokumentation: https://www.rsyslog.com/doc/configuration/index.html). Gibst Du in einem Shelly als Zieladresse Dein Linux-System an, schreibt rsyslog die Log-Meldungen Deines Shellys in /var/log/syslog. Filtern und Anzeigen kannst Du am einfachsten in einem Terminal mit den Befehlen "tail" und "grep"

Beispiel:

tail -n 99 -f /var/log/syslog | grep -e 'shelly'

...ich hoffe, dass Dir diese Kurzfassung genug Futter für eine Google Suche gibt

Gruß, Stefan

PS: Systeme wie Home Assistant oder openHAB laufen oft auf Linux Systemen, die dann auch schnell mal diese Logs aufnehmen können.

Hallo CP,

ja - bei 1.7.0 hatten meine Geräte auch schon dieses Verhalten. Ich will das nächste Woche mal mit einem Gerät im Auslieferungszustand (ich glaube 1.2.3???) gegenchecken.

Ich habe bisher noch nichts zu diesem Problem über Google finden können - sollte jemand weitere Infos dazu haben, bin ich auch interessiert.

Wenn sich bei dem Ticket etwas tut, gebe ich die Infos hier weiter.

Gruß, Stefan

Hallo CP,

habe ein ähnliches Verhalten bei diversen Shelly Plug S gen.3 1.7.1beta - das System auf den Geräten stürzt ab und erzeugt beim Reboot einen Core Dump. Nach dem (schnellen) Neustart, sind sie wieder problemlos erreichbar. Den Dump kann ich per rsyslog auf ein Linux System leiten und sehe so, dass die Abstürze zwischen "alle paar Tage" bis zu "mehrmals am Tag" auftreten. Eine für mich erkennbare Systematik ist nicht dahinter.

Ich habe hierzu schon ein Ticket bei Shelly geöffnet, der Fehler ist bestätigt worden, aber weitere Rückmeldung habe ich nicht.

Bei Shelly PlusPlugS 1.7.0 und Shelly Plus2PM 1.7.0 tritt dieses Verhalten nicht auf.

Gruß, Stefan