Der Bewegungsmelder hängt aber an selber Phase wie der Dimmer? Nicht, dass du 400V drauf gibst.
Es sind nicht alle Bewegungsmelder kompatibel, einige brauchen eine Mindestlast. Gucke dir das Datenblatt an.
Beiträge von Schubbie
VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
-
-
1&1 nutze ich auch mit 8MBit/s. Hoffentlich machen die bei uns nicht auch so einen Schabernack
-
Ich würde versuchen http zu umgehen, da man dann jede Sekunde eine Anfrage stellen müsste.
Hast du die Integration aus dem HACS genommen? Dann entferne diese bitte und nehme die offizielle. Die Offizielle soll laut Forum besser laufen und läuft bei dem Dimmer mit CoIoT und Cloud parallel.
-
Input 0 ist SW1
Input 1 ist SW2
Würdest du es per HTTP selbst abfragen wollen (wäre mit Verzögerung verbunden) oder per MQTT mitgeteilt bekommen.
Für MQTT installierst du dir am einfachsten in Node Red den MQTT Broker von Aedes. Allerdings kannst du dann keine Cloud nutzen, wenn du in den Shellies MQTT installierst.
Anderer Weg ist per CoIoT über Homeassistant, aber damit habe ich mich noch nicht beschäftigt.
Welchen Weg möchtest du gehen?
-
Ah, du willst den Status des SW2 haben?
Den bekommst du per HTTP und kannst den String parsen/filtern oder direkt per MQTT.
Du willst also nur wissen, ob Input 1 (SW2) Spannung hat oder nicht?
Was möchtest du zum Auslesen verwenden?
-
Auch hier gilt, dass man nur den einen Ausgang des Dimmers bedienen kann. Die Eingänge lassen sich nicht beeinflussen, was ja auch keinen Sinn machen würde.
-
Du musst nicht den Button bedienen sondern den Dimmer. Der Button hat doch keine Relais oder?
Am einfachsten über Node-Red einen HTTP-Node verwenden, ich persönlich bevorzuge MQTT:
-
https://www.computerwoche.de/a/ipv6-macht-vpns-probleme,3210854
Hier ist noch etwas über DS-Lite zu lesen. Hätte nicht gedacht, dass es so ein Aufwand ist.
Klar muss der VPN für eine Benachrichtigung stehen. Ich mache es per WireGuard, auf Android hat Viscerion eine Tasker Integration, worüber ich den Tunnel bei Bedarf neu aufbauen lasse. Funktioniert zugegebenermaßen aber nicht immer.
Daher ist meine Überlegung die Push-Benachrichtigungen per Signal, WhatsApp oder Threema zu übermitteln.
Aber erstmal muss geklärt werden, wie der Zugriff erlangt werden kann. Geht es bei DS-Lite denn per Portweiterleitungen? Da wäre doch gleiches Problem?
-
Ist das tatsächlich sicher unnötig Ports nach außen zu öffnen? Ich kenne die Firewall von ioBroker nicht. In der Firma habe ich eine Portweiterleitung auf die Telefonanlage. Pro Tag steckt die ca. 10 IPs in die Blacklist, die von außen zugreifen wollen, teils sind es über 20. Zu Hause habe ich bessere Möglichkeiten, da habe ich gleiche Telefonanlage, auch den SIP-Port nach außen geöffnet, jedoch den Zugriff über eine separate Firewall auf die IPs der Provider begrenzt, somit bleibt die Blacklist der Telefonanlage frei.
Daher würde ich auch zu einem VPN tendieren, was ich bei mir ebenfalls umgesetzt habe. Portfreigaben nur, wenn man weiß, dass die Geräte sicher sind oder es nicht dramatisch ist, falls jemand Zugriff erhält. Vom Ding her denke ich auch, dass das Passwort erstmal geknackt werden muss und auch Interesse bestehen muss, vom Gefühl her fühle ich mich mit VPN anstelle von Portfreigaben sicherer.
AVM liefert hierzu eigentlich auch eine gute Wissensdatenbank:
-
Ich habe eben einen Fuction-Node erstellt, der den msg.payload an Synology-Chat übermittelt. Der Change-Node muss durch diesen ersetzt werden, die Nachricht muss als msg.payload eingehen.
In den Function-Node ist folgendes einzutragen:
Codemsg.method = "url"; msg.url = "https://192.168.178.123:5001/webapi/entry.cgi?api=SYNO.Chat.External&method=incoming&version=2&token=%22<Token>%22&payload={%22text%22: %22"+msg.payload+"%22}"; delete msg.payload; return msg;Text entsprechend anpassen, speziell die IP der Synology und den verwendeten HTTPS-Port sowie den Token, den ich hier durch "<Token>" ersetzt habe.
Was ich etwas ungünstig finde ist, dass der HTTP request Node ca. 15 Sekunden senden muss, bis die Nachricht rausgeht. Ein Neustart der Synology hat dieses wieder beschleunigt.
-
Zudem soll WD40 zwar verträglich zu Gummis sein, bringt auf YouTube jedoch Luftballons zum platzen (wollte ich immer auch selbst testen, ob es so ist).
Ich würde da wohl mit Silikonspray hinterhergehen.
-
Vielleicht ist der Stift zu schwergängig und bei der Kalibrierung fährt er zu früh nach "auf", da die Stromaufnahme erreicht wurde und er davon ausgeht, das Ventil geschlossen zu haben.
Nimm den Antrieb mal runter, drücke den Stift einige Male ganz rein und kalibriere neu.
-
Ich meinte dieses Thema hier:
#5
Aber ist doch etwas anders als in Erinnerung.
-
Vermutlich meine ich den. Ich muss leider nebenbei arbeiten und kann nicht alles suchen
-
thgoebel sucht den Beitrag zu diesem Anschluss sicher raus. Das Schema kommt mir zumindest bekannt vor und ich meine, dass er es getestet hat. Ähnlich wird es hier auch im Forum unter den Anschlussschemen geführt.
-
Ich habe momentan nur einen Plug S in Betrieb, der am Weihnachtsbaum hängt. Uptime zeigt 17 Tage an, also bisher ohne Ausfall.
Ich kann mir induktive Störenflüsse vorstellen, die durch andere Geräte verursacht werden. Die Shelly 1PM sind da empfindlich, ich kann mir vorstellen, dass die Plug S ähnlich sind und bei Störeinflüssen rebooten oder hängen bleiben.
Was dieses nun auslöst kann aus der Ferne schlecht beurteilt werden. Aber meine Vermutung wären Störungen im Netz.
-
Wo auf static ip Shelly oder Box
Statische IPs werden in den Clients festgelegt, sprich in den Shellies. Du kannst in der FritzBox jedoch den Clients immer die selbe IP per DHCP zuweisen. Das wären die beiden unterschiedlichen Möglichkeiten, zu denen ich weiter oben etwas geschrieben hatte.
-
Und ein Motor, z.B. Wärmepumpe, der automatisch anläuft und abschaltet ist auch nicht vorhanden?
Da alle gleichzeitig rebooten sieht es für mich so aus, als wenn eventuell ein anderes Gerät Störungen im Netz verursacht, die die Shellies zum Absturz bringen. Wäre sonst ja ein Zufall, dass die Shellies alle zur selben Zeit neu starten.
Ich nehme an, dass es auch immer die selben sind und andere durchlaufen? Vermutlich hängen diese dann an einem gemeinsamen Außenleiter.
Falls du mehrere Plug S hast und immer die selben ausfallen, kannst du testweise durchtauschen? Meine Vermutung ist, dass die Shellies abhängig von der Steckdose, in der diese eingesteckt sind, ausfallen.
-
Du willst nur von "außen" den HTTP-Befehl ändern, den eine Action ausführen soll?
Das müsste analog zu dieser Möglichkeit gehen:
http://[shelly-IP]/settings/actions?index=0&name=btn_off_url&enabled=false
Gibst du im Browser
http://[shelly-IP]/settings/actions
ein, dann sollten die Bezeichnung klarer werden. 0 ist Input (Index) 1, 1 ist Input (index) 2...
Diese Seite könnte ebenfalls dein Freund werden:
-
stell um auf static IP, ist für die Shelly's sowieso besser.
Warum? Bei Batteriebetrieben vielleicht noch nachvollziehbar, da der Verbindungsaufbau minimal schneller gehen kann. Aber für die übrigen? Da ist es meiner Meinung nach Geschmackssache und sollte an die bisherige Konfiguration angepasst werden, um nicht 2 Arten der IP-Vergabe zu mischen. Ein besser oder schlechter lässt sich da nicht klar ermitteln.
