Ich weiß nicht wie "kritisch" die Pumpe ist: aber ich würde in deinem Fall von einem Shelly mit Relay absehen um die eigentliche Funktion der Pumpe nicht zu beeinflussen. Das Relay ist eine potentielle Fehlerquelle und braucht eben auch 24h am Tag "etwas Strom".
Pumpe:
Ich würde für die Pumpe einen Shelly OHNE Relay (Shelly PM Mini Gen3/4 oder Shelly Plug PM Gen3) verwenden, wo der PS1 wie gewohnt "in Serie" geschaltet ist.
Warnlampe:
Da der Pumpen PM-Shelly leider keinen EINGANG für den PS2 hat brauchst du nur für diesen einen 2ten Shelly.
Für den Betrieb der PS2 (als "Schalter") + Warnlampe (als "Lampe") würde dann eine "normale Schaltung" mit einem z.b.: Shelly 1 Mini Gen3/4 verwenden.
Beiträge von borsti0
-
-
Muss aber sagen das es semizuverlässig ist. Grad jetzt bei den Temperaturen "steht" auch schon mal das Tor offen, obwohl es zu ist. Habe aber bis jetzt noch nicht auf die externe Beleuchtung als Erkennung umgebaut. Bei Hörmann gibt es einen Relaisausgang der dauerhaft ein externes Licht einschaltet wenn das Tor offen ist.
Und deswegen habe ich auch schon zum glaub ich 3ten Mal gefragt: ist das nur zur VISUALISIERUNG oder wirklich der ELEKTRISCHE ENDANSCHLAG für den Motor: Ich würde einem BLU ned wirklich vertrauen dass da das Signal WIRKLICH beim Empfänger ankommt. Es gibt da keinerlei Datensicherung bei der Übertragung. D.h.: wird der "Ich bin nun geschlossen"-Frame des BLU aus irgendeinem Grund "übersehen", dann bekommt der Empfänger nicht mal mit was nun los ist und muss hoffen dass bald eine erneute Nachricht die Daten "nachliefert"!!!
-
ok, hab noch nie näher drüber nachgedacht: aber ich hab auch einen switch "aioshelly_ble_integration".
=> wenn ich den "ausschalte" wird auch wirklich das Script "aioshelly_ble_integration" am Shelly deaktiviert. Interessant dass das anscheinend auch mit "Buttons" geht.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. In der Shelly App ist das ein richtiger Button
Du kannst den Datenpunkt ja in dein Dashboard integrieren - und dort kannst du dir im Wesentlichen die "Form" aussuchen wie es visualisiert wird.
-
Naja, wenn dort wirklich "Plus" steht, dann ist es ein Gen2. Der kann zumindest nicht "lokal" mit Bluetooth-Geräten ("BTHome") nativ umgehen.
ICH verwende mehrere der Gen2-Geräte um auch mehrere Shelly BLU Door/Window an mein Home Assistant weiterzuleiten (was ja geht), aber ich kann sie wie gesagt nicht direkt am Shelly "auswerten". Anscheinend gibt es Ansätze das mit Scripten mehr oder weniger "nachrüsten". Leichter ist eine "lokale Auswertung am Shelly" natürlich mit Geräten ab Gen3
=> Ich habe aber keine Ahnung ob da mittels Cloud noch mehr Möglichkeiten bestehen.
Abgesehen davon nochmals die Frage: Verwendest du den Shelly BLU Door/Window dann nur zur Visualisierung oder wirklich als elektrischen Endschalter für den Motor? -
Verwendest du wirklich einen Shelly Plus 1 (=Gen2) oder einen Shelly 1 Gen3/4? Mich wundert nur wie du mit einem Shelly Plus 1 über die "Bluetooth-Einstellungen des SP1 den BLU Door/Window" hinzugefügt hast?!? BTHome funktioniert ja erst ab Gen3/4, diesen Punkt gibt es gar nicht bei Gen2-Geräten?!?
Und willst du nun den Shelly BLU Door/Window wirklich als ENDLAGENSCHALTER für den Garagentormotor verwenden oder nur zur Visualisierung?
Und wenn du von "Addon-Peripherie" redest denk ich sofort an das Shelly Plus Add-on, welches aber elektrisch direkt auf den Shelly aufgesteckt wird und NICHTS mit Bluetooth zutun hat und somit auch eine ganz andere Schnittstelle verwendet.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Je nachdem was du machen willst kannst du auch The Pill by Shelly dazu verwenden bis zu 3 DitigalIn anzuschließen
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Du kannst zumindest lt. Anschlussdiagramm auch den Analog-In als 2ten DigitalIn verwenden:
-
Ich lasse einfache Zeitpläne, wie Gartenbeleuchtung bei Sonnenuntergang oder Rolläden, die einzelnen Shellys selber schalten, dafür brauche ich keinen iOBroker.
Der erledigt bei mir komplexere Aufgaben, wie Nulleinspeisung oder Automationen, bei denen unterschiedliche Hersteller im Spiel sind.
Wie z.B. bei Alexa Zuruf "Tagesschau" den TV auf dem richtigen Programm einschalten, den Vorhang elektrsch schließen und diverse Beleuchtungen auf die Fernseh-Stimmung umschalten.
Und ich mache es quasi komplett umgekehrt: Ich nutze nur die "Default-Funktionen" auf den Shelly's, also keine Scripte, Web Hooks, usw, und mache den Rest über HA.
Die "Idee" dabei ist, dass es mir in HA relativ egal ist dass meine Fenster Shelly-gesteuerte Rollos haben aber mein Dachfenster Velux-gesteuerte Rollos
=> Ich implementiere 1 "Funktion", z.b.: "fahre im Somme die Rollos ab 11h runter und kippe sie auf 60%", und über HA (bzw. Node-RED) wird das auf alle Systeme, egal ob Shelly oder nicht, umgesetzt.
Aber ich glaube wichtig ist: man muss sich für ein System entscheiden.
Natürlich ist jede Funktion die 1 einzelner Shelly lokal machen kann nicht mehr abhängig vom WLAN/Internet, aber wenn man Geräteübergreifende Features realisieren will glaube ich sollte man nur mehr 1 zentralen "Controller" haben damit sich die Automatisierungen nicht in die Quere kommen.
Frage:
Ich habe noch nirgends gesehen dass man Shelly-SCRIPTE in HA direkt editieren könnte. Da ich auch bisweilen noch keine virtuellen Komponenten verwende hab ich auch die von dir erwähnten Button200 & Button201 noch nirgends gesehen.
@1. Reicht das Backup des Config-Ordners wirklich aus?
=> Ich würde empfehlen die komplette Instanz zu sichern, d.h.: VM/Container stoppen, sichern, und wieder starten. Das dauert nur ein paar Minuten. Ich lass das 1x pro Woche in der Nacht laufen, dann störts auch keinen.
@2. Szenarien aus der Shelly App
=> Die musst du dir direkt mit HA nachbauen, die "Cloud-Features" sind ja nicht mehr verfügbar und soweit ich weiß gibt es auch keinen "converter" für HA.
@3. Zeitpläne (Schedules) für Heizung / Schaltzeiten
=> Wie oben schon geschrieben: für alles was "Schelly-Übergreifend" ist nutze ICH dann HA, dazu zählen (bei mir) auch im Allgemeinen Zeitpläne.
Ich nutze Shelly-Features nur sehr eingeschränkt um wenn notwendig ein Shelly-Device auch gegen eine Fremdkomponenten austauschen zu können. -
was verstehst du unter "keine Funktion"?
Da es sich ja um ein Shelly BLU-Gerät handelt: Hast du z.b. schon probiert es mit einem Shelly-Gerät ab Gen3 zu koppeln oder mit der Shelly BLE Debug-App zu finden? -
borsti0 weshalb noch dein Beitrag?
Weil: nur weil "es funktioniert" wurden vielleicht trotzdem nicht alle Punkte berücksichtigt. Und eine verlässliche Stromversorgung einer Alarmanlage finde zumindest ICH doch als "relativ wichtig".
Aber secundani hat es ja eh schon beantwortet: für IHN stellt die begrenzte Laufzeit der Alarmanlage im Akkubetrieb kein Problem dar. -
Ok.
Dachte es wäre Trotzdem machbar wenn ich händisch zweimal einen kurzen Impuls gebe und ihn immer wieder zurückschalte.
Du hast bei Shelly Taster-Eingängen grundsätzlich 4 unterschiedliche "Events" die erkannt werden können:
- short push
- double push
- tripple push
- long push
Wenn du einen Taster "double push" mit einem Schalter emulieren willst musst du schon SEHR schnell "Ein-Aus-Ein-Aus" schalten, wahrscheinlich innerhalb von <1sec.
Ich überlege ob es möglich ist mit einem Schalter folgendes zu emulieren + unterscheiden:
1) "long push" währe ein "dauerhaft eingeschaltet lassen" des Schalters oder ein "Ein-Aus", wobei das "Ein" relativ lange (>1 sec?) sein müsste
2) "short push" währe dann ein schnelles "Ein-Aus" des Schalters
Dann hättest du 2 Aktionen zur Verfügung mit denen du z.b.: 2 separate Timer ansteuern könntest.
Aber wenn ich ehrlich bin:
- Schau ob es möglich ist bei deinem Schalter eine Feder zu verbauen um aus dem Schalter einen Taster zu machen (=> ist oft der einzige Unterschied zwischen Schalter <=> Taster)
- oder investiere das Geld und kauf dir einen Taster, dann hast du ein "leichteres" Leben. -
Der oben erwähnte Router saugt alleine sicher um die 20W, das ist zu viel.
Natürlich ist das WoMo dauerhaft am Strom und wenn ich mal einen Ausflug mache, dann wird der Strom für den Router auch reichen. also bitte macht Euch keine Gedanken über meinen Strom. Auch der Gaskasten wird mit überwacht und Rauchmelder wie co-Melder sind bereits verbaut.
Das war auch irgendwie mein 1ster Gedanke: Ich kenn mich mit WoMo nicht aus, aber ist da im "mobilen" Betrieb dann nicht nur 1x 12V Autobatterie vorhanden?
Das würde dann bedeuten dass nur max. 100Ah * 12V = 1200Wh verfügbar sind.
Wenn dein Shelly-Setup NUR 10W braucht sind das 1200Wh/10W = 120h = 5 Tage bis deine "Alarmanlage" gar nichts mehr meldet.
Du sagst also das wird bei deinem Setup niemals zu einem Problem werden? -
-
... aber nur solange der Kontakt dann auch hält.
-
ok, das ist ein "lokales" Konto, aber es ist NICHT verpflichtend sich bei der "Home Assistant Cloud" anzumelden!
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Selbst Shelly empfiehlt die Schraubverbindungen nachzuziehen
Besser wärs hald wenn Shelly selber Mechanismen wie "Federklemmen" verbauen würde. Aber einfach Wartungsarbeiten "Vorzuschreiben" ist offensichtlich billiger...
-
Dazu gibt es schon SEHR viele posts hier im Forum wo unterschiedlichste Montageorte/methoden diskutiert wurden, bitte die Suche bemühen.
Bsp:
Aber im Wesentlichen:
Die Wetterstation (wie eigentlich alle) machen sich ihren Schatten selber, ich hatte auch noch nie Probleme wo die WS90 einen "wesentlich anderen Wert" gemessen hat wie ein Referenzsensor. -
Also 1-2 Sekunden ist schon WIRKLICH schlecht, da verstehe ich sogar dass da manche Clients ein Timeout bekommen.
Ich habs aber gerade mal kurz mit x-beliebige Geräten probiert:
- NOUS A1T Plug (Tasmota), RSSI: -55dBm: ~2-40ms
- Shelly Plus 2PM ECO-Mode OFF, RSSI: -45dBm: ~2-40ms
- Shelly Plus 2PM ECO-Mode ON, RSSI: -45dBm: ~40-100ms, manchmal auch bis zu 200ms
Es "könnte" also schon was dran sein dass der ECO-Modus auf den Ping einen Einfluss hat. Aber bei meinen Automatisierungen ist MIR das bisweilen noch nie negativ aufgefallen. -
A auch YAML ist für mich brainf**k. Die Struktur dieser Auszeichnungssprache ist gut beschrieben, die Schlüsselwörter, die der HA-eigene YAML-Interpreter kennt, nicht. So laufen bei mir diverse YAML-Scripte nicht, die z.B. Simon42 in seinem Blog oder auf Youtube zeigt.
also das ist mein GESAMTES YAML-File:
Code
Alles anzeigen# Loads default set of integrations. Do not remove. default_config: # Example configuration.yaml entry my: # Load frontend themes from the themes folder frontend: themes: !include_dir_merge_named themes automation: !include automations.yaml script: !include scripts.yaml scene: !include scenes.yaml logger: default: info logs: custom_components.husqvarna_automower: debug aioautomower: debug #Keep all history data for 1year+1day, default: 10days recorder: purge_keep_days: 366=> Da ich keine "ich bastle es mir selber"-Geräte habe sondern einfach nur beim Kaufen drauf achte dass es irgendeine Integration für ein neues Gerät gibt komme ich OHNE Yaml aus.
Und ich kann ja auch viel ins Node-RED "auslagern" was nicht ganz passt.
Das heißt aber NICHT dass diese Datei nicht schonmal viel länger war, nämlich dann wenn es zu einem Gerät keine Integration gibt. Aber mittlerweile geht schon SO viel nativ dass diese Date z.z. quasi "leer" ist. -
ich glaube dass du die aus der Knowledge Base für The Pill by Shelly rauslesen kannst.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
