Beiträge von akreienbring

Neues Jahr, neues Release!

Release v2.3.0

13.01.2026

Client (2.3.0)

• feature: Click on a KVS entry to go to the corresponding webpage
• feature: Using more MUI colors (72) for the comsumption charts
• feature: Copy device controls (eg. white, brightness, rgb) from one device to another
• feature: Display the number of device reloads after a firmware update
• feature: Timeline now shows consumption gaps (null values) in Minute chart
• fixed: Password visible in local storage after credentials update
• fixed: Wrong user data when reconnecting an previously connected user
• fixed: Unwanted navigation to user home after profile update
• fixed: Showing wrong tooltip when hovering over charts
• fixed: Blog entries could not be expanded to show the full text
• fixed: Wrong devices display when using filter and sort together
• fixed: Too many unnessesary requests send to server, when tab changes or filter / sort was used
• fixed: Switch and Script status not updated from wsmessage
• fixed: Script status not changed when it was stopped by an error
• fixed: Incorrect chart data in timeline by minute because of missing null values

Server (2.3.0)

• feature: Limit the number of device reloads after a firmware update to 5
• fixed: Removed unnessesary Server configuraration (http-server.host)
• fixed: An update to a beta version was not handled correctly
• fixed: Wrong log (update successful) when a device was offline and reloaded
• fixed: Script status not updated on the server side from wsmessage

Guten Morgen,

sorry für die späte Antwort.

Ja, das kann S-Central schon. Aber....

Der Artikel https://community.shelly.cloud/topic/11650-wh…ew-wifi-router/ beschreibt das Thema echt gut.

Die Option 2 (Wifi Batch change mit 2 aktiven Routern) mit der Shelly App ist für den TE die bessere Option.

Der Unterschied:

• Während die Shelly App, nach dem Batch change, die Verbindung zu den Geräten behält (dank Cloud Verbindung) würde meine Applikation sie verlieren, da Client und Server im alten Netzwerk laufen. Erst wenn Client und Server dann auch auf das neue Netz umgestellt werden, würde der Zugriff auf die Shellies wieder funktionieren.
• Meine Applikation verlangt statische IP Adressen. Und die haben im neuen Router (wahrscheinlich) ein anderes Schema. Die Shelly App kommt aber auch mit DHCP klar.

Fazit: Wenn lediglich das Passwort geändert wird, ist S-Central super! Wenn sich die SSID ändert (das WIFI Netz geändert wird) erfordert es mehr Aufwand.

ITComplete Erzähl doch mal wie es gelaufen ist.

Ok.... 20 sek. haben geholfen.

Hallo,

ich habe einen ca. 2 Jahre alten BLU Motion. Plötzlich und unverhofft, zeigt der keine Reaktion mehr. Hab den Taster 10 sek. gehalten, nichts.

Shelly sagt Batterie hält 5 Jahre, hab's trotzdem mal eine neue verwendet. Immer nocht nichts. Ist der Sensor kaputt oder gibt es noch etwas was ich probieren kann.

Vielen Dank.

Does it really Matter?

Also ich kann mit Firmware 1.7.0 Matter auf meinen Gen3 Devices aktivieren. Super!

Und was mach ich jetzt damit? Konkreter: Ich denke darüber nach in meine App eine Testsuite für die Matter Kompatibiltät der Shelly Devices zu implementieren. Soll heißen: Mindestens Ein- und Ausschalten sollte über das Protokoll möglich sein.

Da gibt es matter.js. Sollte mit nodejs funktionieren. Aber weiß jemand wie genau ich, bei aktiviertem Matter, ein Shelly Relay ein oder ausschalte?

Hier noch ein Screenshot der neuen Batch Funktionen:

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Hallo,

Release 2.1.0 ist auf Github verfügbar. Feedback welcome!

Changelog:

Client (2.1.0)

• new: (Batch) functions for update, reboot and WIFI settings of devices
• fixed: Error that reset wsmessages when a device was updated-
• fixed: Error that disallowed deleting an created administrator
• fixed: The change of a users role did not enable the save button
• Code refactored for better readability

Server (2.1.0)

• fixed: Error that allowed the main admin to delete himself
• fixed: User could not be updated
• Support for RGBW2 (Gen1)
• Code refactored for better readability
• With firmware 1.7.0 UDP log output seems to contain the script ID. Hence console.log output is also captured by S-Central
• Supports Firmware 1.7.0. Due to (breaking) changes in the way UDP logs are formatted, Logs and Script Errors are not received with v2.0.2
• Log capturing is now more robust
• Added two example scripts (Example, Watchdog) that demonstrate:
  • how to log output that is captured by the Shellybroker server
  • hot to use the webservice endpoints of the Shellybroker
  • how script Errors are detected and send to the Shellybroker as notification

Zwar ein alter Thread, aber vielleicht braucht's ja noch mal jemand

Computerbild erklärt hier ein Verfahren, wie mit Hilfe von http://deviceip/longifyid

die ProductID eines PlugS verlängert werden kann, wenn sie noch 6 stellig ist. Und das kann dann wohl auch der Grund für die o.a. Fehlermeldung sein.

Ich hab's selber nicht probiert.

Zum Script hier auch nichts. Aber es gibt da dieses Youtube Video. Der hat das mit einem Pro EM-50 gelöst. Evtl. findest du da weitere Hinweise.

Ich bin noch nicht sicher, ob ich Downgrades implementiere.... Wahrscheinlich eher nicht... Und welches offizielle Tool unterstützt Batch-Updates? Also: Alle auf einmal updaten...

Für mich schon. Ich entwickle gerade für meine Applikation S-Central eine neue Funktion, die Batch Reboots und Updates ermöglicht.

Und da ist es durchaus möglich, dass jemand mit einem GEN1 device upgraden (oder auch downgraden) will....

So, wie ich das jetzt sehe, ist:

• Für GEN1 das Upgrade und Downgrade möglich, wenn man diese Archiv API's verwendet und den /ota Befehl mit der richtigen URL verwendet.
• Für GEN2 das Uprade simple, wenn man ShellyUpdate verwendet. Ein Downgrade ist nicht möglich, weil ein vergleichbares Archiv nicht existiert.

Richtig?

Aber wenn das so ist, dann existiert zwar /ota für GEN2, hat aber eigentlich keine sinnvolle Funktion, oder? Ganz einfach, weil ich keine URL zu irgendeinem Firmware ZIP generieren kann.

Fazit: Alles ein wenig verwirrend.

Ah ... OK.

Und dann gibt es da auch noch diese API mit Firmware versionen.

Ist komplizierter als ich dacht Muss wohl doch zwischen GEN1 und GEN2 unterscheiden....

Ja ich weiß, du empfiehlst ShellyUpdate! Und ich möchte mit dem /ota Endpunkt arbeiten.

Wenn ich mir das offizielle Firmware Archiv angucke, dann arbeitet /ota evtl. nur mit einer URL?

Z.B.

http://[shelly-ip]/ota?url=http://archive.shelly-tools.de/version/v1.12/SHBDUO-1.zip

kann das sein?

Hab diesen alten Thread gefunden.

http://shelly-ip/ota?update=1

Stimmt das noch? Und wie unterscheidet man dann zwischen Stable und Beta?

tvbshelly Danke! Aber ich möchte lediglich auf die originale Firmware updaten. Und eine Lösung finden die kompatibel zu Gen1 geräten ist. Und das ist bei /ota der Fall.

Weiß jemand wie das funktioniert?

Hallo, ich habe die gleiche Frage: HTTP Endpoint: /ota aber wie genau muss der Payload aussehen?

In der Doku ist wohl nur die Response beschrieben:

{
    "status": "idle",
    "has_update": false,
    "new_version": "20200320-123430/v1.6.2@514044b4",
    "old_version": "20200320-123430/v1.6.2@514044b4"
}

Nehmen wir das aktuelle Release der Firmware 1.7.0 als Beispiel. Installiert ist bei mir "20250520-083711/1.6.2-gc8a76e2", wenn ich die fw_id nehme und "1.6.2", wenn ich die ver nehme. fw_id und ver stammen aus einem [ip]/shelly request.

Mit einem Shelly.GetStatus request bekomme ich jetzt aktuell diese Information

"available_updates":{"stable":{"version":"1.7.0"}}

Wie sieht jetzt der GET [ip]/ota request aus,, der die Firmware auch tatsächlich updated?

1. [ip]/ota?old_version=20250520-083711/1.6.2-gc8a76e2&new_version=1.7.0
2. [ip]/ota?old_version=1.6.2&new_version=1.7.0
3. [ip]/ota?new_version=1.7.0

Komisch ist auch, dass die stable 1.7.0 so "kurz" geraten ist. Also offensichtlich nur die ver und nicht die fw_id unter stable angegeben wird.

Ergänzung: mit [ip]/rpc/Shelly.CheckForUpdate kriege ich übrigens das hier:

{
    "stable": {
        "version": "1.7.0",
        "build_id": "20250730-063208/1.7.0-gbe7545d"
    }
}

Damit erweitern sich die Möglichkeiten um

4. [ip]/ota?old_version=20250520-083711/1.6.2-gc8a76e2&new_version=20250730-063208/1.7.0-gbe7545d

5. [ip]/ota?new_version=20250730-063208/1.7.0-gbe7545d

Tja, mag sein, aber wenn dafür die Batterie von dem Ding länger durchhält, ist das für mich OK!

Normalerweise schon! Da der H&T aber "schlafen geht" ist das nicht möglich. Jedenfalls ist mir das seinerzeit nicht gelungen.

Ich hab's auch mit einer Aktion auf dem H&T probiert, hat aber irgendwie auch nicht funktioniert!

Ist hier zwar offtopic. Bin für Tips aber dankbar.

EDIT: Ich wusste doch, dass ich damals hier um Hilfe ersucht habe:

Beitrag

RE: Shelly Plus 2 PM - im Skript Werte von Shelly H&T aus der Cloud auslesen

Hallo, ich stand vor der gleichen Herausvorderung!

Direkt aus dem H&T auslesen geht schon mal nicht, weil der nämlich meistens pennt.

Wenn er nicht pennt, dann kann er allerdings Webhooks / Actions auslösen.

Allerdings sind diese offensichtlich eingeschränkt, denn der Versuch Werte direkt an anderes shellies zu übergeben, scheitert an "Ungültige Aktion".

http://[shellyIP]/rpc/Script.Eval?id=1&code='setTemperature(${ev.tC})'
http://[shellyIP]/rpc/KVS.Set?key="eventTemperatureSalon"&value=${ev.tC}'

…

akreienbring

17. Juli 2024 um 10:34

Hier mal ein Beispiel, für den Zugriff vom Script aus.

Ich jedenfalls, musste ein wenig tüfteln, um die Werte von meinem Shelly PLUS HT aus der Cloud zu holen.

let url = 'https://<your_server>.shelly.cloud/v2/devices/api/get?auth_key=<your_auth_key>';
 let body = JSON.stringify({ids: ['<your_id>'], select: ['status']});
 Shelly.call('HTTP.POST', 
   {url: url, body: body, timeout: 60},
   function (response) {
     const oResponseBody = JSON.parse(response.body);
     console.log(oResponseBody[0].type);
     const status = oResponseBody[0].status;
     const oTemperature = status['temperature:0'];
     const oHumidity = status['humidity:0'];
     console.log('Temperature: ' + oTemperature.tC + ' Humidity: ' + oHumidity.rh);
    }
 );

Ausgabe:

sensor

Temperature 22.2 Humidity 44.9

Die Reponse ist ein Array, weil man mehrere IDs angeben kann.

FendiMan

1. Der Client läuft im Browser. OS ist also ziemlich egal. Der Server mit NodeJs. (v20+) ist verfügbar für viele Plattformen.

2. Smarthome Systeme wie Io-Broker oder Homeassistant werden nicht benötigt. Diese, ergänzt z.B. um OpenHab, sind Plattformen für die Integration verschiedener Protokolle / Systeme. S-Central soll einfach nur Shellies managen.

Weitere Fragen, Feedback welcome!