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.
-
probier mal folgendes:
http://<ip-vom-shelly>/ota?url=http://archive.shelly-faq.de/shelly-homekit-Shelly25.zip
<ip-vom-shelly> tauscht du gegen die IP-Adresse des Shelly aus... danach (ca 2-3 Minuten) sollte der Shelly mit Shelly2.5 Homekit laufen.. dann machst du wieder die Original-Shelly Firmware drauf, aber dieses Mal die Richtige, also die für 2.5.
-
Hängt am SW die gleiche Phase wie an L? bitte mal messen..
-
ist ein Bug und wird mit Firmware 1.9 gefixt..
-
installiere dir die alte Shelly2.5 Homekit-Version..
https://github.com/mongoose-os-ap…eases/tag/1.7.0
dann von da aus wieder auf die (richtige) Shelly 2.5 Firmware..
-
wenn sich ein Gerät im Netzwerk mit der URL my.shelly.cloud verbinden will, muss es
a) die IP-Adresse, die sich hinter diesem Namen verbirgt, per Routing erreichen können (dafür ist das Gateway, also dein Router, der kennt den Weg dahin)..
b) den sprechenden Namen in eine IP-Adresse umwandeln können, das ereldigt ein DNS-Server.
Möglicherweise waren (sind) einige IP-Adressen in älteren Firmware-Versionen hart im Quelltext verdrahtet und deshalb hat es geklappt, aber eigentlich wäre das ziemlicher "Schweinskram" aus programmiertechnischer Sicht.
-
dann wird es daran liegen.
Manuell (mit Cloud) bedeutet:
Gateways ist Pflicht: -> IP-Adresse des Routers
DNS ist Plicht -> IP-Adresse des Routers (oder irgendeinen DNS im Internet, z,b, 8.8.8.8)
-
Zusäzliche Komponenten (AccessPoints) im Wifi oder ist der Router alleine da?
IP-Adrdressen manuell oder per DHCP vergeben? wenn manuell, wer/was ist bei Gateway und DNS eingetragen?
-
Hier meine Unify-Config, das ist das vom Wifi, in dem sich die Shellys befinden:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
Die 4 AccessPoints (alle über LAN/DLAN miteinander verbunden) haben alle die folgenden Einstellungen:
für das 2,4Ghz Wifi:
- VHT20
- Autochannel
- TransmitPower: Auto
- Bandsteering "Balanced
-
Sprich, kann Shelly 1 nicht direkt über das WLAN einen Befehl an die HUE schicken?
Nein, das geht nicht.. der Shelly schickt "Befehlszeilenparameter" per HTTP-GET-Variablen..
Die HuE-Bridge möchte aber ausschließlich Paramter per HTTP-POST-Variablen, so als würdest du ein Formular ausfüllen und abschicken.
"Friends of HuE" arbeiten über Zigbee und sprechen das gleiche Funkprotokoll wie die HuE Bridge, nich Wifi wie ein Shelly.
Fakt: Es geht, aber eben nur mit einem "Übersetzer", der entweder beide Protokolle (Zigbee und Wifi) kann oder HTTP-GET-Variablen annehmen und auswerten kann und darauf basierend HTTP-POST-Variablen an die HuE-Bridge schicken kann.
-
Läuft OMD Labs auch auf einer Synolgy, habe dazu leider nichts gefunden.
Kann ich dir in ein paar Tagen sagen, meine DS220+ ist bestellt 
https://github.com/ConSol/omd-labs-docker
Den Entwickler Sven kenne ich persönlich, von daher vermutlich ja, das wird schon klappen.
-
Ich hab hier ebenfalls 4 Ubiquit AP, und kein einziger Shelly rebootet oder braucht einen Reboot.. Die haben teils Uptime von > 60 Tagen.
In der Config deiner AccessPoints wird irgendetwas faul sein.. Ich tippe auf irgendeine Option in den Advanced Settings vom Controller..
-
Was meinst du mit PoE? Power over Ethernet? Das hat zunächst einmal mit dem AP (Access Point) nichts zu tun.
Doch, weil AP, die über PoE gespeist werden, kein zusätzliches Netzteil brauchen..
da reicht das LAN-Kabel, welches als "Backbone" sowieso vorhanden sein sollte..
Ein Kumpel von mir schwört auf Sophos (hat selbst über 50 Shelly), in der Firma nutzen wir Fortinet, ich selbst hab Ubiquiti-Geräte..
Die Ubiquiti sind ok (und vergleichsweise günstig), haben aber seit Baujahr Ende 2019 und neuer ihre Probleme mit batteriebetriebenen Shelly, da dauert der Connect nach dem Deepsleep satte 10 Sekunden. Für den Betrieb mit einem Shelly-Button1 ist das eine Katastrophe..
-
Der Traffic eines Shelly ist nicht die Welt, davon wird ein Internet nicht langsamer.. hab hier selbst aktuell 40 Stück in Betrieb und die Download-Bandbreite hat sich im Vergleich zu vorher (ohne Shelly) kein Stück verändert..
Was aber passiert: Die Access-Points haben durch die 40 zusätzlichen Wifi-Clients mehr zu tun. Da die Shellys aber im 2.4Ghz funken und meine andere Infrastruktur im 5Ghz merke ich davon nichts..
"Billige" AccessPoints / Router gehen aber gern mal in die Knie, wenn sehr viele Clients gleichzeitig verbunden sind.
-
Da die Shellys ja über das WLAN im Haus laufen, benötigen diese gewisse Kapazitäten. in diesem wireless Netzwerk. Wenn jetzt beispielsweise 30 Shellys im Haus installiert sind, hat das Auswirkungen auf das WLAN hinsichtlich Internetgeschwindigkeit oder Stabilität?
Ja, indirekt schon.. daher würde ich auf Technik setzen, die üblicherweise im Gewerbe-Bereich eingesetzt wird.. die ist in der Regel für viele, gleichzeitig verbundene Wifi-Clients ausgelegt.
Der Traffic, den die Shellys machen, ist zu vernachlässigen.. wenn du sie aber eh nur lokal und ohne Cloud betreiben willst, dann fällt auch kein Traffic Richtung Internet an.
-
Jedenfalls werde ich diese Portweiterleitung nun mal entfernen.
Hoffentlich reicht das..
Wenn da erstmal Schadcode drauf ist, dann connected die sich mit dem Botnetz und kann von da aus kontrolliert werden.. Das kannst du dir ähnlich wie de Shelly-Cloud vorstellen, da existiert ja auch kein Portforwarding und du kannst sie von Außen kontrollieren..
du solltest auf jeden Fall prüfen, ob sich die Kamera mit einem Firmware Update neu flashen lässt..
-
Der Self-Reboot über Action http://localhost/reboot ist unter Garantie (absichtlich) geblockt, weil man damit einen Shelly unbrauchbar machen kann..
Default-Einstellung des Relay auf "POWER ON" und bei OUTPUT SWITCHED ON URL die Action und der Shelly befindet sich in einer Endlosschleife.. bevor das Webinterface wirklich oben ist, hat er sich schon wieder selbst gebootet..
Ich denke da sollte das Support Team von Allterco mal mit den Entwicklern reden.
-
Ich hoffe das war einigermaßen verständlich.
ich kann dir leider nicht folgen
Eine Kreuzsschaltung ist für mich eine Lampe, die ich über 3 oder mehr Schalter an und ausschalten kann.
Vielleicht machst du mal eine Skzze, wie viele Lampen, Schalter und Shellys du verbaut hast?
Oder jemand anders versteht dein Konstrukt
-
Und ich würde mich denn beschweren, wenn das Licht länger braucht, bis es angeht.
Genau deswegen hatte Dimitar mal irgendwann auf Facebook geschrieben, dass sie das nicht machen werden.. Weil eben der Großteil der Anwender deutliche Nachteile hätte..
-
Die Einzige mir bekannte Möglichkeit in einen Shelly Software "einzuschleusen" wäre ein Over-The-Air Update mit einer manipulierten Firmware.. Man kriegt ihn zwar vergleichsweise Einfach zum Absturz (z.B. BrutForce auf das Webinterface) aber das war's dann auch..
Dazu müsste der Viren-Hersteller die Shellys bis ins tiefste Detail kennen (Speicheradressen vom Bootloader, Kenntnisse über das Betriebssystem / Erstellen von mongoose Binary-Images)...
Mongoose ist bis auf die Shellies meines Wissens auch nicht sonderlich verbreitet, dementsprechend ist die "Zielgruppe" im Vergleich zu anderen Smarthome-Herstellern (Tuya, Sonoff, Phillips Hue, C for GE, Homematic... ) noch vergleichweise klein..
Ich halte das zwar generell nicht für absolut ausgeschlossen, aber extrem unwarscheinlich..
-
Allterco hat das m.W. bei allen Shellys mit Relay / Lichtfunktion nicht eingebaut, weil ja in der Regel der Schalter NICHT auf Detached steht, sondern das interne Relay/Mosfet schaltet.
ein Doppel oder Dreifach-Druck würde dann zwangsweise das direkt angeschlossene Licht erst deutlich verzögert einschalten können, weil ja immer erst gewartet werden muss, ob noch ein oder mehrere weitere Tastendrucke folgt.
Für solche Zwecke gibt es den IX3 