Beiträge von eiche

Hast du es mal lokal auf dem i4 mit einer Action zu einem Input versucht?

Damit könntest du beginnen.

Die Nutzung der Cloud für eine gewünscht hohe Funktionssicherheit ist eh suboptimal.

Na ja, im Eventhandler (Skript) ist es so.

Ich glaube, dass die Inputs in der Cloud als einzelne Geräte auftreten. Das wirst du selbst leicht finden.

Die Aktion für die Licht schaltenden Shellies ist ... toggle.

Die Tasten Id lauten 0 bis 3.

Das kann @Olsche besser.

Ich nutze in der Cloud keine Szenen, habe so etwas nur mal getestet, um das Prinzip kennenzulernen.

Dann beschreibe mal genau, was bei welchen Tastendrücken geschehen soll.

Es ist gut möglich, dass du ohne Skript auskommen kannst.

Das Skript bietet mehr Möglichkeiten.

Du kannst doch beides nutzen.

Und ja, lokale Actions sind sicher auch möglich, ganz ohne Skript.

Ich würde nicht ausschließlich die Cloud dafür verwenden, das wäre störungsanfällig.

Ich hebe das gesuchte Skript hier nicht auf die Schnelle gefunden und klebe es mal hier ein:

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});
          }
        }
      }
    }
  }
)

Wenn kein MQTT genutzt wird, kann das Skript reduziert werden. Bei mir dient es u.a. zur Rollladensteuerung. Auch die Dauer der Tastendrücke brauchst du vermutlich nicht. Bei Bedarf kann ich es auf deinen Bedarf reduzieren, falls du es nicht schaffen solltest.

Frage bei Bedarf einfach nach!

Prinzip:

Eventhandler schreiben, abhängig von der Button Id passendes HTTP GET senden - oder MQTT Nachricht, wenn du MQTT verwendest.

Ich habe ein konfigurierbares Skript zum i4 hier irgendwo veröffentlicht, das aber mehr kann, als du es brauchst.

Ich schaue mal, ob ich es hier finde.

funkenwerner

Danke für die Aufklärung. Ich weiß nicht, ob ich mir das merken werde.

Dann ist vermutlich meine erste Frage oben irgendwie beantwortet. Das Thermostat ist vermutlich eine Kopplung Sensor - Aktor.

Das werde ich nicht testen, weil ich nichts davon halte, eine Temperaturregelung per Cloud zu implementieren.

Die Frage nach dem Aktor bleibt noch offen.

Ich habe bisher kein wesentliches Problem mit meinen TRV.

Zu 1.1 a) Ich nutze derzeit 4 TRV.

zu 1.1.b) Den ersten TRV seit etwa 2022.02.?? - das genaue Datum weiß ich nicht, wozu auch? Die anderen habe ich danach sukzessive eingesetzt, ab ca. 2022.04.??.

zu 1.1.c) Seitdem laufen sie durch, nur manchmal ein reboot, wenn ich mit meinem selbst erstellten Dashboard experimentierte. Vielleicht fiel mal eine Kommunikation temporär aus, aber nie lange oder gar dauerhaft - nicht reproduzierbar.

zu 1.2 FRITZ!box 7590, alten TP-Link AP, ein Ubiquiti UniFi 6 Lite Access Point, U6-LITE, ein etwas älterer Ubiquity AP, der sich in der App als UBNT mitteilt (genauere Bezeichnung suche ich jetzt nicht)
Ich nutze ausschließlich für den Außenbereich einen alten Repeater, ohne Mesh.

zu 1.3 Nur über Accesspoints bzw. WLAN des Routers, kein Mesh. Meine AP sind allesamt per LAN angebunden.

zu 1.4 Node RED, Android App "MQTT dash", Amazon Echo - kein fertiger Assistent

zu 1.5 MQTT V3.1.1 (mosquitto), kein CoIoT

zu 1.6 ca. 5m zum AP

zu 1.7 Grundsätzlich alle Server und IoT Geräte nur statische IP-Adressen auf den Geräten

Hmm, ob das wirklich weiterhelfen kann?

Ich finde es nicht verwunderlich, wenn ein Akku betriebenes Gerät in der Kommunikation mitunter träge reagiert. Aber Trägheit ist hier wohl nicht das Problem.

Hmm, der Plug S ist ja kein Thermostat. Du schaltest also einen Thermostat irgendwie ein und aus.

Hierzu weitere Fragen:

1. Was ist das für ein Thermostat?
2. Wie schaltet der Thermostat den Plug S, per URL/Webhook?
3. Setzt du irgendwelche Assistentensysteme ein (Homematic, ioBroker, openHAB, ...)? Vermutlich nicht
4. Bist du gewillt, bei Bedarf ein zentrales System zu verwenden, bspw. auf einem Raspberry Pi?
5. Hast du eine gewisse Affinität zum programmieren?

(Ich kenne kein Hamburgermenu.)

Ich verwende Node RED und mehr auf einem Raspberry Pi. Das Dashboard implementiere und anpasse ich selbst per Node RED. Dies bietet mir die gewünschte Flexibilität.

Nachteil: Ich muss dafür programmieren, was ich allerdings nicht ungerne tue.

Ich setze gegenwärtig neben einigen TRV drei Shelly 1 mit AddOn, Temperatursensor und purem Motorantrieb zum öffnen/schließen des Ventils am Heizkörper ein.

Die Regelung erfolgt per Node RED auf einem Raspberry Pi. Vermutlich betreibst du derzeit so etwas nicht.

Zukünftig will ich die Shelly 1 durch Shelly Plus 1 (zweite Generation, mit AddOn) ersetzen, damit ich die Temperaturregelung direkt auf den Geräten per Skripte implementieren kann.

Die Steuerung einer temporären Temperaturänderung nehme ich per Node RED vor. Handhabung per Dashboard - hier ginge mit MQTT auch die richtig gute Android App "MQTT dash".

Ich würde zum einstellen einer (temporären) Zieltemperatur (Basistemperatur?) keine Cloud verwenden, weil zu wenig ausfallsicher.

<-- Dashboardausschnitt:

Der hier wesentliche Teil ist der Schalter hinter "duschen oder baden", die Dauer (10 min) und die Zieltemperatur (22 °C) darunter.

Der Ausschnitt zeigt die Steuerung eines Shelly TRV.

Per Sprachassistent kann ich die temporäre Zieltemperaturänderung derzeit nicht steuern.

Es ist per Node zwar möglich, bspw. Alexa Sprachanweisungen zu verarbeiten, dies habe ich nach Tests aber gelassen, weil ich es nicht schaffte, es ohne root Anmeldung zu implementieren - und es war mir letztlich nicht wichtig genug.

Wenn dir so etwas zusagt und du bereit bist, mehr an Geld und insbesondere Zeit zu investieren, kann ich dir vielleicht weiterhelfen.

Afaik bietet Allterco die Shellies der zweiten Generation seit 2021 an. Ich setze diese erst seit ca. Mitte 2022 ein. Ich hatte mit diesen neueren Shellies nie Probleme, weder mit den Plus 1, noch mit den Plus 2PM (Rollladensteuerungen), noch mit den Pro 2 PM (bisher nur Skriptentwicklungen und Tests). Ich nutze für meine neuen Motor betriebenen Rollläden auch 3 Shelly 2.5, weil ich diese noch liegen hatte (Kauf vor Erscheinen der zweiten Generation).

Die Plus/Pro Geräte beinhalten als Mikrocontroller einen ESP32, der erheblich mehr Ressourcen beinhaltet und auch mehr Performance bietet als der ESP 8266, welcher in den Geräten der ersten Generation werkelt.

Mit den Geräten der zweiten Generation lassen sich

• optional Skripte verwenden, wodurch es wesentlich mehr Möglichkeiten zur Implementation von gewünschtem Verhalten gibt, insbesondere direkt auf dem Gerät und damit i.d.R. ausfallsicherer,
• u.a. MQTT und die Cloud zugleich verwenden - MQTT für die Kommunikation im lokalen Netz, Cloud für Szenen, Zugriff per Internet, bequemer Einsatz eines Sprachassistenten (Alexa und Co.)

Die erste Generation wird vermutlich nicht mehr sehr lange per Firmware Updates unterstützt.

Die Firmware der zweiten Generation lässt sich neueren Entwicklungen in der IoT Kommunikation viel besser anpassen. Die erste Generation wird voraussichtlich hierfür keine Upgrades erhalten.

Imho spricht bei Neukauf nichts für die alten Shelly 2.5 - außer evtl. Nostalgie.

Vielleicht wäre ein "m5stack" für dich geeignet.

Ich habe kein solches Gerät, aber ein Freund zeigte mir ein m5stack und berichtete mir, er könne inzwischen etwas damit anfangen.

Das m5stack hat die benötigten Sensoren, zeigt die gemessenen Werte an, bietet afaik ein konfigurierbares oder programmierbares touch display.

Auch kann es bspw. per Arduino IDE programmiert werden.

Beide Posts nehme ich verwirrt wahr.

Juri Besovsky

1. Welcher Shelly Typ liegt vor? Offenbar kein TRV.
2. Was ist mit Basis gemeint? Die 5°C minimale Frostschutztemperatur? Diese kenne ich nur von den TRV.
3. Welcher "Button" ist gemeint?
4. Sollen "Sonderzeiten" Warmzeiten sein, zu denen eine Halle genutzt wird?
5. Was schaltet der Shelly, wenn es kein TRV ist?
6. Soll ausschließlich die Cloud eingesetzt werden? Dies hätte eine geringere Zuverlässigkeit zur Folge ...

Alles in allem sind deine Darlegungen wenig verständlich. Ich könnte allenfalls ein wenig aus der Abbildung gewagt interpretieren. Das wäre aber zu wage.

biberfamilie

Bist du an obiger Einrichtung (siehe Besovsky) beteiligt?

1. Welcher Thermostat bzw. welche Schaltung liegt vor?
2. Was ist eine "Grundtemperatur"?
3. Wenn ...A... Alexa bedeuten soll, dann solltest du auch "Alexa" schreiben. Wenn nicht, was soll ...A... dann sein?

Ich habe vielleicht etwas ähnliches per Node RED implementiert - für <einstellbare Dauer> <einstellbare Zieltemperatur> einstellen, danach wieder vorherige Zieltemperatur.

Ich könnte aber allenfalls auf dein/euer Vorhaben eingehen, wenn obige Fragen von dir/euch geklärt würden.

Zitat

Prüfe bitte mal die Uptime durch Statusabfrage.

Ich vermute der Shelly rebootet durch induktive Beeinflussung.

Du solltest den Tipp von 66er mal umsetzen.

Hast du zwischen I und O des Shelly einen RC Snubber gesetzt?

Wenn nicht, könnte eine Spannungsspitze durch das Schalten den Shelly aus dem Tritt bringen - ohne ein reboot.

Das Auftreten des Problems immer um 6:00 Uhr spricht zwar nicht für diese Ursache, es gibt aber manchmal solche Zufälle.

Das Abschalten der Pumpe ist dann ggf. die kritische Aktion, also evtl. um 23:00 Uhr.

Ereignen sich evtl. zeitgleich andere Schaltvorgänge?

Für mein Verständnis:

Zitat von T-Buddy

Ich habe lediglich die Zeiten im Zeitplan häufiger angepaßt.

Du hast vermutlich die Anzahl an Zeitplanaktionen beibehalten und die Zeiten der Aktionen, also deren Abstände, verändert. Richtig?

Hast du vielleicht einen Timer für automatisches Ein- bzw. Ausschalten eingestellt?

Der TE schrieb:

Zitat

Habe schon einige Shelly S bei mir eingebunden und die funktionieren auch.

Das hatte ich als "Shellys" interpretiert. Tippfehler sind ja nicht selten.

DIYROLLY

Jo, ok, verstanden und erstmal akzeptiert. Ich täte trotzdem L an L und N an N anschließen, wenn es sich um einen fest zu installierenden Shelly handelt. ...

Da fällt mir auf, dass der TE evtl. Shelly Plug S meinte, als er von "Shelly S" schrieb. Wenn dem so ist, verwundert es nicht, dass er vom Anschließen noch unbeleckt ist.

uwe60rtg

Deine Darlegungen/Fragen zeigen, dass du keine erforderlichen oder zumindest hilfreichen Kenntnisse in der Elektrotechnik hast.

Zitat

Habe schon einige Shelly S bei mir eingebunden und die funktionieren auch.

Das verwundert mich, weil du dabei bereits grundlegendste Kenntnisse hast anwenden müssen.

Offenbar fehlen dir Grundkenntnisse in der Beschaltung der Shellies 2.5. Warum eigentlich die alten 2.5 (nagelneu) und nicht die zweite Generation Plus 2PM?

Die bisherigen Hinweise enthalten hilfreiche Informationen. Diese sind aber für dich nur dann hilfreich, wenn du sie verarbeiten kannst.

Falls du in deiner Umgebung jemanden kennst, der/die sich mit Shellies auskennt, solltest du dessen/deren Hilfe in Anspruch nehmen.

Ob dein Elektriker bereit ist, Shellies einzubauen, erscheint mir noch offen.

Meine Empfehlung:

Zitat von DIYROLLY

Zur Einbindung vor dem Einbau, nutze ich bei Shellys für 230V, ein 230V Kabel mit Eurostecker.

Nur L und N als Anschluß nutzen.

In die Nähe vom Router einbinden, Update durchführen, benennen und einstellen, beschriften.

Nicht der Router ist entscheidend sondern der WLAN-Accesspoint, welcher u.a. im sog. Router stecken kann.

Beispiel ist eine FRITZ!box: Diese enthält typischerweise einen Router, einen deaktivierbaren WLAN-Accesspoint, einen LAN-Switch und ggf. ein DSL-Modem.

Es kann aber auch ein reiner Accesspoint sein, der sich in der Nähe des Shelly-Einsatzortes befindet.

Der Hinweis, besser einen Fachmann zu beauftragen, erfolgte bereits. Falls du trotzdem selbst aktiv sein willst, folgende Hinweise von mir:

Zum Anschluss per Stecker an einer Steckdose, wie es DIYROLLY und auch ich gerne praktizieren, brauchst du für sorgfältiges Vorgehen wenigstens einen Phasenprüfer, um festzustellen, wo an der Steckdose die Phase (=Außenleiter) angeschlossen ist.

Und du solltest am Stecker den Stift, der zur L-Klemme des Shelly führt, entsprechend beschriften, evtl. auch abwischbar an der hierfür temporär verwendeten Steckdose. Stecker passend in Steckdose zu stecken, sollte sich von selbst verstehen.

Sobald du den temporär versorgten Shelly per WLAN (per Smartphone, Tablet, Notebook, ... verbinden - im Web-Browser: IP-Adresse 192.168.33.1) erreichst, solltest du dich zunächst mit den WLAN-Konfigurationspunkten vertraut machen, evtl. mit Hilfe. Manche mögen statt Browser die Shelly-App einsetzen, aber den Shelly internen Webserver zu verwenden, ist im Zweifelsfalle zuverlässiger.

Danach magst du, oder hoffentlich ein Elektriker, den Shelly wie gewünscht anschließen und den Rest konfigurieren. Hierfür gibt es in diesem Forum viele Hinweise, die beiliegende Beschreibung gibt aber auch bereits einiges her.

Schließlich könntest du später hier gezielte Fragen stellen oder bereits beantwortet finden.

Viel Erfolg

Vorsicht!

Wenn eine solche Einstellung möglichst sicher funktionieren soll, warne ich vor der Verwendung einer Cloud bzw. eines externen Assistenten.

Wenn ein externer Assistent (bspw. Cloud) ausfällt oder fehlerhaft arbeitet, ist die Zuverlässigkeit dahin.

Deshalb implementiere ich Aktionen, die möglichst funktionssicher/ausfalltolerant arbeiten sollen, so nahe wie möglich am Gerät (Aktor / Sensor).

Gimmicks, die nur schön oder angenehm sind, sind auch in einem externen Assistenten brauchbar aufgehoben.

Aus diesen Gründen lasse ich auch Datenaufzeichnungen zu Hause speichern, was aber weniger zwingend erscheint, weil solche Speicherungen i.d.R. keine Funktionssicherheit herstellen.

Das ist selbstverständlich nur ein Hinweis.

Devil Die interne Temperatur wird wohl nicht angezeigt?

Afaik messen die ESP32 die Chiptemperatur. Ich dachte, dass dies auf der WebUI angezeigt würde, was ich jetzt nicht bestätigen kann.

Schade