Beiträge von eiche

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

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.