Beiträge von cweiske

Zitat

Ich frage mich gerade, welchen Sinn dieser Thread hat,

Ich wollte einfach nur meine Erfahrung teilen. Scheinbar ist das aber hier der falsche Ort dafür.

Bitte löscht den Thread; ich darf das nicht.

Vor einigen Tagen kam ich früh in die Küche und fand einen kaputten Kühlschrank vor: Temperatur war nicht so kalt wie gewöhnlich, Licht im Kühlschrank war aus, und auch die Temperaturanzeige funktionierte nicht.

Also schnell einen Ersatzkühlschrank aus der Scheune geholt und den gesamten Inhalt umgepackt, damit dieser wieder ordentlich gekühlt wird.

Nachdem das Frühstück durch und die Schnitten geschmiert waren dachte ich nochmal über den Kühlschrank nach. Es war komisch, daß alles ausgefallen war - wenn der Kühlkreislauf kaputt wäre, würde wenigstens die Temperaturanzeige und das Licht noch gehen. Aber alles auf einmal...

Ich entfernte dann die Scheuerleiste unter dem Kühlschrank und fand .. einen Shelly Plug S - eine per Netzwerk schaltbaren Zwischenstecker. Der war aus.

Mitte diesen Jahres nutzte ich einige der schaltbaren Zwischenstecker um den Stromverbrauch von Haushaltsgeräten zu messen, was erklärt, warum der dort steckte.

Letztes Jahr nutzte ich Shelly-Relais um Schwibbögen zentral ein- und auszuschalten. Vor einigen Tagen hatten wir wieder die Schwibbögen aufgestellt, und einer von ihnen hat einen als Schalter verbauten Shelly. Dieser war konfiguriert, bei Betätigung einen zweiten Shelly auszuschalten, und zwar genau den, den ich zur Strommessung des Kühlschranks genommen hatte.

(Original)

Ich habe bei einem Shelly Plus1 mit Firmware 0.11.4 Bluetooth angeschaltet und wollte es vom Laptop aus koppeln.

Leider findet weder der Laptop per "bluetoothctl scan le" noch per "hcitool scan" etwas, auch ein Android-Handy findet den Shelly nicht über die "Bluetooth-Gerät koppeln"-Funktion.

Wie funktioniert die Bluetoothverbindung/-konfiguration bei den Shellys auf technischer Ebene? Ist das Protokoll irgendwo dokumentiert?

Version 1.9.0 ist auf Google Play verfügbar: https://play.google.com/store/apps/det…mi04151309.home

Die Android-App HomeApp nutzt das auch um das Icon auszuwählen.

In der Android HomeApp wird je nach eingestelltem Gerätetyp ein anderes Icon angezeigt. Sonst macht es dort keinen Unterschied.

Zitat

Top Welche Firmware ist auf dem? Würde mit dem Log gerne einen Bug-Report erstellen

Hab schon ein TIcket aufgemacht: #S-22095264. Dort hängen auch JSON-Dumps der Shelly-Einstellungen an.

Firmware: 20211109-130223/v1.11.7-g682a0db

Bei mir sind 9 Shellies im Einsatz, und nachdem der nächstgelegene Access Point ausgefallen war sind alle zum weiter entfernten gewechselt.

Nachdem der nächstgelegene wieder an war, sind alle - bis auf 2 - automatisch wieder zurückgewechselt. Siehe Diagramm.2022-01-12 wifidevs-day.png

Ein Shelly Plug S hat aber ein ziemliches Verständnisproblem von gut und schlecht. Er hängt auf dem schlechten fest und ändert seine Meinung auch nicht. Ich hab das Debuglog angeschaltet und 10 Minuten gewartet und dann meinte er:

603089169 mgos_wifi_sta.c:638     Avg RSSI -87, will scan for a better AP
603095192 mgos_wifi_sta.c:467     Starting scan
603100485 esp_main.c:137          SDK: sl
605214947 esp_main.c:137          SDK: scandone
605221559 esp_main.c:137          SDK: usl
605226573 mgos_wifi_sta.c:345     WiFi scan result: 2 entries
605231430 mgos_wifi_sta.c:397     AP queue:
605236578 mgos_wifi_sta.c:400       0: SSID: home.cweiske.de                 , BSSID: f8:d1:11:8b:3d:0e RSSI -63 cfg 0 att 0
605242945 mgos_wifi_sta.c:400       1: SSID: home.cweiske.de                 , BSSID: 5c:49:79:3b:b1:e0 RSSI -83 cfg 0 att 0
605249402 mgos_wifi_sta.c:497     Current AP is best AP

D.h. er hat bei seiner Verbindung -87 dB, scannt nach APs und findet einen mit viel besseren -63 dB und meint trotzdem, dass der aktuelle der beste ist. Irgendwo ist da schon ein Bug.

Wenn ich den Netzwerkverkehr von Wlan-Geräten mitschneiden möchte, nutze ich meinen Laptop um einen Access Point aufzuspannen. Das Gerät muss dann meinen Laptop-AP nutzen, von dem der Verkehr dann ins Netzwerk weitergeleitet wird.

Dadurch ist sichergestellt, dass der Verkehr wirklich über mein Gerät läuft und ich mit Wireshark mitschneiden kann.

Ich hab das so schon mit Tolino e-book-readern und Android-Handys gemacht.

Vor Weihnachten habe ich geholfen, in die Android-App "HomeApp" Unterstützung für Shelly-Geräte einzubauen.

Die gestern auf F-Droid veröffentlichte Version 1.8.0 hat jetzt offiziellen Support für Shelly 1, Shelly Plug S, Shelly 2.5 und Shelly Plus 1.

Die App kann Shellies automatisch im Netzwerk erkennen, erlaubt die Schaltersteuerung und zeigt Stromzähler, Temperatur und Feuchtigkeitsdaten an.

Da sie aber noch keine Gruppierung in Räume unterstützt ist sie nur für kleine Installationen geeignet.

Links:

- Quellcode: https://github.com/Domi04151309/HomeApp

- Mein Blogpost mit Screenshots: http://cweiske.de/tagebuch/homeapp-shelly.htm

- F-Droid: https://f-droid.org/packages/io.github.domi04151309.home/

- Google Play Store: https://play.google.com/store/apps/det…mi04151309.home

Zitat

Das verlangt aber das ich auf der Shelly mit HomeKit FW die Zeit bestimmen kann wo Strom fliest.

In der Standardfirmware eines Shelly kann man einen "Auto off"-Timer in Sekunden einstellen. Sobald man den anschaltet, schaltet der sich nach x Sekunden automatisch wieder aus.

Ich habe an diesem verregneten Sonntag einen Shelly 1 in unsere alte Stereoanlage eingebaut, damit diese beim Anschalten des Satellitenreceivers (Dreambox) automatisch mit angeschaltet wird.

Damit das Anschalten per Fernbedienung und normalem An-/Ausschalter noch funktioniert, schließe ich mit dem Shelly den gleichen Stromkreis, den auch der An-/Ausschalter der Anlage schaltet. Per "Auto off"-Timer des Shellys wird der Power-Stromkreis nach 1s wieder ausgeschaltet.

Details und Bilder: http://cweiske.de/tagebuch/stereo-shelly-dreambox.htm

Zitat

Ich denke hier an den Bootloader, Webstack und ähnliches.

Die Firmware nutzt als Basis Mongoose OS, das einen "Open Core"-Modell nutzt. Ein paar Basisfunktionalitäten sind quelloffen, aber die die interessanten sind dann Closed Source und müssen gekauft/lizensiert werden.

Zitat

Danke, dann bin ich wohl auf einen Marketingtrick reingefallen.

Ging mir auch so. Ende 2021 steht immer noch auf der Packung vom Shelly1, daß die Geräte "Open Source" sind.

Der Support meinte:

Zitat

By source code we mean that you can flash the device with custom firmware.

Das hat nichts mit Open Source zu tun

Ich habe den Support gefragt wo denn der Quellcode ist, weil auch Ende 2021 auf den Shelly1-Packungen immer noch "Open Source" steht.

Sie meinten:

Zitat

By source code we mean that you can flash the device with custom firmware.

Das ist Etikettenschwindel

Mein Ticket wurde jetzt geschlossen mit dem Hinweis, dass ich doch einen Wunsch abgeben sollte auf https://shelly.cloud/support/devices-and-features-requests/ .

Ich habe eine Antwort vom Support erhalten:

Zitat

Unfortunately, there is not one command which can execute this whole procedure

It is not as easy as for the first generation devices. We recommend setting a pin for your device and not restricted login.

Dann verlinken Sie auf die Gen2-Dokumentation https://shelly-api-docs.shelly.cloud/gen2/Overview/…#authentication und das wars.

Vermutlich soll man jetzt Javascript-Scripte bauen Das funktioniert aber nicht mit den Shelly Buttons oder den anderen v1-Geräten.

Und die vorgeschlagene PIN hilft nichts, weil die API trotz PIN immer noch offen ist - nur das Webinterface halt nicht.

----

Ich hab mal im Ticket geantwortet:

Zitat

This is very, very, very unfortunate.

Setting a PIN only restricts the web interface, but still allows full access to the device via its API.

It basically prevents everyone to secure their devices if they want to control them from Webhooks on other Shelly devices.

Shelly-NG-Geräte nutzen nicht mehr HTTP Basic Auth, sondern Digest Authentication. Da kannst du Benutzer und Passwort nicht mehr in die URL aufnehmen.

Wenn du die Befehle auf Kommandozeile mit curl ausführst, kannst du dessen --digest-Parameter nutzen:

curl -s --digest -u admin:meinpasswort http://192.168.3.72/rpc/Switch.Toggle?id=0

Wenn du gar einen Shelly v2/NG von einem anderen aus per Webhook-URL schalten willst, kannst du das ganz vergessen -> Shelly Plus 1 / 1PM - Authentication - HTTP Requests

• Das 2. URL-Feld ist für die 2. Action - man kann mehrere angeben, die nacheinander ausgeführt werden
• Bei mir kann der Button 1 einen Plug S mit Benutzername + Passwort schalten - so wie du es gemacht im Screenshot zeigst.

Welche Firmwareversion hat dein Button? Gibt es eine Aktualisierung?

Ja, es ist immer "admin":

API-Doku: Successful Request with Authentication Details

Zitat

username: string, must be set to admin. Required