1x LED = 7 W x 1 Nacht (8 Std.) = 0,056 kWh = 0,014€
20x Shelly = 20 W x 24 Std. = 0,48 kWh = 0,12€
Kannst du mir die Einsparung irgendwie erläutern?
Naja, es ist ja nicht so, dass der alte Drehdimmer keinen Strom zieht, wenn er nur so eingebaut ist und das Licht aus ist. Es sei denn, er hat eine richtige Endabschaltung und unterbricht den Stromkreis auch für seinen Eigenbedarf. Und bitte nicht 20x Shelly gegenrechnen, sondern in dem Fall nur einen.
Ich hätte da ein Argument gegen die Drehdimmer und für einen Shelly Dimmer mit Taster.
Nach und nach habe ich bereits einige Lichtschalter im Haus umgebaut. Jetzt freut sich meine Frau über Licht, welches automatisch angeht (man hat ja auch mal die Hände voll) und vor allem über Licht, welches auch automatisch ausgeht (bei uns blieb schon ab und zu mal ein Raum die ganze Nacht hell, weil vergessen wurde, das Licht auszuschalten. Habe jetzt eine zeitbasierte Szene "alles aus" und einen mobilen Schalter am Bett, welcher die gleiche Szene schaltet. Nun bleibt kein Licht versehentlich die ganze Nacht angeschaltet). Für die eingesparten Münzen aus der Stromrechnung dann einfach der Frau mal einen Blumenstrauß mitbringen.
Weiß jemand von euch, ob ein 3EM seine "total" power Werte auf "0" zurücksetzt, wenn ich ein Firmwareupdate mache? Ich speichere 1x pro Woche und 1x pro Monat diese Werte mittels eine JSON Abfrage auf meinem Pi, um akkumulierte Werte des Leistungsverbrauches der Wallbox zu messen. Es wäre schlecht, wenn ein "total" Wert von letzter Woche lokal in einer auf meinem Pi angelegten Datei einen größeren Value hat als der neu ausgelesene Wert nach einem Firmwareupdate, da ich immer nur das Delta berechne und den letzten Wert dann wieder nehme und in meiner Datei überschreibe.
Hallo sesei,
7 shellys dicht beieinander - ich sehe da keine Probleme. Die Dinger brauchen nicht viel Bandbreite, wollen nur ein starkes WiFi Signal haben. Du planst 33 shellys. Sieht für mich nicht schlimm aus. Ich habe selber nur 16 im Netz, aber selbst bei 33 darf das problemlos funktionieren.
Wenn du 7 shellys dicht beieinander betreibst, solltest du aber mal die Temperatur der Dinger checken. Da sehe ich eher eine "Problemstelle" als im WiFi (IP) Bereich.
Bei mir läuft diese hier:
Western Digital WDS500G2B0B WD Blue 500GB 3D NAND Internal SSD M.2 SATA
@Pete0815 : ich nutze auf dem Shelly 1PM diese hier:
20210209-101904/v1.10.0-rc2-g0cf9ee3-heads/v1.10.0-rc2Habe ebenfalls dieses Gehäuse mit einer M.2 SSD 500 GB und Raspberry. Das läuft sehr gut, habe Node-Red und Homebridge laufen. Homebridge einmal nativ und zum Spielen noch weitere 2 Homebridge Instanzen als Container. Flash Card habe ich entfernt und nutze nur die SSD.
... Und die Cloudverbindung scheint viel stabiler zu sein als mit Versionen zuvor. ...
Nach 2 Wochen Testsoftware muss ich nun sagen, dass der Shelly 1PM zwischenzeitlich wieder mehrfach Probleme mit der Cloud hatte. Per Browseraufruf und IP/status mit Refresh im Firefox konnte ich sehen, dass der Shelly quasi im 5 Sekundentakt versucht hat, die Cloudverbindung zu erreichen, diese aber immer wieder verloren hat. Nur ein Reboot hilft dann, damit er stabil die Cloud erreicht. Und das passiert nach ein paar Tagen dann wiederholt.
Und mein zweiter Shelly (Shelly 2.5 im Shutter Mode) zeigt genau das gleiche Verhalten.
Ich nutze eine rc2 Version nun schon einige Tage auf einem Shelly 1PM mit Addon. Und die Cloudverbindung scheint viel stabiler zu sein als mit Versionen zuvor. Ich habe die Cloud angebunden, um die Aufzeichnungen von Temperatur und Luftfeuchtigkeit im zeitlichen Verlauf zu sehen. Habe eben dann noch die rc2 auf dem Shelly 2.5 (Rollladen) aufgespielt.
Falls ihr immer wieder Lücken in eurer Sensoraufzeichnung auf einem Shelly mit Addon habt: probiert die rc2 aus. Bei mir läuft diese Version echt gut! Keine Lücken in der History mehr!
dann muss es wohl die v1.9.4 sein. Ich habe seit über einer Woche die v1.10(beta) drauf und die läuft ebenfalls stabil.
Das hatte ich mal so. Aber ich wohne in einem Reihenendhaus und die Nachbargrundstücke sind hier auch nicht weit weg. Mit anderen Worten: ich sehe die WLANs der Nachbarn und wenn diese ihre Kanäle wechseln, dann dachte ich besser damit zu laufen, auch meine dynamisch zu verwalten.
Anyway: ich versuche es mal auf feste Einstellung. Mal sehen, ob das besser läuft. Allerdings finde ich, dass ein Endgerät doch damit zurecht kommen müsste, wenn sich der Kanal ändert.
... noch eine interessante Tatsache: habe eben mal in meiner Fritzbox im Log nachgesehen. Dort meldeten sich heute um 8:18:23 zeitgleich 5 Shellys ab. Zur gleichen Log Zeit meldete sich auch mein AVM2400 ab. Die Shellys, die sich abmeldeten, sind in ziemlicher Nähe zum AVM2400. Und kurz vorher - und das ist das eigentlich interessante - um 8:18:11, da hat sich die Fritzbox im Autokanal von Kanal 6 auf Kanal 11 umgeändert. Also Abmeldung auf Kanal 6 und Anmeldung auf Kanal 11. Dann müssen ja logischerweise die Clients "umziehen". Vielleicht sollte ich mal auf feste Kanäle einstellen?
jjdave : sehr interessant. Ich schaue mal. Normalerweise ist meine WiFi Signalstärke ganz ok, habe neben der Fritze 6591 noch einen Repeater AVM2400 und zwei Meraki MR33. Die Merakis machen natürlich kein Mash, aber zur AVM2400 habe ich Mash.
Schubbie : du bist einer der wenigen, die ein Netzwerk so aufbauen. Finde ich gut. Dann ist es aber auch korrekt, die FW zu resetten, um den ARP neu aufbauen zu lassen.
Die ARP Tabelle sitzt im Router oder eben da, wo dein default Gateway sitzt. Also normalerweise im Router. Allerdings kann man auch eine Firewall als Layer-3 Gateway (Router) nutzen, dann würde ein Reboot dort den ARP Table löschen.
Der ARP Table ist dynamisch im RAM, muss sich also nach einem Reboot neu aufbauen.
Dynamische MAC gibt es nicht, du meinst sicherlich dynamische IP - also DHCP.
Ich habe ein wenig rumprobiert. ...
...
Dann habe ich eine andere feste IP als durch den DHCP-Server zugewiesen in den Shelly eingetragen und dann ging nichts mehr.
Hallo Schubbie,
du hast den ARP Table des Routers damit gestört. Der Router hält sich einen ARP Table (Address Resolution Protocol), indem er entweder selbst gelernte MAC zu IP Zuordnungen dort einträgt oder die aus seiner festen Vergabe einträgt. Nun hatte er eine feste Vergabe, die MAC im Table stimmte aber mit der IP nicht überein, die dort stand, weil der Shelly durch die feste Vergabe nun eine andere IP benutzte. Das muss schief gehen.
Viele Grüße, Torsten
beobachte das mal. Vielleicht tritt der Fehler unter 1.9.2 ja noch nicht auf.
... und Fritzbox als Router ...
sorry, war ofline. Habe v1.9.4 auf dem shelly 1pm
ich kann jetzt ja etwas mehr rumspielen, hängt ja momentan nichts dran. Also habe ich eben den Shelly wieder über seine initiale SSID und 192.168.33.1 mit Browser-GUI ins Netz genommen. Dann Beta v1.10.0 drauf, mit login/pwd gesichert. Ein paar Einstellungen, wie er sich nach einem Stromausfall verhalten soll. Dann das Backup Netzwerk (andere SSID) eingetragen und nach weniger als 3 Minuten war er wieder weg.
Nun über 192.168.33.1/status mit dem Browser drauf, und was sehe ich? Er hat noch meine SSID vom Hausnetz eingetragen, dazu aber die IP 192.168.33.1 und connected:false. Uptime 217, also hat er sich neu gestartet. V1.10.0 ist drauf, hatte ich ja vorher raufgespielt.
habe eben meinen 1PM ausgetauscht. Der neue verhält sich normal. Ich konnte ohne Probleme das v1.10.0er Update draufspielen. Mal sehen, ob der sporadische Reboot mit WLAN Rücksitzen nun auch Geschichte ist.
Naja, ich vermute ein Hardwareproblem. Oder was denkst du?