Beiträge von akreienbring

    Hallo Shelly Freunde,

    kann jemand was dazu sagen, ob die Shelly Authentifizierung noch so funktioniert, wie sie offensichtlich mal funktioniert hat?

    Dokumentiert ist das hier: https://shelly-api-docs.shelly.cloud/gen2/General/Authentication

    Und ein 3 Jahre altes Beispiel von Allterco gibt's hier:https://github.com/ALLTERCO/gen2-sample-code

    Ich hab das Beispiel implementiert, aber ein mit Passwort geschützter Shelly authentifiziert mich mit der angegebenen Methode einfach nicht. Auch nach dem Senden der Credentials (wie dokumentiert) erhalte ich weiter den Status 401 (unauthorized).

    Ich habe die Changelogs durchsucht, aber nichts gefunden :-(

    Firmware ist die aktuelle 1.4.2 und implementiert hab ich mit node.js 20 und Javascript.

    Hallo, ich habe gerade (mit Entsetzen) festgestellt, dass im KVS meines neuen Minis ein Eintrag vorhanden ist. Dieser kann angeblich nicht entfernt werden, da er für 'interne Zwecke' benötigt wird.

    Allerdings hat ein gezieltes KVS.delete ihn dann doch rausgeschmissen :P

    Das Beste: In der Verpackung waren 2 Minis. Der andere hat den Eintrag nicht!

    Weiß jemand worum es sich hier handelt?


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

    Hoppla, das scheint ja ein heißes Thema zu sein. Ich schildere mal, was ich mir mit Shellies gebastelt hab. Dabei ist es mir jetzt mal egal, ob das als Alarmanlage durchgeht oder nicht. :P

    Die Zutaten:

    • Blu Door/Window an der Tür, dahinter ein Blu Motion. Ob jemand reinkommt oder rausgeht erkennt man an der Reihenfolge der BLE Events.
    • Anwesenheitserkennung (derzeit nur über WLAN Connection zuvor registrierter Handies)
    • Alexa als Sprachausgabe
    • RGBW PM Plus zur Wiedergabe von Farbsignalen
    • BLU Button als "Notfall Entschärfung"
    • WLAN Kamera, angeschlossen an ein PM Relais
    • Sirene ebenfalls an einem PM Relais
    • Synology Surveillance Station als Web Videorecorder für Aufzeichnungen von der Kamera.
    • Scripting um die u.a. Logik zu implementieren.

    Die Story:

    1. Ich verlasse das Haus, mein SH erkennt, das keiner mehr da ist. Die Kamera ist aus (kein Strom).
    2. Die Tür wird geöffnet, eine Bewegung erkannt. Kamera wird eingeschaltet, ein grünes Signal gezeigt. Das System wartet auf eine WLAN Registrierung...
    3. Erfolgt die, in einer konfigurierbaren Zeit, wird die Kamera ausgeschaltet, das grüne Licht erlischt und ich werde mit Namen von Alexa freundlich begrüßt. :love:
    4. Erfolgt keine Anwesenheitserkennung einer registrierten Person, wird die "Alarmstufe gelb" ausgelöst. Ich bekome eine Meldung per WhatsApp über den Zustand und die Kamera beginnt aufzuzeichnen. Gleichzeitig wird der "Besucher" freundlich von Alexa aufgefordert, den Entschärfungsbutton zu verwenden.
    5. Macht er das nicht, kommt nach gelb nach einiger Zeit rot. Die Sirene ertönt. (JA, für höchstens 3 min.) und ich bekomme eine weitere Meldung per WhatsApp.

    Meldet sich das Handy in dieser Zeit (nach Öffnung der Tür) im WLAN an, wird sowohl die Kamera als auch das Warnlicht ausgeschaltet.
    Drückt jemand in dieser Zeit den BLU Button, wird der Alarm ebenfalls deaktiviert.
    Verlässt jemand das Haus und es erfolgt eine gewisse Zeit keine Bewegung mehr, wird der Alarm deaktiviert (Kamera aus). Ach, und natürlich werde ich auch darüber per WhatsApp informiert. 8o


    Garantiert nicht totsicher! Aber es war ein riesen Spaß, das mit Shelly Bordmitteln, ganz ohne Homeassitant oder ähnlichem zu bauen.

    Hallo, ich kann noch beitragen, dass es in FW 1.3.3 immer noch so ist. Mir ist aufgefallen, dass mein Plus 1PM vorallem dann die logs 'verschluckt', wenn der angeschlossene Verbraucher Leistung verlangt.

    Konkreter: Ist die Leistung in mw/m gering erscheinen die Logs mit größerer Zuverlässigkeit.

    In diesem Video:

    habe ich diesen Aufbau gefunden, der doch sicher auch mit einem I4 funktioniert.

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

    Ich stelle mir das so vor: 1 (von den 4) Tastern, steuert die direkte Stromzufuhr zu einer Lampe (auch ohne WLAN!), die anderen 3 können über Webhooks / Scripting weitere Funktionen steuern (Falls WLAN vorhanden). Richtig?

    Hallo, ich bin mir FAST sicher, aber doch nicht ganz...


    Ein Shelly Relais, also z.B.. der Shelly Plus I4, schaltet die Ausgänge SW1-4 mit Hilfe eines Tasters doch sicher auch dann, wenn kein WLAN vorhanden ist, oder?

    Hier ein Beitrag, der das eigentlich bestätigt:

    weissm
    23. Dezember 2020 um 20:21


    Wer steht schon gerne im Dunkeln, wenn der Router mal ausfällt. ;(

    Kann das jemand bestätigen?

    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}'

    werden also gnadenlos abgelehnt. WARUM EIGENTLICH? :cursing:

    Next Stop: Cloud!

    Also gut, dann also den Wert aus der Cloud auslesen. Grundsätzlich ist das hier dokumentiert:

    https://shelly-api-docs.shelly.cloud/cloud-control-api/communication

    Nur dummerweise falsch! :cursing:

    Denn anders als in der Seite beschrieben (Object temperature / humidity) funktioniert nur

     let url = 'https://[myServer]/device/status?&id=[myDeviceID]&auth_key=[myAuthKey]';
     Shelly.call('HTTP.GET', 
       {url: url},
       function (result, error_code, error_msg, userdata) {
         if (error_code != 0) {
           log('Error while getting value from the cloud: ' + error_msg); 
         } else {
           log(result.code);
           let oResponseBody = JSON.parse(result.body);
           log(oResponseBody.isok);
                  let oTemperature = oResponseBody.data.device_status['temperature:0'],
           let oHumidity = oResponseBody.data.device_status['humidity:0'];
           log('Temperature: ' + oTemperature.tC + ' Humidity: ' + oHumidity.rh);
         };      
       }
     );

    Ist übrigens auch mit POST möglich.

     let url = 'https://[myServer]/device/status';
     let body = JSON.stringify({id: [myDeviceID], auth_key: [myAuthKey]});
     Shelly.call('HTTP.POST', 
       {url: url, body: body},
       function (response) {
         let oResponseBody = JSON.parse(response.body);
         log(oResponseBody.isok);
              let oTemperature = oResponseBody.data.device_status['temperature:0'];
         let oHumidity = oResponseBody.data.device_status['humidity:0'];
         log('Temperature: ' + oTemperature.tC + ' Humidity: ' + oHumidity.rh);
        }
     );


    Vielleicht hilfts ja! Auf das euer Smarthome allzeit gut temperiert ist!

    Hallo,

    das Unternehmen bietet diverse Aktoren / Sensoren an. Die primäre Funktechnik scheint (lt. Recherche) EnOcean zu sein. Das Hauseigene Gateway soll aber auch zahlreiche andere Protokolle unterstützen. So werden die WLAN Shelly Produkte z.B. als "kompatibel" bezeichnet.


    Homee unterstützt zahlreiche Produkte von Afriso. Homeassistant wiederrum unterstützt EnOcean. Auf den ersten Blick klingt das alles gut. Aber hat jemand Erfahrung damit? Ziel ist es:

    • Shelly Aktoren / Sensoren in das Afriso System zu integrieren (Auslesen, Steuern, Dashboard etc.) und / oder
    • Die Afriso und Shelly Produkte in ein übergeordnetes System zu integrieren. (Vermeidung von zich verschiedenen Apps) :rolleyes:

    Vielen Dank vorab

    Hallo, ich nutze das Beispielscript für den BLE Scanner. Anscheinend gibt es (neuerdings?) alle 30min. einen Callback mit dem Zustand des Sensors. Das Objekt des Events sieht dann so aus:

    {"encryption":false,"BTHome_version":2,"pid":55,"battery":100,"illuminance":24,"window":0,"rotation":0,"rssi":-51,"address":"xyz"}

    Ich bin ziemlich sicher, dass es früher einen Callback gab, wenn der Status von offen zu zu oder umgekehrt gewechelt hat. Aber jetzt alle 30min.?
    Ist das ein Firmware Issue (1.0.16)? Interessant: In der App werden im Protokoll nur die tatsächlichen Offen / Zu Ereignisse angezeigt.


    Ergänzung: Mit Callbacks meine ich die Funktionsaufrufe durch die Subscription.

    BLE.Scanner.Subscribe(BLEScanCallback);


    Noch eine Erkenntnis: Der Zeitpunkt des "falschen" Callbacks korrespondiert mit dem Zeitpunkt den das BLU Device (hier Door/Window) als letzten Reports des BLE Gateways (hier PlusI4) angibt.

    Meine Vermutung also: Das BLE Gateway checkt in Intervallen, ob ein BLU Device noch "on" ist. Dummerweise löst das nun ein Scanresult callback aus. Also für mich ist das ein Bug (kein Feature)

    Die Script.Eval Funktion ist definitiv sinnvoll, wenn Werte direkt und ohne permanente Speicherung an ein anderes Script übertragen werden sollen. Danke für den Tip!

    Das andere Script kann dabei lokal (hier "auf dem Bluetooth Gateway") laufen oder auf einem anderen Shelly. Beispiel für einen Funktionsaufruf mit einem Object als parameter:

    Lokal:

    Code
     Shelly.call('Script.Eval',
         { id: [id of script], code: '[name of function](' + JSON.stringify([object]) + ')'}
     );

    Remote per RPC:

    Code
       Shelly.call('HTTP.GET',
         {url:  'http://[remote ip]/rpc/Script.Eval?id=[id of script]&code="[name of function](' + JSON.stringify([object]) + ')"'}
       );

    Vielleicht hilft das ja auch dem TE bei seinem Multi-Gateway Problem.

    Hallo,

    ich habe tatsächlich zwei von den BLU Buttons. Und habe zu Beginn auch mit dem o.g. Beispielscript gearbeitet. Hier mal ein paar meiner "Erkenntnisse": Alles ohne den Anspruch auf "Best Practice" sondern mehr als Diskussion.

    Die "BLU Dinger" ;) haben kein WLAN. Sie sind bei einem (oder mehreren) Gateway(s) registriert. Auf jedem Gateway (z.B. PlusI4 oder Plus1PM...) muss dann der Scanner aktiviert und ein Script ausgeführt werden, dass die gescannten Werte interpretiert.

    Das Beispielscript scannt und löst eine Action aus. Was m.E. OK ist, wenn man 1 oder 2 BLU Devices hat. Werden es mehr (BLU Door/Window, - Motion...), wird auch das Script seeehr umfangreich, da alle Actions darin programmiert werden. Irgentwann wurde das Script bei mir zu groß und lief auf dem Gateway schlicht nicht mehr. X(

    Ich hab dann den BLE Scanner ausgelagert. Dieser löst nun Events aus, die die entsprechenden Datenpaket der Devices enthalten.

    Andere Scripte reagieren auf die Events. Macht die Sache zwar schlanker, allerdings sind aber auch nur 3 aktive Scripte pro Gateway erlaubt. Damit komme ich nun zum Thema "zweites Gateway". Klar kann man, wie oben beschrieben, den Scanner auf dem 2. Gateway installieren (OPT1)... ODER man belässt es bei dem einen und nutzt das KVS um Events an den anderen Shelly zu übertragen (OPT2)

    Um OPT1 kommt man sicher nicht herum, wenn die BLE Reichweite nicht ausreicht. Aber OPT2 macht die Sache wieder schlanker, da auf dem zweiten Gateway dann "nur" ein Script laufen muss, dass die KVS Werte interpretiert.

    Hier noch mal in Kurz:

    1 Gateway mit BLE Scanner, scannt ALLE BLU Device, löst lokal Events aus und schreibt diese bei Bedarf auch in das KVS anderer Shellys. Andere Shellys können so auch die BLU Daten interpretieren.

    Bin auf Feedback gespannt, vielleicht haben andere ja bessere Lösungen!

    Hallo,

    wäre es hilfreich, wenn die Shelly Community fehlerhafte Dokumentation geordnet sammelt? Ich finde schon! :saint:

    Nur wo? Ich konnte keinen Thread dafür finden. Und jedesmal eine Supportmeldung... ?

    Vielleicht macht sich ja einer von den Admins mal Gedanken (falls nicht sowieso schon geschehen). Ich fange hier jedenfalls einfach mal an:

    Das Beispiel zum GetMany Request ist m.E. falsch.

    https://shelly-api-docs.shelly.cloud/gen2/Component…getmany-example

    Ich denke es sollte nicht

    Code
    http://192.168.33.1/rpc/KVS.GetMany?key="item"

    sondern

    Code
    http://192.168.33.1/rpc/KVS.GetMany?match="item*"

    heißen.

    Achtung Falle bei Android Devices!

    Klar, feste IP Adresse vergeben ist eine gute Idee! Wenn aber, wie bei mir, die feste IP an eine MAC Adresse gekoppelt ist und sich die MAC Adresse des Smartphones im WLAN jedesmal ändert, ist das weniger vorteilhaft für diese Anwesenheitserkennung. :cursing:

    Android hat ein Feature zur zufälligen Vergabe von MAC Adressen im WLAN. Es dient der Sicherheit und ist unter den Einstellungen für das jeweilige WLAN zu finden. Damit das Skript also funktioniert muss diese Funktion also deaktiviert werden.