Beiträge von ostfriese

Nur zur Info: Bei mir läuft das zum Zählen des E-Auto Verbrauchs seit einem halben Jahr in einer neuen Verteilung ohne zusätzliche Sicherungen. Bis jetzt keine Explosion

Ich denke, du hast das korrekt zusammengefasst

Meinte eher, das dem TE das nächtliche Rennen zum Sicherungskasten erspart wird, falls ein Camping-Jünger seinen Elektrogrill und den Wasserkocher unbedingt gleichzeitig braucht

Zitat von Devil

Naja mit Shelly pro 1PM ist das halt auch so ne Sache gerade am Campingplatz wird dann doch mal mehr angeschlossen als die Sicherung hergibt...

Da könnte die Max Power Protection ja ganz nützlich sein..,

Hallo,

die Stromversorgung des Shelly sollte natürlich durch einen Leitungsschutzschalter und einen FI abgesichert werden. Die Spulen können so angebracht werden, dass der gesamte zu messende Strom diese durchfließt. Ob das nun vor oder hinter einem FI ist, ist egal, da es ja keine direkte (elektrische) Verbindung gibt. Zum Nullleiter enthalte ich mich, da kommen bestimmt noch Kommentare von anderen.

Hoffe das hilft.

Zitat von Telemanni

Vielen Dank für die schnelle Antwort.

Ich brauche keine Belehrungen sondern Lösungsvorschläge.

Sollte keine Belehrung sein, sondern nur ein Hinweis. Ansonsten gilt, was @Loetauge gesagt hat.

Wann besteht die Pflicht zum Einbau geeichter Zähler?

Das neue Eichgesetz (MessEG) gilt überall dort, wo im geschäftlichen Verkehr Zähler eingesetzt werden müssen.

Also ist es rein rechtlich schon nicht möglich!!!

Die Schnittstelle dient zum Aufspielen alternativer Software. z.B. Tasmota

Ne, klar jetzt. Ein 100 Watt Trafo mit WebUi in Fünf-Mark-Stückgrröße. Daran arbeiten die sicher schon. Als nächstes kommt dann die 11-kW Wallbox für die UP-Dose

Man könnte für ein paar Cent auch ein (Mini)Relais in den Input setzen, um ein EM-freies Signal hinzubekommen. Ist günstiger als der Elektriker.

Hallo,

hast du evtl. bei einem Reset das falsche Loch erwischt? Wenn man mit einem spitzen Gegenstand in dem, von vorne gesehen, linken Loch herumstochert, kann man den internen Temperatusensor beschädigen, was dann zu der Fehlanzeige führt.

Hallo

das hast du komplett falsch verstanden. Der Shelly ist ein Schalter, kein Trafo. Er kann am Ausgang nur das herausgeben, was am Eingang hereinkommt. Du brauchst unbedingt einen Trafo.

Hallo,

würde bevor ich die kaufe mal das lesen:

Klick

Dreh es einfach so, dass es passt. Passiert ja nichts.

Gleiche Phase ist wichtig, sonst fliegt dir der Shelly um die Ohren.

Ansonsten, 230V an SW wird als On erkannt. Verhalten des Shelly kann man dann im WebIf festlegen.

Zitat von Devil

Der 2.5 kann nur kurzer oder langer Tastendruck

Habe ich nicht gewusst. Habe keinen 2.5 und bin davon ausgegangen, dass das für alle Relais gleich ist. Beim Shelly1 gibt es das. Würde also den verwenden. Damit kann dann alles was der TE will realisiert werden.

Dann wäre die Lösung:

Shortpress Action:

http://lokalhost/relay/0?turn=on&timer=30

Longpress Action:

http://lokalhost/relay/0?turn=on&timer=600

Doublepress:

http://lokalhost/relay/0?turn=toggle

toggle --> erster Longpress schaltet Dauuerlicht, nächster Longpress schaltet Licht aus... usw.

localhost

Was passiert, wenn du den Autotimer mal testweise deaktivierst?

Geht dann der Longpress?

Da wir nichts an der Firmware des TRV ändern können, verfolge ich den Ansatz weiter, die TRV mit dem Zugangspunkt dauerhaft in Verbindung zu halten. Seit ich das so mache, habe ich keine Abstürze mehr.

Ich habe zuerst über diese Option aus der HTTP-Api das TRV wach gehalten: (alle 150 Sekunden an jedes TRV gesendet)

Das hat aber den Stromverbrauch so gesteigert, dass das nicht zielführend war.

In der Api gibt es aber eine zweite Option, von der ich zunächst nicht wusste, was sie bedeutet:

Ich habe dann mal recherchiert:

Hier:

delivery traffic indication message (802.11) (DTIM)

In WLANs nach 802.11 können die Clients zur Energieeinsparung in einem Power-Save-Mode arbeiten. Sie sind dann von der aktiven Kommunikation ausgeschlossen. An sie gerichtete Multicast- und Broadcast- Nachrichten werden im Funkzugangspunkt zwischengespeichert.

Der Access Point informiert den Client während einer Beacon-Periode mit einer Delivery Traffic Indication Message (DTIM) über die zwischengespeicherten Broadcast- und Multicast-Nachrichten und dass der Zugangspunkt sie nach dem Rückwärtszählen eines Zählers übermittelt. Der Zählerstand wird in der Traffic Indication Message ( TIM) übertragen, die dem Beacon-Intervall entspricht, wohingegen das DTIM-Intervall ein Mehrfaches des TIM-Intervalls beträgt. Das DTIM-Intervall, mit dem der Zugangspunkt die DTIM- Nachricht aussendet, kann im Zugangspunkt konfiguriert werden. Der Power-Save-Modus kann vom Benutzer auf dem Client eingestellt werden.

Zusammenhang zwischen Beacon, TIM und DTIM

Der DTIM-Betrieb beeinträchtigt in keiner Weise den normalen Unicast-Betrieb. Er hat auch keinen Einfluss auf den Multicast-Betrieb wenn keiner der an den Zugangspunkt angeschlossenen Clients im Power-Save-Mode arbeitet.

Und hier bezogen auf den verbauten WF200

Deepl Übersetzung:

-----

KBA: WF200 : Erklärung zum Stromverbrauch von DTIM3 und Sleep

Im Datenblatt des WF200 bzw. WFM200 wird der Stromverbrauch von 294μA im DTIM3 als durchschnittlicher Stromverbrauch des WF(M)200 angegeben, wenn kein Datenframe gesendet/empfangen wird (nur Empfang von Beacon mit dem DTIM

Jul 9, 2021-Wissen

Details

Im Datenblatt des WF200 bzw. WFM200 wird die durchschnittliche Stromaufnahme des WF(M)200 im DTIM3 mit 294 μA angegeben, wenn kein Datenframe gesendet bzw. empfangen wird (nur Empfang von Baken im DTIM-Intervall und Verwendung des Ruhezustands).

Mit diesem Verbrauch bleibt der WF(M)200 mit dem Wi-Fi-Zugangspunkt verbunden und ist bereit, Datenrahmen zu senden oder zu empfangen, und geht zwischen zwei Rx-Baken in den Ruhezustand mit einem Stromverbrauch von nur 22 μA.

--------

Und im Datenblatt steht:

Average current for DTIM=10

ILP_DTIM10 VDD_PA pin, VVDD_PA = 3.3 V 118 nA

VDD_RF pin, VVDD_RF = 1.8 V 38 µA

VDD_D pin, VVDD_D = 1.8 V 65 µA

VDD_IO pin, VVDD_IO = 3.3 V 3.7 µA

Das scheint mir nicht sehr hoch.

Bei Verwendung dieses Befehls treten bis jetzt auch keine Abtürze auf, da ja nach der Beschreibung ja das TRV dauerhaft verbunden bleibt und somit der Absturz bei Reconnect vermieden wird.

Muss mir natürlich noch im Dauerbetrieb ansehen, wie sich das auf den Akku auswirkt.

Da ich als Automations-Server eine komplett selbst programmierte Lösung auf einem Raspberry verwende, weiß ich nicht, ob z.B. der Iobroker oder andere Server in der Lage sind, alle 150 Sekunden

http://ip_des_trv/psovrd2

zu senden.

Falls ja, könnt ihr ja gerne mal testen. Ich löse das über ein Python-Skript, welches ich bei Bedarf auch gerne zur Verfügung stelle.

Shelly Plug, Tauchsieder und ein ölgetränkter Lappen