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.
Ich versuche genauer zu erfassen, was du derzeit einsetzt und was du erreichen willst.
Das Prinzip gefällt mir. Das zyklische Wechseln per Modulo ist interessant.
Von einem sog. "Volkszähler" hatte ich vor Jahren mal etwas gelesen - und verworfen.
Läuft irgendetwas dbzgl. bei dir bzw. dem Kumpel auf einem ESP32 Board, vielleicht sogar mit Tasmota32?
Wenn ja, hast du mal ein Berry-Programm versucht?
Mir gefällt Berry für solche Einsatzzwecke sehr gut und das Konzept überzeugt mich.
Bin selbst Software Engineer.
Dann solltest du nicht wirklich überfordert sein. Und entschuldige, falls ich dir etwas versucht habe zu erklären, was für dich selbstverständlich ist. 
Dann könnte dich meine Skripteinführung (siehe Signatur) unterfordern, aber vielleicht auch interessieren.
Echtes "komplettes" JavaScript ist ja nicht zu machen. Von daher musste ich mich mit dem zufrieden geben.
Der aktuelle JavaScript Interpreter ist recht brauchbar und es gibt ein gutes API, was relativ ausführlich und gut beschrieben ist.
Ich vermisse derzeit nichts.
Und was du hier und anderswo finden kannst, ist nicht selten zu sehr stereotyp. Ich kann dir nur empfehlen, manches kritisch zu betrachten.
Für den Fall, dass die Abbrüche bleiben, habe ich noch zwei Hinweise.
Du kannst eine Ausnahmebehandlung einbauen. Dies ist so etwas wie ein Sicherheitsnetz für den Fall eines Laufzeitfehlers.
Eine Ausnahmebehandlung ist eine Kombination aus einem try-Block und einem unmittelbar darauf folgenden catch-Block.
Hier mit einem Code-Ausschnitt von #3:
function startMonitor() {
alertTimer = Timer.set(10 * 1000,
true,
function () {
try {
getData();
getDate();
/...
if(myState === 3) {
Shelly.call("Switch.Set", {"id": switch1, "on": true});
Shelly.call("Switch.Set", {"id": switch2, "on": true});
Shelly.call("Switch.Set", {"id": switch3, "on": true});
}
} catch(exception) {
print("exception: ", JSON.stringify(exception));
}
}
);
}
function getData() {
Shelly.call("HTTP.GET", {
url: 'http://192.168.178.119/cm?cmnd=status%2010'
},
function (res, error_code, error_msg, ud) {
try {
// if call is not successful, this should prevent the outputs from beeing turned on
current = powerPerLine + 1234;
if (error_code !== 0) {
print("error" + JSON.stringify(error_code));
// Not read response if there is an error, to avoid that the script stops
}
else if (res.code === 200) {
let st = JSON.parse(res.body);
current = st.StatusSNS.SML.z16_7_0;
}
} catch(e) {
print("Auisnahme: ", JSON.stringify(e));
}
}
);
};Ich habe zwei Ausnahmebehandlungen eingefügt, die sich in den Parametern ein wenig unterscheiden, um deutlich zu machen, dass nur die Struktur und nicht der Parametername wesentlich ist.
Dies ist eine relativ grobe Methode, um einen Skriptabbruch zu verhindern. Sie kann und soll nicht die von mir weiter oben aufgeführten Sicherheitsabfragen ersetzen.
Falls auch dies nicht helfen sollte, kannst du noch eine Notmaßnehme einsetzen, welche wenigstens für eine, wenn auch nicht technisch saubere, Fortsetzung der Funktionalität sorgt.
Dazu setze einen Schedule Job ein, der bspw. jede Minute das Skript startet.
http://<IP Adresse des Skript-Shelly>/rpc/schedule.create?timespec="0 * * * * *"&calls=[{"method":"script.start","params":{"id":<Skript Id>}}]
Einen solchen Schedule Job kannst du nicht per Web UI anlegen, aber dessen Zeitmuster (timespec) später per Web UI ändern.
Wenn das Skript läuft, bleibt das so. Ist das Skript gestoppt, wird es zu jeder vollen Minute gestartet.
Zu Schedule Jobs habe ich einen kurzen Artikel verfasst.
Verstanden.
Bei Cloud-Nutzung wie Szenen oder gar Cloud-Thermostat bin ich raus.
Begründung: Siehe meine Signatur!
Zur Cloud wissen andere mehr.
Wenn du mit einem solchen kleinen Relais über 3kW leiten willst,
Von Schalten war gar keine Rede.
Das ist unerheblich aber verständlich. Dann korrigiere ich mich so:
Es geht mit einem solchen Verbraucher an diesem Shelly einfach nicht.
Grässlicher Code, sorry.
Das Wichtigste zuerst:
Immer wenn auf eine Objekt-Komponente zugegriffen wird, könnte sich ein Fehler ereignen, der zum Skriptabbruch führt.
Beispiel:
let x = a.b.c; // a sei ein Objekt mit erwartungsgemäß vorhandener Komponente b, die erwartungsgemäß Komponente c enthält.
Wenn a oder a.b nicht existiert (undefined), kommt es zum Skriptabbruch.
Gegenmaßnahme:
let x;
if(a.b.c!==undefined) x = a.b.c;
oder
if(a.b.c===undefined) return;
x = a.b.c;
Baue bei jedem lesenden Zugriff diese Sicherheitsabfrage ein!
Btw, wenn a.b.c undefined ist, kommt es an dieser Stelle nicht zum Skriptabbruch, aber bei einer Weiterverarbeitung kann es dazu kommen
Bin mir nicht ganz sicher. Evtl. ist eine noch aufwändigere Abfrage zielführend.
if(a===undefined | | a.b===undefined | | a.b.c===undefined) return; // | | ist das logische ODER, das Leerzeichen dazwischen ist zwecks Vermeidung eines Smileys erforderlich.
...
Logische Verknüpfungen werden i.d.R., hier immer, per Kurzschluss gewertet, d.h. sobald das Resultat der Verknüpfung feststeht, wird nicht weiter gewertet.
Hier: Wenn a.b undefined ist, wird a.b.c nicht mehr auf undefined geprüft.
Wenn du verstanden hast, wirst du den Code selbst verbessern können.
Unwichtig, aber zum verschlanken des Codes geeignet:
Du brauchst beim Verketten mit einem String einen numerischen Wert nicht per JSON.stringify in einen String zu verwandeln. Das tut der Interpreter alleine, weil der Operator + bei bereits einem String-Operanden als Verkettungsoperator interpretiert wird.
Unsinnig, auch wenn oft zu finden:
Als user defined parameter ein null zu übergeben ist stereotypischer Bullshit. Nimm solchen Quatsch heraus!
Wozu soll die Variable alertTimer gut sein?
Diese wäre erforderlich, wenn im Skript irgendwo der Timer gelöscht (Timer.clear(alertTimer)) werden soll. Auch das ist stereotypischer Unsinn, weil überflüssig.
myunixdayint = result.unixtime / 86400 | 0;
Mir erschließt sich nicht, was die bitweise ODER Verknüpfung mit 0 bewirken soll. x | 0 ergibt immer x.
Vielleicht ist das ein tricky Ausdruck zur Umwandlung in einen Integer-Wert?
Dazu sind Math.round(), Math.ceil() und Math.floor() vorgesehen.
Es gibt noch mehr, ich will es hier aber mal so belassen.
Ein kürzeres Skript ist übersichtlicher und leichter zu pflegen.
Da gibt es einen semantischen Widerspruch im Skript.
Zeile 14:
// Do not change code below this line!
Zeile 90:
Wozu gehört diese IP Adresse?
%20 ist der Code eines Leerzeichens. ?
Hab's gelesen - Volkszähler.
Vielleicht, aber nicht wahrscheinlich, bringt die Antwort des Zählers das Skript irgendwie "aus dem Takt".
Ich schaue mir das Skript weiter an ...
wir kennen schließlich den Regensensor nicht…
Damit meint Thomas, dass du mehr zum Regensensor mitteilen solltest, wenn du weitere Hilfe haben möchtest.
Davon hängt es ab, ob und wenn ja wie er mit dem AddOn zu verbinden ist.
Tja, das vernundert nicht.
Wenn du mit einem solchen kleinen Relais über 3kW leiten willst, dann solltest du gelegentlich eine Fachkraft hinzuziehen.
Die Werbeangabe von 16A ist totaler Unsinn, also brauchst du zum schalten noch einen Schütz.
Dann gelingt aber das Messen nicht mehr.
Irgendetwas mache ich noch falsch. Aber was?
Die Cloud-Nutzung hierfür ist ein Fehler.
und scheinbar auch das Ausschalten
Du kannst doch sicher prüfen, ob der Shelly ausschaltet oder nicht. Das wäre zunächst am wichtigsten.
Dann sollte das richtige Erkennen des Schalterzustandes wenigstens zumeist gelingen. Falls dbzgl. gelegentlich Aussetzer festzustellen sind, sind insbesondere die Kenntnisse von thgoebel gefragt.
Meine Fragen:
Yes, of course.
Question: Does it have to be exactly 5 minutes or can it be up to about 6 minutes?
An event handler receives the values and when power is 0 for the first time, it saves the timestamp.
If power > 0, the timestamp is deleted.
If 5 minutes later (current timestamp - saved timestamp) the power is still 0, the output is turned off.
This is the simple algorithm.
The Pro 4PM is afaik scriptable.
Do you use any script on this Shelly?
If you want Node-RED to receive periodically the status of the Shelly, it is usefull using schedule jobs on the Shelly.
Do you do the request for "status_update" in one of your projects and it's working?
Yes I do - via schedule jobs not via requests.
If a request doesn't get a response, it's probably better to let Shelly send it on its own.
Those jobs sends periodically informations, e.g.status.
Via older Node-RED flows I control Shelly 1 (1. Gen.) for heating successfully, also without requests.
Zu einer möglichen Lösung mit Actions fällt mir nichts ein.
Das Problem könnte mit zwei Actions für input toggled on und input toggled off gelöst werden, was aber dem Ziel für kurzes Drücken widerspricht.
Eine Lösung ist aber mit einem Skript möglich.
Liegt die Dauer des Drückens unter einer Zeitschwelle, bspw. 0.5s, wird der Rollladen bis zum Ende gefahren.
Liegt diese Dauer darüber, wird mit dem Loslassen des Tasters sofort gestoppt.
Räusper,
ich habe so etwas nicht, aber Plus 2PM. Und skripten kann ich auch und Node-RED Flows erstellen und ...
Darüber täte ich es lösen.
Btw, es ist auch möglich, einen Shelly per Skript eine (interaktive) Webseite liefern zu lassen, die das Gewünschte anzeigt - ganz alleine und ohne sonstige Dinge, außer (W)LAN selbstverständlich.
Von der App und der Cloud halte ich weniger.
Diese Antwort gebe ich, weil niemand sonst reagierte.
Ich weiß es nicht.
Aber hier gibt es ein fast DAU sicheres Skript dazu: https://github.com/ALLTERCO/shell…ther-devices.js
Du musst nur die Configuration zu jedem Test mit einem Bluetooth Gerät anpassen und testen.
Viel Erfolg!
Äh ... eine Therme schalten per Cloud?
Ich kann nur empfehlen, noch einmal darüber nachzudenken - s.a. meine Signatur.
In aller Freundschaft
In addition to thgoebel note:
Why don't you use a small Node RED flow for this?
Also you should use a locally working MQTT broker.
The hivemq public broker is not reliable enough.
You may use instaed of this the public mosquitto broker. But as seen, you use mosquitto_pub. So you probably have mosquitto installed - or didn't you?
Klar, so geht es auch, ist aber weniger ausbaufähig als die Verwendung eines Schedule Job mit Skript im Shelly selbst.
Was der Shelly per Schedule Job tun soll, kann leicht im Skript implementiert werden. Auch können hierfür mehrere Jobs genutzt werden.
Und warum sollte ein übergeordnetes System etwas zusätzlich tun, was bereits vom betreffenden Gerät erledigt werden kann? Rhetorische Frage
Der Shelly könnte bspw., bei Bedarf zusätzlich zum veröffentlichen einer MQTT-Nachricht, eine HTTP-Request an ein bestimmtes Gerät senden.
Das ginge selbstverständlich auch über eine Node-RED Zentrale, was aber das ganze etwas weniger ausfallsicher machen täte.
Je autarker die Endgeräte arbeiten, desto weniger wahrscheinlich ist ein Funktionsausfall bei Ausfall der Zentrale.
Damit ich nicht ganz falsch verstanden werde. Auch ich nutze Node-RED und das sehr gerne, insbesondere für anwendungsgerechte Dashboards, Datenspeicherung (InfluxDB) und Visualisierung (Grafana).
Da Shelly der zweiten Generation oder höher per zusätzlicher Möglichkeiten(Skripte, Schedule Jobs) zunehmend autark einstellbar sind, halte ich diesen Weg für eindeutig besser.
Dein Hinweis zu Node-RED ist trotz alledem angemessen und evtl. hilfreich.
Zur sauberen Überprüfung, ohne soviel herumzubasteln:
Vergiss temporär die App! Die ist oftmals suboptimal.
Nimm stattdessen einen Browser und gib in der Adresszeile ein: http://<IP Adresse des Shelly>/rpc/shelly.getstatus
Suche in der Antwort nach "input:0" und schaue dir an, was dort hinter "state" steht!
false bedeutet Aus, also keine Verbindung zu L (bzw. N).
true bedeutet Ein, also Verbindung zu L (bzw. N).
Das wiederholst du mit dem anderen Schalterzustand.
Dann werden wir vielleicht weitersehen können.
Das ist mein Ass im Ärmel.
Edit: Wenn möglich, nimm als Browser Edge oder Firefox! Diese zeigen die Antwort vom Shelly übersichtlich an. Das tun andere Browser vielleicht auch ...
