Beiträge von towiat

Hmmm... könntest du die folgende abgespeckte Version mit deinen Settings einmal durchlaufen lassen und den Output aus der Console posten?

let CONFIG = {
  ip: "192.168.178.168", //Hue Bridge IP
  user: "Y0NXhTgbfcZYk0dSrTB70Va0XSZKFJdUYJcAj4bp", //Hue Bridge API user
  light: "4", // Hue Light ID
  input1: 0, // Shelly Button ID
  btnevent1: "single_push", //Shelly Button Event
};

Shelly.call(
  "http.request",
  {
    method: "GET",
    url: "https://" + CONFIG.ip + "/api/" + CONFIG.user + "/lights/" + CONFIG.light,
    ssl_ca: "*",
  },
  function (res, errc, errm) {
    if (errc !== 0) {
      console.log("Shelly error: " + errc + "/" + errm);
    } else if (res.code !== 200) {
      console.log("Server error " + res.code + "/" + res.message);
    } else {
      console.log(JSON.parse(res.body));
    }
  },
);

Shephard

Der gepostete Link kann nur mit einem Hue Developer Account geöffnet werden....

Zitat von Shephard

Was ich noch nicht ganz verstehe ist, wieso das Senden mit Tools wie Postman funktioniert, aber mit dem Shelly Script nicht.

Beitrag #7 beschreibt, wie das im Script (auch ohne Installation des Zertifikates) funktionieren sollte. Hast du das versucht und wenn ja, was war das Ergebnis?

Zitat von Shephard

Wie muss ich mein Script nun anpassen, damit es per HTTPS sendet und das Zertifikat nicht zu prüfen versucht?

Ich kann das bei mir nicht testen, aber laut Doku sollte sich die Zertifikatsprüfung mit einem zusätzlichen Parameter beim HTTP(s) request abschalten lassen:

Shelly.call("http.request", {
  method: "GET",
  url: "https://" + CONFIG.ip + "/api/" + CONFIG.user + "/lights/" + CONFIG.light,
  ssl_ca: "*" // <-- disable certificate validation
});

I'm not sure if I understand the desired functionality completely, but the following code should run without technical difficulties. This version will:

1. Turn the switch on
2. Wait 115 seconds
3. Check if the endpoint can be reached
   • if no: increase the failCount, wait 5 seconds and go back to step 3
   • if yes: increase the rebootCount, turn the switch off and immediately restart from step 1

Two notes:

• You define a CONFIG.rebootToggleTime, but it is never used
• The CONFIG.httpTimeout variable is not defined, so I added it with a value of 10

Let me know if this does what you need...

/*
SHELLY REBOOT STABILITY TEST SCRIPT
This script is intended to test the stability of the example units by
subjecting them to a long series of constant rebooting, checking to see HTTP
data returned successfully after each reboot. We are, obviously, striving for
a "failCount" of zero after a two-week period of testing.
*/
// Basic configuration of the Shelly Plug Plus US

let CONFIG = {
  // The endpoint of the unit to test against.
  endpoint: "http://192.168.1.5",
  // Time in seconds for the relay to be off
  rebootToggleTime: 30,
  // timeout
  httpTimeout: 10,
};

// The number of failures it has encountered
let failCount = 0;

// The number of reboots it has performed
let rebootCount = 0;

function httpGetAndReboot() {
  Shelly.call(
    "http.get",
    { url: CONFIG.endpoint, timeout: CONFIG.httpTimeout },
    function (response, error_code, error_message) {
      //http timeout, magic number, not yet documented
      if (error_code === -114 || error_code === -104) {
        print("Failed to fetch ", CONFIG.endpoint);
        failCount++;
        // call to endpoint failed; wait 5 seconds and try again
        Timer.set(5000, false, httpGetAndReboot);
      } else {
        rebootCount++;
        print("Number of Reboots: " + rebootCount);
        print("Number of Failures: " + failCount);
        print("");
        print("Resetting!");
        print("");
        Shelly.call("Switch.Set", { id: 0, on: false }, function () {
          // device powered off, initiate next test immediately
          Timer.set(0, false, startTest);
        });
      }
    },
  );
}

function startTest() {
  // power on
  Shelly.call("Switch.Set", { id: 0, on: true }, function () {
    // device is powered on - wait 115 seconds, then call httpGetAndReboot
    Timer.set(115000, false, httpGetAndReboot);
  });
}

startTest();

Zitat von Der_Dscho

Was muss ich ändern bzw. beachten, damit das Skript auch auf dem Shelly Plug S (Gen3) ausgeführt werden kann?

Soweit mir bekannt ist, stehen für Scripte grundsätzlich 25 KB an Hauptspeicher zur Verfügung. Auf manchen Geräten reduziert sich das aber auf ca. 8 KB, wenn Matter aktiviert ist. Wenn du also Matter aktiv hast und es nicht benötigst, könntest du durch die Deaktivierung eventuell genug Speicher frei bekommen...

Zitat von schreckus

was bringt mit der UDP log wenn keine Verbindung mehr besteht?

Gute Frage - ich habe einmal nur auf den geäußerten Wunsch reagiert. Natürlich könnte man das Script beliebig ausbauen - man könnte auf Statusänderungen reagieren und Nachrichten im KVS oder WebStorage ablegen, um sie dann bei Wiederherstellung der Verbindung auszuwerten...

Schaun wir mal, was OP sagt...

Zitat von gantim

Schade ist, dass ich in den UDP Logs des Shelly nicht sehe, mit welchem AP er sich verbindet/verbunden ist. Oder kann man den Loglevel erhöhen?

Das folgende Script schreibt den aktuellen Status des WLAN im Sekundentakt ins Log (die Frequenz kannst du in Millisekunden variieren):

Timer.set(1000, true, function() {
  console.log(JSON.stringify(Shelly.getComponentStatus("wifi")));
})

Die Einträge im Log sehen dann so aus:

{"sta_ip":"192.168.178.253","status":"got ip","ssid":"xxx","bssid":"xx:xx:xx:xx:xx:xx","rssi":-60}

Vielleicht hilft's ja...

Laut dem Log meines Pi-Hole hat mein Plus Plug S gestern exakt 4 DNS-Abfragen durchgeführt:

Dec 22 13:05:24 dnsmasq[67]: query[A] updates.shelly.cloud from 192.168.178.253
Dec 22 15:02:16 dnsmasq[67]: query[A] api.energy-charts.info from 192.168.178.253
Dec 22 22:11:38 dnsmasq[67]: query[A] updates.shelly.cloud from 192.168.178.253
Dec 22 22:38:39 dnsmasq[67]: query[A] powerstrip.internal from 192.168.178.253

Der Zugriff auf api.energy-charts.info kommt von meinem Preissteuerungsscript; powerstrip.internal ist im Pi-Hole als lokaler Name für meinen Powerstrip hinterlegt (testweise aus einem Script aufgerufen).

Offenbar kann der Shelly bei mir problemlos den via DHCP kommunizierten DNS aufrufen. Vielleicht gibt ja das Log des Pi-Hole genauere Aufschlüsse - bei mir ist es unter /var/log/pihole/pihole.log zu finden...

Zitat von Yankee

kann jemand bestätigen, dass die Shellys bei DHCP tatsächlich nicht die IP des Nameserver setzen/speichern?

Ich habe ein ähnliches Setup - ein PiHole, der in der Fritzbox als DNS-Server hinterlegt ist und fixe IP-Adressen via DHCP. Die Shellies haben bei mir auch keinen Nameserver eingetragen, können aber problemlos die lokalen Domain Names aus dem Pihole auflösen. Der Hauptunterschied zu deinem Setup ist wohl, dass ich für lokale Clients .internal als TLD verwende (TLS brauche ich im internen Netzwerk nicht).

Ich lese gerade das "What you need to know" über die Änderungen, die offenbar mit Firmware 1.8 kommen.... da wird's wohl ein paar Anfragen im Forum geben - Beispiele:

Zitat

• Browsers and other clients may warn about certificate trust chain validation problem. The certificate is issued by Shelly private CA. Shelly will publish the chain of trust for importing into your client. Shelly application will have this chain of trust by default.
• Account lockout after repeated failures within a time window, only established sessions are allowed.
• Bluetooth channel is automatically disabled after setup; enabling it opens a 15-minute pairing window only.
• You must complete initial configuration (admin password, Wi-Fi, etc.) within the guided 15-minute window after powering up/resetting the device.

Siehe https://kb.shelly.cloud/knowledge-base…elly-and-eu-red

Es gibt in der Knowledge Base einen Artikel der verspricht, dass das WebUI ab Firmware 1.8 über HTTPS gesichert werden kann:

Zitat

Web-UI: From v1.8.0 (Gen3+), HTTPS is supported, including custom HTTPS certificates (self-signed or private PKI).

Siehe https://kb.shelly.cloud/knowledge-base…ed-certs-config

Zitat von tvbshelly

HTTP Kommunikation (welche ich abfangen und ändern könnte)

Du hast recht. Ich bin fälschlicherweise davon ausgegangen, dass der Shelly auch die Integrität der Nachricht verifiziert, aber die entsprechende Quality of Protection (auth-int) wird offensichtlich nicht unterstützt. Somit ist zwar das Passwort geschützt, aber der Inhalt der Nachricht ist manipulierbar. Asche auf mein Haupt...

Es nützt genau das, was ich gesagt habe. Ein Eindringling kann durch Datenanalyse wahrscheinlich problemlos herausfinden, welcher Shelly dein Garagentor steuert - aber er kann es ohne Passwort nicht öffnen. Dass es besser ist, das Netzwerk von vornherein so abzusichern dass es ger nicht erst so weit kommt, halte ich für offensichtlich.

Wie schon gesagt, bleibt es jedem selbst überlassen, ob er das machen will (ich tu's auch nicht).

Zitat von tvbshelly

Die Shellys sprechen aktuell nur http - da ist das mit der Passwortsicherheit eh hinfällig.

Da würde ich (ein bisschen) widersprechen. Die Grundidee der vom Shelly verwendeten Digest-Authentication ist es ja, dass das Passwort auch bei unverschlüsselten Verbindungen geheim bleibt (weil es nie im Klartext sondern nur als Teil eines Hashes übertragen wird, der für jede Abfrage neu berechnet wird).

Ein potentieller Eindringling ins Netzwerk könnte zwar problemlos den (unverschlüsselten) Datenverkehr vom und zum Shelly mitlesen - ohne Kenntnis des Passwortes ist es ihm aber unmöglich, selbst Abfragen oder Befehle an den Shelly zu schicken.

Ob die Absicherung gegen dieses Szenario den Aufwand für die Passworterstellung/-verwaltung rechtfertigt, ist wohl eine individuelle Entscheidung...

Zitat von tvbshelly

Ich habe es bei meinem einfachen Test "zu simpel" versucht.

Das ist eher eine Verkettung unglücklicher Umstände - der Shelly lehnt offenbar POST-Requests ohne Body ab und curl sendet keinen Body, wenn er nicht explizit angegeben wird. Deswegen geht curl http://ip/rpc/Shelly.GetStatus -X POST nicht durch, aber curl http://ip/rpc/Shelly.GetStatus -d "{}" oder curl http://ip/rpc/Shelly.GetStatus -d "xyz" sehr wohl - muss man auch einmal draufkommen...

PHP ist nicht meine Baustelle, daher hier die Beispiele direkt in curl (die optionalen Parameter habe ich weggelassen). Es gibt zwei gleichwertige Methoden, um RPCs via POST zu schicken:

1. Du schickst einen POST an den /rpc Endpunkt. Dann musst du einen vollständigen JSON_RPC Frame mit id, method und params verwenden:

curl http://192.168.178.253/rpc -d '{"id": 0, "method": "Webhook.Create", "params": {"event": "switch.on", "cid": 0, "name": "Action-Name", "enable": true, "urls": ["https://meine-domain.de"]}}'

2. Du schickst einen POST direkt an den /rpc/Webhook.Create Endpunkt. Dann reichen die Request-spezifischen Parameter im Body:

curl http://192.168.178.253/rpc/Webhook.Create -d '{"event": "switch.on", "cid": 0, "name": "Action-Name", "enable": true, "urls": ["https://meine-domain.de"]}'

Dokumentiert ist das alles hier...

Ich habe kein PM Gerät aber wenn ich das richtig sehe, haben diese Geräte eine PM1 Komponente, für die es auch einen ResetCounters RPC in der Form

http://<ip>/rpc/PM1.ResetCounters?id=0&type=["aenergy","ret_aenergy"]

gibt - siehe Doku. Wie es scheint, ist diese Funktion über das WebUI nicht zugänglich...

Zitat von hajueschmitz

da ich von einem Raspberry Pi abrufe

Ah jo, steht eh im ersten Post - mein Gehirn hat mit "Edge=Windows" kurzgeschlossen...

Falls du Zugriff auf eine Linux-Box (und vermutlich auch Mac) hast, kannst du dir den Authentication-Austausch mit curl und dem -v Parameter ansehen (mit der Windows-Version von curl geht das leider nicht):

curl http://<ip>/rpc/Shelly.GetStatus -v --digest --user admin:password

Wäre interessant, ob es da Unterschiede bei deinen Shellies gibt...

Ich habe Version 3.6 des Scriptes veröffentlicht - hier ist das Changelog:

3.6 (2025-11-18)

This release enhances the priceModifier function so that it can be used to calculate date- or time-dependent price variations (like variable grid fees which have become more widespread in many European countries).

With this version, the script will pass both the price value and the date and time for each price into the priceModifier function. An example on how this can be used:

A grid operator charges different grid fees depending on the time of day:

• The fee is 10 ct/kWh during the peak hours from 7:00 to 9:00 and 18:00 to 20:00.
• For the remainder of the day, the fee is 8 ct/kWh.

The priceModifier can be modified like so to add these fees to the EPEX price:

function priceModifier(datetime, spotPrice) {
  let hour = datetime.getHours(); // extract hour from the datetime
  if (hour === 7 || hour === 8 || hour === 18 || hour === 19) {
    return spotPrice + 10; // peak hour - add 10 cent to the EPEX price
  }
  return spotPrice + 8; // normal hour - add 8 cent to the EPEX price
}

These modified prices are then used by the price analysis algorithm to determine the cheapest hours of the day.

Note that the WebUI will display these modified prices (and not just the pure EPEX price) when this feature is used.