Beiträge von eiche

"klingel_trigger" muss afaik ein HTTP Endpoint sein.

Elbling
Statt eines HTTP Endpoint gelingt es einfacher via

http://192.168.178.77/rpc/script.eval?id=2&code=klingel_trigger()

Hierzu müssen das Skript mit der id=2 laufen und klingel_trigger() die auszuführende Funktion sein. Dafür braucht man nicht den Overhead eines HTTP Endpoints, d.h. das Skript kann einfacher gehalten werden. In einer Action auf demselben Gerät ist die localhost Adresse (127.0.0.1) zu verwenden.

Mit "... gelingt es einfacher ..." meine ich das Skript, nicht den Aufruf bzw. den URL.

Zitat von DIYROLLY

https://hus.plus/produkt/flower%E2%80%A6or-im-3er-pack/

Ich habe mal bzgl. Kommunikationsstandard nachgefragt (MQTT, HTTP, ...).

Antwort:

"... Intern läuft die Kommunikation über MQTT, wir haben aber derzeit keine öffentliche Schnittstelle. Geplant ist eine REST API. ..."

Ich weiß nicht, warum die MQTT Kommunikation "intern" läuft - werde nachfragen. Vermutlich sind diese Geräte noch nicht konfigurierbar. Jedenfalls sind sie so für mich noch uninteressant.

Zitat von tvbshelly

Leider gab es dort keine abschließende Rückmeldung.

Deshalb sehe ich da noch immer Unklarheiten. Wer weiß hier, was via WiFi.SetConfig mit welchen Wirkungen (de)aktivierbar ist?

Dazu wären die Kommerziellen gefragt. Ob diese aber für so etwas überhaupt Interesse haben ... bezweifle ich.

Mir fehlt dafür die Ausstattung.

kws30 Wenn du nichts Konstruktives dazu mitzuteilen hast, wäre es rauschärmer, deinen Kommentar via PN unterzubringen.

Andreas101

Bevor du dich von den vielen Vorschlägen erschlagen fühlst, habe ich noch Fragen zu deiner Topologie und deren Handhabung.

1. Wieviele Messstellen nutzt du oder willst du nutzen?
2. Besuchst du diese Messstellen regelmäßig? Wenn ja, in welchen Abständen?
3. Wie weit liegen alle deine Lokationen auseinander?

Evtl. könnten LoRa AddOns hier weiterhelfen.

Alternativ kenne ich eine preisgünstige Möglichkeit, Messdaten im Shelly persistent zu speichern und in gewissen Abständen via Smartphone und MQTT zu übertragen. Dies ergibt aber keine ständige Verfügbarkeit der Kommunikation zwischen deinem zu Hause und den Messstationen.

Banananas Versuch einer Klarstellung

1. Es ist völlig unklar, ob und wie WLAN im Shelly abschaltbar ist. Vermutlich ist das nicht möglich und man kann allenfalls via RPC und/oder Skript einen SSID Eintrag deaktivieren bzw. eintragen und zugleich aktivieren. Die API Dokumentation bietet folgende Informationen.
   1. https://shelly-api-docs.shelly.cloud/gen2/Component…i#configuration zur Struktur
   2. https://shelly-api-docs.shelly.cloud/gen2/Component…tconfig-example ein Beispiel
2. Das Skript ist zunächst ausschließlich dazu gedacht, nach einem Stromausfall den gewünschten WLAN Access Point (wieder) zu erreichen, falls er zuvor (via Scheduler) deaktiviert wurde. Hierzu dürften SSID und Passwort erforderlich sein. Solange nach einer irgendwie gestalteten Deaktivierung - vermutlich nur des SSID Eintrags - keine Stromversorgung ausfällt, und somit der Shelly interne Zeitstempel aktuell ist, kann der Schedule Job zur Aktivierung des SSID Eintrags seine Wirkung erfüllen. Mit Stromausfall übernimmt mit dem Booten dies das Skript - auch dann, wenn die Aktivierungszeit noch nicht eintrat. Wenn letzteres vermieden werden soll, ist ein komplexeres Skript erforderlich. So oder so sollte danach das Shelly seine Zeit wieder via Zeitserver synchronisieren können.

Fazit: Es ist sehr fraglich, ob all dies zu dem führt, was du erreichen willst - weniger Funkwellen?, weniger Energieverbrauch?.

Um zu erfassen, ob dein Ziel überhaupt erreichbar ist, braucht es erheblich mehr Kenntnisse über Interna sowohl der Hardware als auch des Betriebssystems (Firmware). Jemand mit gut ausgestatteter Funk-Messtechnik könnte hier vielleicht Detektiv spielen.

Wenn du damit experimentieren willst, empfehle ich

1. mindestens ein zusätzliches Experimentier-Shelly zu nutzen und
2. parallel irgendwie die Stromaufnahme des Experimentier-Shelly zu erfassen/aufzuzeichnen.

Alles in allem vermute ich, dass du einen solchen Aufwand nicht treiben möchtest. Dann lautet meine Empfehlung: Lasse dieses Vorhaben sein, es beinhaltet zu viele Unwägbarkeiten! Bedenke, dass die Funktion des Shelly auf funktionierendes WLAN angewiesen ist!

Andreas101

Ich weiß nicht, was daran so kompliziert ist. thgoebel hat bereits in #4 darauf hingewiesen, was fehlt.

In deinem bisherigen Ausdruck 80 * 3,1 - 148 fehlt zumindest das x, bspw. 80 * x - 148, was bei x = 3,1 den Wert 100 ergibt. Dein Ausdruck ist schlicht eine Konstante mit dem Wert 100. Deshalb erhältst du auch nie etwas anderes.

Ergänzend zur Darstellung von horkatz :

Angenommen, bei 4mA durch 500Ohm soll 0% herauskommen und bei 3.1V (deine Vorgabe) 100%.

Die lineare Formel (Approximation): a * x + b, x ist der Original Messwert des Shelly ohne Anpassung

1. x1 = 3,1V -> 100% (deine Vorgabe)
2. x2 = 0,004A*500Ohm = 2V -> 0% (angenommen)

a * 3,1 + b = 100

a * 2 + b = 0

=> a * (3,1 - 2) = 100 <=> a = 100 / 1,1 ca. 90,91

90,91 * 2 + b = 0 <=> b = -90,91 / 2 = -45,455

90,91 * 2 + b = 0 <=> b = -90,91 * 2 = -181,82

Ein dich weiterbringender Ausdruck kann somit lauten 90,91*x-45.455 evtl. mit gerundeten Konstanten. Quatsch, ich korrigiere:

Ein dich weiterbringender Ausdruck kann somit lauten 90,91*x-181.82 evtl. mit gerundeten Konstanten.

Merkwürdig, dass mich hier noch niemand verbessert hat, was leider häufig vorkommt.

Elbling

Genereller Hinweis:

Wenn etwas via App nicht gelingt, ist das WebUI eine Alternative. Ich halte das WebUI IMMER für den besseren Zugang.

Also http://<IP Adresse des Action Shelly>

twlbln

Du kannst auch mal meine Implementation zu Gen 3 ausprobieren. Anleitung dazu ist enthalten.

Zusätzlich ist es auch in deinem Skript nützlich, die erhaltenen Werte von sensors[TEMP_SENSOR_KEY][0] via print ausgeben zu lassen, um zu sehen, was wann ankommt.

print(JSON.stringify(sensors[TEMP_SENSOR_KEY][0]));

Banananas

In #7 beschreibe ich einen kompletten Test. Dieser ist evtl. nicht ganz geeignet. Mir stellt sich die Frage, was genau ein disablen von WiFi bewirkt. Ich kenne keine geeignete Beschreibung dazu. Demzufolge ist der Erfolg des Skripts fraglich. Vermutlich müssen zu enablen auch die Parameter "ssid" und "pass" genutzt werden.

Der folgende ungetestete Aufruf sollte eine manuelle WLAN Freigabe ersetzen. Nachteil: SSID und Passwort sind im Skript lesbar.

Shelly.call("WiFi.SetConfig", {"config":{"sta":{"ssid":"<Dein SSID>","pass":"<Dein SSID Passwort>","enable":true}}},
  function(result, errc, errm) {
    if(errc) {console.log(errc, errm); return;}
    print(JSON.stringify(result));    
  }
);

Ich ersetze den Skripttext nun auch noch in #7.

Zitat von Banananas

Wir haben ein WLAN Gerät, welches wir per Shelly ebenfalls nachts ausschalten wollen. Das Gerät selbst erlaubt keine Zeitpläne, deswegen die Idee, ob Shelly es per Zeitplan steuern kann. Shelly selbst soll nachts dann aber auch das WLAN deaktivieren, sonst könnte das Gerät auch einfach selbst die Nacht durchfunken.

Offensichtlich will der TE WLAN des Shelly deaktivieren. Ich fragte nicht nach dem Zweck sondern suchte nach einer Möglichkeit und evtl. Stolperfallen.

Somit muss zunächst geklärt werden, ob und wie eine WLAN Aktivierung überhaupt gelingen kann. Genau dazu habe ich einen Weg zum testen aufgezeigt, mehr nicht.

Das ist eine nicht konstruktive Frage. Ich gehe trotzdem darauf ein.

Der Bootvorgang geschieht in diesem Projekt ausschließlich nach einem Stromausfall.

Wenn du etwas von den Shelly verstehen solltest, dann solltest du auch wissen, dass sich kein Shelly herunterfahren kann, nur rebooten. Also ist deine Frage ohne Substanz.

Und noch etwas. Ein laufender Shelly kann durchaus via Schedule Job rebootet werden.

Ich habe folgendes Skript mal eben auf einem Shelly Plus Uni getestet, aber ohne zuvor das WLAN zu deaktivieren. Letzteren Test überlasse ich dir.

Es ist stark zu vermuten, dass dein Shelly Plug S Gen 3 sich ebenso verhalten wird.

// nachträglich geändert und so nicht getestet - siehe Hinweis in #12
Shelly.call("WiFi.SetConfig", {"config":{"sta":{"ssid":"<Dein SSID>","pass":"<Dein SSID Passwort>","enable":true}}},
  function(result, errc, errm) {
    if(errc) {console.log(errc, errm); return;}
    print(JSON.stringify(result));    
  }
);

Die Antwort im Console Fenster ist

{"restart_required":false}

Dies zeigt, dass die Methode irgendwie ohne Fehler abgearbeitet wurde.

Für den kompletten Test ist

1. zum Skript "Run on startup" einzuschalten - via WebUI,
2. das WLAN zu deaktivieren - Settings -> WiFi 2 settings aus und speichern (Save settings), WiFi 1 settings aus und speichern,
3. zu prüfen, ob das betreffende Shelly nicht mehr per WLAN erreichbar ist - ohne dies ist der Test sinnfrei,
4. dem Shelly die Stromversorgung zu nehmen,
5. den Shelly wieder mit Strom zu versorgen.

Danach ca. 1 Minute warten und nachschauen, ob der Shelly im WLAN erreichbar ist.

Wenn dies letztlich nicht gelingt, womit gerechnet werden muss, kann ein "Factory reset" erforderlich sein.

Vielleicht ist in einem solchen Fall noch der Shelly Access Point nutzbar, um WiFi wieder einschalten zu können. Irgendwie erscheint es mir aber merkwürdig, an einem auf WLAN angewiesenen Gerät, die WLAN Funktionalität ausschalten zu können. Schließlich braucht auch der AP Modus diese Funktionalität.

Falls es überhaupt gelingt, die lokale WLAN Funktionalität automatisiert zu aktivieren, bspw. via Schedule Job, dann lässt sich dies auch mit einer Zeile in einem Skript erreichen, welches automatisch nach dem Booten abgearbeitet wird.

Shelly.call(<Methodenname>, <Parameterobjekt>);

In deinem Fall könnte dies gelingen mit (ungetestet)

Shelly.call("WiFi.SetConfig", {"config":{"sta":{"enable":true}}});

oder ähnlich.

Banananas Die Shelly haben ja keine bei Stromausfall weiterlaufende Uhr, wie es PC haben.

Nein, es gibt kein Standarddatum. Solange das Shelly keine Zeitsynchronisation via Zeitserver (oder vermutlich den Anwender im WebUI) erhält, wird sein UNIX Timestamp durch die Uptime gebildet, also die Anzahl an Sekunden seit dem letzten Bootvorgang. Darin steckt selbstverständlich kein Datum, weshalb der Scheduler nicht wie gewünscht arbeiten kann.

Etwas anders ist es, wenn der "timespec" Wert bspw. "0 * * * * *" enthält, also jede volle Minute etwas ausführen lässt. Dies funktioniert nach meiner bisherigen Erfahrung, aber nicht sekundengenau, solange keine Synchronisation erfolgte. Eine Uhrzeit hingegen kann der Scheduler ohne Synchronisation nicht verarbeiten.

Damit dein Wunsch erfüllbar sein kann - ob es überhaupt gelingt, ist damit noch nicht gesagt - muss das Shelly nach einem Bootvorgang seine intern laufende (nicht gestellte) Uhr synchronisieren können, wozu (W)LAN erforderlich ist, solange du nicht jedesmal selbst die Uhrzeit via Web Browser einstellen willst. Eine Synchronisation genügt dafür. Diese braucht weniger als eine Minute.

Die API Dokumentation zeigt folgenden beispielhaften URL.

http://192.168.33.1/rpc/WiFi.SetConfig?config={"sta":{"ssid":"Shelly","pass":"Shelly","enable":true}}
// Besser für folgendes geeignet:
curl -X POST -d '{"id":1,"method":"WiFi.SetConfig","params":{"config":{"sta":{"ssid":"Shelly","pass":"Shelly","enable":true}}}}' http://${SHELLY}/rpc

Dies ist insofern widersprüchlich, als die AP Funktion des Shelly für die genutzte IP Adresse ja bereits aktiv sein muss. Das Beispiel kann somit allenfalls zur Änderung des Passworts genutzt werden. Ein ssid Wert "Shelly" erscheint mir auch merkwürdig, weil es nach meiner Erfahrung nicht möglich ist, auf einem Shelly dessen AP SSID zu ändern. Sorry meine Falschaussage, sta bezieht sich auf externe Access Points.

Interessant - mittlerweile ist es doch möglich SSID auf Shelly zu ändern. Damit könnte dein Ziel erreichbar sein. Ich täte selbst experimentieren, ergänzend zur erhaltenen Aussage seitens Shelly.

Edit:

Um in einem Schedule Job einen lokalen RPC Aufruf zu nutzen, ist vermutlich kein URL geeignet - ich weiß nicht, ob "localhost" oder "127.0.0.1" ohne aktiviertes WiFi nutzbar ist. Hier wäre eine JSON Notation zu testen, etwa folgende (ungetestet).

{"method":"WiFi.SetConfig","params":{"config":{"sta":{"enable":true}}}}

Wie gesagt, ob dies erfolgreich nutzbar ist, weiß ich nicht. Ich zeige hiermit einen Weg zum testen auf.

Bisher sind KI relativ unfähig, was Shelly Skripte betrifft. Eine API Funktion Shelly.addJob() existiert nach der Dokumentation nicht.

Via URL kann man aber weit über die vorgesehene Konfiguration hinausreichende Funktionalitäten via Schedule Jobs (Zeitpläne) implementieren. Weil eine Zusammenstellung solcher URL relativ komplex und leicht fehlerträchtig ist, habe ich für solche Zwecke eine kleine Website zusammengestellt:
http://tools.eichelsdoerfer.net

Damit und mit der API Dokumentation zur WiFi Component kannst du selbst experimentieren.

Diese Jobs funktionieren nach meiner Erfahrung dann, wenn das Shelly einen Timestamp mit Datum hat, was ohne WiFi Verbindung (und ohne Ethernet) nach einem Reboot nicht der Fall ist. Wenn sich zwischenzeitlich kein Stromausfall ereignet, sind die Zeitpläne (=Schedule Jobs) aber funktionstüchtig.

In der Konsequenz ergibt sich daraus folgendes kleines Problem. Auch falls das Einschalten der WiFi Funktion auf einem Shelly gelingen sollte, wird es dies nicht bei sich nach einem Stromausfall tun können.

Nur zum verstehen nachgefragt.

1. Du suchst eine Möglichkeit, die Nähe von Smartphones mit verschiedenen Shelly zu erfassen?
2. Soll dies auch für andere Geräte außer Smartphones gelten?
3. Wenn ein Smartphone irgendwo liegt, statt von einer Person mitgeführt zu werden, ist das dann noch wirksam in deinem Sinne?
4. Dazu möchtest du Messwerte wie RSSI und MAC Adressen erfassen?

Meine Hinweise:
Wenn das deine Ziele sind, dann ist das sehr anspruchsvoll und ich bin gespannt, ob hierzu jemand eine annähernde Teillösung anbieten kann. Mit Shelly BLE wären passende Empfänge möglich, aber ohne irgendeinen Feldstärke Indikator - afaik. Ob und wie ein Shelly ein Smartphone Bluetooth Signal erfassen könnte, weiß ich nicht.

Ich habe mal ein Skript für so etwas erstellt. Der folgende Ausschnitt enthält alles dafür Grundlegende und noch ein paar Funktionen zum schalten, die auch entfernt werden können. Entscheidend für die Funktionalität ist, dass die geprüften Geräte (Smartphones) immer dieselbe IP-Adresse erhalten.

Mit BLE hat das alles nichts zu tun. Ein damaliger Wunsch war, diese Erkennung via Zeitplänen zu aktivieren - und vermutlich auch zu deaktivieren (ist schon länger her). Abhängig von der angestrebten Kommunikation wäre das Skript anzupassen.

Mit Standardmethoden ist so etwas nicht vorgesehen, weshalb es nur via Skript implementierbar ist.

//GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007
//More information: https://www.gnu.org/licenses/gpl-3.0.txt
//ABSOLUTELY NO WARRANTY!
//created by eiche, 2024-06-13, V 0.1

// begin of configuration
let Devices = ["172.16.4.136", "172.16.4.135"]; // IP addresses of all significant devices
let Response = "-1: Connection error: -14";
let Period = 2 * 60 * 1000; // two minutes
let DevPeriod = 5 * 1000; // check device all five seconds
let TimeOut = 2; // HTTP Get timeout = two seconds
let OutId = 0;
let debug = true;
// end of configuration

let Index = null;
let Present = null; // If true, one device at least is present.
let busy = false;
let Th = null; // timer handle

function ping() {
  if(!busy && !Present && Index != null && Index < Devices.length && Index >= 0) {
    let IPaddr = Devices[Index];
    if(debug) print("ping " + IPaddr);
    busy = true;
    Shelly.call("HTTP.Get", {url:IPaddr, timeout:TimeOut},
      function(res, errc, errm) {
        //if(errc) print(errc, errm) else print(res);
        if(errm === Response) { // found
          Timer.clear(Th);
          Th = null;
          Present = true;
          if(debug) print("Device " + IPaddr + " is present.");
        }
        busy = false;
        --Index;
      }
    );
  }
}

function checkDevices() {
  // for(let i=Devices.length-1; i>=0 && !Present; --i) ping(Devices[i]); // not robust enough
  if(!Present) {
    Index = Devices.length - 1;
    let Thl = Timer.set(DevPeriod, true,
      function() {
        ping();
        if(debug && Index < 0 && !Present) print("No device found.");
        if(Index < 0 || Present) Timer.clear(Thl);
      }
    );
  }
}

function doSwitch(state) {
  Shelly.call("Switch.Set", {id:OutId, on:state});
}

// three functions, called by three schedule jobs

function start() { // called by schedule job to start device checking
  Present = false;
  Timer.clear(Th);
  checkDevices();
  Th = Timer.set(Period, true, checkDevices);
}

function trigger() { // called by schedule job to turn on
  if(!Present) doSwitch(true);
}

function off() { // called by schedule job to turn off
  doSwitch(false);
}

start();

Nur mal als funktionierendes Beispiel, auch weil du Date erwähntest, ein Codeschnipsel dazu:

function d2(d) {
  d = JSON.stringify(d);
  return d.length<2 ? '0' + d : d;
}

function getTime(t) {
  if(t===null) return;
  let d;
  if(t===undefined) d = new Date();
  else d = new Date(t);
  return d.getFullYear()+'-'+d2(JSON.parse(d.getMonth()) + 1)+'-'+d2(d.getDate())
    +' '+d2(d.getHours())+':'+d2(d.getMinutes())+':'+d2(d.getSeconds());
}

Ich kann dir nur meine Handhabung und Erfahrung mitteilen.

Ich nutze für Kurzrecherche zu Javascript die Website https://www.w3schools.com/. Die dortigen Beispiele können zum experimentieren genutzt werden, allerdings ist der dortige Fokus auf in HTML Code eingebetteten Javascript Code gerichtet. Oftmals stehen Funktionen/Methoden, die dort dokumentiert sind, in ShellyScript nicht zur Verfügung.

Besonders wichtig ist die Dokumentation der Shelly API und darin https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…anguageFeatures.

Diese sind mit Components and Servicesund den RPC Methoden zu kombinieren.

Dein Link zu Espruino habe ich bisher nicht oder sehr selten genutzt, er ist anscheinend sehr nützlich.

Der Rest ist experimentieren und die Suche nach eigenen Fehlern im Code.

Ich kann dir noch anbieten, hier oder via PN (oben rechts "Konversationen") mit mir zu kommunizieren, damit ich meine Erfahrungen mit dir teilen kann.