Beiträge von muety

Zitat

Oder keinen Firefox verwenden

Das klingt nicht nach einer besonders nachhaltigen Lösung.

Gleiches Problem hier! Mein Workaround war, die Schedule Zeiten jetzt "manuell" per Websocket RPC Call zu setzen. Hier scheint ein Problem mit dem UI vorzuliegen.

Zitat

Warum machst Du nicht selbst ein Ticket auf?

Hab ich bereits, aber wenn das mehrere Personen einbringen, wird es vielleicht priorisiert bearbeitet und mehr beachtet.

Ich hab das gleiche Problem! Der Shelly scheint den Verlust der Verbindung auch nicht korrekt zu erkennen, denn Mqtt.GetStatus liefert weiterhin connected zurück.

Vielleicht kann sich ja mal jemand an den Support wenden?

Wollte mir als Workaround ein Script schreiben, das mithilfe eines Timers den Shelly einfach pauschal jede Stunde neustartet. Aber aus irgendeinem Grund hat sich das Script immer nach einiger Zeit selbst wieder deaktiviert.

Zitat

muety :

Sicher dass es kein ShellyPlusPlugS ist?

Sorry, ja, hab die Topic geändert!

Zitat

Aber kannst du uns sagen, was bei dir um 4:50 passiert; du bist bis jetzt der erste der dieses Problem reproduzieren kann.

Ich habe gemerkt, dass das Problem teilweise auch schon um 4:48 oder so auftritt. Das einzige, was an dem Zeitpunkt "besonders" sein könnte ist, dass ungefähr da die erste Sonne rauskommt. Der Plug ist mit einem Balkonkraftwerk verbunden und in etwa um die Zeit (bevor dann keine Daten mehr kommen) sehe ich das erste Mal ein paar Watt Stromproduktion in meinem Monitoring.

Ich habe mal MQTT Debugging aktiviert und einen Tag lang mitgeloggt. Hier ist ein Log Auszug zu der Zeit, ab der ich dann keine Daten mehr bekomme:

shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 16385 1685846845.590 1|shelly_notification:163 Status change of switch:0: {"id":0,"apower":0.0}
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 16386 1685846854.590 1|shelly_notification:163 Status change of switch:0: {"id":0,"current":0.041}
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 16387 1685846856.590 1|shelly_notification:163 Status change of switch:0: {"id":0,"current":0.072}
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 16388 1685846858.590 1|shelly_notification:163 Status change of switch:0: {"id":0,"current":0.000}
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 81 1685867241.029 1|shelly_notification:163 Status change of mqtt: {"connected":true}
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 82 1685867241.907 1|shos_rpc_inst.c:230     shelly.getstatus via WS_in 192.168.178.38:52617 user admin
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 83 1685867241.936 1|shos_rpc_inst.c:230     shelly.getdeviceinfo via WS_in 192.168.178.38:52617
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 84 1685867241.962 1|shos_rpc_inst.c:230     shelly.getconfig via WS_in 192.168.178.38:52617 user admin
shellies/shelly-plug-solar/debug/log shellyplusplugs-d4d4da7beeb0 85 1685867241.979 1|shos_init.c:82          New min heap free: 122492

Zwischen Zeile 4 (2023-06-04T02:47:38.590Z) und 5 (2023-06-04T08:27:21.029Z) liegen knapp 6 Stunden. Der letztere Zeitpunkt (Zeile 5) war dann, als ich mich manuell eingeloggt und das Gerät rebootet hatte. Ich sehe davor keinerlei Hinweise auf das Problem.

Der Wasserzähler in meiner Wohnung ist mit diesem Funkmodul ausgestattet, und ich habe mich gefragt, ob es eine Möglichkeit gibt, die Messwerte prorgammatisch Code abzurufen. Kann mir jemand mit folgenden Fragen helfen?

• Was für ein Empfangsgerät kann ich verwenden, um die Messwerte abzurufen?
• Ist Verschlüsselung involviert? Brauche ich einen Key zum Abruf der Werte?
• Kennt jemand eine Software, die das Ablesen von Wasserzählern dieser Art bereits implementiert?

Ich verwende Firmware Version 1.0.0-beta1 auf meinem Plug S und habe das Problem, dass jeden Morgen regelmäßig um 4.50 Uhr offenbar die MQTT Verbindung verloren geht. Das äußert sich so, dass ab diesem Zeitpunkt einerseits keine Daten mehr rausgeschickt, andererseits aber auch keine RPC Commands über MQTT mehr angenommen werden. Mqtt.GetStatus hingegen gibt mir aber {"connected": "true"} zurück. Was hilft ist dann ein manueller Neustart.

Hat jemand eine mögliche Erklärung für dieses Problem?

Interessant, ich hatte mit meinem Plus 1PM gestern das exakt gleiche Problem! Nach dem Reboot war der energy total counter plötzlich um ca. 2.6 MWh. höher. Ich habe dann letztendlich einen Factory Reset durchgeführt und seither ist das Phänomen nicht wieder aufgetreten. Mein Setup ist genau wie das von GrobiMotorik, insbesondere auch keine FIs, mit dem einzigen Unterschied, dass der Shelly in der Steckdose sitzt und nicht im Schaltschrank. Firmware ist 0.11.0 Beta 2.

Ich bin gerade durch Zufall über diesen Thread gestolpert und habe interessiert mitgelesen. Ich verwende ebenfalls einen 1 PM Plus an meienm Balkonkraftwerk, hatte jedoch noch nie das Problem, dass er sich von selbst ausgeschaltet hat. Welche Gründe sprechen denn ansonsten noch gegen einen 1 PM Plus und stattdessen für einen EM?

Thanks a lot, very helpful! In the meanwhile, I am actually considering to use a fully-fledged three-phase power meter (like this one) instead of one or multiple Shellies 🤔.

Did you find an answer to this? I'm wondering the same.

Hi all!

I want to buy a Shelly Pro 1PM to measure the net power consumption of my apartment. Almost my whole apartment runs on the same circuit (apart from bathroom and stove), so the measurements produced by that sensor will capture the consumption quite accurately.

I also have a solar panel on my balcony, which is on the same circuit, so the sensor will actually give me my net balance, i.e. consumption minus production.

What if I go negative though, i.e. if there is higher production than consumption? Can the sensor produce negative power draw measurements? Is that even physically possible? The Plug S for example only produces unsigned values. Is there a way to know whether I'm consuming or producing 100 Watts at the moment, if producers and consumers are on the same circuit / same fuse and it's infeasible to observe every single wall socket separately?

Okay, der Support hat mich darauf hingewiesen, dass meine Firmware Version veraltet ist. Offenbar hat der Plug die neue Version nur nicht von alleine gefunden und ich musste ein manuelles Update machen. In der neuen Version 1.18 scheint der Fehler behoben zu sein.

Ich hab' mir mit der FritzBox mal einen tcpdump rausgelassen und in WireShark angeschaut, was der Plug bei einem Reboot so tut, wenn er Internetzugriff hat.

1. Der eingetragene NTP Server (de.pool.ntp.org) wird korrekt verwendet
2. Zusätzlich passiert aber noch ein HTTP Request an http://api.shelly.cloud/timezone/tzinfo?tz=Europe/Berlin&time=1659601475&fw=201, um irgendwelche Informationen über die Zeitzone abzurufen. Die Antwort darauf sieht so aus:

{
  "isok": true,
  "data": {
    "utc_offset": 7200,
    "is_dst": true,
    "has_dst": true,
    "next_dst_shift": 1667091600,
    "next_utc_offset": 3600
  }
}

Wenn ich also UDP Port 123 (NTP / SNTP) in meiner Firewall freigebe, würde zwar der NTP Request funktionieren, der oben gezeigte HTTP Request nicht. Ich vermute, dass der Plug beides haben möchte, um die Uhrzeit zu setzen. Man könnte also zusätzlich api.shelly.cloud für HTTP in der Firewall erlauben. Das will ich jedoch nicht.

Ein weiterer Workaround könnte aber folgender sein (noch nicht ausprobiert):

• Für den Request an die Shelly API wird HTTP verwendet, nicht HTTPS, d.h. insbesondere wird nicht überprüft, ob der Zielserver auch tatsächlich zur Domain gehört
• Man könnte nun einen eigenen Webserver bereitstellen, der immer die oben gezeigte Antwort liefert (mit korrekten Timestamps)
• Man müsste dann den verwendeten DNS Server (konfiguriert per DHCP) so einstellen, dass er für http://api.shelly.cloud meine eigene IP (sh. voriger Schritt) zurückgibt
• Wenn ich dem Plug nun die Internetverbindung nehme und nur die IP meines Webserver whiteliste, dann würde die oben gezeigte HTTP Anfrage trotzdem korrekt funktionieren, auch wenn die Shelly API niemals erreicht wird

Da man in der Firmware aber keinen custom DNS Server konfigurieren kann, ist das ziemlich umständlich und vermutlich den Aufwand nicht wert.

Hi zusammen!

Ich habe gerade die (mittlerweile 3 Jahre alte) Konversation verfolgt. Ich habe mit meinem Shelly Plug S (firmware 20190516-073020/master@ea1b23db) das gleiche Problem und die gleichen Beobachtungen angestellt.

Weder einen NTP Server aus meinem lokalen Netzwerk zu konfigurieren, noch "de.pool.ntp.org" als Zeitserver zu verwenden und entsprechend in der Firewall zu whitelisten, hat das Problem behoben.

Ich habe nochmals den Shelly Support kontaktiert und hoffe auf eine Antwort.