Schock Nr.3 der FI für eine Wallbox ist ein FI Type B vorgeschrieben UVP von ABB 699€
Danke für die Zusammenfassung 
Ist das vielleicht der Grund weshalb einige Wallboxen deutlich teurer sind? Soweit ich weiß enthalten manche einen FI, das würde dann den Aufpreis erklären.
Ich habe Busch Jäger Taster, unter anderem diesen: https://www.busch-jaeger.de/produktuebersi…9bb3bb65f8b898c
2020 U-206
Kann ich da die litze direkt einstecken und würdet ihr das machen? Kann ich eigentlich die zwei Positionen für L und N am Taster nutzen, um da weitere Verbraucher anzuschließen und mir so Klemmen zu sparen?
Edit: letzteres geht, bei der Litze bin ich mir aber unsicher. Die verbiegt es doch sicher beim Reinstecken, selbst mit Aderendhülse ist mir da nicht ganz wohl. Somit wäre eine Klemme am i3 oder massive Adern bei mir praktischer
Der erkennt doch nur ob das Fenster geschlossen ist, nicht aber, ob es auch verriegelt ist? Ein Sensor, der letzteres erkennt, würde das Problem „auf der Terrasse mit zugezogenem, nicht verriegelten, Fenster“ vermeiden. Ich finde nur leider sehr wenige Sensoren, die das können.
Das ganze nur von der Terassntür abhängig zu machen ging bei mir zumindest nicht gut.
Eine Variante wäre noch ein Sensor, der auch erkennt, ob die Tür verriegelt ist.
Von der Idee her ist die perfekt, das entspricht der Crimpzange von Knipex. Allerdings gibt es bei den chinesischen Klons Qualitätsunterschiede, manche machen ihre Aufgabe besser als andere.
Das sind ganz gewöhnliche Rohrmotoren, kein Trennrelais etc verbaut?
Diese sind dafür zugelassen.
Danke, dass wusste ich noch nicht!
Übrigens macht Shelly vor, wie man nicht arbeiten sollte (Foto aus der Facebook Gruppe):
Ich hoffe die i3 sind intern besser verarbeitet.
Edit: Er meint ohne Aderendhülse ist unzulässig:
[media]https://www.youtube.com/watch?time_con…ature=emb_title[/media]
Ich überlass aber mal euch die Diskussion, was jetzt stimmt. Wobei ... ich denke auch, dass deine Aussage stimmt und die Zunge die Aderendhülse überflüssig macht.
Sieht du einen Vor/Nachteil gegenüber MQTT? Ich bin da nach wie vor nicht besonders tief in der Thematik
Die Befehle zum De-/Aktivieren des Zeitplans lauten:
http://<IP des Shelly>/settings/roller/0?schedule=false
http://<IP des Shelly>/settings/roller/0?schedule=true
Vielen Dank!
Es wäre mit einem übergeordneten System dann auch eine Zwitterlösung denkbar:
Der Zeitplan läuft auf dem Shelly 2.5. Das übergeordnete System (und nicht der Fenstersensor) schaltet dieses aus, wenn die Tür geöffnet wird. Wenn die Tür geschlossen wird, wird vom übergeordneten System der Zeitplan wieder aktiviert und (wenn es spät genug ist) der Befehl zum Rollo schließen gegeben. Das wäre ohne Cloud möglich und gegenüber der Lösung mit Zeitplan auf dem übergeordneten System hat das den Vorteil, dass der Zeitplan auch ohne übergeordnetes System noch in Betrieb bleibt.
Der Nachteil ist wohl, dass der Zeitplan nicht mehr zentral verwaltet wird, ist dann eine Grundsatzüberlegung, ob lieber alles zentral oder dezentral angelegt sein soll.
Hättet ihr da eine Präferenz? Vom Aufwand ist das wohl ähnlich, denn wenn der Zeitplan auf dem übergeordneten System läuft, dann muss da eine Abfrage des Fenstersensors integriert werden.
Hier haben doch sicher einige schon die Beta oder Infos zu den Änderungen. Könnt ihr die hier hochladen und / oder die Änderungen in der CoAP erläutern?
Das von Dir geschilderte Szenario kannst Du z.B. leicht lösen in dem das "übergeordnete System" auf der Terasse (was z.B. auch ein einfacher Türsensor sein könnte) den Zeitplan vom Shelly mittels http-Befehl ausschaltet. Dann bleibt das Rollo oben.
Das geht? Also zum Beispiel Türsensor schaltet bei Öffnen der Tür den Zeitplan aus, beim Schließen schaltet er ihn wieder ein, im Idealfall verbunden mit dem Befehl das Rollo jetzt zu schließen?
Genial!
Würdest du das so umsetzen oder lieber das übergeordnete System dazu einsetzen? Letzteres hätte wohl den Vorteil, dass man keinen Sensor braucht, der HTTP Befehle absenden kann.
Meine Systeme laufen auch seit Jahren problemlos. Aber wenn wir ehrlich zu uns sind, dann läuft so eine klassische Elektroinstallation halt auch 30 Jahre ohne Probleme.
Beispielsweise finde ich das System auf der SD im Raspberry nicht optimal, deswegen läuft das bei mir bald auf dem NAS in einem Container.
Was derzeit nicht geht ist z.B. irgendwelche Befehlswege im Shelly durch externe Signale zu Sperren
Genau das meinte ich. Vielleicht könnte man irgendwann mal den Timer mit einer Abfrage von Parametern verknüpfen? Momentan ist es in meinem Beispiel zum Beispiel sinnvoll, dass dann der Timer im übergeordneten System und nicht im shelly selbst läuft. Ich hab für Home assistant mal recherchiert, da gibt es zumindest schon einige Anfragen zu high availability und auch schon erste Lösungsansätze.
Darf ich dich mal etwas OT fragen, was dich das ungefähr in der Anschaffung und im Unterhalt kostet?
Ich habe kürzlich das Angebot der SWM gesehen, dass ich ziemlich frech finde. Dort mietet man die Ladestation nur, dafür werden 1500€ + 45€ mtl. + monatliche Energiekosten je nach Batteriegröße (für 10 kWh fand ich es teuer mit 24€ mtl., 100 kWh kosten 54€) fällig. Das fand ich ziemlich happig, allerdings sehe ich gerade, dass deren Kauflösung auch nicht wirklich teurer ist. Ein Servicevertrag sollte aber doch eigentlich überflüssig sein....
Was erhoffst du dir vom shelly?
Das heißt leider auch (oder habe ich einen Denkfehler?), dass bei komplexeren Algorithmen nichts mehr lokal über den Shelly laufen kann. Also zum Beispiel übergeordnetes System meldet "Nutzer auf Terrasse", deswegen fährt der Rollladen nicht um 22 Uhr runter. Dieser Algorithmus funktioniert wohl nur, wenn auch der 22 Uhr Timer über das übergeordnete System läuft.
Für mich hat das den (wohl leider nicht behebbaren) Nachteil, dass man die einzelnen Shellys nur noch bedingt autark betreiben kann und ein Ausfall des übergeordneten Systems einen großen Verlust an Funktionalität bedeutet.
Gibt es schon übergeordnete Systeme mit Redundanz? Eigentlich würde es schon Sinn machen, wenn da zwei Raspberrys etc als High Availability Cluster laufen würden.
Edit: Wobei da die Shellys trotzdem noch recht gut abschneiden, denn oft hängt an denen ein Taster, mit dem die Basisfunktionalität noch möglich ist. Bei manch anderem System ginge gar nichts mehr.
Was verwendet ihr denn sonst für Kabel für den Anschluss der Shellys? Ich habe da bisher einfach kurze Drahtstücke aus einem NYM-Kabel verwendet, die Frage hat mich dann zu dem Gedanken gebracht, ob nicht mehradrige Drähte flexibler und damit einfacher wären?
Danke für eure Antworten, dann werde ich mal noch neue Wago 221 oder Endhülsen bestellen.
Wäre der Einsatz von Leuchtenklemmen eigentlich zulässig? Ich vermute mal ja, hat mein Elektriker jedenfalls bei den Trennrelais gemacht.
Gibt es auch eine Aussage weshalb das geändert wird?
Hallo,
meine ersten i3 sind bei mir eingetroffen und ich wollte noch einmal nachfragen, bevor ich diese anschließe. Bisher kenne ich in der Wand keine Litzenleitungen (naja, an meinen Trennrelais sind welche verbaut). Soweit ich weiß darf man die nicht in die klassische Wago-Klemme stecken, in die neuen händisch zu öffnenden aber wohl schon? Kann ich die mit Aderendhülse direkt in Schalter / klassische Klemme stecken?
Ansonsten kenne ich noch die Leuchtenklemme zum Beispiel von Wago, die wäre wohl auch eine Option?
So ganz nachvollziehen kann ich nicht, weshalb der i3 mit Litzenleitungen kommt, etwas längere Massivdrahtleiter wären mMn eine gute Verbesserung.
Hab ich doch gesagt. An jeden Rollladen eine eigene Shelly und die Trennrelais raus.
Mit Trennrelais geht schon - ist aber tricky und nur mit bestimmten Trennrelais machbar.
Walta
Im Prinzip geht es schon auch mit allen Trennrelais, aber eben nur über Umwege. Dazu misst man die Zeit, die der Motor hoch / runter braucht und kalibriert dann zum Beispiel mit Glühlampen, bevor man dann wieder den Rollladen / Jalousie anschließt. Besonders intuitiv ist das so dann nicht, funktioniert aber ganz gut.
