An den Farbunterschied hätte ich jetzt nicht gedacht - obwohl es bis zu einem gewissen Grad plausibel erscheint.
Ich dachte da aber auch an eine mögliche Eigenerwärmung die bei den unterschiedlichen Geräteklassen designbedingt vielleicht vorhanden ist - mir kommen aber bei einem "Temperaturmessgerät" ~1.5°C unterschied trotzdem sehr viel vor.
Beiträge von borsti0
-
-
HI MLAN1984 , willkommen im Forum.
Da dein Haus ja schon 146 Jahre alt ist hoffe ich dass deine Lampen nicht mehr mit Gas betrieben werden 😁.
Ist sicherlich interessant so eine alte Installation etwas "smarter" zu machen. -
OK, das ist auch ne wichtige Info: "in der Shelly App registriert" - also User die die Shelly-Geräte OHNE App verwenden würden da rausfallen, müssen diese somit noch "schnell" in der App registrieren...
-
...Mit welcher Shelly Outdoor Plug S Gen3 FW-Version, wie gut ist der WLAN-Empfang (RSSI)
-
Was bedeutet denn die "Service version", kann die separat upgedated werden?!? Bei meinen Shelly's ist diese Spalte gar nicht vorhanden.
-
Flash wäre für diesen Anwendungsfall m.M.n. nicht sonderlich gut geeignet wegen der vielen Schreibzyklen.
Und das ist genau der Punkt: Mit einem "groß genugen Flash", einer relativ geringen Schreibrate und einem Schreiben "im Ringpuffer" bekommst du die Schreibrate pro Zelle SEHR weit runter.
Rechenbeispiel:
Angaben: 14400 Werte für 10 Tage
Schreibmengenberechnung:
14400 Werte/10Tage * 4bytes (float) * 365 Tage * 10 Jahre (Lebensdauer) = 5.625kB/Tag * 365 Tage * 10 Jahre = ~20MB geschrieben innerhalb von 10 Jahren
Der Shelly EM Mini Gen4 hat ein internes Flash von 8MB, werden nur 1% davon (= ~80kB) als Ringpuffer verwendet, dann werden diese Zellen jeweils nur ~250x beschrieben was BEI WEITEM innerhalb der erlaubten Schreibzyklen liegt. -
Ich habe selber zwar keinen TopAC Portable EV charger 11kW EVE01-11R, aber es scheinen zumindest alle deine Häkchen die du auch in der App gemacht hast auch hier so gesetzt zu sein.
Wenn sich kein User hier meldet um das auch bei ihm auszuprobieren solltest du wohl ein Ticket bei Shelly aufmachen, vielleicht ist das ja ein bekanntes Problem. -
OK, ich habe mal die KI befragt was "die glaubt" wie das scheinbar läuft, und es scheint mir zumindest plausibel da wir selber auch ein ähnliches System angedacht hatten:
Lt. KI:
Die Daten werden "simpel" im internen Flash gespeichert.
Vermeidung der Überschreitung der Schreibzyklen:
- Aufzeichnung "nur" im Minutentakt
- Speichern nur Blockweise
- Wear-Leveling => wir hätten hierfür auf ein Dateisystem gesetzt welches quasi alle Dateien in einem "Ringpuffer" schreibt und relativ Resourcenarm, für Flash optimiert und vor allem auch Spannungsausfallsicher gewesen währe. -
Ich meinte ob die Einstellungen auch "gleich" sind wenn du im Handy/Desktop-Browser direkt auf die IP-Adresse des Gerätes gehst und somit die Cloud komplett "umgehst", z.b. für meinen Shelly 3EM-63W Gen3:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Kleines Sidequest:
Es sollte auch möglich sein eine Einspeisung auf der Dose 0 und das Schalten der Dosen 1-3 am GLEICHEN Shelly Power Strip 4 Gen4 mittels Actions zu lösen und das somit komplett "offline" zu lösen.
z.b.: Bei meiner Shelly Plug PM Gen3 kann ich eine Aktion bei "Power > X Watts" auslösen -
Sieht man im Webinterface des TopAC Portable EV charger 11kW EVE01-11R andere Einstellungen als in der Shelly-App?
-
Also wenn da nicht irgendwo im Hintergrund eine Automatisierung läuft, dann fasse ICH das als "Bug" auf - denn es muss schon mir (oder in dem Fall hald dir
) überlassen sein WANN ich das Laden anstarten will. -
"Leider" ist in den letzten 20-30 Jahren IT so gehandhabt worden wie wenn es keine "Bösen Leute" gäbe. Dadurch konnte man relativ simpel einen z.b.: HTTP (ohne "s")-Server mit minimalen Aufwand betreiben. Als dann die "Bösen Leute" kamen konnten sich viele noch mit einer guten Internet-Firewall (meist im Router) und HTTPS behelfen.
Nun wurden aber die internetfähigen Geräte IM Haushalt so viele (>>>10), dass auch eine Router-Firewall nicht mehr hinreichend ist, da ein "Angriff" auch von innen kommen kann => somit muss man sich nun auch im internen Netzwerk bei JEDER Kommunikation Verschlüsseln + Verifizieren, sodass kein Teilnehmer den anderen "Angreifen" kann.
Im privaten Bereich ist das jedem ja noch fast egal, aber im Firmenbereich, in der Produktion, bei Kraftwerkssteuerungen, welche im Wesentlichen ähnliche Komponenten verwenden, ist das bei Weitem nicht mehr so lustig.
Darüber hinaus können auch die privaten "Smart"-Geräte super in ein Botnetz verwendet werden.
Es MUSS nun irgendwann mal zumindest ein Anfang gemacht werden um zu verhindern dass nicht "Smart"-Geräte im Internet herumgeistern welche eine >20 Jahre alte Firmware besitzen.
Der Umstieg wird für DIY bis zu einem gewissen grad "schmerzlich", lässt sich aber leide nicht verhindern.
Und ich glaube dass vor allem Firmen wie Shelly, welche dir ja die "Smarten" Vorteile bringen und sich ab 2027 nun gleichzeitig auch noch das Security-Thema kümmern MÜSSEN (=> sind wir ehrlich: ICH kann und will mir das nicht selber umhängen müssen), der DIY-Gruppe immer noch eine sehr gute Platform bieten werden. -
Ich nehme auch an dass es da u.u. sogar einen ZWANG für die Kunden gibt upzudaten. Interessant ist aber für Shelly auch was sie mit den Shelly Gen1 machen werden. VERKAUFEN tun sie die ja nicht mehr, aber wenn sie an den Schnittstellen für Gen2+ herumreißen ist die Frage ob sie Gen1 auch wirklich noch sauber mitsupporten können.
=> Auch ein alter Gen1 mit aktueller (aber alter) Firmware kann ein "Einfallstor" ins Shelly-Verse sein -
"Secure by Default" heisst im Übrigen NICHT "Secure by Zwang"!
Naja, mit dem "cyber resilience act" kommen schon fiele ANFORDERUNGEN von der EU hinzu, soweit ich eben auch weiß dass man seine Produkte absichern muss. Somit ist das nicht "Freiwillig" oder "Mutwillig" => wenn sich Shelly nicht daran hält dürfen sie in der EU meines wissens die betroffenen Produkte nicht mehr verkaufen.
Im Übrigen: Das kann dann auch dazu führen, dass User keine Firmware-Updates (auf die Firmware mit dem "Breaking Change" und nachfolgende Versionen) mehr durchführen können, weil sie das alte Verhalten beibehalten wollen/müssen. Und wenn dann z.B. in einer späteren Firmware (z.B. 1.7.9) ein wichtiger Security- (oder Safety-)Bugfix reinkommt, dann können diese User (weil sie "auf ewig" auf 1.7.4 bleiben müssen) davon nicht profitieren.
Kann derjenige schon machen - aber spätestens wenn man ein neues Produkt ab 2027 (Dezember?) kauft muss ja diese neue FW-Version sowieso vorinstalliert sein.
Die Funktion "Sobald ein AP-Passwort festgelegt wurde, kann es nicht mehr auf leer (offenes AP) zurückgesetzt werden.", finde ich sehr schlecht. Es kann durchaus Gründe geben, warum man KEIN AP-Passwort haben will. Wenn man jetzt aus Versehen doch eines setzt, muss man – durch den Feature Change – immer einen Werks-Reset machen (und ich hoffe, dann wird das PW wieder auf leer gesetzt!) – und damit dann alle anderen Settings (Skripte, usw.!) sehr aufwändig wieder konfigurieren/eingeben.
Nein, ich finde es gibt KEINE Rechtfertigung ein WLAN-Gerät/Webinterface/Zugang ohne Passwort zu betreiben. Das haben sie auch schon bei den Routern gelernt: Beim ersten Mal einschalten wird man GEZWUNGEN ein Passwort für alles wichtige zu vergeben und es ist "nicht erlaubt" das wieder zu löschen.
=> Somit sollte man den User dazu "zwingen" ein PW zu vergeben bevor überhaupt noch anderweitige Automatisierungen überhaupt möglich sind. Das ist mittels Shelly-App wahrscheinlich sogar automatisierbar (=> gib hald jedem Shelly-Device das GLEICHE AP-Passwort welches im Account vom User definiert werden muss).
Das gehört meiner Meinung nach dazu wenn man Geräte hat die sich im Internet befinden. -
glaub nicht dass Shelly's ihren "eigenen Verbrauch" mitmessen - aber trotzdem: ein Shelly braucht ca. 1-2W => nach 1h würdest somit 1-2Wh angezeigt bekommen.
Was ICH aber habe:
Mein Shelly 3EM-63W Gen3 meldet auch auf den Phasen wo GAR KEIN Draht durchgeführt wird ~3VA "verbrauch". Es werden 230V und ~14mA (=> Strommessungs-Toleranzen) gemessen, was eben etwas Leistung ergibt. Lt. dem integrierten Energiezähler auf dieser Phase habe ich sogar einige Wh "zurückgespeist"
. Meine Werte sind aber deutlich unter deinen 11Wh. -
Jeder soll doch den "Schalter/Taster" haben den er gerne haben will. Natürlich "reicht" ein simpler Schalter/Taster für einen Shelly, aber dieser Busch-Jäger-Schalter macht hald mehr und ist hald auch schon vorhanden.
Ob dann Automatisierungen im Shelly-Verse oder mittels Jung/BuschJäger gemacht werden, das soll doch hier mal egal sein. Die Frage ist ja: ist es MÖGLICH den BJ weiterhin as Bedienelement zu verwenden?
Frage an Karsten :
Hast du schonmal im Webinterface (NICHT in der App) nachgeschaut ob das Schalten des Inputs erkannt wird?
Lt. KI hat der Einsatz 6418U einen "Elektronischen" Schalter und keinen potentialfreien Schalter.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
=> Wenn das stimmt, dann hast du u.u. das Problem dass die Eingangsschaltung von Shelly bei "digitalen Ansteuerungen" ohne komplett potentieller Trennung oft sowohl bei 0V als auch 230V einen "aktiven Eingang" erkennt.
Ein 6411U-Einsatz würde demnach mit einem Shelly Plus 2PM funktionieren.
U.u. kann hier auch ein Bukowski-Draht helfen, weiß aber nicht ob das schon wer bei so einer Schaltung probiert hat.
-
Die Spannungswerte überwachen ja im Wesentlichen nur dein Hausnetz, welches ja je nach Strom-Last und -Produktion schwankt. => Die Spannungswerte finde ich an sich deswegen auch "irrelevant", da du ja eh nichts dagegen machen kannst.
Die Last-Werte (Over-Current/-Power) sind da schon "Sinnvoller".
Ich habe die Werte bei meinen Rollos empirisch ermittelt und jedes mal um einige % hochgedreht. Hab dann hald ein paar Tage/Wochen lang immer wieder einmal warnings bekommen, aber nun sind diese aufs "Minimum" eingestellt.
Ich hätte ja die Hoffnung dass die Werte mal bei Verschleiß/Blockade das Rollo "retten", mal schaun...Meine Werte:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Auch wenn es hier wohl nicht sinnvoll ist: könnte man die Uhrzeit per Action + HTTP-Request zwischen den beiden Geräten "transferieren"?
-
Vermutlich kommt aber das nächste Problem, wenn der Shelly abschalten soll, denn ich hab (ganz clever, dachte ich) Sonnenauf- bzw. Untergang als Schaltzeitpunkte gewählt. Die nicht dumme Frage meines Mannes gerade, woher der Shelly denn weiß, wieviel Uhr es ist, und wann die Sonne unter- und aufgeht, wenn er keine Netzverbindung hat, hat mich kurzzeitig aus meiner Euphorie dass es funktionier hat wieder herauskatapultiert. Das wird vermutlich nicht gehen?
Den Sonnenauf/untergang kann man hinreichend genau aus dem Datum + Uhrzeit berechnen. Es wird anscheinend im Shelly-OS dafür eine Funktion zur Verfügung gestellt.
Es wurde hier in mehreren Threads bereits diskutiert dass manche User das Problem haben dass "manche Geräte" zu einem anderen Zeitpunkt als "der Rest der Geräte" schalten:
Anscheinend verwenden da aber nur Gen1-Geräte eine andere Implementierung als Gen2+-Geräte => auch das deutet darauf hin das die Berechnung lokal und nicht in der Cloud gemacht wirdNach dem Einschalten benötigt der Shelly Internetzugriff um die aktuelle Uhrzeit per NTP zu beziehen. Man kann NTP auch lokal z.B. per Router bereitstellen. Das funktioniert bei dir natürlich nicht. Notfalls kann man die Uhrzeit im lokalen WebUI auch über den Browser setzen. Technisch bedingt wird diese aber über die Zeit nach und nach ungenau.
Wenn kein RTC-Modul vorhanden ist muss man einem OS die Zeit bei jedem Boot mitteilen, welche dann zur Laufzeit "weitergerechnet" wird. => dies muss bei jedem Neustart gemacht werden.
Problem:
Auch mit einem 1-maligen Sync driftet die berechnete Uhrzeit mit der Zeit weg => eine online-Nachjustierung ist notwendig.
D.h.: für Zeitgesteuerte Aktionen brauchst du einen NTP-Server, der meistens im Internet steht.
