Beiträge von Space Jelly

Oh, ich seh schon, die Sache wird dann doch nicht ganz so einfach.

Aber okay, für so einen Mini sollte Platz im Gehäuse vom Pegelmesser sein.

Macht ja auch Sinn etwas zu verbauen, was permanent mit Strom versorgt wird, der müsste mir ja dann auch eine Meldung schicken können wenn der Strom wieder abgeschaltet wird; richtig?

Was aber mache ich bitte wenn der Pegelmesser schaltet, die Pumpe aber kein Strom zieht, da z.B. der Fehlerstromschutz-Schalter der Pumpe ausgelöst hat?

Wie bitte könnte man das erfassen und dann auch gegebenenfalls z.B. eine E-Mail schicken „Pumpe zieht keinen Strom“; ginge das?

Moin,

gegeben sei ein Pegelmessgerät welches auf eine integrierte Steckdose Strom aufschaltet.
In diese Steckdose möchte ich ein Shelly Plus Plug S einstecken, welcher

1. durchschalten soll um eine Pumpe zu aktivieren

2. einen weiteren Shelly Plus Plug S im gleichen WLAN, aber anderem Raum, einschalten soll, welcher wiederum eine Lampe einschaltet, damit man weiß das die Pumpe läuft und die Lampe natürlich auch wieder abschaltet wenn die Pumpe aus ist.

3. Eine E-Mail oder Nachricht auf ein Smartphone schickt wenn die Pumpe ein und wieder ausgeschaltet wird.

Ist das mit einem Shelly Plus Plug S bitte möglich oder welche Geräte müsste man dafür verwenden, wenn möglich nichts, wo man in die Hauselektrik eingreifen müsste; wenn es nicht anders geht, dann welche Geräte bitte auch dafür.

Danke!

So sollte es im Script funktionieren:

Shelly.call("HTTP.Get", {url: 'http://localhost/settings/relay/1?btn_type=detached'});

Warum könnte man z.B. einen Wechselrichter vielleicht abschalten wollen:

-man vertraut den Schutzvorrichtungen des Wechselrichter nicht (oder hat z.B. einen Deye ohne Relais, welcher die VDE-Normen nicht erfüllt)

-man fährt in Urlaub und möchte das er aus ist

-man will nur Strom zu einem bestimmten Zeitpunkt produzieren

-man schaltet damit eventuell ein eingebautes WLAN wegen der Strahlung ab

-der Wechselrichter ist an einem entlegenen Ort installiert

-man möchte die Lebensdauer des Wechselrichters verlängern

-man hat Angst (kein Witz) das was passiert wenn man nicht im Haus ist

usw.

-einfach weil man es möchte

Wenn man lange genug sucht, fallen da einem eine Menge Gründe für ein Abschalten (ob mit oder ohne Shelly) ein, ob sie sinnvoll erscheinen (egal ob falsch oder richtig), liegt im Auge des Anwenders.

Also wenn jemand das Teil mit einem Shelly abschalten will, soll er das doch einfach machen und wenn FendiMan der Auffassung ist, dass das sinnlos sei, ist das ja genauso seine berechtigte Meinung; jeder wie er möchte.

Bereits ähnlich beschrieben, nur IP anpassen und dann im Browser starten:

http://192.168.xxx.xxx/rpc/Shelly.GetStatus

Ausgabe von einem Shelly Plus 1 (mac: Adresse gelöscht, tut hier nichts zur Sache)

Wenn bei time und unixtime der Wert "null" steht, wurde die Zeit per SNTP (noch) nicht (oder gar nicht) empfangen.

Damit lässt sich ganz schnell herausfinden beim Shelly die Zeit stimmt, leider muss die unixtime noch konvertiert werden (z.B. kann man das da machen https://www.unixtime.de oder nach unixtime umrechnen suchen).

Zitat von SparkyMaster

Wenn nicht dann braucht jeder Motor einen Shelly oder man muss mit Trennrelais arbeiten.

Aus jahrzehnter lange Erfahrung kann ich dem nur beipflichten, bitte daran denken, die Rollladenmotoren können auch mal kaputt gehen und dann hat man den Salat (erst recht, wenn die alle parallel geschaltet sind); bitte nicht an der falschen Stelle sparen.

Coole Idee, gefällt mir so die Steckdosen zu schalten, zufälligerweise heute diese auch, aber für in den Schaltschrank gekauft.

Soweit ich weiß hat nur der Shelly1 und der Shelly Plus 1 (ist neuer, den habe ich genommen, denn der ist SELV konform ) einen potentialfreien Kontakt und nur damit darf man da schalten.

Wenn man sich diesen Artikel mal anschaut:

https://smartapfel.de/shelly-homekit-ota-installieren/

wird da eine eigene Homekit Firmware installiert, muss ja irgendwie, denn wie sollte man sonst Apple mit Shelly zusammenkriegen, da die Shelly´s ja kein Apple unterstützen; vielleicht kommt das ja mal irgendwann.

Ich habe zwar kein Wohnmobil, fand das Thema aber auch interessant, gerade wozu man die Shelly´s doch alles verwenden kann.

Denn wer bitte kommt auf die Idee damit eine Rollladensteuerung im Wohnmobil zu betreiben; ich finde das klasse

Liege ich damit richtig, das alle Shelly´s im Wohnwagen mit der Fritzbox 4040 verbunden sind und zum Einen lokal im Wohnwagen selbst über das WLAN gesteuert werden und dann zum Anderen zuzüglich extern über den WAN Port angesteuert werden können?

Zitat von eiche

Und diese ist oder sollte unabhängig vom externen Bein sein.

Nicht schlagen, leider nur in der Theorie, in der Praxis aber muss der Router die Verbindung kappen um seine Routing Tabelle "aufzuräumen" und damit wollte ich nur Erklären warum der Shelly die Verbindung verlieren muss und sie wieder bekommt wenn das Internet aus-, und wieder eingeschaltet wird.

Der "Schuldige", gleichzeitig unschuldig, ist die Fritzbox, da sie im Router Modus so funktionieren muss.

Wenn wir das z.B. alles über die LAN Ports oder im WLAN und im selben Netzwerk abwickeln würden hast Du 100% Recht, da die Shelly´s ja gar kein Internet brauchen um zu funktionieren.

Hmm (der Text ist etwas länger geworden, nur bei Interesse, sehr laienhaft erklärt),

wir dürfen jetzt zwei Sachen nicht miteinander vermischen und vermischen sie nachher doch

Der Router (wie der Name schon sagt soll der ja was von A nach B transportieren), hier die Fritzbox 4040, steht dafür mit einem Bein A im Internet (egal ob Kupfer-, Antennenkabel, Glasfaser, mobiles Gerät oder wie auch immer) und mit dem zweiten Bein B im LAN (bei Bedarf auch im WLAN).

Wenn jetzt der Router die Routinginformationen von Bein A, welches im Internet steht, bekommt muss der das ja irgendwie mit dem Bein B im LAN verknüpfen, weil man sonst nicht die Daten von B nach A bekommt; das macht der intern "von ganz alleine".

So wenn ich jetzt hin gehe und dem armen Router ganz gemein das Bein A absäge (Aua), tut dem das weh und er ist auf das übelste beleidigt und kappt daher die Verbindungen vom Bein A "von ganz allein", weil er "intern was aufräumen muss", da er die Daten ja nicht mehr von B nach A senden kann, das Bein A fehlt ja; okay?

Natürlich hat das Ganze jetzt auch einen Impakt auf das Bein B mit seinem LAN und WLAN etc. denn der schmeißt das kurzer Hand in den Gully und das ist der Moment wo die Verbindung zum Shelly ausfällt.

Der Router ist nicht lange beleidigt, hat "intern" alles aufgeräumt und ist wieder zu neuen Schandtaten bereit, allerdings ohne Bein A, was ja noch immer fehlt. Jetzt stellt sich die erste Frage in wieweit der Router gut aufgeräumt hat und ob er intern die Verbindung zum Shelly noch kennt oder nicht (siehe Log im Router).

Der Shelly wiederum kriegt er mit ob seine Verbindung getrennt wurde oder nicht, das ist die zweite Frage und die lässt sich leicht im LOG/Debug vom Shelly beantworten.

Jetzt fangen wir an zu mischen und zwar mit DHCP, denn wir müssen ja irgendwie Bein B mit Bein A verbinden.

Dazu hat die Fritzbox 4040 einen DHCP Server an Bord, welcher dem Shelly eine IP Adresse zu weist ABER auch eine Gateway-Adresse und eine DNS-Adresse und damit fangen die Probleme an (nur nebenbei die Zugewiesene IP-Adresse hat eine Gültigkeit, sagen wir mal von 7 Tagen oder 12 Stunden und *mit* dieser IP-Adresse hat dann logischerweise die Gateway,- und DNS-Adresse dieselbe Gültigkeitsdauer. Das wird wichtig wenn sich diese Adressen zwischenzeitlich ändern sollten und der Shelly das nicht mitkriegt).

Also, die IP-Adresse bekommt der Shelly vom DHCP Server, also intern, sagen wir mal Bein B, ABER die Gateway-Adresse und eine DNS-Adresse bekommt er ebenfalls intern, nur vom Bein A! (reicht die Fritzbox 4040 "intern" durch) Und wo bitte soll der die denn herholen wenn wir ihm das Bein A absägen?

Basteln wir ihm das Bein A wieder dran und schon funktioniert der Shelly wieder. So funktioniert die Fritzbox wenn sie im Modus Router betrieben wird, der schickt dann alles zum WAN-Port (Achtung WAN, nicht WLAN) raus und bekommt von da auch wieder alles rein; wenn das so nicht gewünscht wird, muss der Modus des Routers geändert werden.

Nun, das war die "Routing Geschichte", zum WLAN egal ob mit oder ohne Internetverbindung, der Shelly *muss* das WLAN sehen und sich mit ihm Verbinden egal ob der Router mit dem Internet verbunden ist oder nicht; notfalls beide Systeme resetten, das muss funktionieren.

Ja der Shelly darf ja mal auch gestresst werden, wenn er nicht mitspielt

Spaß beiseite, der Print Screen ist ja nur ein Beispiel von meinem Test-Shelly.

Nichts desto Trotz muss der Shelly gestresst werden um ein Fehler zu finden, heißt ja nicht das der Shelly Schuld ist, aber wenn man zeitgleich Ereignisse von unterschiedlichen Geräten erfassen möchte, geht das mit einem Syslog-Server gut; alternative Wireshark, aber wir wollen ja nicht gleich mit Kanonen auf Spatzen schießen.

Zumal ich ja extra darauf hin gewiesen hatte nur einige wenige Shelly´s zu stressen, sobald der Fehler gefunden wurde stellt man das selbstverständlich sofort wieder ein, wozu den Shelly mit unnötigem belasten; versteht sich eigentlich von selbst.

Habe ich in einem anderen Thema bereits geschrieben:

"Wenn möglich Wifi channel optimization ausschalten und sich einen Kanal suchen auf dem weniger los ist und den fest einstellen.

Ferner prüfen ob das WIFI nicht zu bestimmten Uhrzeiten abgeschaltet wird (z.B. Nachts).

Standardmäßig würde der Shelly bei Signalstärke-Werten (rssi) unterhalb von -80 auch auf die Suche nach neuen AP/Repeater gehen (falls möglich deaktivieren), daher ebenfalls im LOG der Shelly´s prüfen wie die rssi Werte sind, bei unter -80, wenn möglich einen zusätzlichen Repeater zwecks Signalverstärkung dazwischen setzen."

Mesh deaktivieren.

Falls möglich das LOG/Debug des Shelly´s auf einen Syslog-Server übertragen lassen, da wird er parametrisiert (auf einem Shelly Plus 1), die URL mit dem Port eingeben, Print Screen ist nur ein Beispiel:

Da der Syslog Server ja 24/24h laufen sollte, sollte es bei der Auswertung des Logs leichter sein die eventuellen Probleme zu einer bestimmten Uhrzeit festzustellen. Man kann dann auch mehrere Shelly´s die Daten an den Syslog Server senden lassen, aber bitte, für den Anfang, nicht zu viele gleichzeitig, sonst wird das Syslog zu unübersichtlich.

Ich habe mir extra einen Shelly Plus 1 zu viel gekauft, den ich nur zum Testen verwende, was bedeutet, das ich, unter anderem, auf den als erstes auch ein neues Update installiere und wenn alles passt kommen die Anderen dran.

Dazu habe ich ebenfalls extra einen AP zum Testen nur für die Shelly´s gekauft um das WLAN und eventuelle Verbindungsprobleme vom Shelly zu testen.

Das Ganze hängt an einer geschalteten Mehrfachsteckdose und so ist eine minimale Testumgebung sofort verfügbar.

Kostet jetzt nicht die Welt, macht das Leben bei einer wo möglichen Fehlersuche aber viel einfacher.

Zitat von clathi

Meine Erklärung:

Wenn die Fritz!Box den Paketmitschnitt startet, klinkt sie sich in alle Pakete ein, die an der überwachten Schnittstelle ankommen.

Und schickt dann alles in eigenem Namen weiter.

Bei einem Paketmitschnitt wird der Promiscuous-Modus aktiviert, welcher aber keine Daten manipuliert, der liest (horcht) nur mit.

Zitat von Kreisel

hm ok also ich wollte jetz wie oben beschrieben u/z und gnd anschließen. Geht das nicht? Und ja ich benutze eine Fernbedienung. Und was meinst du mit 2 shellys?

Danke

Wenn ich die Anleitung richtig verstanden habe, braucht man den ersten Shelly für U/Z zum Schließen, den zweiten Shelly OTW zum Öffnen und eigentlich zur Sicherheit einen Dritten Shelly für STOP, falls man aus irgendeinem Grunde den Vorgang unterbrechen muss.

In der Programierungsebene gibt es eine Möglichkeit das Verhalten des Steuereingangs ein,- umzustellen:

mit 3F Öffnen/Stop/Schließen/Stop bräuchte man dann nur noch theoretisch einen Shelly. Bitte mal überprüfen wie das Eingerichtet worden ist.

Das mag jetzt vielleicht nicht die Lösung sein, wenn möglich könnte man den AP aus dem Mesh nehmen (was wahrscheinlich andere Probleme mit sich zieht) oder einen neuen AP (oder vielleicht hat man noch einen übrig) installieren und den nicht ins Mesh einbinden.

Wenn das ganze Haus an dem Teil hängt funktioniert das logischerweise natürlich nicht.

Bei mir in der Garage läuft ein extra AP nur für die Shelly´s und der hängt mit Absicht nicht im Mesh weil der so schlechte Werte zum nächsten Repeater hat, das ich da gar kein Mesh haben möchte.

Wäre also eher ein Workaround, als eine Lösung.

Kann die Vitotronic nur einen oder zwei Heizkreise steuern?

Und wenn ja, wird der zweite Heizkreis verwendet oder ist der frei?

Hat die Ölheizung einen Außentemperatur Fühler und wird der Öl-Heizkessel mit einer gleitenden Temperatur gefahren? Dann klappt das mit der Steuerung bezüglich der Temperatur nicht.

Ich würde den Stecker vom Ölbrenner auf keinen Fall manipulieren, da verliert man die Hersteller-Haftung, wenn deswegen Haus & Hof abbrennt und Menschenleben in Gefahr geraten wird man seines Lebtages nicht mehr froh.

Wie bitte wird der Öl-Heizkessel aus dem Pufferspeicher beschickt, mit der gleichen Pumpe wie P3?

Kleine Skizze wie das Schematisch angeschlossen ist wäre dienlich.

Hmm,

wenn ich das LOG vom Cisco richtig lese, moniert der, gemäß 802.11 WLAN a, b, g, n, ac, ax, vielleicht eine "Missing Supported Rate".

Will sagen die 5 GHZ können wir ja bei den Shelly´s ignorieren da die das nicht unterstützen, bleiben also nur noch die Standards für 2,4 GHz übrig und der Cisco will wegen "schlechtem" WLAN "runterschalten" entweder auf z.B. 802.11b oder geringere Data Rates, was er nicht kann/darf.

Da würde ich mal im Cisco schauen welche Verbindungstypen b,g,n,ax erlaubt sind und diese gegebenenfalls nach unten hin bis inklusive b erlauben oder (ich habe keinen Cicso) da soll es auch einen Eintrag für "unterstützte" Data Rates geben, diese mal prüfen ob sie mit dem Shelly harmonieren.

Ist allerdings ein bisschen komisch bei RSSI Werten von -60, funkt da vielleicht nicht zeitweilig ein kaputter Kühlschrank oder was weiß ich (WLAN vom Nachbarn oder mehreren Nachbarn) dazwischen?

Könnte natürlich auch sein, das der Cisco einen an der Waffel hat...