Beiträge von eiche

Es gibt keine prellfreie mechanische Schalter oder Taster. Wenn ein Motörchen damit geschaltet wird, merkt man halt nichts davon. Elektronik ist dbzgl. erheblich schneller und sensibler. Gegen Prellverhalten habe ich in einem Shelly Plus 2 (gerade zur Hand) keine Konfiguration gefunden. Ich täte bei Prellproblemen versuchen, dies per Skript zu lösen - mit Entkopplung Input -> Output.

So etwas habe ich vor ca. 40 Jahren an meinem ersten Fädeltechnikcomputerchen zum letzten Mal gemacht. Schwierig ist das aber nicht.

Wenn ein Taster-/Schalterereignis eintrifft

1. Schalter-/Tasterzustand zwischenspeichern
2. ein wenig warten (Timer.set(...)) - vielleicht 50ms, kann getestet werden
3. Schalter/Taster abfragen
4. wenn gespeicherter Zustand = aktueller Zustand -> die gewünschte Aktion auslösen

Ich bin ein wenig überrascht, dass in der Konfiguration keine Entprell-Wartezeiten zu finden sind, hatte bisher aber nie Probleme mit so etwas. Ich setze allerdings keine speziellen Rollladenschalter/-taster ein.

sisos

Ich habe mit einem Shelly Plus 1 + Sensor Addon und Skript ein preisgünstiges Thermostat entwickelt, das autark arbeitet, zuverlässig und relativ preisgünstig ist.

Dieses Thermostat bietet auch Zeitpläne, in der Allterco Firmware und auch Unix Terminologie heißen diese Zeitpläne Schedule Jobs.

Zur Parametrierung setze ich gegenwärtig Node-RED + MQTT ein, es sollte aber auch ohne ein übergeordnetes System per HTTP GET und HTML-Seiten + AngularJS möglich sein, dies zu implementieren.

In einem anderen Projekt nutze ich solche HTML+AngularJS Dateien erfolgreich.

Ich kann dir bei Interesse gerne mein Skript und sonstiges zur Verfügung stellen. Allerdings ist meine Implementation bisher nicht für Umgebungen ohne Node-RED und MQTT angepasst.

Für das Shelly Plus 1 Thermostat habe ich Node-RED + MQTT nur für ein Dashboard bzw. die Kommunikation eingesetzt, Der Shelly regelt ansonsten ganz alleine.

Programmieren können ist hierfür hilfreich, falls du aber Zeit hast und ich den Kontext genau kenne, könnte ich dir evtl. eine fertige Lösung bieten.

Die Firmware der zweiten Shelly Generation bietet sehr viele Möglichkeiten ...

Meine Lösung kommt ganz ohne Cloud aus und ist per VPN aus der Ferne nutzbar.

BTW, die H&T Plus (also 2. Generation) sind für eine feinfühlige Heizungsregelung imho ungeeignet, weil die Hysterese mindestens +-0,5°C beträgt und der Shelly relativ selten seine Werte überträgt.

Für den Fall, dass du zu Tuya (Smart Life ...) neigen solltest, könnte auch eine Tasmota32 Firmware interessant sein. Mit Tuya habe ich aber keine Erfahrungen.

Ich schreibe dies hier nur, um aufzuzeigen, dass es Alternativen zu Konsum-Lösungen mit Anpassungsfragen gibt.

Man muss meine Ideen nicht für interessant halten. Sie haben aber ihre Berechtigung und sie sind sehr flexibel nutzbar.

Klar und gut so.

Ich möchte noch erwähnen, dass diese, von mir kurz dargelegten Dinge auch einen Cloud freien Betrieb unterstützen, weil sie alles, was die Cloud zur Verfügung stellt auch können - und oft besser.

Nachteil: Sie kosten zur Einarbeitung Zeit und mitunter Vorkenntnisse.

Axel_zwo

• Im Bereich IoT ist MQTT ein sehr nützliches Kommunikationsprotokoll, weil es schlank ist, temporär ausgefallene Geräte die Kommunikation insgesamt nicht beeinträchtigen und es leicht zu nutzen ist.
• Node-RED ist eine relativ leicht verständliche Entwicklungsumgebung mit grafischen Elementen zwecks Programmierung in JavaScript, die mit verschiedenen Protokollen ausgestattet ist, u.a. MQTT und u.a. Möglichkeiten für Anwendung spezifische Dashboards bietet.
• InfluxDB ist ein Zeitreihendatenbanksystem, mit dem man auf relativ einfache Weise Messwerte und Zustände mit Zeitinformationen speichern kann, hierzu gibt es auch Nodes zu Node-RED.
• Grafana ist ein sehr guter Service zur Darstellung von zeitabhängigen Verläufen in Form von Funktionsgrafiken (Kurven), das die Daten bspw. aus InfluxDB bezieht.

Und schließlich läuft das alles sehr zügig auf einem Raspberry 4 (ein 3er tut's auch).

Tja, es könnte für dich sehr interessant sein.

Edit: Zu HTML kann ich dir AngularJS empfehlen. Viele Infos gibt es bei https://www.w3schools.com/

Ach ja ... und alle diese 4 Dinge gibt es legal kostenfrei im Netz (im Fall von MQTT ist es ein sog. MQTT Broker als Dienst, bspw. Mosquitto).

Nein, aber danke für diese Illustration und deine Informationen.

Ich meinte das Fenster, aus welchem du Alexa werfen wirst.

Ich nutze schon länger Node-RED Dashboards und in letzter Zeit verstärkt den template-ui Knoten, nachdem ich mich eingehender mit AngularJS beschäftigt habe. Damit lassen sich Dashboards noch besser nach Anwenderwünschen gestalten. AngularJS brachte mich auch dazu, einzelne HTML-Dateien (ohne irgendeine IoT-Zentrale) zusammenzustellen, mit Hilfe derer die Kommunikation mit einem Shelly Generation 2 + Skript möglich ist.

Btw, bis auf weiteres interessiert mich dann die Lokation deines Fensters.

@dekat win prima Ergänzung

Axel_zwo

Wenn VPN möglich ist, würde ich auf eine Cloud-Lösung verzichten, weil die nur dann funktioniert, wenn die Cloud verfügbar ist und funktioniert.

Ok, die Cloud bietet jemandem, der nicht programmieren will, ein paar brauchbare Lösungen an. Da du aber nicht vor dem Programmieren zurückschreckst, empfehle ich dir die Cloud-Lösung nicht.

In dieser erwähnten HTML-Datei kannst du selbstverständlich auch das ad hoc Schalten der Ausgänge unterbringen, was besonders einfach geht.

Ich verwende die Shelly-App fast nie.

Ich setze auf Node-RED und MQTT ergänzt durch InfluxDB und Grafana.

Die Festlegung der Vorwahltemperatur geht aber auch ohne solche Systeme und ausschließlich per HTTP GET. Dazu kann man sich eine HTML-Datei erstellen, welche in einem Eingabefeld diesen Wert aufnimmt und nach einem Klick auf einen Button oder einen Link diesen Wert an den Shelly sendet.

Methode "Script.Eval", in params die aufzurufende selbst erstellte Funktion mit dem eingegebenen Wert als Parameter. Diese deine Funktion muss halt den Parameter irgendwo ablegen, am besten sowohl in einer Variablen für den synchronen Zugriff als auch im KVS zur persistenten Speicherung. Mit der HTML-Datei hast du dein Frontend.

Das Erfassen der aktuellen Zustände ohne ein übergeordnetes System kann ich derzeit nicht und weiß nicht, ob dies möglich ist.

Frage: Was bedeutet eine "Override-Steuerung"?

Ach so, damit ist sicher eine ad hoc Parametrierung gemeint bzw. das Öffnen bzw. Schließen des Ventils.

Ich halte inzwischen sehr viel von dieser Firmware und deren API. Sie bietet sehr viele Möglichkeiten zur eigenen spezifischen Verwendung abseits der üblichen Standardanwendungen.

Damit das Skript nach einem Reboot automatisch gestartet wird, musst du es nur "enablen" - Schiebeschalter-Symbol rechts.

Sobald in Abständen von ca. 1 Minute die gemessenen Temperaturwerte eintreffen, kannst du diese jeweils einmalig verarbeiten lassen. Dann liegt das Timing in erster Linie am System, welches diese drei Ereignisse mitteilt. Vermutlich sollte das genügen, da die Temperaturen sich nicht schnell verändern dürften.

Willst du aber das Timing sekundengenau selbst festlegen, dann sind hierfür die schedule jobs bestens geeignet. In diesen können von dir festgelegte Funktionen deines Skript aufgerufen werden. In einer solchen Funktion kannst du eine Temperatur abfragen und speichern. Da hier in der Anzahl limitierte RPC erforderlich sind, empfehle ich dir, zu jeder Temperaturabfrage einen separaten schedule job und eine separate Funktion. Es genügt, wenn die schedule jobs jeweils 1 Sekunde auseinander liegend deine Funktionen aufrufen. In einem vierten schedule job lässt du dann die Verarbeitungsfunktion aufrufen, welche deinen Motor steuert. All dies geschieht dann einmal in jeder Minute.

Beispiele für die timespec Werte der schedule jobs:

0 * * * * * zum Abfragen der ersten Temperatur + speichern
1 * * * * * zum Abfragen der zweiten Temperatur + speichern
2 * * * * * zum Abfragen der dritten Temperatur + speichern
3 * * * * * zur Verarbeitung der Temperaturwerte und Steuerung des Motors
Du kannst die Sekundenabstände selbstverständlich auch größer wählen.

siehe hierzu auch https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

Ich habe in einem aktuellen Projekt solche schedule jobs verwendet und zum Anlegen solcher Jobs eine Webseite erstellt. Die passt zwar nicht zu deinem Projekt, dort kannst du dir aber mal ansehen, wie solche schedule jobs per HTTP GET angelegt werden können.

Edit:

Es ist auch möglich die schedule trigger mehrmals pro Minute zu nutzen. Dann verwendest du statt 0 bis 3 in den Sekunden */10 (in 10 Sekunden Abständen) oder bspw. */20 (in 20 Sekunden Abständen). Für die oben erwähnten schedule jobs müsste ich noch sorgfältig über passende timespec Werte nachdenken. Alternativ ließe sich nur ein solcher schedule job einsetzen und im Skript Timer verwenden.

Der Eventhandler ist keine Endlosschleife. Auch das Skript ist es nicht. So etwas gibt es in der Arduino Programmierung und heißt dort loop().

Teile eines solchen Skripts werden durch Ereignisse aufgerufen, wie bspw. deine anonyme Eventhandler Funktion innerhalb des Aufrufs von Shelly.addEventHandler().

Hierbei wird dem System (Firmware) mitgeteilt, welche Funktion aufzurufen ist, wenn ein Ereignis eintritt, wie bspw. das Messen einer Temperatur.

Anonym ist die Funktion deshalb, weil sie keinen Namen erhält. Es ginge auch anders:

function processData(event) {
    // process the imported event info
}

Shelly.addEventHandler(processData);

Diese Eventhandler Funktion ist nicht anonym, weil sie einen Namen erhält (processData).

Es ist wichtig, zu verstehen, dass ausschließlich Ereignisse die Abarbeitungen im Skript triggern müssen. Vermeide jegliches Warten per Schleife auf ein solches Eintreffen!

Andere Ereignisse können bspw. solche sein, die per Zeitplan, hier schedule job genannt, ausgelöst werden.

Das musst du jetzt noch nicht alles wissen oder genau verstehen. Es ist aber zweckmäßig, dass du schon einmal davon gelesen hast und nachsehen kannst, wenn du einen entsprechenden Fehler in dein Skript einbaust.

Falls du schon einmal Tasmota mit Rules verwenden haben solltest - für die Tasmota Rules gilt das Gleiche bzgl. Ereignissteuerung.

Edit:

Die Anweisungen im Skript werden mit dem Skript Start genau einmal abgearbeitet. Dies ist bspw. das Anlegen von Variablen/Objekten und insbesondere das Eintragen einer Eventhandler Funktion. Shelly.addEventHandler(...) ist eine solche Anweisung, die mit dem Start des Skripts ausgeführt wird und die veranlasst, dass beim Eintreffen eines Event die von dir gewünschte Funktion aufgerufen wird.

Ich bin ja ein Anhänger von Code reduzierenden Datenstrukturen und täte es wie folgt implementieren.

// Vor dem Eventhandler:
let Status = {
    Temp: [null, null, null]
    // und nach Bedarf weiteres
};

// Innerhalb des Eventhandlers:
let i = event.info; // Nur, damit der Quellcode eetwas kürzer wird.
if (i.event==="temperature_measurement") Status.Temp[i.id-100] = i.tC;

Du kannst in der Eventhandler-Funktion bspw. nach event.info.event==="temperature_measurement" selektieren. Dann ist die Reihenfolge weniger "wirr". Auch erhältst du so in regelmäßigen Abständen von ca. 1 Minute die Temperaturwerte. Mit temperature_change kommen nur Werte bei Temperaturänderung rein, was auch genutzt werden könnte, aber hier nicht erforderlich ist.

// Vor dem Eventhandler:
let Status = {
    Location1: {Temp:null}, // und mehr nach Bedarf
    Location2: {Temp:null}, // dito
    Location3: {Temp:null} // dito
};

// Innerhalb des Eventhandlers:
let i = event.info; // Nur, damit der Quellcode eetwas kürzer wird.
if (i.event==="temperature_measurement") {
    if (i.id===100) Status.Location1.Temp = i.tC
    else if(i.id===101) Status.Location2.Temp = i.tC
    else Status.Location3.Temp = i.tC;
// und weiteres bei Bedarf, evtl. Verarbeitungsfunktion aufrufen
}

Statt LocationX solltest du für deine Zwecke passende Namen wählen, auch müssen die LocationX keine Objekte sein. Wenn du darin nicht zusätzliches speichern willst, genügt es, dort direkt die Temperatur abzulegen. Dann wird der jeweilige Zugriff etwas kürzer.

Die Verarbeitung der Temperaturen (in Status) kann direkt im Eventhandler erfolgen oder später an anderer Stelle. Bei unmittelbarer Verarbeitung solltest du die Werte zuvor auf ungleich null prüfen lassen. Hier empfiehlt sich der Aufruf einer Verarbeitungsfunktion.

Solltest du noch ein Relais für 24V mit zwei Umschaltern, also 2 mal 3 Kontakten liegen haben oder günstig ergattern können, wäre dies zu empfehlen. Damit kannst die den gewünschten Betrieb realisieren.

Ich habe mal schnell bei Amazon nachgeschaut. Andere Händler täte ich auch abfragen wie Reichelt, Voelkner ...

Mit diesem Relais sollte dein Anliegen leicht erfüllbar sein.

Btw, mit zwei pnp-Transistoren und passenden Parametern sollte dies auch gelingen. Das brauchte dann weniger Strömchen.

... oder vielleicht FETs

Womöglich könnte im Motorgehäuse etwas elektrisch entfernt werden, damit er auch auf Masse Schalten passend reagiert. Vermutlich würde dies bspw. thgoebel oder DIYROLLY versuchen.

Wenn der Motor eine interne Elektronik hat, sind deine Bedenken berechtigt.

Ohne interne Elektronik sollte es afaik unerheblich sein, ob der Shelly - oder + schaltet.

Im ersten Fall wären zwei zusätzliche Relais oder Transistorschaltungen geeignet.

Ein Polwende-Relais genügt. Das ist ein Relais mit zwei Umschaltkontakten.

Ich finde es erstaunlich, dass der Motor auch läuft, wenn beide Plus-Anschlüsse Strom erhalten.

Ich wollte dies jedenfalls vermeiden, was technisch ja kein Problem darstellt.

Btw, du kannst im Shelly Plus 2 den Roller Modus einstellen, per Actions das gewünschte Verhalten konfigurieren oder dies per Skript steuern.

Wenn es per konfigurieren gelingen sollte, täte ich dies nicht im Skript implementieren.

Nö, einen Shelly Plus 2 oder Pro 2 einsetzen - besser ist das.

Wegen des AddOn selbstredend einen Plus 2 ...

Warum mehr Devices als erforderlich?

Klar.

Deshalb sind dafür die Schedules bestens geeignet.