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.
Wer viel misst, misst viel Mist.
Das ist in diesem Zusammenhang schlicht eine Ausrede.
Ich kenne einen solchen Spruch (ohne das Wort "viel") auch. Dieser ist aber ausschließlich in dem Sinne zu verstehen, dass man sich auch über das zu messende Signal und das Messgerät Gedanken machen sollte.
Zwischen zwei Außenleitern kann ich leicht die Spannung messen und hatte damit bisher keinerlei Probleme - noch nicht einmal beim ergründen einer bestehenden Installation.
Nun ja, dann könntest du gelegentlich darüber nachdenken, warum viele elektronische Bauteile eine gewisse Spannungsfestigkeit haben.
Und warum Leiterbahnen spannungsabhängig Abstände voneinander brauchen.
Vom ohmschen Gesetz mag ich fast nichts erwähnen. 
Ok, es gibt mitunter weniger konstruktive Beiträge. Hoffentlich fällt meiner nicht darunter. 
Zumindest wirst du inzwischen dazugelernt haben ...
Bei der Software implementierten Schwingungspaketsteuerung handelt es sich ja um eine PWM (pulsweitenmodulierte) Steuerung, da die Nulldurchgänge von einem Shelly nicht erfasst und eine Netzspannungsschwingung schon gar nicht synchron geschaltet werden kann. Das Synchronisieren, soll heißen schalten im Nulldurchgang, muss selbstverständlich das SSR übernehmen.
Eine PID-Regelung braucht es hier imho nicht.
Ich täte mit der Anstiegsgeschwindigkeit der gemessenen Temperatur experimentieren. Auf Grund derer wäre die Reduktion der vom Shelly ausgegeben Pulsdauer je Schaltperiode (bspw. 60s) zu wählen.
Nach ersten Überlegungen sehe ich hierfür vier konfigurierbare Parameter.
Parameter 1 ergibt sich aus der installierten Elektrik.
Die anderen Parameter lassen sich durch Versuche vor Ort ermitteln.
Ich denke, das sollte gelingen.
Unter Umständen ließe sich auch eine Lookup Tabelle erstellen, welche an Hand der Temperaturdiff. das Puls/Pausenverhältnis liefert.
Edit:
Ich besitze keine solche Folie. Ansonsten könnte ich an Hand einer Heizfolie eine solche Temperaturregelung entwickeln - mit genügend Zeitreserve und Muße.
Danke, dies erscheint mir sehr preisgünstig.
Ein Shelly Plus 1 PM kann bei 12V Versorgung keine Leistungsmessung (Stromstärkemessung) vornehmen. Dies gelingt ausschließlich mit den üblichen 230V.
Zur Ansteuerung der Heizelemente kann ich auf die Schnelle nichts sagen, da ich keine Einzelheiten kenne.
Ich werde mal deinem Link folgen ...
Eine Schwingungspaketsteuerung für träge Systeme wie Heizungen ist jedenfalls technisch zweckmäßig.
Edit:
Es bleibt die Frage, was ein hierfür qualifizierter Elektriker dazu sagen kann.
Zur Programmierung sollte ich etwas beitragen können, bspw. dies:
Ein Schedule Job ruft alle 60s (o.ä.) eine Skriptfunktion "doctrl()" auf.
"doctrl()" prüft, ob überhaupt geheizt werden soll. Wenn ja wird irgendwie auf der Grundlage der gemessenen Temperatur und der Solltemperatur berechnet, wie lange innerhalb der 60s Periode die Heizfolien eingeschaltet werden sollen. Danach wird eingeschaltet und ein Timer mit der passenden Einschaltdauer gestartet, an deren Ende ausgeschaltet wird.
Zur Sicherheit noch ein zweiter Schedule Job, der in jeder 59. Sekunde einer Minute ausschaltet.
Für Feinheiten wäre die vorhandene bzw. vom Elektriker empfohlene Ansteuerelekronik wissenswert.
Wie ein Shelly der zweiten Generation, bspw. ein Shelly Plus 1 mit 12V betrieben wird, ist nach meiner bisherigen Erfahrung auf dem Shelly-Gehäuse dargestellt.
Dazu braucht man dann jeweils ein 12V Netzteil oder eine (kleine) parallele 12 V Infrastruktur.
Ja, ein Skript wäre ein Programm, welches auf dem Shelly abgearbeitet wird - hier in einem Subset von JavaScript.
Ich habe so etwas erstellt zum regeln meiner alten Heizkörper, incl. Zeitplansteuerungen für bis zu 8 Wochenplänen.
Bzgl. elektrische Kommunikation wird es bedeutungsvoll sein, wo du die Sensoren platzieren kannst/willst.
Btw, meine alten Shelly 1 (1. Gen.) mit AddOn und der Regelung per Node-RED auf einem Raspberry Pi arbeiten zuverlässiger als die ebenfalls eingesetzten TRV.
Ich täte somit zwar eine direkt am Ort laufende Regelung bevorzugen (s.o. mit Shelly Plus 1), WLAN aber nicht ausschließen.
Die von dir erwähnte Steuerung der Heizungsfolien arbeiten offenbar per Schwingungspaketen (eine Schwingungspaketsteuerung). Möglicherweise beinhalten diese bereits Schaltelemente, die bei Nulldurchgang des Wechselstroms schalten. Das wäre ebenso zu prüfen wie die vorgesehene Ansteuerung der Folien (+ interner Elektronik).
Edit:
Zu den Halbleiter-Relais, auch als Solid State Relais (SSR) bekannt.
Es gibt solche SSR, die im Nulldurchgang schalten, auch mit davorliegenden Optokopplern zur galvanischen Trennung. Was solche SSR an Stromstärken dauerhaft schalten können, weiß ich derzeit nicht. Eine solche Frage können sicher DIYROLLY und thgoebel beantworten.
Zur Temperaturregelung:
Keinesfalls Shelly Plus H&T einsetzen - allenfalls mit dauerhafter USB-Versorgung, trotzdem suboptimal.
Besser sind die AddOns an Shelly (Plus) 1.
Schließlich ist noch unklar, wo die Temperaturregelung implementiert werden soll.
Am besten wären Shelly Plus 1 mit AddOn und 12V Stromversorgung.
Darin könnten auch die Temperaturregelungen per Skripte untergebracht werden.
Vermutlich ist dein Gewünschtes per MQTT möglich.
Ich nutze diesen Kanal in Node-RED, aber nicht zur Konfiguration eines Shelly.
Meine Empfehlung:
Experimentiere mit sys.getconfig! Vielleicht ergeben sich so Erkenntnisse für sys.setconfig.
Edit:
Tun es die beiden von dir aufgeführten MQTT messages/payloads nicht?
Btw., der src-Wert dient afaik ausschließlich für eine Antwort des Shelly und wird im Antwort-Topic verwendet.
Es erscheint somit zweckmäßig, eine Nachricht zu diesem Antwort-Topic zu abonnieren, um die Reaktion des Shelly auswerten zu können.
In deinen messages/payloads wäre das Antwort-Topic "user_1/rpc".
Edit 2:
Notfalls könntest du die gewünschte Funktionalität per Skript implementieren.
Ein MQTT Subscriber (callback Funktion) nimmt eine simple Payload entgegen (bspw. 1 oder 2 als Modus-Identifier) und ruft die RPC per Shelly.call() auf.
Dies täte die MQTT-Kommunikation verschlanken und so einfacher gestalten.
I would also like to mention that a position measurement or level measurement is possible with an ESP32 board, HC-SR04 and Tasmota.
The biggest problem, in my opinion, is the high humidity in the measuring room.
I implemented this with Tasmota32 and an application written in Berry.
Hallo Michael,
vielen Dank. Das wollte ich tatsächlich irgendwann noch nachholen. Nun kann ich deine Ergänzung nutzen. 
Ich habe für meinen neuen Schuppen folgende Lichtschaltsteuerung implementiert.
Danke für die Hinweise von ostfriese. Auf Grund seiner Hinweise liegt das Skript nun komplett vor.
Anforderungen
Eine Lampe soll per Bewegungsmelder eingeschaltet werden, wenn die Lampe aus ist.
Der Bewegungsmelder soll per HTTP mit einem Shelly Plus 1 kommunizieren und dabei die Einschaltdauer per GET liefern.
Sobald per Schalter/Taster am Plus 1 Eingang die Lampe eingeschaltet wird, soll die Einschaltdauer deaktiviert werden, damit die Lampe eingeschaltet bleibt.
Dies löste ich mit Hilfe eines Shelly Motion (Gen. 1), einem Shelly Plus 1 und einem kleinen Skript auf dem Plus 1.
Das Skript:
let on = null; // output status
let th = null; // timer handle
function send_response(response, body) {
response.code = 200;
response.body = body;
response.send();
}
HTTPServer.registerEndpoint('on',
function (request, response) {
send_response(response, "OK");
if (on!==true) {
Shelly.call("Switch.set", {'id': 0, 'on': true});
if (request.query.length > 0) {
let dur = JSON.parse(request.query);
print(dur);
if(!isNaN(dur) && dur>0) {
th = Timer.set(Math.floor(1000*dur), false,
function () {
Shelly.call("Switch.set", {'id': 0, 'on': false});
}
);
}
}
}
}
);
Shelly.addEventHandler(function(e) {
on = e.info.state;
if (e.component==="input:0") {
Timer.clear(th);
}
});Auf dem Bewegungsmelder wird folgende Action konfiguriert:
http://<IP-Adresse des Plus 1>/script/<Skript Id>/on?<Dauer in s>Als Skript Id kommt typischerweise die 1 zum Zuge, falls auf dem Shelly kein anderes Skript abgelegt wurde.
Dies ist im Zweifelsfalle zu prüfen.
Es sind als Einschaltdauer auch Werte mit Nachkommastellen möglich.
Wenn in der Action des Motion die Einschaltdauer fehlt, bleibt die Lampe eingeschaltet.
Anwendungsfälle
Vielleicht kann dies für andere nützlich sein.
Die Heizungsregelung lässt sich leicht per Skript implementieren, aber ...
Der Bewegungsmelder dürfte kein dauerhaftes Aktivsignal liefern, solange er eine Bewegung erkennt.
Außerdem müsste sich dann jemand wiederholt bewegen, wenn geheizt werden soll.
Etwa zielführend wäre folgende Lösung:
Eingesetzt wird ein Skript, darin die Heizungsregelung, ein Eventhandler und ein Timer.
Sobald eine Bewegung erkannt wird - Eingang ist aktiv - wird dies im Skript wie folgt verarbeitet.
2. und 3. bewirkt eine Retriggerung des Timers mit jeder Bewegungserkennung.
Wenn der Timer abgelaufen ist, wird die Heizung ausgeschaltet und die Regelung deaktiviert.
Ein Eventhandler zur Regelung prüft die globale Variable Ctrl. Nur wenn diese true beinhaltet, wird der vom Sensor gelieferte Temperaturwert zur Regelung verarbeitet.
Ctrl muss demzufolge mit false initialisiert werden.
Falls du selbst mit dem scripting nicht zurechtkommen solltest, wirst du dafür geeigneten Code brauchen.
Die obige Idee sollte aber nutzbar sein.
Die Dauer des Timers ist nach deinen Bedürfnissen zu wählen.
Sowohl Temperaturschwellen (Hysterese) als auch Timerdauer könnten auch konfigurierbar gestaltet werden.
Ich danke euch.
Das ist zwar schade, ich werde aber irgendwann eine alternative Lösung finden.
Der betroffene Motion arbeitet inzwischen wieder.
Ich habe einen Motion (1. Gen.) im Außenbereich montiert. Andere Motions arbeiten unter Dach.
Ich fand nirgendwo einen Hinweis, demzufolge ein solcher Motion ausschließlich unter Dach einzusetzen sei.
Nach einem Regen leuchtet er durchgängig blau und ist nicht mehr erreichbar. Ich arbeite daran.
Meine Frage:
Sollte ein solcher Motion besser nicht Regen ausgesetzt sein?
jjk-2023 Nachfrage: Ist der Thermostat ein separates Gerät oder nutzt du den Shelly Plus 1 als Thermostat, was durchaus möglich ist.
Im beiden Fällen ließe sich jegliche gewünschte Funktionalität per Skript implementieren.
Nun sah ich, dass diese neue App auch Shelly Geräte der ersten Generation findet und zum Hinzufügen zur Cloud anbietet, auf welchen ich MQTT zur Kommunikation verwende. Ein Test ergab, dass nach wie vor bei solchen (älteren) Shelly nicht beides, MQTT und Cloud, nutzbar ist. Das "mal schnell" Hinzufügen eines MQTT Gerätes per App missfällt mir. Ok, ich muss wissen, das dies kontraproduktiv ist. Dies unterstützt jedoch nicht nur nicht den Anwender, es verleitet ihn dazu, es mal, vielleicht für Testzwecke, schnell zu tun. Das stufe ich als schwache Usability ein. Es ist durchaus möglich, die Konfiguration eines Shelly zu lesen ...
Fauwee Danke
Ich nutze ein Android Smartphone.
Inzwischen fand ich in der neuen App die Stelle, an welcher ein Gerät der Cloud hinzugefügt werden kann. Dazu muss man wissen, dass zuerst das Home Icon in der Fußleiste zu wählen ist. Danach in der Kopfleiste nach rechts zu "Entdeckt" scrollen. Ich sah schlicht die Aufteilung zwischen Kopf- und Fußleiste in der App nicht. Auf der Website selbst ist nach meinen Versuchen das Hinzufügen eines Gerätes nicht mehr möglich. Somit ist man hierfür auf eine Smartphone App angewiesen. Dies halte ich, die Cloud Website betreffend, für einen Rückschritt.
Ich freue mich aber, dass die neue App hierfür doch geeignet ist. 
Bisher hatte ich keine Probleme damit, ein neues Gerät (aktuell Shelly Plus 1) der Cloud hinzuzufügen. Nun finde ich den Pfad weder in der neuen App noch auf der Website control.shelly.cloud.
Ich kann zwar anscheinend ein Gerät hinzufügen, lande dann erzwungen in der Auswahl eines Raumes und ... komme nicht weiter, weil ich kein neues Gerät hinzufügen kann.
Der Shelly ist selbstverständlich mit der aktuellen Firmware ausgestattet und darauf die Cloud enabled.
Edit: Mir erscheint die Konstellation aus neuer Cloud, deren Website und der neuen App unausgegoren. Ich finde darin keine Möglichkeit, der Cloud ein neues Gerät hinzuzufügen. Selbst wenn ich per https://control.shelly.cloud ein Gerät hinzufügen will, bin ich genötigt, die Shelly App auf einem Smartphone (o.ä.) zu installieren. Dann wird jedoch die alte App installiert. Dort wird mir mitgeteilt, ich solle die neue App installieren.
Inzwischen konnte ich per alter App das Gerät per Angabe dessen IP-Adresse installieren. Dies war der einzige Weg, welcher mir nach meinen vielen Versuchen offenstand.
Das riecht nach Überforderung der/des Softwareentwicklers bzgl. Cloud und neuer App.
Mein Fazit: Die alte Shelly App bietet derzeit die einzige Möglichkeit, ein Gerät "zu Fuß" - und damit überhaupt - der Cloud hinzuzufügen.
Never change a running firmware - soll heißen:
Wenn man die Funktionalität einer Anlage nicht gefährden will, sollte man zum testen einen gleichen Shelly nutzen und die neue Firmware erst einmal damit ausgiebig testen.
Das ist zwar aufwändiger, verringert aber die Gefahr von Fehlfunktionen der Anlage bei einem Firmware Update/Upgrade.
Mit neuer Firmware steigt auch die Spannung bzgl. des neuen Verhaltens.
Nur mal so und in aller Freundschaft.
Auf diesen Schaltplan bin ich gespannt.