Beiträge von akreienbring

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    An dieser Stelle mal eine Einordung / Abgrenzung von S-Central im Vergleich mit

    • Shelly Cloud
    • Homeassistent mit Shelly Integration

    Klar gibt es noch andere. Aber diese beiden Systeme sind auf jeden Fall zu betrachten, wenn es um das Thema Smarthome geht.

    Offensichtlich: Bei der Frage der verfügbaren Funktionen kann (und will) S-Central da nicht mithalten. Und natürlich gibt es Unterschiede bzgl. der Einsatzbereiche und der eigenen Ansprüche an den Grad des Smarthome - Managements und der Automatisierung.

    Eines fällt aber sofort auf:

    • Shelly Cloud - Wie der Name schon sagt: 'Cloud'. Für volle Funktionalität ist sie notwendig. Inklusive kostenplichtigem Angebot für spezielle Funktionen. Dafür aber quasi null Installation und Konfiguration notwendig.
    • Homeassistant - Kann lokal installiert / konfiguriert werden, ist aber kein Zuckerschlecken 😉Auch hier Cloud kostenpflichtig möglich.
    • S-Central - Keine Cloud, läuft mit minimalen Voraussetzungen im lokalen Netzwerk. Installation und Konfiguration vergleichsweise einfach. (Nodejs)

    Alles andere würde hier zu weit führen. Und übrigens, wenn von Interesse:

    Seit dem neuen Release 2.5.0 von gestern: Immerhin knapp 60 mal heruntergeladen. Und damit hoffentlich auch installiert. 😀 Wenn hier eine/r von euch dazugehört würde ich mich über Feedback freuen.

    Ach ja... (Ergänzung) da wäre auch noch Allterco Fleet Management. Ebenfalls ohne Cloud zu nutzen. Vielleicht kann hier jemand seine Erfahrungen damit schildern.

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    Hallo,

    S-Central unterstützt keine Automatisierung. Eine Szene ist da "nur" das Abspeichern und wieder herstellen der Schalterzustände (Output, Brightness, White, RGB) von einem oder mehrerer Shellies.

    Ist bisher auch nicht geplant, in dem Terain tummeln sich HA und andere "übergeordnete" System deutlich effizienter. Da müsste ich mit viel Aufwand was nach-programmieren, was andere schon viel besser können.

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    Ooops, I did it again. 😉

    Feeback welcome. Download, contribute or inform about issues on Github.

    Release v2.5.0

    07.04.2026

    Client (2.5.0)

    • feature: Save/Restore current switch settings for all or some devices as scene
    • fixed: Not using NotifyFullStatus for getting current script status
    • fixed: Userprofile updated in client even if data was not inserted in DB
    • fixed: Error when switch settings were pasted after the copy source was altered.

    Server (2.5.0)

    • fixed: Switch.Set and RGWB.Set commands not turning on / of the switches

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    Feeback welcome. Download, contribute or inform about issues on Github.


    Release v2.4.0

    27.03.2026

    Client (2.4.0)

    • Migrated to Typescript
    • feature: Minimize the cards in the Script/KVS Tab
    • feature: Start and stop scripts directly from the overview of devices
    • feature: Show server- and client version in nav bar. ATTENTION: index.html has changed!
    • feature: Highlight specific parts of a WS message from a device when the icon is clicked
    • feature: Delete all notifications at once
    • feature: Show websocket, matter and mqtt status in WSInspector
    • fixed: more precise script and switch status by using NotifyStatus for Gen2+ devices
    • fixed: List/Batch table not filtered/sorted

    Server (2.4.0)

    • feature: Start and stop scripts directly from the overview of devices
    • feature: Setting a device to offline, if there's no response to a status request for 3 min.
    • feature: Added an 'Error' script example, that can be used to test the script error notification.
    • feature: Start the server as 'Test' server to enable cypress tests to create data.
    • fixed: more precise script and switch status by using NotifyStatus for Gen2+ devices
    • fixed: wrong available firmware updates of Gen1 devices
    • fixed: Available firmware updates only correct after server restart
    • fixed: Adding unnecessary auth header to status request
    • fixed: Sending an script error notification, if the script was stopped manually

  • Frage zu der ID von Scripten

    Hallo,

    Ein Shelly sendet u.a. einen "NotifiyFullStatus" der Informationen zum Script enthält enthält:

    "script:1":{"id":1,"running":true,"

    Es wird aber auch ein "NotifyStatus" gesendet (z.b. wenn ein Script gestoppt / gestartet oder wenn fehler auftreten. Das sieht dann so aus:

    "script:2":{"error_msg":null,"errors":[],"running":true}

    Wichtig: bei NotifyStatus fehlt die im NotifyFullStatus enthalten id des Scriptes!

    Frage: entspricht die Angabe "script:x" IMMER der im NotifiyFullStatus angegebenen id?

    Folgendes Szenario: 3 Scripte werden erstellt. Eines wird gelöscht ein anderes neu erstellt: Welche id bekommt dann dieses neue Script? Bekommt es die "freigewordene" id oder etwa die id 4?

    Meine Test deuten darauf hin, dass id's wiederverwendet werden. Aber ich meine mich zu erinnern, dass das mal anders war und sehrwohl auch die 4 als id vergeben wurde.

    ?(

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    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

  • WLAN Einstellungen bei 60 Aktoren ändern

    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.

  • BLU Motion Kopplungsmodus?

    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.

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    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?

  • S-Central - Applikation (React / Nodejs) für Monitoring + Kontrolle von Shellys

    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

  • Update Pfad für OTA

    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. :-(