VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
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:
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.
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.
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.
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:
(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.