Shelly Scripting - kurze Einführung

    Shelly-Script

    Wir möchten Ihnen das neue Feature näher erläutern, das die Plus- und Pro-Serie haben wird.


    Die Entwicklung einer Lösung, die komplexe Logik oder zeitlich asynchrone Interaktionen zwischen Komponenten verwendet,

    erfordert Flexibilität, die nicht einfach durch die ständige Komplikation des zugrunde liegenden Betriebssystems des Geräts bereitgestellt werden kann.

    Wie bei jedem anderen Softwaresystem ist/sind die Softwarelösung(en) des „Benutzerraums“ besser geeignet, um eine für den Anwendungsfall

    spezifische Logik zu implementieren, die vom Endbenutzer entwickelt werden kann.

    Die natürliche Lösung für die Komplexität der zu erledigenden Aufgaben der Benutzer besteht darin, die Rechenlast des Lösungserstellungsprozesses zu verteilen. Wir hier können einfach nicht so schlau sein, die richtigen Formeln zu finden. Daher befähigen wir unsere Benutzer, Lösungen zu erstellen, indem sie Skripte auf Shelly-Geräten (zweite Generation) bereitstellen.

    Tatsächlich ist uns derzeit kein anderes Gerät bekannt, das dies bietet.

    Jetzt können Sie noch mehr von der _kreativen Autonomie_ haben, die eines der Haupterfolgsthemen unserer Produkte war.

    Wir möchten Ihnen nicht sagen, wie Sie das Problem lösen können, wir möchten nicht, dass Sie eine Drittanbieter-Integration verwenden, wir möchten nicht, dass Sie einen Hub kaufen.

    ## Was ist ein „Shelly-Skript“?

    Ein Skript ist ein Programm, das in einer Teilmenge von JavaScript geschrieben ist, einer bewährten Technologie - Mongoose OS, der gleiche Stack, auf dem der Rest unserer Geräte aufgebaut ist. Die geheime Sauce ist die Offenlegung der RPC-APIs für das Skript. Und die zusätzlich benötigte Funktionalität - HTTP.GET (bald POST), Timer für die Planung, die Möglichkeit, die lokale Weboberfläche des Geräts zum Hochladen, Bearbeiten und Verwalten laufender Skripte zu verwenden.

    Wir werden in den kommenden Tagen Links zur Dokumentation und zum Repository mit Beispielen veröffentlichen.


    (frei übersetzt aus der Ankündigung von Dimitar Stanishev, Allterco)



    Link zum englischsprachigen Tutorial:

    https://shelly-api-docs.shelly.cloud/gen2/Scripts/Tutorial

    Link zu den offiziellen Scriptvorlagen:

    https://github.com/ALLTERCO/shell…ation-switch.js

    Zitat

    Daher befähigen wir unsere Benutzer, Lösungen zu erstellen, indem sie Skripte auf Shelly-Geräten (zweite Generation) bereitstellen.

    Tatsächlich ist uns derzeit kein anderes Gerät bekannt, das dies bietet.

    Naja, wer will denn als reiner Endkunde auch ein IoT Gerät auf einer Umgebung programmieren, wo ein Syntaxfehler höchstens mit einem leisen Klicken des Relais quittiert werden kann.

    Süsse Idee - recht schnell werden Horden von Programmierern OpenSource Projekte rund um die Scriptingfähigkeit der neuen Shellies hochziehen in Form von Eclipse-Plugins, wo man nur seinen Shelly-Zoo mit IP-Adresse einträgt und man dann eine Simulation des Geräteparks mit den selbsterstellten Scripten fahren kann.

    Hey ... schon die URL-Geschichte der Shellies untereinander funktioniert mangels Debugging nur zum wegrennen, das soll mit Scripting auf dem Shelly-Host besser werden?

    Bernd

    Hallo Bernd,

    Zitat von Sixtus Freebyte

    ...

    Hey ... schon die URL-Geschichte der Shellies untereinander funktioniert mangels Debugging nur zum wegrennen, das soll mit Scripting auf dem Shelly-Host besser werden?

    ...

    Ich liebe solche Pauschalaussagen ungemein, zeugen sie m.M. nur davon, dass sich der Aussprechende meist nicht sehr intensiv damit beschäftigt hat.

    Auf der "Url-Geschichte" basieren alle Kopplungen Shelly-Homematic und die funktionieren 100% zuverlässig.

    Debugging bei einem http-Einzeiler: Der ist echt gut. :thumbup:

    Naja, vielleicht (oder eher bestimmt? :/ ) habe ich nach >90 eingebundenen und vernetzten Shelly noch nicht genug Erfahrung gesammelt. ^^

    Zitat von 66er

    Auf der "Url-Geschichte" basieren alle Kopplungen Shelly-Homematic und die funktionieren 100% zuverlässig.

    Ich schrub: schon die URL-Geschichte der Shellies untereinander (also zB. Motion steuert Relais). Mit einem Server dazwischen (vorallem, wenn er mit fertigen URL-Templates arbeitet), ist das eine ganz andere Geschichte.

    Wieso ist das eine ganz andere Geschichte? :/

    Du machst mich neugierig. :thumbup:

    Nochmal, Deine Aussage war:

    Zitat von Sixtus Freebyte
    ...

    Hey ... schon die URL-Geschichte der Shellies untereinander funktioniert mangels Debugging nur zum wegrennen, das soll mit Scripting auf dem Shelly-Host besser werden?

    ...

    Die URL-Geschichte, also DDD, braucht erstmal weder meine Homematic noch Deinen Server, sondern funktioniert unter Nutzung der REST-API mit 1 http-Befehl (oder meinetwegen auch mehreren). Das funktioniert und sollte unstrittig sein.

    Binde ich nun weitere Instanzen ein (meine Homematic, Dein PC) und es gibt Probleme, sollte das Debugging auf genau dieser Instanz laufen. Was wilst Du denn da auf dem Shelly debuggen?

    In meinen Skripten sind Debug-Code-Zeilen enthalten, die mir z.B. bei Problemen nach Firmwareupdates die Richtung weisen. Aber damit hat der Shelly nicht wirklich was zu tun. Alle Infos, die ich vom Shelly in der Situation brauche, liefert die Statusabfrage.

    Zitat von Sixtus Freebyte

    Ich schrub: schon die URL-Geschichte der Shellies untereinander (also zB. Motion steuert Relais). Mit einem Server dazwischen (vorallem, wenn er mit fertigen URL-Templates arbeitet), ist das eine ganz andere Geschichte.

    Das ist direkte Kommunikation, das schon nicht mehr. Du mußt Dich schon entscheiden. Die Aussage ist ein Widerspruch in sich.

    Und tatsächlich eine ganz andere Geschichte. ;)  :thumbup:

  • Dieses Thema enthält 38 weitere Beiträge, die nur für registrierte Benutzer sichtbar sind.