Beiträge von borsti0

Da ich beide Geräte nicht bei mir zuhause habe kann ich das nicht nachvollziehen. Aber man muss zumindest aufpassen was man hier vergleicht: du hast auf der einen Seite die Daten des Shelly Pro 3EM wo ~11kW LEISTUNG angezeigt werden zwischen ~19h-21h (was sehr plausibel erscheint), auf der anderen Seite sehe ich heir viele Plots die die ENERGIE in kWh zeigen - und da muss man aufpassen über welchen Zeitraum die Energie aufakkumuliert wurde.
Bsp: Ist das die Energie die jede Stunde verbraucht wurde, oder die Energie welche an einem Tag INSGESAMT verbraucht wurde - diese werden dann jede Stunde/Tag resettiert und neu aufakkumuliert.
Oder ein "fließender Wert" wie viel Energie über ein Zeitfenster von 1h/1d fließend ausgegeben werden.

Auch du scheinst hier diesen Fehler zu machen:

Zitat von ulrichp

Weil Durchschnitt sollte ca. 9,4 kWh sein, Max kann maximal 11 kWh sein, mehr kann der Onboard Lader einfach nicht.

Du meinst wohl dass der Onboard-Lader max. 11kW LEISTUNG kann, aber da ~2h15 geladen wurde sind ~2.25*11kW = ~25kWh ENERGIE ins Auto reingeflossen.
=> beim 1sten Plot suche ich noch immer wo ich diese Werte "rauslesen" soll, bei den unteren Plots glaube ich zumindest die 25kWh rauslesen zu können.

Zitat von DIYROLLY

Echt, ohne eine Taste zum "aufwecken" nach Anforderung der App zu drücken und die FW wird nicht geprüft?

Ne, habe ja mittlerweile einen 2ten hier am Tisch liegen - den brauche ich nur etwas "zu schütteln" damit der Vibrationssensor anschlägt, dann misst er 1x neu die Distanz und sendet das in einem Frame raus - Obwohl in der App steht "drücke eine Taste" hat der Vibrationssensor den gleichen Effekt wie wenn ich die Taste drücke.
Ich komme es auch einmal probiert: wenn ich den 30 Sekunden-Timer abwarte wo er "von selber" eine Messung macht und rausschickt => auch das hat den "Effekt eines Tastendrucks".

Zitat von DIYROLLY

Ich finde das bei vielen BLU und der BLE Debug eher nervig und man hat xx Kopplungen im Handy, daher mache ich das nur wenn es notwendig ist....

Da ich ja nur mittels der Shelly BLE Debug-App arbeite um die Firmware zu aktualisieren MUSS ich ja quasi die Geräte gekoppelt haben, auch wenn ich nur 1x im Jahr ein Update einspielen werde.

Zitat von DIYROLLY

Die Wetterstationen allgemein senden auch Daten die andere nutzen können, nutzt Du auch den Wetterdienst von Shelly?

fast - ich habe den "original" Ecowitt Wittboy WS90, d.h.: da gibt es die Kopplung zwischen der Basisstation und dem Sensor mittels 866MHz-Funks die ich händisch an der Basisstation bestätigen muss. K.a. was die für ein Protokoll drüber fahren, aber es ist zumindest mal "Properitär" und bedarf schon einer händischen Kopplung zwischen den beiden. K.a. ob da eine Art Verschlüsselung vorhanden ist, aber zumindest eine "simple" Verifikation beim Verbindungsaufbau scheint vorhanden zu sein.

Bei dir sind die Endlagen des Motors (mechanisch/elektrisch) wohl falsch eingestellt
=> die Frage ist ob die Endlagen vorher "richtig" eingestellt waren und nun sich durch den Stromausfall "verstellt" haben oder ob die schon immer falsch waren und sich der Shelly resettiert hat?

Fährt der Shelly wenn du die Tasten drückst und/oder per App aktivierst in die falsche Richtung?

Naja, grundsätzlich kann sich jeder mit dem Shelly pairen. Man muss hald nur "abwarten" bis der Shelly das nächste Packet schickt - das ist bei meinem Shelly BLU Distance relativ leicht: einmal "auf die Regentonne" geklopft, dann sendet er ein Packet und schon ist das Pairing OK. Ansonsten muss man nur ein paar Sekunden warten bis der automatisch ein neues Packet schickt.

Und wenn man dann den Alu-Hut aufsetzt:
Man kann ja dann nicht nur die Daten abhorchen sondern auch IRGENDEINE Firmware einspielen und dann mit dem Gerät machen was man will.
Dann ist die Frage welche Einfallstore es in den Shelly's oder (wie bei mir) in Home Assistant & Co drinnen sind um noch mehr Daten abzugreifen oder Schaden anzurichten.
Andere betreiben ja auch mit den Shelly BLU TRV oder anderen BLU-Sensoren (z.b.: Shelly BLU Flood, ...) eine Heizungssteuerung oder andere Automatisierungen bei denen es u.u. schon auch mal "gefährlich" oder zumindest "unangenehm" werden könnte wenn wer einen manipulierten Sensor-Datenframe versendet.

Ich persönlich finde einfach nur dass man bei jeglicher Datenübertragung, vor allem wenn sie "öffentlich" über Funk läuft, eine Sender-Verifikation und Grundverschlüsselung angebracht ist.
Und da dieses Feature bei den BLU-Geräten angeboten wird möchte ich es auch verwenden - nur beim Shelly BLU Distance scheint da noch was in der Firmware "kaputt" zu sein.

ohne dass ich mich da IRGENDWIE auskenne oder die App jemals installiert zu haben:
1) Du hast eine Virtuelle Komponente Storen34 erstellt
2) Du hast 2 Aktionen bei dieser virtuellen Komponente erstellt die jeweils auf 2 deiner Raffstore eine pos+slat_pos setzen bei JEDER AKTIVITÄT des Storen34

Für mich würde das heißen:
Sobald du den "button" des Storen34 drückst werden BEIDE Aktionen ausgeführt, da dies aber so schnell geht wird nur die letzte "wirklich" ausgeführt.

Ich denke mir du brauchst für die 2 Aktionen auch 2 separate "Storen"
=> Probier doch mal noch eine 2te virtuelle Komponente "Storen34_100" zu erstellen und die 2te Aktion auf eine Aktivität des "Storen34_100" zu triggern.
Dann solltest du in der App 2 Taster haben mit denen du jede der Aktionen separat triggern kannst.

Bei der Shelly BLE Debug-App macht eben der "OTA"-Button den "normalen" Update mit dem File welches er vom Server holt (slow, not-slow). Und in dem Zuge fragt er hald auch ob er nicht doch ein eigenes "Custome File" laden soll.
Also irgendwie haben sie bei der App alles "in einen Button" verfrachtet .

OK, aber ansonsten gibt mir dass dann leider auch nicht mehr Infos WIE ich nun mein gbl-File downloaden soll...muss wohl auf den Support warten bis der sich wieder meldet...

Zitat von MaFi63

Sieht bei meiner Jalousie so aus.

Herunterfahren 100% zu einer bestimmten Uhrzeit und Neigungsposition auf 50% = 45°

Frage: und wie schaut es aus wenn du auf 100% "herunterfährst" und dann die Lamellen komplett schließt oder öffnest (slat position = 0% bzw. 100%)?
=> Bei einer dieser slat positions müsste auch bei dir die position auf 99% "hüpfen".

Das ganze ist abhängig von:
- Wie lange eine Raffstore ist:
Bei "langen" Raffstore (= Balkontür, kein Fenster) sind die 100 Inkremente der "%"-Auflösung eine relativ lange Verfahrzeit.
D.h.: Wenn wie bei mir eine volle slat position 90°-Verstellung ~1 Sekunde dauert, dann ist das u.u. noch immer <1% der position-Verfahrzeit und führt somit nicht zu einer Veränderung in der "%"-Positions-Anzeige in der GUI.
=> Ich hatte bei gleichen Algorigthmus + Shelly Plus 2PM + Raffstore bei meinen Fenstern immer ~3% Positionsbewegung, bei meinen Balkontüren aber nur 2%

- Wie "lange" braucht deine Raffstore um die Lamellen zu Kippen:
d.h.: wie viele "%" der Verfahrposition wird dafür verwendet um die Lamellen komplett auf/zu-zuklappen.

Da ich die slat position meiner Shelly's+Raffstores vor ein paar Jahren noch komplett ohne "slat position"-Feature in Home Assistant mit eine Statemachine ausprogrammierte mit:
- fahre auf position
- fahre um x = 2 oder 3 Inkremente nach oben (je nach Raffstore)
- fahre um 1-x Inkremente wieder nach unten um die Lamellen um einen Winkel von n/x*90° zu verstellen
- Mache aber alles etwas anders wenn die Rollo ganz oben steht, da du ja nicht auf 100% + x fahren kannst .
- ...

=> Unterm Strich: Das sind die "Resttoleranzen" mit denen man offensichtlich leider leben muss. Sind wir froh dass die slat position so relativ gut&simpel funktioniert.

Zitat von alpitz

falsches Verhalten bei den zwei Actions: anstatt auf Pos = 0 und Slat = 20 zu fahren, bleiben die Storen auf Pos = 99, die Lamellen bewegen allerdings auf 20%

Das sich bei Winkelverstellungen auch die Position um 1-2% verschiebt ist leider "Normal", das Problem habe auch ich. Die Position wird leider noch immer wie vorher ABSOLUT berechnet.
D.h.: wenn du vor der Umstellung auf "slat control" auf eine position (z.b.: 0% = ganz unten) gefahren bist und dann den Winkel händisch mit den Tastern eingestellt hast, dann musstest du auch "etwas rauffahren" (z.b.: auf 1%) um ca. 50% Lamellenneigung zu erreichen
=> Genau so rechnet auch jetzt noch immer die Positionsberechnung die absolute Motorbewegung mit ein, auch wenn es "teil der Lamellenstellung" ist.

Aktuell mein Schlafzimmer-Raffstore:
Position: ganz unten
Lamelle: ~63%
=> Lt. Shelly ist die Position dabei wieder auf 1% "gestiegen"

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Ich habe gelernt "damit zu leben"

Da du ja jetzt eh den Fehler alle paar Tage "reproduzieren" kannst => ist es möglich einen/alle Rollos wirklich von 0% in der Nacht auf 100% am Tag fahren zu lassen und zu sehen ob das was in den nächsten Tagen ändert?

Frage tvbshelly :
Was ist das für eine App auf iOS?. Ist das die Shelly-App selber oder die Shelly BLE Debug-App?
Da hast du ja 4 Buttons/Optionen zur Auswahl: "Update", "Force OTA", "Force OTA (Slow)" und "Load from File".

Frage: Was ist bei dir der Unterschied zwischen "Update" und "Force OTA"/"Force OTA (slow)"? Den rest habe ich quasi auf der Android-Seite auch irgendwie.

Deine Optionen kann ich wahrscheinlich auf folgende Aktionen in der "Shelly BLE Debug"-App ummünzen:
- Force OTA => normaler "OTA"-Button
- Force OTA (slow) => normaler "OTA"-Button, aber ich muss vorher den Schalter "Slow OTA" aktiviert haben
- Load from File => Die Option ein FIle auszuwählen wird mir im Zuge des "normalen" OTA Firmware-Downloads angeboten (slow oder auch nicht-slow)
- Update => k.a. was das bei mir für eine Option sein sollte?!?

in Shelly BLE Debug-App:
1) Shelly BLU Distance Pairen
2) "Slow OTA" Button aktivieren
3) "OTA"-Button drücken
4) Im 2ten/3ten Button im Menü fragt er dann:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
5) Wenn man dann das File auswählt und downloaden probiert komm die folgende Meldung:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Ich habe nun nach längerem Warten eine Test-Firmware von Shelly bekommen.

eMail:

Hallo,

Please use this firmware version to update the device manually, and then run the slow OTA update again. This should help. 

Mit freundlichen Grüßen,
Shelly Support Team

Die angehängte Datei heißt "btl_3.0.6_WS (1).gbl". Ich dachte mir ich muss den Shelly "einfach" über die Shelly BLE Debug-App mit einem "Custome-ROM" updaten, aber das funktioniert so nicht.

Frage: Weiß wer wie man so ein File in den Shelly BLU Distance einspielen soll?

Beim Dateinamen "btl_..." denke ich an "Bootloader", aber k.a. wie ich den einspielen sollte?!?

Zitat von Christian93

Entweder wurde der Herd im inneren auf eine Phase gebrückt oder im Unterverteiler ist ein Fehler was die 3Phasensicherung betrifft.

Ich habe schon 1/2 "Kochplatten" bzw. E-Herde (Kochplatte + Backrohr) angeschlossen und eigentlich gab es bei allen die Option diese auch nur 1-Phasig zu betreiben. Ich nehme mal an dass man dann aber nicht alle Platten gleichzeitig einschalten kann.
Da du ja nur
Unser reines Backrohr kommt ja mit einer 1-Phasen-Versorgung aus.

Zitat von Christian93

Soll man den Shelly pro 3 mit einen Sicherungsautomaten absichern, da ja keine Sicherung vor den Shelly hängt? Außer die 26 A Sicherung vom Zähler.
Danke für deine Bemühungen und Tipps.

Lt. Shelly-Homepage ist zumindest eine Sicherung vorgeschrieben.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Ich hab mein Smartmeter (kein Shelly) aber direkt HINTER einer Sicherung + FI angeschlossen um es ähnlich abzusichern wie alle anderen Geräte hald auch.
Hier im Forum wird immer davon gesprochen eine "Feinsicherung" für diese Messgeräte zu verwenden.

Aber wie immer: Frage deinen Elektriker!!! Der muss dir das ja einrichten und er "sollte" die Forschriften in deinem Gebiet am besten kennen!!!

Zitat von MHMH19

Ich hatte die Vermutung, dass die Position über die Stromlast ermittelt wird. Da wäre auch logisch, dass die Position leicht variiert, da bei kalten Temperaturen der Motor ggf etwas mehr Leistung zieht. Wenn es rein über die Laufzeit errechnet wird, dann bin ich tatsächlich ratlos.

Also der Shelly kalibriert im Wesentlichen damit dass er in die untere Endlage fährt (=> das bekommt er mit indem der Strom aufhört weil das Rollo durch die Hardware den Stromkreis unterbricht).
Dana misst der Shelly die Zeit wie lange es dauert dass das Rollo komplett nach oben in die Endlage fährt.
Das Ganze dann nochmals in die andere Richtung (oben nach unten).
Es wird dann noch in beide Richtungen "schrittweise" gefahren um auch die Zeiten dazwischen zu ermitteln oder u.u. auch die "Beschleunigung" bei mehreren Start-Stop rauszurechnen (weiß ich ned genau)

Aber im Wesentlichen hat der Shelly dann eine ZEIT wie lange das Rollo braucht um komplett von einem Ende bis zum Anderen zu fahren und repräsentiert das als "% offen"-Slider im Interface.
Soweit ich weiß wird dann auch noch im Betrieb diese ermittelte Zeit jedes mal bei Erreichen der Endlagen "nachjustiert" um drifts zu vermeiden.

=> Für mich ist komisch dass du diene Rollos auch mit den Shelly 2.5 schon " 1-2 mal im Jahr" nachkalibrieren musstest => die meinen sind seit 5 Jahren eingestellt und funktionieren noch immer wie am Anfang. Schon da war etwas "komisch".

Es ist nach meiner Auffassung auch (fast) nur möglich dass die "%"-Anzeige nicht stimmt wenn sich die Verfahrzeit aus irgendeinem Grund stark verändert und/oder du NICHT in die Endlagen fährst.
Kann es irgendwie sein dass der Motor manchmal "langsamer" fährt als an anderen Tagen?!?

Da ich leider die Shelly-App nicht verwende kann ich dir da leider nicht wirklich weiterhelfen - hoffentlich kann dir da irgendwer weiterhelfen wie du diese Requests absetzen kannst.

Du kannst aber soweit ich das mitbekommen habe lokal am Shelly folgendermaßen diese Aktion ausführen durch:
1) lokale "Actions" kann eine konkrete Position + Slat Position anfahren:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

2) lokales Script
3) externes http-request (wie bisher beschrieben)
4) ???

Wie kann eine dieser Optionen "getriggert" werden:
a) Um eine Action (1)) oder Script (2)) auszuführen brauchst du ein "Event"
=> dies geht u.u. mit einer "Virtuellen Komponente". Diese ist auch hoffentlich in der Shelly-App direkt "als Button" sichtbar. Diese Komponente kann dann lokal diese Action/Script ausführen.
Es müsste/könnte dann somit auf allen Shelly's diese virtuelle Komponente eingerichtet werden welche in der App dann gemeinsam "ausgelöst" werden müssten.
b) Eine "Virtuelle Komponente" oder ein physikalischer Ausgang (=> z.b.: ungenutzter Relay-Ausgang) auf einem physikalischen Shelly könnte als "Event" genutzt werden um eine Aktion auszuführen welche die bisher beschriebenen HTTP-Requests an alle anderen Shelly's absetzt
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Es muss dann nur auf 1 Shelly diese virtuelle Komponente eingerichtet werden. In der App hättest du dann bereits einen "zentrale Komponente" verfügbar.

Die Frage dabei ist also:
- kann man eine "Virutelle Komponente" als "Button" in der App einbinden? Und kann man durch diese Virtuelle Komponente eine Aktion auslösen => vielleicht gibt es hier im Forum dazu bereits threads.
- bist du mit nur 1 bzw. wenigen direkt anzufahrenden Positionen zufrieden?

Ich finde es schade dass man da HTTP-Request nicht auch irgendwie direkt ausführen kann, aber diese sind wohl nur für "lokale Netzwerkkommunikation" gedacht.

Ich hoffe ein "erfahrener Shelly-App-Nutzer" kann dir das vorab bestätigen bzw. eine bessere Lösung anbieten.

K.a. ob da auch zu so einem Fehlerbild führen kann, aber ist u.u. die Haltebremse des Rollladens kaputt oder "rutscht"? Dann hättest du aber wohl eher das Problem dass der Rolladen "zu" ist und er zeigt noch immer z.b.: "30% geöffnet" an.

...und zusätzlich sind die NOUS Tasmota-Dosen lt. Datenblatt für 16A zugelassen.

Ich persönlich als Embedded-Entwickler verstehe grundsätzlich warum es u.u. nicht "gut" ist Daten zyklische zu speichern:
Steht ein nur "normales" Flash zur Verfügung, dann kann man nur ~100.000x auf dieselbe Speicherzelle schreiben.
D.h.: Willst du nun eh "nur" alle ~1 Minute etwas auf die gleiche Speicherzelle speichern (z.b.: Gesamtenergie) dann ist diese Speicherzelle, und somit das gesamte Gerät nach ~100.000 / 60 / 24 = ~69 Tagen kaputt. Auch wenn man durch diverse HW/SW-Tricks diese Zeit um z.b.: Faktor 10 verlängern kann ist das Gerät theoretisch nach ~690 Tagen = ~2 Jahren kaputt.
Bei uns wird deswegen nochmals ein separater, sehr teurer, kleiner "Spezial-Speicher" verbaut um ein paar Datenpunkte auch zyklisch sehr oft speichern zu können - ich bezweifle dass Shelly diese Kosten & den zusätzlichen Platzaufwand investiert hat.

Zitat von ulrichp

von dem noch ca. 3,1 kWh für andere Verbraucher abzuziehen sind

Es ist zumindest in diesem Beispiel wenn du bei den 22kWh die 3.1kWh nicht abziehst sondern hinzuaddierst dass du GENAU die 25.1kWh des TopAC Portable EV charger 11kW EVE01-11R erhälst - wiederholt sich dieses Verhältnis auch zu anderen Zeiten?!?

Sry, ich verwende noch immer die Schalter die "mit meinem Haus" gekommen sind. Hab auch mit den Shelly-Tastern noch keine Erfahrungen gemacht - da kann dir aber sicherlich hier im Forum noch wer mehr Infos geben.

ABER: wenn du Shelly-Devices HINTER einen "normalen" Schalter verbauen willst musst du aufpassen ob die Dose eh tief genug ist - du brauchst ja dann doch noch Platz für den Shelly selbst und auch u.u. ein paar zusätzliche Klemmen!!!.

Zitat von borsti0

in HA habe ich es leider nicht hinbekommen beides gleichzeitig mit 1 Kommando zu setzen, aber du kannst ja auch mal probieren ob folgendes funktioniert:
[Shelly 2pm Gen4]/rpc/Cover.GoToPosition?id=0&pos=20&slat_pos=50

Lt. diesem Forumseintrag scheint dieses 1 Kommando direkt zu funktionieren - also probier es mal vom Browser aus aus - leider sind bei mir heute schon alle im Bett, will sie jetzt nicht mehr wecken um es selber zu testen