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.
Hast Du mal den Trade angesehen?
?? sagt mir nichts..
ich denke du hast / hattest da irgendwo im ioBroker einen Loop gebaut, der auf den Shelly zeigt.. in der grafischen Oberfläche (VIS) oder in den Szenes/Blockly-Sachen..
Aber da bin ich dann fachlich komplett raus..
Bis auf kleine Ausnahmen, das man den "orginalen-"Schalter mehrfach hin und her schalten muss bis Shelly den Zustand merkt. Damit kann man aber in erster Linie leben.
Damit musst du nicht leben, das kann man Einstellen: unter Settings - Schalter Type "Edge", und alles wird gut 
Bezüglich der Cloud/Einbindung in Alexa:
Haben deine Shellys ihre IP-Adressen per DHCP erhalten oder hast du feste IP-Adressen vergeben.. falls feste IP, dann poste bitte mal die Konfiguration (Daten für IP-Adresse, Subnetz-Maske, Gateway und DNS)
wie stellst du dir das denn vor? willst du dann vom Gecko aus sekündlich den Shelly via REST-API abfragen, ob er an oder aus ist? Eigentlich wäre der Weg anders herum sinnvoller, also der Shelly meldet dem Gecko seinen Zustand..
Hat der MyGecko-Kram eine REST-API oder spricht ggf. MQTT oder CoAp, wo man solche Dinge drüber realisieren könnte? Ist das ein Gerät bei dir in der Wohnung oder ist das eine rein cloud-basierte Lösung?
Das Problem bei mir ist, dass ich langsam nicht mehr durchblicke, wer hier welche Probleme mit welchen Geräten hat..
chrissiboy kannst du ggf. ein eigenes Thema aufmachen oder einen Link posten, wo du deine exakten Probleme bereits beschrieben hast..
Danke.
ich teste das morgen früh mal, dann geb ich dir Rückmeldung..
hast du mal versucht den einen "bösen" Shelly im ioBroker zu löschen?
das betroffene Ojekt markieren und dann hinten auf den Mülleimer klicken..
Über WebUI des Shelly, WebUI der CCU3, sowie meiner Visualisierung Mediola per iPad werden die Schaltbefehle sofort umgesetzt.
dann würde ich eher nicht auf einen Fehler im WLAN tippen, denn wenn es von der CCU3 zum Shelly schnell geht, dann kannst du WLAN-Probleme eigentlich ausschließen..
der HMIP WRC6 ist per Funk 868Mhz mit der CCU verbunden, oder? Könnte es da, ggf. durch Updates auf der CCU, eventuell Probleme geben?
Hast du einen Rechner (Raspberry PI) oder dergleichen im Heimnetz, der permanent läuft?
Dann schreib ich ein kleines Programm in Go, welches als Proxy die Daten vom Shelly (http://shelly-ip/relay/0) holt und dir ein faches ON oder OFF zurückgibt..
i3 via http zu 3x Shelly2.5
Kannst es ja mal probeweise hiermit zwischen I3 und den 2.5ern probieren..
https://github.com/shelly-tools/ShellyActionRouter
Also I3 an ActionRouter, der dann an die 3x Shelly 2.5.
Die Software kann wahlweise auf einem PI, Linux oder Windows-PC gestartet werden.
Vorab: ich mach euch beiden da keinerlei Vorwürfe, ihr wolltet helfen und habt im eigenen LAN Beobachtungen gemacht, die diesen Schluss durchaus zulassen. Zudem nutzt ihr Beide eure Shellys ohne Cloud, so dass ihr mögliche Fehler, die daraus entstehen, gar nicht spüren würdet.
Da meine Shelly-WLAN-Signalstärke aber beim Eintragen der jeweiligen Repeater-IP von rot auf grün springt, ist es dann doch merkwürdig! Na gut, man muss nicht alles verstehen!
Dafür gibt es eine relativ einfache Erklärung: Der Shelly verbindet sich beim Einrichten mit dem WLAN, je nach Empfangsqualität/Kanaleinstellungen etc. kann er sich aber trotzdem mal mit einem weiter entfernten AccessPoint verbinden.
Durch das Ändern des Gateways hast du einen Neustart des Wifi-Stacks im Shelly ausgelöst, d.h. er beendet seine Wifi-Verbindung, löscht seinen Cache und macht anschließend einen Full-Wifi-Scan.
Da hat er dann den nähergelegenen Repeater gefunden und schon ist die Signal-Qalität auf einmal deutlich besser.
Den gleichen Effekt hättest du vermutlich mit einem Reboot des Shelly erzielt.
Aber mal das Problem mit OH weggelasen, warum wird der Netzwerkbefehl welcher direkt beim Flood gespeichert ist, nicht zuverlässig ausgeführt?
Wohin schickst du den denn? zum OpenHAB container?
Hast du eventuell einen Shelly1, den du als Ziel definieren köntest?
Dann trag beim Flood bei "FLOOD DETECTED URL" mal den Shelly 1 als Ziel ein:
http://ip-vom-shelly1/relay/0?turn=toggleDas speicherst du ab.
Dann wartest du bis der Flood sich wieder im Deepsleep befindet und legst ihn in ein kleinen Behälter mit Wasser.. i
ch wette das dauert keine 10 Sekunden bis der akkustische Warnton angeht und das Licht vom Shelly1 entweder an oder aus geht, je nach vorherigem Zustand.
Ich habe nur umgesetzt was SparkyMaster und 66er in den Beiträgen 6 und 7 genannt haben.
ja, aber auch wenn die beiden Jungs das geschrieben haben und es eventuell trotzdem (mit Einschränkungen) funktioniert ist es aus TCP/IP-Sicht komplett falsch..
Das kannst du gerne hier (https://www.biteno.com/tutorial/einfu…erk-grundlagen/) oder in jedem Fachbuch über TCP/IP / Routing nachlesen.
es gibt in deinem Netz exakt ein Gerät, welches den Weg zu my.shelly.cloud kennt, das ist deine FritzBox, also dein Gateway nach "draußen".
Das solltest du unbedingt korrigieren, sonst sind Probleme vorprogrammiert.
btw. mit TLS könnte man sowohl http, als auch mqtt "unten rum" verschlüsseln, aber ob der Aufwand im Heimnetz lohnt, ist echt fraglich.
ja, aber auch TLS nutzt Zertifikate.. die werden, wenn sauber implementiert, von einer Certificate Authority ausgestellt und haben z.B. Ablauf-Daten, die CA hält/veröffentlich eine Revocation-List etc..
Der Aufwand für eine solche Integration steht in keinem Verhältnis zum Nutzen.. und wenn man sich hier im Forum mal umschaut, dann sind viele Anwender schon beim Einrichten der Wifi-Verbingung an ihren Grenzen angelangt.. Wie soll man einem IT-Laien erklären, dass er zunächst mal ein paar Bücher wälzen muss bevor er sein Smarthome-Equipment in Betrieb nehmen kann..
Wie / wohin schickst du denn deine Actions vom I3 aus? direkt zu einem anderen Shelly?
Der I3 ist ein Gerät, mit dem sich andere Shellys steuern lassen.. der hat aber kein Relais, welches ein Rollladen-Motor steuern könnte..
zum Steuern eines Rolladen-Motors braucht es üblicherweise 2 Relais, eines für "hoch", das andere für "runter" Dafür gibt es den Shelly2.5, der hat 2 Relais verbaut und kann entweder 2 separate Lampen oder einen Rolladen-Motor steuern..
CoAp ist recht simpel erklärt.. jeder Shelly sendet CoAp-Status-Nachrichten in regelmäßigen Abständen an die Netzwerk-Adresse 224.0.1.187 Port 5683
Shellys mit Strom-Anschuss machen das alle 15 Sekunden oder z.B. wenn man einen Schalter betätigt auch direkt. Shellys mit Batterie machen das alle 12 Stunden oder wenn eine andere Aktion den Status ändert, beispielsweise ein Wasser-Alarm.
Der OpenHAB mit Shelly-Binding startet normalerweise einen CoAp-Listener auf der Adresse 224.0.1.187 und lauscht auf die eingehenden Nachrichten.Denn da kann er mitlesen, was die Shellys so von sich geben..
Ich gehe mal davon aus, dass dein OpenHAB auf der Synology über Docker läuft? Grundlegende Voraussetzung wäre es, dass CoAp-Meldungen ihren Weg in den Docker-Container finden..
Dementsprechend muss beim Container unter Netzwerk Port 5683 von intern auf 5683 auf extern gemappt sein (UDP).
Läuft der OpenHAB denn über Bridge oder Host-Netzwerk?
PS: Ich hab hier selbst eine DS220+, könnte es also im Ernstfall mal selber durchtesten..
Ich bin mir sehr sicher das das bis vor ein paar Wochen noch nicht so war.
CoAp-Messages werden über UDP an eine Multicast-Adresse geschickt. Der Shelly schickt die Mesage einfach ab und wartet nicht auf eine Quittung, ob sie tatsächlich angekommen ist.. Spätestens wenn das Relais geschaltet wird, sendet der Shelly die Nachricht..
Hast du seit dem Zeitraum irgendetwas in deinem Netzwerk verändert? Firmware-Update vom Router / AccessPoint, Einstellungen verändert, neue Komponenten eingerichtet etc?
Da hast du einen Gedankenfehler..Actions sind dazu gedacht, HTTP-Kommandos an andere Geräte zu schicken..
Beim I3 ist das mit dem MQTT sicherlich trotzdem sinnvoll.. wenn aktiviert, dann sendet er bei jedem Druck auf den Schalter entsprechend Status-Meldungen an den MQTT-Broker (in deinem Fall Mosquitto).. Diese Meldungen müssen auf dem Broker ausgewertet werden.. dazu brauchst du aber eine Logik-Ebene, die entscheidet, bei welchem Button welches MQTT Kommando wohin geschickt wird..
ein Beispiel wäre:
wenn I3 Button1 kurz gedrückt wird, sende eine MQTT Nachricht an shellies/shellyswitch25-40F52001xxxx/roller/0/command open
Das kann man z.B. mit ioBroker, OpenHAB oder HomeAssistant realisieren..
PS: Bei meinem I3 hab ich durchweg sensationell schnelle Reaktionszeiten unter einer Sekunde.. ich denke, da wirst du ein Problem mit deinem WLAN haben..
PPS: Wozu sollte man im lokalen LAN verschlüsseln? das macht es langsamer und viel komplizierter..CA notwendig, abgelaufene Zertifikate etc..99,9% aller Anwender wären damit hoffnungslos überfordert..
PPPS: auch über MQTT verschlüsselt der Shelly nicht
Hallo Reiner,
ich hab deinen Beitrag weiter oben überflogen und eine Erklärung dafür..
Die Eintragung im Gateway habe ich geändert von der Router-IP auf die Repeater-IP.
das hier ist definitv falsch, weil es gegen jegliche Grundlagen des TCP/IP-Protokolls handelt. Ein Gateway ist ein Netzwerk-Gerät mit mindestens zwei "Beinchen" und damit in der Lage, Netzwerk-Pakete von einem Netz (dein lokales Netz) in ein anderes Netz (z.B. Richtung Internet) zu transportieren..
Dein lokales Netz dürfte nach dem folgenden Prinzip aufgebaut sein:
FritzBox: 192.168.178.1
Repeater: 192.168.178.50
Shelly 192.168.178.211
Subnetz-Maske: 255.255.255.0
Durch die Subnetzmaske befinden sich allle Geräte mit einer IP-Adresse 192.168.178.x, also den ersten drei Stellen, im gleichen Netzwerk. Wollen diese untereinander kommunizieren, dann können sie das so, weil sie sich im gleichen Netz-Segment befinden.
Wollen Sie mit einem Teilnehmer außerhalb dieses Netzwerks kommunizieren, dann brauchen sie dafür ein Gateway (und einen DNS-Server).
In deinem Netzwerk gibt es genau ein Gerät, welches diese Funktion erfüllt: dein Router (Fritzbox)
Er hat zwei "Beinchen" und kann unterscheiden, ob ein Netzwerk-Paket an einen Teilnehmer innerhalb des lokalen Netzwerkes oder außerhalb des Netzwerkes erreicht werden muss.. außerdem hat dein Router eine Funktion, mit der man IP-Adressen in sprechende Namen umwandeln kann (DNS).
wenn dein Shelly also z.B. mit der Shelly-Cloud reden möchte, dann benötigt er ein Gateway und einen DNS-Server, der den Namen my.shelly.cloud in eine IP-Adresse umwandeln und auch erreichen kann.
Eine korrekte Einstellung wäre z.B. diese hier:
Alternativ stellt man die IP-Adressen auf DHCP, denn dann werden IP-Adresse, Subnetzmaske, Gateway und DNS automatisch (vom Router mit DHCP-Server) richtig vergeben.
So, hier noch kurz die Bestätigung nach Test: der Long Press (Langes Drücken) startet den Rollladen, stoppt aber nach dem Loslassen nicht.
Und was ist, wenn ich „hoch“ gedrückt halte? Fährt er dann nur so lange hoch, bis ich wieder los lasse?
nein, das wäre die Einstellung "Momentary" im Shelly, die wird üblicherweise für Schalter benutzt.. Taster geben ja nur einen kurzen Strom-Impuls (1. Impuls an - zweiter Impuls aus)..
Ich kann das aber gerne morgen früh mit dem Long-Press-Verhalten testen, da ich hier sowohl Rollläden mit Schaltern als auch Tastern verbaut habe.. Im Moment ist es schlecht, weil die Kids schon schlafen.. da will ich die Motoren nicht unnötig laufen lassen..
