Beiträge von eiche

Shelly-Typ? (Bild: vermutlich Plus 1 PM)

Leistung der Klimaanlage?

Abschaltung nach welcher Dauer?

Evtl. wird der Shelly zu warm. Interne Temperatur verfolgen!

Konfiguration automatisches Abschalten ist wenig wahrscheinlich, trotzdem nachsehen!

1. Schalter/Taster tauschen (evtl. hoher Übergangswiderstand oder mechanisches Problem)
2. Konfiguration des Eingangs (Schalter-/Taster-Typ)

Nur mal so:

Per Node RED ließe sich jegliche Gruppierung per Liste in einem Konfigurationsknoten ganz leicht implementieren. Allerdings gehört dazu selbstverständlich noch Funktionales und ggf. auch ein Dashboard.

Ich habe derzeit keinen entsprechenden Anwendungsbedarf.

Vielleicht gelingt es über die Type Einstellung am Shelly. Leider gibt es in den Shelly 1. Generation hier keine kategorisierenden Vorgaben (Auswahlliste), welche zu den Cloud Gerätekategorien passen könnten.

Immerhin gibt es in der Firmware der Shelly Plus 1 bspw. unter "Consumption Type" eine solche Auswahlliste. Vielleicht ginge damit das Gewünschte als Workaround.

Bachsaibling

Ob dafür vielleicht eine dauerhafte VPN-Verbindung zwischen zwei DSL-Routern (bspw. FRITZ!box) helfen könnte? Nur ein Gedanke. Ich täte es versuchen.

Hmm, Thema verfehlt. Die Cloud ist gemeint.

Die Anordnung der Räume ließe sich so einrichten, dass alle Räume der ersten Wohnung bspw. oben und die der zweiten unten angeordnet wären.

Ansonsten gibt es bessere Möglichkeiten als die Shelly App und die Cloud, wie von elektroman bereits erwähnt, bspw. openHAB - evtl. in Verbindung mit VPN.

Nachteil: Zusatzinvestition und Einarbeitung erforderlich.

Vorteil: Unabhängigkeit von der Cloud und recht gute Modellierung.

Vielleicht ließe sich dafür ein smart home Spezialist beauftragen, was halt Geld kosten täte.

Schubbie , Devil

stimmt, ich war etwas übereifrig

Schwierig, schwierig ... ohne Kenntnisse

Ich implementiere so etwas auf einem Raspberry Pi mit Node RED (darin ist etwas Programmierung erforderlich), dem Zeitreihendatenbanksystem Influx (ist nicht wirklich gut ohne kleinere SQL-Kenntnisse nutzbar) und Grafana für die grafische Darstellung der Influx-Datenbankinhalte.

Und ich bevorzuge MQTT (Mosquitto auf dem RPi). Es ginge aber auch per HTTP und ohne MQTT (imho etwas suboptimal).

Wenn du das alles nicht willst, dann bleibt nur noch eine fertiges System (ioBroker, Homeassistant, openHAB, ...) zu nehmen und sich darin durchzuARBEITEN.

Ohne Arbeit kein Erfolg.

Viel Erfolg

Zitat von FHEM-2020

Jedoch speichert er nicht die lokale IP meines Netzwerks.

Merkwürdige Formulierung

Der Shelly sollte die Daten des nächsten WLAN Accesspoint speichern. Er könnte noch eine statische IP-Adresse speichern. Mit DHCP sollte er sich die IP-Adresse und mehr liefern lassen - und diese Daten speichern.

Hast du auch mal statische Daten versucht, welche der Shelly statisch speichern muss?

Deshalb strebe ich immer auch Autarkie an. Am anfälligsten ist der Betrieb und insbesondere Automatisierung sowie Datenspeicherung per Cloud. Zumindest ein parallel nutzbares System halte ich für sehr zweckmäßig.

Niomzone Ich verwende auf einem Raspberry Pi mosquitto (MQTT broker), Node RED, Influx und Grafana.

Per Node RED steuere ich teilweise, baue bei Bedarf Adapter, erstelle mir ein Dashboard, speichere per Infflux Node in der Zeitreihendatenbank.

Zusätzlich setze ich MQTT Dash als Android App auf Smartphones ein.

Die Skripte lassen sich relativ bequem in den WebUI der Shelly Plus per dort vorhandenem Editor erstellen, speichern, starten, stoppen und testen.

Zitat von Niomzone

Wie hast du die API eingebunden das sie im Browser funktioniert? Bei mir geht nur mit Node.js

Was genau meinst du mit API?

Node.js ist die JavaScript Laufzeitumgebung von Node RED.

Habe ich damit irgendwie deine Frage beantwortet?

Niomzone

Klar, kein Problem.

// Author: eiche
// Device: Shelly Plus 2PM, Type: Cover
// This skript uses MQTT and self defined topics.

let Pre = 'Schlafen-links/';

let Pub = {
  Status: Pre+'status'
};

let Sub = {
  Cmd: Pre+'cmd'
};

let Cover = {
  state: 'stopped'
};

// dependState() delivers a command depending on the imported command and the current cover state.
// This allows multifunctionality of a control Button, that sends only one command.
function dependState(c){
  if(c==='open')
    if(Cover.state==='opening') return 'stop'
    else if(Cover.state==='closing' || Cover.state==='closed' || Cover.state==='stopped') return 'open';
  if(c==='close')
    if(Cover.state==='closing') return 'stop'
    else if(Cover.state==='opening' || Cover.state==='open' || Cover.state==='stopped') return 'close';
  if(c==='stop' && (Cover.state==='closing' || Cover.state==='opening')) return 'stop';
  return c;
}

Shelly.addEventHandler(
 function (event) {
   // event.info.
   // ts: timestamp when event occurs
   // source: WS_in | timeout | SHC (Cloud, Alexa) | limit_switch
   // event: closing | stopped | opening | open | closed | pf_...
   if(event.name==='cover') {
     let e = event.info;
     let ev = e.event;
     if(ev==='closing' || ev==='opening' || ev==='open' || ev==='closed' || ev==='stopped'){
       Cover.state = ev;
       MQTT.publish(Pub.Status, e.event, 0, false);
     }
   }
 }
);

MQTT.subscribe(Sub.Cmd,
  function(topic, payload){
    let cmd = dependState(payload);
    //print('_',Cover.state,'_',payload,'_',cmd);
    Shelly.call('Cover.'+cmd, {id:0});
  }
);

// Author: eiche
// Device: Shelly Plus i4 using 4 buttons with id 0 to 3
// ...03 means buttons 0 and 3, ...12 means button 1 and 2
// This skript uses MQTT and self defined topics.
// It allows using of alternative press durations.

let Pre03 = 'Schlafen-links/';
let Cmd03 = Pre03+'cmd';
let Status03 = Pre03+'status';

let Pre12 = 'Schlafen-rechts/';
let Cmd12 = Pre12+'cmd';
let Status12 = Pre12+'status';

let Timestamp = [0,0,0,0]; // id 0 .. 3
let State = ['stop','stop'];
let Idx = {left:1, right:0}; // assigning left/right to State index

let dependState = function(id, p){
  if(id<0 || id>3) return p;
  let i = id===0 || id===3 ? Idx.right : Idx.left;
  return p===State[i] ? 'stop' : p;
};

// list with one entry for each input id as index
// Each entry consists of a list of durations bounds (d),
// each followed by an MQTT message (msg), consists of topic (t) and payload (p)
// or an http-request URL (url) followed by a parameter string (p), which may be empty ('').
// Finally there may exist an optional function (pointer f) and an optional index (i) as call parameter to f.
// f may processes a payload respective parameter before sending.
// For useful codings this list entries should be ascending ordered by d values.
let cfg = [ // d=duration bound, msg=mqtt message, url=http request url, t=mqtt topic, p=payload/parameter
  [{d:1, msg:{t:Cmd03,p:'open'}, f:dependState, i:Idx.right}], // id 0
  [{d:1, msg:{t:Cmd12,p:'open'}, f:dependState, i:Idx.left}], // id 1
  [{d:1, msg:{t:Cmd12,p:'close'}, f:dependState, i:Idx.left}], // id 2
  [{d:1, msg:{t:Cmd03,p:'close'},f:dependState, i:Idx.right}] // id 3
];

// only assigned to button 0 or button 3 (right hand side)
MQTT.subscribe(Status03,
  function(topic, payload){
    State[Idx.right] = payload;
  }
);

// only assigned to button 1 or button 2 (left hand side)
MQTT.subscribe(Status12,
  function(topic, payload){
    State[Idx.left] = payload;
  }
);

// act() publishs an mqtt message (topic, payload) or sends an http request registered in cfg
// with the first d value greater than the imported duration.
function act(id, duration) {
  let n = cfg[id].length;
  for(let i=0; i<n; ++i){
    let entry = cfg[id][i];
    if(duration < entry.d){
      //print(JSON.stringify(entry));
      if(entry.msg!==undefined){
        let msg = entry.msg;
        if(msg!==null){
          let p = entry.f===undefined ? msg.p : entry.f(entry.i, msg.p);
          //print(msg.t,p);
          MQTT.publish(msg.t, p, 0, false);
          return true;
        }
      }
      if(entry.url!==undefined){
        Shelly.call('http.get',
          {url: entry.url + ((entry.p===undefined) ? ''
            : (entry.f===undefined ? entry.p : entry.f(id, entry.p)))},
          function(response, errc, errm, i){
            //print('post:',response.body);
            //print(response.body);
            State[i] = JSON.parse(response.body).state;
          }, entry.i
        );
        return true;
      }
    }
  }
  return false;
}

Shelly.addEventHandler(
  function (event) {
    if(event.name==="input"){
      let id = event.info.id;
      if(event.info.state) Timestamp[id] = event.info.ts
      else{
        let ts = Timestamp[id];
        if(ts>0){
          let dt = event.info.ts - ts;
          // true: act could performed, false: nothing done
          let done = act(id,dt);
          if(!done) {
            // do something else
            // Shelly.call('http.get',{url:AlterUrl});
          }
        }
      }
    }
  }
)

Die Datenstruktur "cfg" lässt einige Optionen zu, wie bspw. verschiedene Tastendruckdauern - hier ist jeweils nur 1 für <1s eingetragen, MQTT Nachrichten, HTTP URLs, Manipulation einer Payload vor dem Senden einer MQTT Nachricht (bspw. abhängig vom aktuellen Status).

Die letzte Option nutze ich dafür, den Antrieb zu stoppen, wenn er aktuell läuft. Das ist bei mir erforderlich, weil ich zu jedem Antrieb nur zwei Tasten verwende. Mit einer 4fach Tastengruppe steuere ich manuell zwei Rolllädenantriebe.

Mit einer solchen Tastengruppe steuere ich vorläufig (damit ich keinen zusätzlichen Schalter installieren muss) auch eine Deckenleuchte, zusätzlich zu den Rollläden. Die Leuchte wird geschaltet, wenn eine der vier Tasten länger gedrückt wird.

Für weitere Fragen zu den Skripten stehe ich zur Verfügung.

Btw, ich täte die Skripte in einigen Stellen kürzer schreiben, wenn es nicht Probleme mit Funktionsaufrufen in Ausdrücken gegeben hätte, welcher herstellerseitig ursächlich sind. Ich vermutete Stack-Engpässe. Ich weiß derzeit nicht, ob diese Probleme bereits behoben wurden.

Niomzone

Ich verwende zum manuellen Steuern meiner Rollladenantriebe je zwei Taster an einem i4.

Auf den Plus 2PM läuft jeweils ein Skript mit selbstgeschriebenen Subscriber, Publisher und Eventhandler. So kann ich die von mir gewünschten Topics selbst frei festlegen.

Auf dem i4 läuft ein Skript, welches die von mir festgelegten Topics verwendet. Darüber steuere ich auch alte Shelly 2.5 an. Die Nachrichten lege ich per Konfiguration in den Skripten fest, damit sie leicht anpassbar sind.

Wenn du schon selbst programmierst, dann sollten solche mJS Skripte für dich kein Problem darstellen.

Allerdings habe ich für die von mir gewünschte Flexibilität nicht wenig Zeit investiert.

Ob eine solche Vorgehensweise für dich in Frage kommt, weiß ich selbstverständlich nicht.

Es geht tatsächlich noch viel einfacher - in einem Skript. Hier habe ich jegliche Retriggerbarkeit weggelassen.

// Author: eiche
// I call this script "switchLatency".
// When switch:0 toggles on, enable is set to false and a message (e.g. a switch on message) is send to a second device.
// This action is only triggered if enable is true.
// After the LatencyTime enable is set to true.

let Method = 'http.get';
let SwitchOn = {'url':'http://172.16.3.62/relay/0?turn=on'}; // switch on message
let LatencyTime = 1*60*1000; // 1 minute
let enable = true;

Shelly.addStatusHandler(
  function(e) {
    if (enable && e.component==="switch:0" && e.delta.output) {
      enable = false;
      Shelly.call(Method, SwitchOn);
      Timer.set(LatencyTime, false, function() {enable = true;});
    }
  }
);

Warum bin ich darauf nicht sofort gekommen?

Zitat von markus-hi

Problem ist nun, dass ich keinen der beiden via mqtt ans Laufen bringe.

Also erhältst du auch vom Licht schaltenden Shelly 1 (mit Allterco Firmware?) keine MQTT Nachricht? Ich nehme an, dass dieser Shelly per Taster gesteuert wird.

Wenn ich das richtig verstanden habe, würde ich zunächst einmal die MQTT Kommunikation des Shelly 1 versuchen zum laufen zu kriegen.

Der sollte nämlich mit jedem Schalten eine Nachricht absetzen.

Wie kommunizieren denn bisher der Shelly 1 und Node RED miteinander, per HTTP?

Sorry, ich sah eben erst, dass ihr bereits viel weiter seid.

Hiermit ersetze ich meine beiden Skripte (in #52) durch die aktuellen.

Alles bereits vorher von mir Beschriebene gilt nach wie vor.

Wichtig!

Da ich hier einen kleinen Automatismus per Shelly.getCurrentScriptId() eingebaut habe, müssen beide Skripte in der Liste unmittelbar hintereinander stehen, das Skript "enable" zuerst. Die Skripte erkennen so selbst die passenden Id.

Man kann so beide Skripte hinter ggf. bereits vorhandenen Skripten ablegen wie auch davor liegende Skripte löschen - ganz nach Belieben.

Im ersten Skript ist in Zeile 10 die IP-Adresse des Slave einzusetzen!

Das erste Skript "enable":

// Author: eiche
// I call this script "enable".
// When switch:0 toggles on, a message is send to a second device e.g. a switch on message.
// Within the on time (e.g.) this action is retriggerable.
// After the retriggerable time a second script (called "disable") is started, which stops this "enable" script.
// The script "disable" starts the "enable" script after a while and stops itself.
// Both scripts must have consecutive id, "enable" first.
// version 2023-01-07

let Method = 'http.get';
let SwitchOn = {'url':'http://172.16.3.62/relay/0?turn=on'}; // switch on message
let Retriggerable = 5*1000; // 5 s

let SuccId = Shelly.getCurrentScriptId() + 1; // id of the successor script "disable"

let h = Shelly.addStatusHandler(
  function(e) {
    if (e.component === "switch:0") {
      if (e.delta.output) {
        Shelly.call(Method, SwitchOn);
        // If you don't whish retrigger, delete Timer.set() and only use both inside instructions! 
        Timer.set(Retriggerable, false, function(){
          Shelly.removeStatusHandler(h);
          Shelly.call('Script.Start', {id:SuccId});
        });
    }
  }
});

Das zweite Skript "disable":

// Author: eiche
// I call this script "disable".
// When it is started, it stops the "enable" script.
// After the end of an invoked timer the script "enable" is started and this script "disable" stops itself.
// Both scripts must have consecutive id, "enable" first.

let DisableTime = 1*60*1000; // 1 minute

let ThisId = Shelly.getCurrentScriptId(); // this script id
let PreId = ThisId - 1; // id of the predecessor script "enable"

Shelly.call('Script.Stop',{id:PreId});

Timer.set(DisableTime,false,
  function(){
    Shelly.call('Script.Start', {id:PreId}); // start "enable"
    Shelly.call('Script.Stop', {id:ThisId}); // stop "disable"
  }
);

Diese beiden Skripte gefallen mir besser.

Ergänzung:

Der Slave (hier ein Plug S) ist per Shelly App tatsächlich noch schaltbar, auch ohne den Gateway-Eintrag. Offenbar greift die App schlicht per WLAN zu. Das ist zwar nicht gewünscht, muss aber kein Problem sein.

Ich kann hierfür empfehlen, ein anderes Frontend als die Shelly App einzusetzen oder alle beteiligten Personen darauf hinzuweisen, nur Räume und Gruppen zu verwenden.

Schade, dass man die Option "Entdeckte Geräte" in der App nicht deaktivieren kann. Vielleicht wäre es praktikabel, ein Gerät in der Cloud zu verstecken.

Nachtrag 2023-01-07:

Sorry, ich musste noch ein wenig nacharbeiten. Im ersten Skript habe ich noch zusätzlich den status handler entfernt (Shelly.removeStatusHandler(h)).

Ich weiß nicht, ob mit dem Stopp eines Skript auch dessen Referenzen entfernt werden. Deshalb habe ich vorsichtshalber diesen Aufruf noch eingefügt.

Das zweite Skript ist wie vorher geblieben.

Ich versuche noch, die Funktionalität in einem einzigen Skript zu implementieren.

Praxis ist, wenn es funktioniert ...

Ich habe testweise in Shelly.call() nicht die Methode 'http.get' und den URL verwendet sondern:

Shelly.call('Script.Start',{'id':3});

Ich erwartete, dass dieser Aufruf bereits genügt. Aber nein, so gelingt der Start des Script 3 nicht. Ohne die single quotes um id ist es nicht anders.

Script.Start wie auch Script.Stop sind in der Methodenliste aufgeführt (<ip-address>/rpc/Shelly.ListMethods).

Deshalb ist zu erwarten, dass obiger Aufruf das Script ebenso startet wie mit

Shelly.call('http.get', {'url':'http://127.0.0.1/rpc/Script.Start?id=3'});

Das tut er merkwürdigerweise nicht.

Nachgereicht:

Ich hatte im zweiten Skript ("disable") einen Syntaxfehler. Der kurze Aufruf gelingt doch. Ich werde die jetzigen Skripte nachreichen.

Johnny Glatteis

So, geschrieben und getestet mit einem Shelly Plus 1 (Master) und einem Shelly PlugS (Slave).

Die gewünschte Funktion wird mit zwei Skripten implementiert, ein Skript "enable" und ein Skript "disable". Diese Namen sind selbstverständlich frei wählbar. Beide Skripte laufen auf dem Master.

Sowohl die IP-Adressen als auch Dauern sind für eigene Zwecke anzupassen.

Zuerst "enable", welches auch enabled werden sollte, damit es nach einem Stromausfall automatisch gestartet wird.

// Author: eiche
// I call this script "enable".
// When switch:0 toggles on, a message is send to a second device e.g. a switch on message.
// Within the on time (e.g.) this action is retriggerable.
// After the retriggerable time a second script (called "disable") is started, which stops this "enable" script.
// The script "disable" starts the "enable" script after a while and stops itself.

let Method = 'http.get';
let SwitchOn = {'url':'http://172.16.3.62/relay/0?turn=on'}; // switch on message
let StartDisable = {'url':'http://127.0.0.1/rpc/Script.Start?id=3'}; // instead of id 3 use the "disable" script id
let Retriggerable = 5*1000; // 5 seconds

Shelly.addStatusHandler(function(e) {
  if (e.component === "switch:0") {
    if (e.delta.output === true) {
      Shelly.call(Method, SwitchOn);
      // If you don't whish retrigger, delete the Timer.set() and only use the Shelly.call()! 
      Timer.set(Retriggerable,false,function(){Shelly.call(Method, StartDisable);});
      // Shelly.call(Method, StartDisable); // without retrigger
    }
  }
});

Dieses Skript reagiert auf das Einschalten des eigenen Relais mit dem Senden einer Nachricht an den Slave. Diese Aktion ist für eine gewisse Zeit (hier 5s) retriggerbar. Die Retriggerbarkeit kann leicht entfernt werden.

Das zweite Skript "disable" ist nicht zu enablen, weil es nur durch das erste Skript gestartet werden soll.

// Author: eiche
// I call this script "disable".
// When it is started, it stops the "enable" script.
// After the end of an invoked timer the script "enable" is started and this script "disable" stops itself.

let Method = 'http.get';
let StopEnable = {'url':'http://127.0.0.1/rpc/Script.Stop?id=2'}; // instead of id 2 use the "enable" script id
let StartEnable = {'url':'http://127.0.0.1/rpc/Script.Start?id=2'}; // dito
let StopDisable = {'url':'http://127.0.0.1/rpc/Script.Stop?id=3'}; // instead of id 3 use the "disable" script id
let DisableTime = 1*60*1000; // 1 minute

Shelly.call(Method, StopEnable);

Timer.set(DisableTime,false,
  function(){
    Shelly.call(Method, StartEnable);
    Shelly.call(Method, StopDisable);
  }
);

Dieses Skript stoppt das erste Skript "enable" und startet einen Timer. Sobald der Timer abgelaufen ist, startet dieses Skript das erste Skript "enable" und stoppt sich selbst.

Das "enable" Skript ist somit während der "disable" Dauer inaktiv und der Slave kann nicht per Master geschaltet werden.

In der Praxis werden die gewünschten Dauern länger sein. Für Funktionstests sind die obigen Dauern gut geeignet.

Wer es noch ein wenig komfortabler möchte, mag Shelly.getCurrentScriptId() verwenden. Wenn bspw. beide Skripte hintereinander liegen, können alle konstanten Skript-Id per Shelly.getCurrentScriptId() und Konvertierung in einen String ersetzt werden.

Wichtig!

Für lokale HTTP-Nachrichten, also zum selben Gerät, muss die IP-Adresse 127.0.0.1 (=localhost) verwendet werden. Mit der eigenen IP-Adresse funktionieren die HTTP-Nachrichten derzeit nicht (Firmware 0.12.0).

Der Slave sollte ausschließlich vom Master gesteuert werden können. Die Shelly App könnte dies evtl. trotzdem, das habe ich nicht getestet.

Empfehlungen:

1. Die Einschaltdauer des Master auf 1s stellen.
2. Den Slave nicht mit der Cloud verbinden. Er kann sogar ganz ohne Internetzugriff auskommen.

Womit der Master eingeschaltet wird, ist total beliebig. Entscheidend ist nur das Einschalten. Auf diese Weise gibt es reichlich Steuerungsoptionen.

Wenn statt des Plus 1 bspw. ein Plus 2 verwendet wird, kann per zweitem Relais eine Signalleuchte geschaltet werden.

Und nun viel Erfolg! Und einen Dank an SebMai für seine initiierende Skriptidee.

Noch ne Idee

Erstmal würde ich die Skriptlösung bevorzugen.

Gründe:

1. Der Script-Shelly arbeitet autark und somit am funktionssichersten, weil außer ihm alles ausfallen darf und er kann immer noch arbeiten.
2. Es kann eine Cloud verwendet werden, muss aber nicht.

Nun meine Zusatzidee - ohne Signalleuchte, die kann eh irgendwie geschaltet werden:

Erforderlich sind

• ein Shelly der zweiten Generation, weil darauf ein Script arbeiten soll, bspw. das von SebMai oder eines auf seiner Grundlage
  Hier bietet sich ein Plus 1, ein Pro 1, ein Plus 2 oder ein Pro 2 an.
  Ich nenne diesen Shelly den Master. Der Master schaltet den eigentlichen Verbraucher NICHT.
• ein beliebiger Shelly mit Relais, der den eigentlichen Verbraucher schaltet
  Ich nenne diesen Shelly den Slave.

Der Master erhält bei Bedarf die Verbindung mit der Cloud und kann per Sprachassistent gesteuert werden.

Der Slave erhält keine Verbindung zur Cloud und kann (vermutlich) nicht per Sprachassistent gesteuert werden. Notfalls könnte in dessen Konfiguration bei statischer IP-Adresse das Gateway weggelassen werden, wodurch der Slave sogar keine Verbindung mit dem Internet hätte.

Der Master steuert per Skript den Slave. Wenn der Master eingeschaltet wird, wodurch auch immer, kann er dem Slave die Schaltnachricht senden oder auch nicht, wenn dies temporär gerade gesperrt ist.

Auf diese Weise erscheint mir ein Einschalten innerhalb der gesperrten Zeitphase unmöglich, allenfalls wäre es evtl. per App im WLAN möglich, was ich nicht weiß, da ich die App für solche Zwecke nicht verwende.

Der Master mag vielleicht kurz schalten, wenn er den Befehl oder das Signal erhält, er kann aber bspw. nach eine Sekunde wieder ausschalten.

Vielleicht werde ich dieses gelegentlich ausgiebig testen ..

Btw - das Ganze ginge auch mit einem Shelly der ersten Generation und Tasmota-Rules.

Ich nutze bisher solche "hübschen" Dinge nicht. Vermutlich kann dir dabei Tasmota(32) weiterhelfen. Diese Firmware ist ziemlich flexibel konfigurierbar und sehr vielseitig einsetzbar, besonders dann, wenn man sie selbst kompiliert. Man kann aber auch fertig kompilierte Versionen einsetzen. Gewöhnungsbedürftig sind für eigene Erweiterungszwecke die Rules. Aus dem ESP32 wird mit der Programmierung in Berry eine "Kanone" - im nichtmilitärischen Sinne.

Das Tasmota32 System ist imho dem derzeitigen Shelly Firmwaresystem noch überlegen. Mit gefällt das Shelly Firmwaresystem trotzdem sehr gut und Allterco entwickelt ja auch weiter.

Der JSN-SR04T ist ein digitaler Sensor. Das Senden des Schalls wird binär getriggert. Sobald der Empfänger des Sensors den reflektierten Schall empfängt, wird dies binär mitgeteilt. Der Mikrocontroller muss die Zeitspanne zwischen dem Triggern und der Empfangsmeldung messen. Daraus ergibt sich die Laufzeit für Hin- und Rückweg des Schalls und daraus der Abstand zur reflektierenden Oberfläche. Hier ist also kein analoges Signal beteiligt.

Digital ist der Sensor durch die ihn begleitende Elektronik, welche mit dem Mikrocontroller kommuniziert.

WEMOS D1 ist eines der vermutlich geeigneten Boards, ich nutze ein für Experimentierzwecke geeignetes ESP32 Board mit zwei Stiftleisten zum stecken. Das ist zwar nicht erforderlich, ermöglicht mir aber einen einfachen Boardwechsel, wenn dies erforderlich ist.

Mit einem Arduino habe ich begonnen, ein ESP32 mit Tasmota32 ist aber wegen der bereits vorhandene Firmware (Tasmota) und deren Erweiterbarkeit per Berry-Funktionen eindeutig zu bevorzugen.

Mein System ist parametrierbar und liefert den resultierenden Nutzwert, hier also den verfügbaren Füllstand.