Beiträge von akreienbring

Hallo,

bin mir nicht ganz sicher, ob dir das hilft. Also einfach als Hinweis:

Daten versenden, geht grundsätzlich mit HTTP.POST

Der empfangende Endpoint muss die Daten dann natürlich verarbeiten. Hier die Dokumentation

https://www.afriso.com/de/PM/Haustech…e-Gateway-HG-02

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)

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:

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

Remote per RPC:

   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.

AH... OKAY! Danke für den Tip. Werde das mal ausprobieren!

Hallo,

Zitat von eiche

Ein EventHandler kann leicht verschiedene Events unterscheiden. Dazu braucht es nicht mehrere Skripte.

Damit wollte ich nur sagen, dass der Platz dennoch knapp werden kann und hab geschmeidig zum KVS auf weiteren Shellys übergeleitet. In meinem Fall überprüfen die Skripte auf dem zweiten Shelly ständig das KVS um auf gesetzte Werte zu reagieren.

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.

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!

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

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

sondern

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.

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.

WOW! Vielen Dank für das Script

Hier ein kleiner Hinweis: Ich glaube diese Zeilen in der ping() Funktion sind überflüssig.

// set user to present in users_online_array
users_online_array[i] = true;

Hallo,

wahrscheinlich ist das ein Feature Request. Zumindest habe ich nichts gefunden, was darauf hindeutet, dass es schon möglich ist.

Ich hätte gerne die Möglichkeit Custom Widgets auf meinem Dashboard in der App zu plazieren. Dort sollen (beliebige) Informationen angezeigt werden, sie sich aus dem Smarthome System gewinnen lassen.

Das ist bewußt sehr allgemein formuliert. Aber ein Anfang wären z.B. KVS Werte von einem Shelly, die dann im Idealfall noch visuell formatiert werden können. Bsp: ein KVS Wert von 1 wird als "XY ist aktiv" angezeigt.

Es würde also ein KVS Wert per RPC Call von einem Gen2 Shelly abgerufen werden und im Widget visualisiert.

Damit handelt es sich NICHT um Geräte und deren Status sondern letztlich um meine private Logik im SmartHome.

Ich bin auf Feedback gespannt

Zitat

Im Moment bin ich noch geflashed von all den Möglichkeiten

Ich bin ja auch noch relativ neu in dem Thema und fand es von Anfang an gut, dass ich mit Shelly viele Möglichkeiten habe meine Ziele zu erreichen:

Szenen, Actions
Quasi No-Code Automatisierung. Ich stöpsel mir verschiedene Komponenten zusammen und habe ein (halbwegs) smartes Home. Als HUB zwischen verschiedenen Systemen kann z.B. mit Alexa gearbeitet werden. Szenen sind allerdings abhängig von der Cloud.

Scripte

Eingeschränkt in Sachen Speicher und im Zweifel irgendwann absolut unübersichtlich. ABER: höchst individuell und funtioniert auch ohne Cloud.

Übergeordnet (OpenHAB, Homeassistant, IOBroker u.a.)

Ohne Cloud aber dafür mit riesen Communities zum eigenen SmartHome. Möglicherweise auch mit übergreifenden Standards und Protokollen (ZWave, ZigBee, Matter...) Aber definitiv eher was für Profis, was die Installation, den Betrieb und die Anwendung betrifft.

Hallo, gibt es hier was Neues? Ich hab zwei Buttons. Beide eingebunden, und die "shelly-blue" Events werden mit Hilfe des Demo Scripts auch brav empfangen.

Aber der Beacon Mode oder auch alle Versuche mit BLE Debug ein Pairing herzustellen, schlagen nun fehl. Ich drücke den Knopf die 10 verlangten Sekunden, nur damit danach das Ganze wieder von vorne anfängt. Soll heißen: Ich kriege das Pairing mit den Buttons nicht mehr hin. Übrigens klappt das auch nicht über die Shelly-Cloud App.

Nur den, hier angegebenen, Hard-Reset hab ich noch nicht probiert. Wollte erstmal hören, ob evtl. ein allgemeines Problem vorliegt.

Good Morning!

Yes, that's what I did before I found the described solution. BUT:

1. Alexa notifications from Shelly scenes are limited to 3 (with basic plan)
2. Scenes can't handle dynamic information. They are preset and can't include dynamic information like e.g. a date or any other dynamic value. I wanted Shelly to speak whenever my script has some information for me. And a scene for every possible sentence is just...
3. The "Alexa Says" action in the routine won't let you give Shelly her personal voice

WTF! Affiliate Links? I just inserted the Link to the Amazon Skills in question! Don't earn anything from this!!!

... with the help of Amazon Alexa.

If you hate cloud based stuff, then stop reading

Challenge: I wanted to trigger (unlimited) Alexa routines from a Shelly Script. And especially I wanted Alexa (Shelly) to give spoken feedback.

The solution I found is based on triggering Alex routines with a single HTTPS call. Somehow like described in this existing forum thread.

The steps in short are:

1. Install the 'TextVorlesen' Skill and let Alexa speak anything.

- Go to https://esp8266-server.de/alexa/TextVorlesen/ to find out how to make Alexa speak your text. This includes installing the 'TextVorlesen' Skill.

- Log on to Amazon on that site to get your personal API access HTTPS call. Now you're able to send any text to Alexa with that call.

2. Automate the process of speaking your text

- Normally you have to say "Alexa, Text vorlesen" to have your text spoken, but this can be automated by a second skill: Webhook Routine Trigger Skill

- For this you first need to create triggers on this site: https://trigger.esp8266-server.de/

- Every created trigger shows up under your Alexa Smarthome devices after searching for new ones (just like the limited Shelly Alexa notifications). These "virtual devices" can be "activated / pressed" by the trigger URL.

- finally create a Alexa routine that is triggered by your new device and ultimately calls the "Text Vorlesen Skill".

3. Use your trigger(s) in Shelly script to make Alexa / Shelly say something

- Just like any normal HTTPS Call. Here's an example:

Shelly.call('HTTP.GET',
  {url: 'https://trigger.esp8266-server.de/api/?id=4498&hash=[your-personal-hash]'}
);

Sounds complicated? Only on the first sight.

Hint: Give your Shelly a personal sound by choosing an available voice in your language and using SSML commands

Hallo, nette Diskussion

Aber vielleicht kann mir jemand sagen, ob diese Art der Berechnung richtig ist. Es handelt sich ebenfalls um einen 1PM.

nCurrentMW = event.delta.aenergy.by_minute[0];
nCurrentW = nCurrentMW / 1000;
nCurrentKW = nCurrentW / 1000;

console.log('Current consumption ' + nCurrentMW + ' mw/m, ' + nCurrentW * 60 + ' w/h, ' + nCurrentKW * 60 + ' kw/h');

Beispiel Output:

Current consumption 225.842 mw/m, 13.55052 w/h, 0.01355052 kw/h

Sieht jetzt für mich, anhand der angegebenen Verbrauchswerte des Geräts, erstmal richtig aus. Aber ich frage hier lieber mal nach...

Zitat

"damit kommt der Shelly net zu recht"

Seltsam aber OK! However

Bestpractice also bis hierhin:

Nachdem ich jetzt beim inneren asynchronen Aufruf, entweder

- keine Funktion

      Shelly.call("HTTP.GET",
        { url: "someOtherShellyURL"},
        null,  /function
        null  //userdata
      );

oder

- eine benannte Funktion

      Shelly.call("HTTP.GET",
        { url: "someOtherShellyURL"},
        someCallbackFunction
        null  //userdata
      );

angegeben habe, kommt es nicht mehr zum spontanen Stop des Scripts. Danke!

DONE! Mal abwarten. Kann gerade nicht viel berichten. Die neue(?) Diagnostics Seite zeigt mir "out-of-memory" Probleme an.