Beiträge von eiche

Merkwürdig. Mein Test läuft mit Firmware 1.6.2. Ich lasse allerdings die beiden RPC Aufrufe nicht arbeiten. Vielleicht erwirken zu viele RPC Aufrufe das Problem.

Ich werde nun das Skript länger laufen lassen.

Mich interessiert dein Skript mit der Id 2, welches du stoppen und starten lässt.

woodblack

Nun will ich endlich meinen Skriptentwurf nachreichen.

Das folgende Skript implementiert deine Anwendung. Es ist noch ungetestet, funktioniert aber vermutlich. Ich habe es auf einem Shelly Plus 1 (Generation 2) mit einem BLU Door/Window und print Ausgaben statt Aufrufen der RPC Methoden erfolgreich getestet. Somit wird es auch auf einem Shelly Plus 2PM funktionieren. Es kann bei Bedarf relativ flexibel um weitere Aktionen auf Grund von BLU Nachrichten erweitert werden. Die Ausgaben per print() dienen ausschließlich der Kontrolle und können später entfernt werden.

// Created by eiche, version 2025-06-28_01
// script user: woodblack
// This script requires the running script ble-shelly-blu.js.

const SkriptId = 2; // the id of the stopable script

const Config = [
 	{addr: "38:39:8f:ed:ad:40",
 		func: function(ev) { // Aktionen
 			let i = ev.info;
 			if(i.data===undefined || i.data.window===undefined) return;
 			if(i.data.window) { // wenn geöffnet
 				print("Cover.Open and Script.Stop");
 				Shelly.call("Cover.Open", {id:0});
 				Shelly.call("Script.Stop", {id:SkriptId});
 			}
 			// wenn geschlossen
 			else {
 			  print("Script.Start");
 			  Shelly.call("Script.Start", {id:SkriptId});
 			}
 		}	
 	}
 ];

function process(ev) {
  if(ev.info===undefined || ev.info.event!=="shelly-blu") return;
  let i, info = ev.info;
  if(info.data.window!==undefined) print(JSON.stringify(ev));
  for(i=Config.length-1; i>=0 && Config[i].addr!==info.data.address; --i);
  if(i<0) return;
  Config[i].func(ev);
}

Shelly.addEventHandler(process);

Das folgende Skript ist eine von mir auf das funktional notwendige Maß verkürzte Version des Originals "ble-shelly-blu.js". Es kann durch entfernen der vielen Kommentare noch weiter gekürzt werden. Statt dieses Skripts kann selbstverständlich auch das Original genutzt werden.

// origin script: ble-shelly-blu.js
// compressed by eiche without changing functionality on 2025-06-04
/**
 * This script will use BLE scanner to listen for advertising data from nearby Shelly BLU devices,
 * decodes the data using a BTHome data structure, and emits the decoded data for further processing.
 *
 * This script DOESN'T execute actions, only emit events. Can be used with `ble-events-handler.js` example.
 * You can configure the event name, by default its `shelly-blu`, the body of the event contains all the data
 * parsed from the BLE device
 *
 * Represents data provided by each device.
 * Every value illustrating a sensor reading (e.g., button) may be a singular sensor value or 
 * an array of values if the object has multiple instances. 
 * 
 * @typedef {Object} DeviceData
 * @property {number} pid - Packet ID.
 * @property {number} battery - The battery level of the device in percentage (%).
 * @property {number} rssi - The signal strength in decibels (dB).
 * @property {string} address - The MAC address of the Shelly BLU device.
 * @property {string} model - The model of the Shelly BLU device.
 * @property {number | number[]} [temperature] - The temperature value in degrees Celsius if the device has a temperature sensor. (Can be an array if has multiple instances)
 * @property {number | number[]} [humidity] - The humidity value in percentage (%) if the device has a humidity sensor. (Can be an array if has multiple instances)
 * @property {number | number[]} [illuminance] - The illuminance value in lux if the device has a light sensor. (Can be an array if has multiple instances)
 * @property {number | number[]} [motion] - Motion status: 0 for clear, 1 for motion (if the device has a motion sensor). (Can be an array if has multiple instances)
 * @property {number | number[]} [window] - Window status: 0 for closed, 1 for open (if the device has a reed switch). (Can be an array if has multiple instances)
 * @property {number | number[]} [button] - The number of presses if the device has a button. (Can be an array if has multiple instances)
 * @property {number | number[]} [rotation] - The angle of rotation in degrees if the device has a gyroscope. (Can be an array if has multiple instances)
 * 
 * @example
 * {"component":"script:*","name":"script","id":*,"now":*,"info":{"component":"script:*","id":*,"event":"shelly-blu","data":{"encryption":false,"BTHome_version":2,"pid":118,"battery":100,"button":1,"rssi":-76,"address":*},"ts":*}}
 */

/******************* START CHANGE HERE *******************/
const CONFIG = {
  // Specify the destination event where the decoded BLE data will be emitted. It allows for easy identification by other applications/scripts
  eventName: "shelly-blu",

  // If this value is set to true, the scan will be active.
  // If this value is set to false, the scan will be passive.
  // Active scan means the scanner will ping back the Bluetooth device to receive all its data, but it will drain the battery faster
  active: false,

  // When set to true, debug messages will be logged to the console
  debug: true,
};
/******************* STOP CHANGE HERE *******************/

const BTHOME_SVC_ID_STR = "fcd2";

const uint8 = 0;
const int8 = 1;
const uint16 = 2;
const int16 = 3;
const uint24 = 4;
const int24 = 5;

// The BTH object defines the structure of the BTHome data
const BTH = {
  0x00: { n: "pid", t: uint8 },
  0x01: { n: "battery", t: uint8, u: "%" },
  0x02: { n: "temperature", t: int16, f: 0.01, u: "tC" },
  0x03: { n: "humidity", t: uint16, f: 0.01, u: "%" },
  0x05: { n: "illuminance", t: uint24, f: 0.01 },
  0x21: { n: "motion", t: uint8 },
  0x2d: { n: "window", t: uint8 },
  0x2e: { n: "humidity", t: uint8, u: "%" },
  0x3a: { n: "button", t: uint8 },
  0x3f: { n: "rotation", t: int16, f: 0.1 },
  0x45: { n: "temperature", t: int16, f: 0.1, u: "tC" },
};

function getByteSize(type) {
  if (type === uint8 || type === int8) return 1;
  if (type === uint16 || type === int16) return 2;
  if (type === uint24 || type === int24) return 3;
  //impossible as advertisements are much smaller;
  return 255;
}

// functions for decoding and unpacking the service data from Shelly BLU devices
const BTHomeDecoder = {
  utoi: function (num, bitsz) {
    const mask = 1 << (bitsz - 1);
    return num & mask ? num - (1 << bitsz) : num;
  },
  getUInt8: function (buffer) {return buffer.at(0);},
  getInt8: function (buffer) {return this.utoi(this.getUInt8(buffer), 8);},
  getUInt16LE: function (buffer) {return 0xffff & ((buffer.at(1) << 8) | buffer.at(0));},
  getInt16LE: function (buffer) {return this.utoi(this.getUInt16LE(buffer), 16);},
  getUInt24LE: function (buffer) {return (0x00ffffff & ((buffer.at(2) << 16) | (buffer.at(1) << 8) | buffer.at(0)));},
  getInt24LE: function (buffer) {return this.utoi(this.getUInt24LE(buffer), 24);},
  getBufValue: function (type, buffer) {
    if (buffer.length < getByteSize(type)) return null;
    let res = null;
    if (type === uint8) res = this.getUInt8(buffer);
    if (type === int8) res = this.getInt8(buffer);
    if (type === uint16) res = this.getUInt16LE(buffer);
    if (type === int16) res = this.getInt16LE(buffer);
    if (type === uint24) res = this.getUInt24LE(buffer);
    if (type === int24) res = this.getInt24LE(buffer);
    return res;
  },

  // Unpacks the service data buffer from a Shelly BLU device
  unpack: function (buffer) {
    //beacons might not provide BTH service data
    if (typeof buffer !== "string" || buffer.length === 0) return null;
    let result = {};
    let _dib = buffer.at(0);
    result["encryption"] = _dib & 0x1 ? true : false;
    result["BTHome_version"] = _dib >> 5;
    if (result["BTHome_version"] !== 2) return null;
    //can not handle encrypted data
    if (result["encryption"]) return result;
    buffer = buffer.slice(1);

    let _bth;
    let _value;
    while (buffer.length > 0) {
      _bth = BTH[buffer.at(0)];
      if (typeof _bth === "undefined") {
        console.log("BTH: Unknown type");
        break;
      }
      buffer = buffer.slice(1);
      _value = this.getBufValue(_bth.t, buffer);
      if (_value === null) break;
      if (typeof _bth.f !== "undefined") _value = _value * _bth.f;

      if (typeof result[_bth.n] === "undefined") result[_bth.n] = _value;
      else {
        if (Array.isArray(result[_bth.n])) result[_bth.n].push(_value);
        else result[_bth.n] = [result[_bth.n], _value];
      }

      buffer = buffer.slice(getByteSize(_bth.t));
    }
    return result;
  },
};

/**
 * Еmitting the decoded BLE data to a specified event. It allows other scripts to receive and process the emitted data
 * @param {DeviceData} data 
 */
function emitData(data) {
  if (typeof data !== "object") return;
  Shelly.emitEvent(CONFIG.eventName, data);
}

//saving the id of the last packet, this is used to filter the duplicated packets
let lastPacketId = 0x100;

// Callback for the BLE scanner object
function BLEScanCallback(event, result) {
  //exit if not a result of a scan
  if (event !== BLE.Scanner.SCAN_RESULT) return;
  //exit if service_data member is missing
  if (typeof result.service_data === "undefined" || typeof result.service_data[BTHOME_SVC_ID_STR] === "undefined") return;

  let unpackedData = BTHomeDecoder.unpack(result.service_data[BTHOME_SVC_ID_STR]);
  //exit if unpacked data is null or the device is encrypted
  if (unpackedData === null || typeof unpackedData === "undefined" || unpackedData["encryption"]) {
    console.log("Error: Encrypted devices are not supported");
    return;
  }

  //exit if the event is duplicated
  if (lastPacketId === unpackedData.pid) return;

  lastPacketId = unpackedData.pid;

  unpackedData.rssi = result.rssi;
  unpackedData.address = result.addr;
  unpackedData.model = result.local_name;

  emitData(unpackedData);
}

// Initializes the script and performs the necessary checks and configurations
function init() {
  //exit if can't find the config
  if (typeof CONFIG === "undefined") {
    console.log("Error: Undefined config");
    return;
  }

  //get the config of ble component
  const BLEConfig = Shelly.getComponentConfig("ble");

  //exit if the BLE isn't enabled
  if (!BLEConfig.enable) {
    console.log("Error: The Bluetooth is not enabled, please enable it from settings");
    return;
  }

  //check if the scanner is already running
  if (BLE.Scanner.isRunning()) console.log("Info: The BLE gateway is running, the BLE scan configuration is managed by the device");
  else {
    //start the scanner
    const bleScanner = BLE.Scanner.Start({duration_ms: BLE.Scanner.INFINITE_SCAN, active: CONFIG.active});
    if (!bleScanner) console.log("Error: Can not start new scanner");
  }

  //subscribe a callback to BLE scanner
  BLE.Scanner.Subscribe(BLEScanCallback);

  // disable console.log when logs are disabled
  if (!CONFIG.debug) console.log = function () { };
}

init();

Mein gedachter Favorit wäre die Kombination aus

1. Shelly 2PM Generation 3 (wegen besserer BLU Kompatibilität) - Generation 2 ist auch nutzbar,
2. evtl. BLU Motion zwecks Bewegungserkennung (nur für Komfortzwecke, nicht zwingend),
3. BLU Button (beacon Modus erforderlich, meldet vermutlich auch seine Batteriespannung in %, zumindest als Schätzwert geeignet),
4. Skript (ob auch Szenen Aktionen geeignet sind, weiß ich nicht).

Das Skript wertet den BLU Button Batteriewert aus und sperrt das Schließen des Terrassenrolladens in folgender Weise. Ein niedriger Batteriestand oder ein zu lange nicht mehr eingetroffene Nachricht seitens des BLU Buttons wird persistent gespeichert und mit dem Hochfahren des 2PM gelesen. Somit steht immer die (nicht vorhandene) Verlässlichkeit des BLU Buttons zur Verfügung. Ist diese Verlässlichkeit nicht gegeben und der Rollladen wird geschlossen, öffnet das Skript diesen sofort wieder, was als Signal zu werten ist, dass der BLU Button oder dessen Batterie auszuwechseln ist.

Das Skript kann auch ein Drücken des BLU Buttons auswerten und den Rollladen öffnen. Dies braucht aber vermutlich vielleicht nicht zu sein. Ich kann dies derzeit mangels funktionierendem BLU Button nicht testen.

Diese Kombination dürfte eine sehr verlässliche Funktionsweise gegen das Aussperren ergeben. Allerdings wird die Knopfzelle des BLU Button wegen des beacon mode weniger lange durchhalten - vielleicht 1/2 Jahr.

Btw, das wäre auch eine Lösung bei meiner Schwiegermutter - mal sehen. Somit bedanke ich mich für die Frage.

Wurstpeel

Ich sehe nicht, dass ich eine Grundsatzdiskussion begann. Ich versuche es kurz machen.

Shelly Geräte werden (bisher) unter einer total anderen Philosophie entwickelt als es mit anderen, proprietären IoT Geräten der Fall ist. Wer sich mit den Möglichkeiten der Shelly Geräte nicht befassen will, darf das selbstverständlich gerne tun. Dann sollte er sich aber nicht anmaßen, seinen spezifischen Anwendungsfall als üblichen Normalfall darzustellen und den Shelly Entwicklern einen Vorwurf daraus zu machen, dass diese dafür keinen simplen Weg vorgesehen haben.

Statt solcher unqualifizierten und überflüssigen Bemerkungen herauszulassen, kann jeder einen Fachmann damit beauftragen, der genau das umzusetzen hat, was der Auftraggeber haben will. Btw, Shelly als Nr. 1 in diesem Markt zu bezeichnen, geht aller Wahrscheinlichkeit nach an der Realität vorbei.

Dein Vorhaben umzusetzen, ist tatsächlich mit hinreichenden Kenntnissen gut möglich - insbesondere ohne Cloud. Es gibt einen sehr bekannten Spruch in der Linux Gemeinde. "Wer keine Ahnung hat, einfach mal ....". Fragen ist völlig in Ordnung. Sich als Nichtwisser über die Shelly Entwickler ein Urteil zu erlauben - "Peinlich für Shelly" - ist absolut unangemessen.

Trotzdem wünsche ich dir noch viel Freude mit deiner Licht Anwendung.

Meine Ecowitt Geräte sind

1. die Wetterstation Wittboy und
2. das Gateway dazu.

Das Gateway liefert per MQTT im Abstand von ca. 1 Minute Nachrichten, die alle möglichen Daten in einer Zeichenkette enthält. Ich brauche dafür weder App noch Cloud. Allerdings war die App zeitweise hilfreich beim erkennen, welche Daten in der übertragenen Nachricht vorliegen bzw. wie diese zu interpretieren sind. Zu Letzterem habe ich einige Zeit in meine Recherchen investiert.

Mein Beispiel:

"PASSKEY=xxxxxxxxxxxxxxxx&stationtype=GW2000A_V3.2.5&runtime=1497300&heap=81132&dateutc=2025-06-25%2022%3A35%3A51&dns_ip=172.16.1.2&dns_err_cnt=0&cdnflg=29&tempinf=78.44&humidityin=47&baromrelin=29.515&baromabsin=29.515&tempf=73.76&humidity=63&vpd=0.311&winddir=255&windspeedmph=0.00&windgustmph=0.00&maxdailygust=1.34&solarradiation=0.00&uv=0&rrain_piezo=0.000&erain_piezo=0.000&hrain_piezo=0.000&drain_piezo=0.000&wrain_piezo=0.004&mrain_piezo=1.039&yrain_piezo=1.039&srain_piezo=0&ws90cap_volt=5.1&ws90_ver=155&wh90batt=3.16&freq=868M&model=GW2000A&interval=60"

Daraus lassen sich die gewünschten Daten isolieren, verarbeiten und speichern, mit welchen Werkzeugen auch immer. Ich nutze hierfür etwas JavaScript Code in Node-RED. Entscheidend ist es, den langen String in seine Bestandteile zu zerlegen. Es folgt die Zusammensetzung meines JavaScript Codes.

let p = msg.payload.split('&'); // msg.payload ist die MQTT Nachricht, auch Payload (Nutzlast) genannt.
let s = '{', n, e = [];
for(let i=p.length-1; i>=0; --i) {
    e = p[i].split('=');
    n = isNaN(e[1]);
    s += '"' + e[0] + '":' + (n ? '"' : '') + e[1] + (n ? '"' : '') + (i>0 ? ',' : '');
}
s += '}';
p = JSON.parse(s); // Konvertierung des String in ein Objekt

Nun liegen die Daten als Key Value Paare im Objekt p vor und können leicht verarbeitet werden. Meine Verarbeitung enthält Selektionen und Konvertierung in von mir bevorzugte Einheiten.

const dt = 7200000, // Zeitverschiebung in ms
mph2kmph = 16.09344,
in2mm = 254;

let d = {};
d.batt = p.wh90batt;
d.cap = p.ws90cap_volt;
d.tempC = Math.round((p.tempf - 32) / 0.18) /10;
d.tempinC = Math.round((p.tempinf - 32) / 0.18) / 10;
d.humidity = p.humidity;
d.humidityin = p.humidityin;
d.pressure = Math.round(p.baromabsin * 338.6389) / 10; // Luftdruck in hPa
d.windspeed = Math.round(p.windspeedmph * mph2kmph) / 10; // in km/h
d.windgust = Math.round(p.windgustmph * mph2kmph) / 10; // kürzliche Windböe in km/h
d.maxdailygust = Math.round(p.maxdailygust * mph2kmph) / 10; // Max. des Tages in km/h
d.winddir = p.winddir;
d.vpd = Math.round(p.vpd * 338.638864) / 100; // in kPa
d.solar = p.solarradiation;
d.srain = p.srain_piezo; // Status Regen
d.erain = Math.round(p.erain_piezo * in2mm) / 10; // Regenmenge in mm
d.rrain = Math.round(p.rrain_piezo * in2mm) / 10; // Regengeschw. in mm/h
d.hrain = Math.round(p.hrain_piezo * in2mm) / 10; // Regen der Stunde im mm
d.drain = Math.round(p.drain_piezo * in2mm) / 10; // Regen des Tages im mm
d.wrain = Math.round(p.wrain_piezo * in2mm) / 10; // Regen der Woche in mm
d.mrain = Math.round(p.mrain_piezo * in2mm) / 10; // Regen des Monats in mm
d.yrain = Math.round(p.yrain_piezo * in2mm) / 10; // Regendes Jahres in mm
let t = new Date(decodeURIComponent(p.dateutc));
t = new Date(t.getTime() + dt);
let M = t.getMonth() + 1, D = t.getDate(), h = t.getHours(), m = t.getMinutes();
M = (M < 10 ? '0' : '') + M;
D = (D < 10 ? '0' : '') + D;
h = (h < 10 ? '0' : '') + h;
m = (m < 10 ? '0' : '') + m;
d.ts = t.getFullYear() + '-' + M + '-' + D + ' ' + h + ':' + m;

Das Objekt d enthält nun alle mich interessierenden Daten.

Hyde_

1. Eine Zeitsteuerung ist auf einem Shelly Plus 1 sehr flexibel möglich und sehr verlässlich. Dazu braucht es kein Amazon Echo.
2. Wenn deine Wetterstation ausschließlich proprietäre Kommunikation mit einer App (leider der übliche Unsinn) bietet, kann keine Automatisierung implementiert werden.
3. Ist die Abbildung in #9 die Darstellung eines Web Browsers? Das ist zu vermuten, wenn diese Abbildung deine Antwort auf die gestellte Frage ist. Dann kann es prinzipiell möglich sein, wenn auch vielleicht unschön und aufwändig, auf die Daten deiner Wetterstation zuzugreifen, da dort nicht nur Grafiken sondern auch Zahlenwerte dargestellt werden.

Für eine Lösung gemäß 3. ist sowohl der URL (Browser Adresszeile) als auch der HTML Code der Webseite erforderlich.

Vermutete Lösungsmöglichkeit

Am besten wäre eine standardisierte Kommunikation, welche nicht an eine App gebunden ist. Vermutlich kann dies mit deiner Wetterstation genutzt werden.

Ich nutze ebenfalls eine Ecowitt Wetterstation mit einem Gateway Funk -> LAN (bei Bedarf WLAN). Auf dem Gateway kann MQTT genutzt werden, was ich auch tue. Damit ist es möglich, per übergeordnetem System (ioBroker, Home Assistant, openHAB, ... ich nutze ausschließlich Node-RED) oder einem Shelly Skript die Daten der Wetterstation zu erhalten, nicht abzufragen. Mit diesen Daten kann selbstverständlich eine Bewässerung automatisiert werden. Allerdings erscheint es mir zielführend, dafür zusätzlich die Bodenfeuchtigkeit zu messen. Wie gut eine Kommunikation ohne MQTT gelingt, habe ich bisher nicht getestet, weil ich gerne MQTT verwende.

Du solltest herausfinden, welche Kommunikation deine Station zur Verfügung stellt - im Handbuch und/oder der Konfiguration. Daraus und aus deiner IoT Umgebung sowie deinen Ambitionen ergeben sich die Wege zu deinem Ziel.

Tiroler63

Lasse bitte weiter von dir lesen, wenn es dazu etwas Neues gibt!

ShellBeto

Kleiner Hinweis:

Statt deiner zwei Timer.set Aufrufe genügt einer - in Zeile 16.

Timer.set(Zeitfenster, true, Schleife02);

Der Aufruf in Zeile 13 kann dann entfallen.

Frage: Wozu dient die Funktion Schleife01? Vermutlich um zur Halben Zyklusdauer etwas ausführen zu lassen.

Btw, die Schedule Jobs sind dafür auch sehr nützlich - und Uhrzeit bezogen sekundengenau.

Anmerkung: Inzwischen lassen sich relativ viele JavaScript Methoden nutzen. Die API Dokumentation ist auch recht ausführlich dokumentiert. Wenn man sich erst einmal an das Shelly Konzept gewöhnt hat, ist es gut verständlich.

Ich habe soeben noch einmal das neue Laden des betreffenden Shelly getestet, mit laufendem Skript großen Umfangs.

Die Webseite war sofort da. Das Problem tritt also vermutlich erst nach längerem Nichtladen des WebUI auf. Alles nebulös.

Inzwischen musste ich feststellen, dass die Firmware 1.6.2 tatsächlich zu erheblichen und unerträglichen Verzögerungen beim laden des WebUI führt. Offenbar haben wir es bei den Firmware Versionen über 1.5.1 mit den üblicherweise beim Kunden reifenden Bananen zu tun.

Jrtripper01

Da wirst du reichlich zu tun haben, wenn du das gesamte Forum nach solchen "wichtigen Dingen" durchsuchen willst. Wenn die Elektrofachleute, also diejenigen, die professionell Elektroinstallationen durchführen, wenigstens ähnlich "richtige" Bezeichnungen in allen einschlägigen Themen verwenden täten, wäre die Welt hier vielleicht heile.

Zitat von Jrtripper01

Der N(Neutralleiter) war noch nie der Nulleiter.

Alt: Nulleiter Neu: PEN

Interessant. Dann ist also der nicht existierende Nulleiter ein Null Eiter? Es gibt die Null und den Leiter -> Nullleiter, auch wenn es nur das Wort, aber nicht den Gegenstand geben sollte. Offenbar hängst du der veralteten Schreibweise nach, in welcher drei unmittelbar aufeinanderfolgende Konsonanten sehr selten gültig war.

Dieses Wort "Null(l)eiter" ist also die alte Bezeichnung, welche noch nie galt? Wenn du dich schon bemühst, mich (und vielleicht andere) in dieser "freundlichen" Weise zu verbessern, dann bitte nicht derart nachlässig!

Damit ich richtig verstanden werde. Ich habe nichts gegen deine Erklärungen und nehme solche gerne entgegen, merken werde ich mir PEN vermutlich nicht. Mir missfällt deine besserwisserischere und anmaßende Ausdrucksweise - und das gewaltig.

Ich bin gespannt, wo du an anderen Stellen in diesem Forum ähnlich wichtige Belehrungen loslassen willst. Am grundlegenden Sachverstand werden solche genormten Bezeichnungen nichts verbessern können. Ich bin außerdem überrascht, dass du das Wort Phase nicht bemängelst ...

Btw, ich halte den VDE für einen sehr arroganten Verein, pardon Verband. Und ich bin sicher nicht der Einzige mit dieser Einschätzung.

woodblack

Diese Struktur gefällt mir nicht.

1. Wozu dient der Text zu Beginn? Ich kann dessen Funktion nicht erkennen. Vermutlich wird statt eines Datenfeldes ein Objekt verwendet.
   Teile bitte die komplette Datenstruktur mit, in welcher deine drei Teile eingetragen sind!
2. Es wird zweimal dieselbe Kombination aus id und event verwendet und dahinter ein call Datenfeld.
   Entweder es braucht nicht das Datenfeld "call" und stattdessen "method" und "parameter" oder
   man bringt die Methoden incl. Parameter in das Datenfeld "call" von Eintrag 1 unter.
   Ich halte für deinen Zweck die erste Variante für leichter verständlich.
3. Einem einzigen BLU Gerät werden mehrere Aktionen zugeordnet, die von verschiedenen Events getriggert werden. Deshalb halte ich eine Adresse und eine diesem BLU Gerät zugeordnete Funktion für zielführender. Hierfür ist eine relativ einfache Struktur geeignet.

const Config = [
 	{addr:"38:39:8f:ed:ad:40",
 		func: function(ev) { // Aktionen
 			let i = ev.info;
 			if(i.data===undefined || i.data.window===undefined) return;
 			if(i.data.window) { // wenn geöffnet
 				Shelly.call("Cover.Open", {id:0});
 				Shelly.call("Script.Stop", {id:2});
 			}
 			// wenn geschlossen
 			else Shelly.call("Script.Start", {id:2});
 		}	
 	}
 ];

Was bei dir "id" heißt, nenne ich "addr", weil dies besser zu meinem Skript passt.

Diese Struktur "Config" ist ausschließlich für Erweiterungen erforderlich. Solange nur dieser eine Sensor genutzt werden soll, kann diese Struktur weggelassen und die Funktion vom Eventhandler aufgerufen werden.

Eine Sensor spezifische aber generische Funktion erfordert umständliche Konfigurationseinträge. Für gewünschte Aktionen kurze Funktionen mit aussagekräftigen Kommentaren zu nutzen, halte ich für angemessener. Bei Nutzung von vielen BLU Geräten können die Aktionen spezifischen Funktionen benannt und aus "Config" ausgelagert werden.

Wenn du den Inhalt der obigen function verstehst und anpassen kannst, sollte diese Struktur für dein Anliegen angemessen sein.

Vorsicht!
Die obige Struktur soll dir nur einen Eindruck verschaffen. Ich werde diese Struktur in einem Testskript einbauen - mit anderem addr Wert.

Zitat von Dirk65

Soll ich auf 1.6.2 updaten?

Nein!

Zitat von Dirk65

Oder muss ich noch die Einstellung vornehmen, wie der Shelly sich nach stromausfall verhalten soll?

Nein!

Zitat von Dirk65

aus der FB kann ich ihn also nicht aufrufen.

Das kenne ich und finde solches in der Anwendung "ShellyScanner" in gleicher Weise. Das ignoriere ich und setze im Browsertab die mir bekannte IP-Adresse ein.

Und ja, das erscheint merkwürdig. Ich kenne die Ursache dieser Erscheinung auch nicht.

woodblack

Ich kann dir eine Kombination aus meinem einfachen Skript und dem Skript ble_shelly_blu.js empfehlen. Diese Kombination funktioniert bisher mit Firmware 1.6.x.

Thema

BLU Skripte für Shelly der Generation 2 mit Firmware 1.6.x +

Ich sah mir die Möglichkeiten an, mit einem Shelly der Generation 2 - hier Shelly Plus Uni - auf relativ einfache Weise Daten von BLU Sensoren zu verarbeiten.

Dazu bildet das Skript https://github.com/ALLTERCO/shell…e-shelly-blu.js die Grundlage. Neben den Grundfunktionen des Scannens und des Koppelns von Shelly BLU Geräten sendet dieses Skript Ereignisse, welche in anderen, anwendungsorientierten Skripts genutzt werden können.

In meinem Anwendungsskript lege ich Wert auf möglichst einfachen,…

eiche

4. Juni 2025 um 19:12

Wenn du die von dir genutzten Nachrichten beschreibst - HTTP, MQTT - kann ich gelegentlich mein Skript dazu für dich anpassen.

Ich teste nun beide Skripte mit der Firmware 1.7.0-beta2 auf einem Plus Uni. Mal sehen, was sich ergibt.

tvbshelly

Zielführende Tests. Sehr gut gemacht. Demnach sollte man b.a.w. bei 1.5.1 bleiben.

tvbshelly zu #24

Ist das das einzige Skript auf deinem Testshelly?

Was läuft da ggf. sonst noch?

Btw, ich denke, dass Shelly aufpassen sollte, dass der Überblick in der Firmware nicht verloren geht. Es gibt in letzter Zeit einiges an Merkwürdigkeiten, welche der weiteren erfolgreichen Vermarktung im Wege stehen werden. Skripte machen die Shelly erst wirklich interessant. Ohne Skripte versinken die Shelly imho in der Masse der IoT Geräte.

Zitat von woodblack

Schieberegler?

Das ist ein Schalter bzw. eine boolesche Variable der Firmware. Wahr oder nicht wahr, das ist hier die Fra... äh ... das Wesentliche.

Zitat von tvbshelly

Hast du da irgendeine Idee was hier falsch läuft? Darf man sowas nicht machen?

Vermutlich sollte man eine Beta Firmware "mit spitzen Fingern anfassen".

Nein, ich sehe nichts, was man in diesem Skript nicht tun sollte. Ich sehe da keinerlei Wiederholungsstruktur oder ähnlich mitunter "Gefährliches".

Mit einem Shelly Gen 3 braucht man eigentlich das Easy_call Skript nicht, weil auf einem solchen Shelly die BLU Geräte als Komponenten konfiguriert werden können. Ein zusätzliches erheblich kürzeres Skript kann die gewünschten Prozesse ausführen lassen.

Beispiel dazu hier: BLU Daten per Shelly Gen 3 und MQTT senden - ohne oder mit Skript

Statt der beispielhaften MQTT Nachrichten kann man andere Prozesse triggern.

Hinweis:

Mit einem Firmware Update auf 1.5 (?) oder 1.6 wurden Änderungen wirksam, die in manchen Skripten zu Fehlern führen. Solche Skripte können, wenn man diese Änderungen kennt, relativ leicht angepasst werden.

S.a. Änderung mindestens einer KVS Methode von Firmware 1.4.4 auf 1.5.1

Ein Cloud gesteuerter Eierkocher ...

Mit einem Skript ist solches lokal möglich.

Bietet der FRITZ!Smart Energy 200 auch eine Skriptnutzung auf dem Gerät?