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.
Meine "Administration" (bei produtkiv genutzten Shellies) beschränkt sich eigentlich auf die einmalige Einrichtung: also Shelly einbauen, konfigurieren und dann tut er jahrelang das was ich will. Ab und an mal ein Firmware-Update über die App, fertig.
Wozu man die oben genannten Funktionien in einer produktiven Umgebung brauchen könnte erschließt sich mir auch nicht so ganz: spielt ihr von Morgens bis Abends an den Geräten rum?
Limitation would produce a "limit exceeded" message. No idea what is causing the -104 error but this is probably related to the remote site.
I have copied the entire JSON from the URLto a github Gist, this is working fine.
https://gist.githubusercontent.com/eurich/d0288bc…2db237c2/hidden
function handleResponse(result, error_code, error_message) {
print(error_code);
print(error_message);
print(JSON.stringify(result.body));
}
Shelly.call(
"http.request", {
method: "GET",
url: 'https://gist.githubusercontent.com/eurich/d0288bc265e1f324e2afe7589ece8fb9/raw/287649319150556b354029433562f2a82db237c2/hidden',
ssl_ca: '*',
},
handleResponse
);Ich kenne Modbus jetzt nicht im Detail aber meines Wissens fuktioniert RTU über eine serielle Schnittstelle, sowas hat ein Shelly nicht.
- Der SHelly 3 EM kann gar kein Modbus
- Der neue Shelly Pro 3 EM spricht Modbus TCP über das LAN-Interface
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Modbus
ich kann es leider im Moment selbst nicht ausprobieren aber es müsste mit folgender Syntax funtionieren, ext_t ist der Wert für externe Sensoren,
shellies/shellytrv-<id>/thermostat/0/command/ext_t
die Firmware 0.13-beta 2 ist verfügbar, die könnte Abhilfe schaffen 
Sie besitzen leider nicht die notwendigen Zugriffsrechte, um diese Aktion auszuführen.
nee, eben nicht.. ich hatte die Person schon vor längerer Zeit (bestimmt > 1 Jahr) blockiert, anfangs hatte das geklappt aber mittlerweile leider nicht mehr..
Meine Shelly Plug S und 3ME wir in der Cloud nicht angezeigt trotz eigener IP Adresse die ich den Geräten gegeben habe.
wurde die IP-Adresse auch aus dem richtigen Subnetz vergeben? Meist ies es besser, wenn man den Shelly einfach in das WLAN des Routers (AccessPoints) einbindet und die Vergabe der IP-Adresse dem DHCP-Server (vermutlich der Router) überlässt.
Wenn du was von Video-Tutorials schreibst vermute ich mal vorsichtig, dass deine Netzwerk-Kenntnisse relativ begrenzt sind.
die Forensoftware ist buggy, ich hab einen Benutzer in der Ignore-Liste, kann seine Beiträge aber trotzdem sehen (obwohl ich das nicht möchte).. irgendwann in der Vergangenheit hatte das mal funktioniert.
Könntet ihr euch darum kümmern?
- Ist der Repeater Teil eines Mesh-Netzwerkes oder wurde der ggf. ohne Mesh-Betrieb mit der FritzBox gekoppelt?
- ist der Repeater ausreichend groß dimensioniert? (welches Modell)
- Haben alle Shellies die aktuelle Firmware?
Ich vermisse eine Anleitung und einen integrierten Temperatursensor!
das hast du bereits in einem vorherigen Beitrag geschrieben.. warum wiederholst du das hier anstatt dich direkt an den Hersteller (per Ticket) zu wenden?
Aber das hatte ich ja fast schon vergessen, du bist ja nur zum Stänkern hier
Ich habe jetzt mehrfach festgestellt das die Verbrauchsdaten auf 0 zurück gesetzt werden
wo meinst du das genau? Daten in der Cloud werden eigentlich nicht zurückgesetzt bzw. gehen nicht verloren.
Was "verloren" geht ist der interne Counter "totals" von der REST-API.
die Daten hierzu liegen im flüchtigen Speicher und sind nach jeden Reboot, Firmware-Update oder Stromausfall weg.
Bei den neuen Plus Geräten gibt es die Einstellung meines Wissens nicht mehr..
Feature-Request stellen, je mehr das tun desto eher wird es umgesetzt.
https://www.shelly.cloud/de/company/contacts
- Es sind alle auf der gleichen Phase (die ist IO, hab schon Wochenlang ein Speicheroszi drauf hängen gehabt wegen dem Rundsteuersignal flackern Thema)
Ich hab von Elektrik / Eletrotechnik viel zu wenig Ahnung als dass ich da irgendeine Hilfe wäre aber das klingt zumindest verdächtig nach einem möglichen Zusammenhang. kannst du probeweise mal einen Dimmer an einen anderen Außenleiter hängen um zu gucken, ob das "Flackern" dann noch vorhanden ist?
Vielleicht hat ja auch einer der anwesenden Elektriker / Elektrotechniker eine sinnvollere Idee?
Wenn mehre Shellies hintereinander wegsterben könnte die Ursache rein theoretisch auch irgendwo im Haus zu suchen sein. Gibt es denn bei den bisher abgerauchten Dimmern sonst noch irgendwelche Gemeinsamkeiten (außer möglicherweise der Charge)?
- mit oder ohne N?
- mit oder ohne Bypass?
- identische Leuchtmittel?
- alle am selben Außenleiter?
...
Ansonsten hat Krauskopp natürlich Recht, solange Gewährleistung drauf ist auf jeden Fall an den Verkäufer wenden.
Warum hat das nicht mit dem I/O Einstellungen funktioniert?
vielleicht weil deine Geräte im WLAN nicht untereinander reden dürfen (WLAN-Einstellungen) oder weil du die Ziel-Shellies mit Benutzername / Passwort geschützt hast? oder den falschen Befehl eingefügt hast oder die falsche IP-Adresse?
das ist eine Frage, die du eigentlich nur selbst beantworten kannst. Ich hab das Thema jetzt von oben nach unten durchgelesen und nirgends gefunden, was du jetzt bei den i/o Actions probiert hast bzw. was da genau nicht klappt.
guck dir das hier mal an, da ist in Grunde ein Sleep (über delay) umgesetzt worden.
Aber wenn das nochmals vorkommt nach der Vollinstallation wäre das bitter.
ich denke das hätte auch problemlos mit dem alten Account geklappt, möglicheweise ein Problem mit alten (gecashten) Daten auf dem Smartphone.
- the blue pause on the left: script is currently active (running)
- the grey play icon in on the left: script is currently stopped (not running)
the switch on the light controls start behaviour of scripts.
- on_ script starts automatically (after reboot or power loss)
- off: scitpt isn't automatically started.
mein Homematikzeugs läuft, seitdem ich es eingebaut habe.
das kann ich für die meisten meiner Shellies auch sagen. ich hab hier reihenweise 1er, 1pm und auch noch 2er (Vorgänger vom 2.5er) und die laufen seit dem Einbau komplett fehlerfrei. Aber das sind natürlich nicht 12 Jahre, denn Shellies gibt es ja erst seit weniger als 5 Jahren. meine Ältesten sind von 2018.
Lediglich beim 2.5er hatte ich 3 Ausfälle (alle fast zeitlgleich, dank Thomas aber repariert). die anderen 5 laufen ohne Probleme.
Ein Verbindungsaufbau über HTTPS ist nicht möglich.
korrekt, es geht nur HTTP. für ein fehlerfreies HTTPS bräuchte man theoretisch eine eigene Zertifizierungstelle (CA) im Haus, die hat vermutlich niemand
Wäre eine MQTT-Kommunikation zwischen Homeassistant und Shelly auch unterschlüsselt?
korrekt, bei den Geräten der ersten Generation läuft die MQTT-Kommunikation unverschlüsselt. Shellies mit dem Zusatz "Pro" und "Plus" sind Geräte der 2. Generation, die können MQTT auch als Secure (also verschlüsselt), aber auch hier gilt: macht man es richtig braucht man eine CA. die Weboberfläche vom Shelly ist dann trotzdem noch unverschlüsselt (also http)
Ich bin auf dem Gebiet leider neu und kenne mich nicht wirklich aus - aber bedenklich finde ich es schon, wenn keine Verschlüsselung vorliegt.
Natürlich ist verschlüsselte Kommunikation immer schöner und sicherer, allerdings ist die Einrichtung auch entsprechend komplex und ein Großteil der Shelly Nutzer ist ja schon bei der manuellen Vergabe einer IP-Adresse überfordert. Wie soll man denen erklären, wie man eine CA aufsetzt, Zertifikatsanforderungen erstellt, diese dann mit der CA signiert, dann auf dem Client (Shelly importiert) ..
Sofern sich der Shelly aber Richtung Cloud bewegt ist die Kommuknikation mittels TLS 1.2 verschlüsselt, also da wo es problematisch würde ist entsprechende Sicherheit vorhanden.
