Beiträge von eiche

Ok, die Szene mag funktionieren. Dabei kann ich nicht mitreden, da ich die Cloud wegen zu geringer Funktionssicherheit hierfür nicht nutze.

Frage: Was soll der TE tun, wenn die Cloud ausfällt ,,, oder der Internetzugriff ...?

Devil

Ja, verstanden und akzeptiert.

Ich habe versucht, die Problematik bei funktional grundlegenden Steuerungen per Cloud anzudeuten. Dies erscheint mir unabhängig von der Anzahl an zu steuernden Geräten.

Und mit einem Shelly Plus ließe sich die gewünschte Funktionalität ohne zusätzliche Hardware/Software implementieren, autark und weitgehend ausfallsicher.

Die Cloud mag dann zusätzliche Optionen bieten, die aber die grundlegende Funktionssicherheit nicht bereitstellen müssten.

Ich fand soeben in der mJS Library eine Vorlage für eine zyklische Schrittkette namens "cycle-switch.js", nutzbar in Shelly Plus Geräten.

Zitat aus der Library zu diesem Skript:

Zitat

Configurable Cycle switch

Replicate Cycle switch feature from Gen1 devices. Allows for custom list of operations to cycle through.

Hm, wenn daran etwas verwirrend ist, dann bedauere ich dies. Zugleich bin ich gerne bereit, auf Fragen hierzu einzugehen oder Fehlernachweise entgegenzunehmen.

Eine fertige Lösung kann ich nicht anbieten, weil die Rahmenbedingungen hierfür noch nicht hinreichend dargelegt sind.

Vielleicht gibt es eine Möglichkeit für eine Implementation in der Cloud, aber die Cloud basierten "Programmiermöglichkeiten" erscheinen mir hierfür nicht flexibel genug - ich mag mich aber irren.

Hier täte das Prinzip der Schrittkette greifen.

Ein paar Bemerkungen:

1. Ich täte für grundlegende Haussteuerungen nicht die Cloud verwenden, zu wenig ausfallsicher.
2. Ein Shelly der zweiten Generation (Shelly Plus ...) bietet erheblich mehr Flexibilität als einer der ersten Generation.
   Hiermit ließe sich die Schrittkette per Skript implementieren. Der SW Eingang des Shelly wäre hierfür auf "detached" zu konfigurieren, damit er sich nicht am Skript vorbei auf Schaltzustände auswirkt.
3. Zu einem Shelly der ersten Generation, wie einem Shelly 2.5, würde ich per Node RED Flow geeignete Kommunikationsadapter erstellen, welche die Implementation einer Schrittkette ermöglichen.
4. Mit fertigen Assistenten (ioBroker, HomeAssistent, openHAB, Homematic) gelingt so etwas vermutlich auch. Ich nutze so etwas nicht und brauche diese auch nicht.

Prinzip der Schrittkette:

In einer Statusvariablen wird der aktuelle Status gespeichert. Mit jeder Betätigung eines Sensors, hier Schalter oder Taster, wird die dem Status zugeordnete Aktion ausgeführt/angestoßen und der Status auf einen Nachfolgewert gesetzt. So wird nach jeder Betätigung des Schalters ... ein neuer Status eingenommen, welchem eine neue Aktion zugeordnet ist.

Im einfachsten Fall sind die Werte für den Status natürliche Zahlen 1, 2, 3, ,,,

Die Werte des Status muss eine zirkulare Folge bilden, bspw. 1, 2, 3, 1, 2, 3, 1, 2, ...

... oder die SSD ist mit dampfbetriebenem Generator ausgestattet.

Ich setze voraus, dass du mit Jalousie keinen Rollladen meinst.

Vermutlich wird vom Shelly zur zeitlichen Kalibrierung die ansteigende Leistung bei vom Motor aufgebrachtem ansteigendem Drehmoment erfasst. Ist dieses Drehmoment recht gering, wird evtl. die Leistung zu klein sein - eine Jalousie ist i.d.R. ja erheblich leichter als ein Rollladen. Da ich keine elektrisch betriebene Jalousie habe, habe ich auch keine Erfahrung hierzu.

Eine parallel zum Jalousiemotor geschaltete Zusatzlast könnte evtl. die geschaltete Leistung hinreichend erhöhen.

RobK_ Ich setze mal einen Shelly Plus 1 (PM) mit Plus Addon voraus.

Folgendes ungetestet, also nur eine Idee:

Wenn du auch gerne mal selbst lötest, kannst du auch mit Hilfe der Referenzspannung eine Konstantstromquelle (kurz Stromquelle) zusammenstellen - wie von thgoebel angedeutet.

Ich kenne von früher eine einfache Schaltung mit bipolarem pnp-Transistor, Referenzspannung zwischen Basis und hier Vcc+ und den Quellenstrom bestimmenden Widerstand im Emitterkreis.

Mit einem Feldeffekttransistor sollte dies auch gelingen, wenn man will.

Der Emitterwiderstand ist dann so zu dimensionieren, dass die Stromstärke durch den PT100(0) den gewünschten Spannungsmessbereich ergibt.

Per Skript ließe sich bei Bedarf der Spannungsmessbereich softwaremäßig anpassen bzw. kalibrieren ... Dies würde auch die Möglichkeit bieten, einen npn-Transistor einzusetzen -> fallende Spannung bei steigender Temperatur.

Wenn du keine selbstgelötete Elektronik magst, ist selbstverständlich der Hinweis von Frank Berges sehr gut.

Die values sind HTML Kommentare.

Diese haben in JSON Texten nichts zu suchen.

Sorry, mit einem Plug S lässt sich kein Ventil steuern. Da muss es noch einen vom Plug S geschalteten Antrieb geben, welcher das Ventil öffnet und schließt.

Zitat

Deswegen wird das auch über NodeRed nicht laufen, zumindest lokal nicht.

Doch, das gelingt problemlos. Genau das habe ich im Experimentierstatus getan. Ich nutzte einen externen Sensor, einen Plug S und einen einfachen Stellantrieb zum öffnen (ein) und schließen (aus) des Ventils.

(Meine an dich wiederholt gestellte Frage gilt einem solchen Antrieb. Der Plug S besitzt ja keinen Antrieb.)

Später habe ich den Plug S und den externen Sensor gegen einen Shelly 1 mit Addon und Temperatursensor ersetzt.

Die Kommunikation läuft über MQTT. Die Temperatur regele ich per Node RED Flow. Selbstverständlich läuft diese Heizungsregelung im lokalen Netz und komplett ohne Cloud.

Und der von mir erstellte Flow kann viele Heizkörper mit jeweils obiger Ausstattung regeln, für jeden Shelly ist nur ein Eintrag in einem Konfigurationsknoten erforderlich, somit leicht erweiterbar oder änderbar.

Demnächst will ich die Shelly 1 mit Addon durch Shelly Plus 1 mit Addon ersetzen, weil ich dann die Regelung auf jedem dieser Shellies auch ohne Zentrale per Skript autark implementieren kann.

Zitat von biberfamilie

Bei unserer Haussteuerung ist es allerdings so, dass ein manueller Eingriff (egal ob BM, Lichststimmung, Thermostate...) die Programmierung übersteuert.

Aha, und das möchtest du auch für die Steuerung einer Raumheizung, wenn ich das nun richtig verstanden habe.

Ich fasse Node RED nicht als zusätzliche "Schnittstelle" auf. Zumindest dürfte ein Node RED Flow auf deinem Raspberry wesentlich zuverlässiger arbeiten als eine Szene oder ähnliches in der Cloud.

Und das, was du erreichen willst, ist in einem Node RED Flow sehr gut implementierbar, ok einen komplexen Zeitplan nutze ich nicht, nur Tag-Beginn und Tag-Ende.

Ich weiß noch immer nicht, was dein Aktor zum stellen des Ventils ist.

Deine Schlussfolgerung ist nicht belastbar.

Ich kenne weder die interne Beschaltung der Umwälzpumpe noch die des Stellmotors.

Ich habe 12V Hutschienen-Netzteile in Gebrauch, die in einem Radius von ca. 50 cm die WLAN-Verbindung von Shellies erheblich stören.

Vielleicht liegt bei dir ähnliches vor.

Hast du denn auch mal einen RC-Snubber zwischen I und O, also parallel zum Verbraucher, geschaltet?

Ein solcher Snubber kann sowohl die Relaiskontakte schonen als auch beim Abschalten Spannungsspitzen verkleinern.

Schaden kann ein RC-Snubber keinesfalls.

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.