ich hab meine Shelly immer direkt Over The Air geflasht:
https://github.com/yaourdt/mgos-to-tasmota
etwas weiter unten auf der Seite sind Beispiele:
Beiträge von Seven of Nine
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.
-
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Alternativ (wenn du den Hersteller nicht kontaktieren willst) könnte man einfach Tasmota oder ESPEasy auf den Shelly flashen und gut ist..
das ist ja der Riesen-Vorteil von Shellys, jeder so wie er mag..
-
Bedeutet der Wechsel auf unicast auch, dass dein genannter Vorteil von „Listen CoAp for color change commands“ ALLE Shellys gleichzeitig steuern zu können wegfällt?
hab es gerade mal getestet, das funktioniert nur, wenn auch im Shelly "mcast" als Ziel eingetragen ist..
Sobald man den Shelly auf Unicast umstellt, werden gar keine Befehle mehr über CoIoT entgegen genommen..
-
eigentlich fragt der Shelly alle 2 Stunden nach einem Software-Update, da er bei euch aber an die URL http://api.shelly.cloud/files/firmware nicht dran darf macht er das vermutlich im Minutentakt immer wieder ..
ob das so sein sollte würde ich auch eher mit nein benantworten, besser wäre ein Checkbox- mit "Check for updates", die man an bzw. ausschalten kann..
Meines Erachtens rückt dieses Verhalten des Switchs ihn in ein dubioses Licht.
Das finde ich ehrlich gesagt übertrieben dargestellt.. funktoiniert denn irgendetwas deshalb nicht, weil der Shelly nach Software-Updates gucken will (und in deinem Fall nicht darf)? vermutlich nicht..
-
Ich wette das es irgendwie geht,
ja, via REST-API.. hatte ich ja weiter oben geschrieben..
-
Ach ja- noch am Rande. Ich habe die neue Beta Firmware 1.10.2-RC5 einmal draufgepackt jetzt sagt er "Neue Firmware" vorhanden und meint jedoch die 1.10.1 vom 23.03.2021- wohl auch ein Bug ?
kein Bug, das ist Absicht.
die letzte offizielle Firmware ist 1.10.1 und jede andere Version (auch eine aktuellere BETA) werden als nicht aktuelle Version angezeigt..
der kleine Blaue Strich in der App / webinterface dient in der Tat dazu, den Schalter-Zustand vom Anschluss SW darzustellen.. Da der bei dir ja lediglich den Zustand anzeigen soll aber das Relais nicht ändern darf sollte da bei Button-Type auf jeden Fall "Detached" eingestellt sein..
Wenn keine Push und E-Mail-Nachrichten kommen, dann hat der Shelly möglicherweise keine Verbindung zur Cloud .. kannst du im Webinterface (oben in der Mitte das Wolkensymbol) sehen.. ist das grün ist die Verbindung da, ist es Orange oder Rot dann nicht.
-
Topic ist doch richtig - oder?
nein, das ist kein MQTT Topic sondern die Syntax der REST-API-Calls.
mittels MQTT lässt sich das Relay an bzw. aus schalten.. die Einstellungen (z.B. Button Type) lassen sich nicht ändern:
https://shelly-api-docs.shelly.cloud/#shelly1-1pm-mqtt
shellies/<model>-<deviceid>/relay/0/commandacceptson,offortoggleand applies accordingly
-
Wenn ich MQTT bei dem Button1 aktiviere, scheint es so, als könne man nur Informationen über den Button1 selber darüber einsehen. Ich hatte eigentlich gedacht, dass man auch auf Knopfdruck etwas in ein bestimmtes Topic publishen kann.
MQTT benötigt einen Broker, der die Steuerung übernimmt.. z.B. Mosquitto.. Entweder machst du das über den Broker oder wie Loetauge bereits geschrieben hat via HTTP-Kommandos..
-
Na OH3 verwendet er doch
ja, wer lesen kann ist klar im Vorteil
in der Tat werden der ShellyUni und die ColorBulb mit dem OH 3.0.1 Release noch als "ShellyUnknown" erkannt..
ich warte noch auf Rückmeldung von Markus, würde aber davon ausgehen, dass auch hier das Binding auf den DEV-Build umgestellt werden muss..
-
wirklich verdächtiges kann ich da nicht erkennen, was mir aber auffällt:
es kommen regelmäßig HTTP-Reuqests von zwei IP-Adressen an, von der Adresse 192.168.30.20 sogar immer 4er-Blöcke, sprich 4 direkte Abfragen unmittelbar hintereinander..
Was ist das dür ein System? eventuell schaltest du das mal ab und schaust, ob es dann besser wird..
4005931091 mgos_http_server.c:180 0x3fff360c HTTP connection from 192.168.30.20:458804006892704 mgos_http_server.c:180 0x3fff360c HTTP connection from 192.168.178.157:50202
unanhängig davon kannst du mal http://<shellyip>/erase_sys_params ausführen und den Shelly anschließend neu starten..
Im OpenSense steht nichts sinnvolles im Log? Fehlerhafte Anmeldung, DTIM-Fehler, wer den Disconnect ausgelöst hat?
-
-
Hallo an alle, wirklich keiner dabei der einen Uni im Openhab laufen hat.
der Uni wird genau wie der Motion erst in OpenHAB3 direkt richtig erkannt.. Alternativ, wenn du OpenHAB 2.5.3 nutzt das Shelly Binding manuell gegen eine neue Version austauschen:
Abschnitt Installing DEV Build:
-
your IX3 has got outdated firmware .. current version is:
20210323-110457/v1.10.1-gf276b51
-
ob das normal ist oder ob ich eventuell Rückläufer bekommen habe welche schon konfiguriert und wo anders in Betrieb waren?
mein Bauchgefühl sagt Rückläufer..
ich hab bisher fast ausschließlich in Bulgarien bestellt und hatte bei keinem einzigen Shelly das Problem (Anzahl siehe Signatur), dass ich zunächst einen Werksreset machen musste bevor sie erreichbar sind..
-
ich habe nun auch einmal die Logs aktiviert. Aber schlau wird man daraus nun auch nicht.
am besten Logs sowohl vom WLAN-Gerät (Router, AP..) als auch vom Shelly hier posten, eventuell kann ich oder jemand anders etwas daraus erkennen..
Möglicherweise ist dein WLAN-Euqipment einfach überlastet oder falsch konfiguriert, oder die Shellys haben fehlerhafte Daten im RFData-Cache... aber ohne Logfiles ist das aber schwierig zu beurteilen..
-
mit einem Shelly 1PM alleine geht das nicht.. Man kann zwar z.B. den Schalter temporär auf "detached" stellen aber nicht anhängig vom Stromverbrauch und via App / Sprache ließe er sich dann immer noch schalten..
-
coiot_update_period bezieht sich nur Statusmeldungen, die keine Änderung beinhalten (KeepAlive)..
Bei einer echten Statusänderung (Beispiel ich drücke den Schalter, das Relais schaltet an oder aus) sendet er immer direkt.
reiner Stromverbrauch (sofern er nicht zwischendurch auf 0 wechselt) wird meines Wissens seit Firmware 1.10 alle 45 Sekunden übertragen.. das Verhalten hier ist aber auch nicht beeinflußbar..
-
you're probably refering to my site at http://archive.shelly-tools.de? SHWT-1 is the related firmware for ShellyFlood.
I haven't added real names yet because there's no such information in the file I use to download an archive the files..
Alternatively you can use the archive from this forum (which displays the real names)
-
folgende Einstellungen prüfen, am besten mittels Browser im Webinterface (http://<ip-vom-shelly>)
- Safety: Obstacle detection sollte während der Kalibrierung auf "disabled" stehen.
- Settings: Open/Close Working time sollte mindestens auf 99 stehen, eventuell reicht die Zeit nicht
Also Browser für die Kalibrierung würde ich Google Chrome oder Firefox empfehlen, zumindest beim Safari hab ich schon häufiger gelesen, dass es damit Probleme gibt / gab..
Wenn das alles nicht hilft: Debug-Log aktivieren.. das findest du ganz unten im Shelly unter Settings - Device Info.
Aktivieren - dann Kalbrierung starten, falls sie abbricht: Log inhalt kopieren (und hier posten) und das Log wieder deaktivieren..
-
Zum Anderen schickt er auch spontan Meldungen z.B. bei wechselnder Last. Zum Teil mit wenigen Sekunden Abstand.
Gibt es da einen Threshold (bzw. Info dazu) bei welcher Änderung (Power) eine Nachricht geschickt wird.Seit der Version 1.10 sendet der Shelly meines Wissens alle 45 Sekunden wenn Stromverbrauch festgestellt wird sowie bei Änderungen, wenn z.b. der Stromverbrauch beginnt oder endet..
vorher war es (glaub ich zumindest) alle 15 Sekunden..
