Beiträge von eiche

Zitat von subbamaggus

Berry Programm? Meinst du auf einem Raspberry? das ist schon zu "gross".

Nein, kein Raspberry Pi.

Wenn man Tasmota32 (nur für ESP32 Boards) nutzt, steht auch die Programmierumgebung, ein online Editor, zum Erstellen von Programmen zur Verfügung, die in der Programmiersprache Berry erstellt werden. Diese ist C affin und bietet so einiges, was es in Shelly Script nicht gibt. Ich mag Shelly Script insbesondere wegen des gut strukturierten API und der mächtigen Schedule Jobs.

Ich habe seit langem kein Berry Programm mehr erstellt, weiß aber noch folgendes.

Es gibt eine Berry Konsole, in welcher man Berry Kommandos eingeben und damit testen sowie experimentieren kann.

Bei laufendem Berry Programm kann man bspw. Variableninhalte ausgeben lassen und auch Funktionen aufrufen.

Es steht ein einfaches Dateisystem zur Verfügung, in welchem man seine Berry Programme ablegen kann.

Berry ist eine Hybridsprache, Quellcode wird in Dateien mit Suffix .be abgelegt. Ein Compilat erhält das Suffix .bec. Der kleine Interpreter arbeitet solche .bec Dateien ab, die geladen wurden.

In eine Datei autoexec,be trägt man am besten per load <Dateiname> die Dateien ein, die mit dem Booten geladen und ausgeführt werden sollen. .be Dateien werden mit dem Laden automatisch compiliert, das Compilat in einer .bec Datei abgelegt und ausgeführt.

Berry ist sehr interessant und man kann von Rules Berry Funktionen aufrufen lassen - mit Parameterübergabe.

Per Berry kann man auf die flüchtigen (Varx) und die nichtflüchtigen (Memx) Rules-Variablen zugreifen.

Die Rules sind Ereignis gesteuert und somit die Berry Funktionen auch.

Es ist sogar möglich, per Berry externe Hardware (Sensoren, Aktoren) direkt anzusprechen (Gerätetreiber), was ich aber nie ernsthaft tat.

Inzwischen soll es weitere Möglichkeiten geben, die ich (noch) nicht kenne.

Ich habe ein wenig dazu dokumentiert.

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.

Zitat von subbamaggus

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.

Zitat von subbamaggus

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.

Zitat von eiche

Wenn du mit einem solchen kleinen Relais über 3kW leiten willst,

Zitat von Duschkabine

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.

Zitat von subbamaggus

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:

Zitat von subbamaggus

// Do not change code below this line!

Zeile 90:

Zitat von subbamaggus

url: 'http://192.168.178.119/cm?cmnd=status%2010'

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 ...

Zitat von thgoebel

wir kennen schließlich den Regensensor nicht…

Damit meint Thomas, dass du mehr zum Regensensor mitteilen solltest, wenn du weitere Hilfe haben möchtest.

1. Ist es ein binärer Sensor (ein/aus, ja/nein) oder ein analoger?
2. Welche Anschlüsse hat er?

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.

Zitat von Kevin63

Irgendetwas mache ich noch falsch. Aber was?

Die Cloud-Nutzung hierfür ist ein Fehler.

Zitat von Kevin63

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:

1. Hast du auf dem Shelly schon mal den Cloud-Zugriff deaktiviert?
2. Wie ist die Zeitsteuerung implementiert?

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.

Zitat von bauerflo

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?

Martin Fielembach

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.