Beiträge von Seven of Nine

Der Aufruf vom Shelly.Call ist asynchron, das Script arbeitet weiter bevor die Änderungen übrhaupt im Hauptteil vom Script ankommen.

Wie sich das umgehen lässt hab ich z.B. hier beschrieben:

Beitrag

RE: test and usage of KVS

Shelly.Call is asynchron, so the print at the end is executed before the kvsGet() has finished.

you can validate this by adding a delay (Timer).

(Quelltext, 32 Zeilen)

Seven of Nine

26. August 2022 um 19:00

ist kein Mesh, funktioniert technisch wie eine Router-Kaskade mit Portforwarding.

die Scripts zu einem zusammenfassen wäre eine Möglichkeit.

Zitat von AlexAn

Kann die Plus/Pro Serie https Befehlserkennung?

Ja, das geht problemlos..

ist der Dimmer denn schon kalibriert worden?

na Guck, doch viel einfacher als gedacht... deshalb hab ich gefragt was du genau erreichen willst

HTTPServer.registerEndpoint('testserver', function (req, res) {

    // check request and comapare the querystring
    if (req.query === 'powerusage=1') {
        // response with some text
        res.body = 'Shelly Webserver: you requested power usage';
        res.code = 200;
        res.send();

    } else {
        res.body = 'Shelly Webserver';
        res.code = 200;
        res.send();
    }


})

Aufruf dann z.B. über

http://192.168.178.84/script/1/testserver?powerusage=1

Zitat von PatrickR

Hinweis: Der Switch über Taster auf ON gesetzt startet einen Timer für's Ausschalten, und der URL action soll diesen Timer u.a. löschen

Ich bin nicht ganz sicher, ob ich das richtig verstehe..

- der lokal am Shelly angeschlossene Taster startet einen Timer und schaltet das Relais für Zeit X an, dann wieder aus?

- der Aufruf von extern (I3 über HTTP) soll diesen Timer löschen? also relais soll dauerhaft anbleiben?

Was soll passieren, wenn der Shelly über die App / Sprache etc geschalten wird?

mit einem HTTP-Server Handler kannst du auf jeden Fall unterscheiden, woher der Aufruf kommt aber ich würde gern die genaue Problemstellung kennen

https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…ures#httpserver

Zitat von karloslb

Laut Hersteller: Der Datenaustausch erfolgt über das UDP-Protokoll (mit Broadcast-Unterstützung).

akuell kann ein Shelly Plus kein UDP-Paket schicken, damit dürfte das nicht klappen.

Zitat von karloslb

Ich bekomme die Meldung "undefined",

liegt daran, dass Wifi.Scan ein Array an Daten zurückgibt und ein result.rssi deshalb nicht existiert.

Shelly.call(
    "WiFi.Scan",
    {},
    function (result, error_code, error_message) {
        print(JSON.stringify(result));
    }
);

hiermit siehst du was ich meine.

Mach ein Update auf die 0.12Beta2, da kannst du das ganz einfach direkt im Webinterface bei den Actions einstellen.

Wenn der Taster außerhalb der Zeit nichts tun soll muss er auf Detached stehen:

etwas andere Form, aber der Plus 1 PM ist insgesamt kleiner, vor allem aber flacher ..

Zitat von Doggie

Würdet ihr heute den Plus nehmen oder noch den alten Gen1?

ganz sicher die neuen Gen2 Geräte, weil sie viel mehr können (MQTTs, Websockets, webhooks mit HTTPS, Scripting.. ) ..Außerdem haben sie einen ESP32 verbaut und können in irgendwann in Zukunft auf den Smarthome-Standard "Matter" umgerüstet werden. (dazu sind die alten ESP8266 in den alten Shelly Gen1 nicht in der Lage).

Zitat von vShellEu

shellies/shellyplug-s-xxxxxxxx/relay/0

das Topic ist richtig, da bist du sicher?

Schau mal in der Forensuche, ich hab hier reihenweise Beispiele für Mosquitto gepostet.. m.E. fehlen auch Username und Passwort oder betreibst du MQTT komplett offen und ungesichert?

Zitat von Schubbie

Damit kenne ich mich nicht aus.

Dann wäre es eventuell sinnvoll einfach mal gar nicht zu antworten

Zum thema: ist schwierig zu sagen, woher die 4 Aufrufe kommen.. aktuelle Firmware ist drauf? wenn nicht erstmal updaten

wenn das dann immer noch nicht hilft: Update auf 0.12Beta1 machen und prüfen, ob der Fehler weg ist.. falls er noch vorhanden ist im Debug nachschauen, ob da entsprechende Ereignisse protokolliert werden und dann bitte hier posten. In den fall würde mich aber auch ein etwaiges Anschlußschema interessieren.

da kommt ein Timeout (siehe auf dem Screenshot direkt oberhalb der blauen Einträge)..

Was passiert denn, wenn du die URLim Browser aufrufst? kommt da irgendeine Antwort.

Zitat von DIYROLLY

Ich habe mit einzelnen Geräten bemerkt, war von Vorteil mit getrennter SSID.

macht eigentlich nur bei "veralteter" Technik Sinn, die kein BandSteering beherrscht. Intelligente AccessPoints schubsen ihre Clients automatisch von 2,4 nach 5Ghz, wenn es in Reichweite ist.

ob das mit dem 2.5er so machbar ist lässt sich ohne Anschlußplan des Motors sehr schwer sagen. Kannst du den ggf beim Fensterbauer anfragen?

Zitat von Thomas1122

Aber nun zum eigentlichen Problem , obwohl meine Fritzbox 6690 Kabel am nächsten ist verbinden sich die Shellys nur über den auch verbauten Repeater 2,4GHz von Fritz.

je nach Firmware-Version vernbinden sich Shellies mit dem ersten WLAN, welches vom Shelly gefunden wird und das kann durchaus beim Wifi.Scan der Repeater sein.

Mit der aktuellen Firmware 1.12.1 sollte das eigentlich behoben sein und spätestens nach Neustart der Wifi-AP mit dem besten Empfang ausgewählt werden.

I haven't tested GET Request via Javascript for quite a long time but allowing CORS is IMHO a dirty workaround. Whenever you built a solution the browser is restricting access more and more.

If possible you should consider a server side solution with PHP, Python, or whatever you prefer as scripting language.

Example in PHP:

https://github.com/shelly-tools/shelly-php-proxy-examples

geht problemlos..allerdings mit der Einschränkung, dass das WLAN verfübar sein muss um die Deckenbeleuchtung zu schalten. Aber ich denke das wirst du bereits wissen...