Beiträge von eiche

    DirtyHaerry

    Da du deine Firmware in C++ programmiert hast, sollte es für dich kein ernsthaftes Problem sein, ein Shelly Skript zu erstellen, wenn du das anstreben solltest. Darin brauchst du

    1. einen EventHandler - eine in der Shelly Firmware zu registrierende Funktion mit einem zu importierenden Parameter (das Event Objekt),
    2. einen HTTPServer Endpoint - eine in der Shelly Firmware zu registrierende Funktion mit einem zu importierenden response Objekt, mit welchem die Antwort an das Frontend (Web Browser) gesendet wird.

    Die EventHandler-Funktion muss auf die Änderung des Eingangssignals (SW), Component "input:0" reagieren. Dazu selektierst du ausschließlich die Ereignisse mit der Component "input:0". Damit du sehen kannst, welche Ereignis-Informationen im EventHandler eintreffen, lässt du einfach den importierten Parameter ausgeben, am besten per JSON.stringify() in ein kompakteres Ausgabeformat umwandeln.

    Code
    function eventHandler(evt) {
      print(JSON.stringify(evt));
    }
    
    Shelly.addEventHandler(eventHandler);

    An der Ausgabe kannst du erkennen, wie du auf die importierten Informationen zugreifen kannst und welche für dein Projekt relevant sind. Du kannst dir für den Einstieg auch meine Skripteinführung anschauen - s. meine Signatur.

    Die HTTPServer Endpoint Funktion wird bei deren Registrierung einem Namen zugeordnet, welcher in der Anforderung der Webseite enthalten sein muss. Wie du die gewünschte Webseite zusammenstellen willst, weißt du ja bereits - s. dein C++ Code.

    Die Webseite wird dann wie folgt angefordert, hier per Methode GET.

    Code
    http://<IP Adresse des Shelly>/ctrl?<Parameterliste>

    Die Funktionsnamen kannst du selbstverständlich nach deinem Gutdünken wählen, wie auch den HTTP Endpoint Namen - ich wählte "ctrl".

    Die Methode POST ist für in der Shelly Antwort eingebetteten JavaScript Code - im Frontend verarbeitet - besser geeignet. Die Methode GET ist für eingebettete Links gut geeignet.

    Insgesamt kann mit einem Skript die Funktion des Shelly flexibler und insbesondere on the fly angepasst werden.

    DirtyHaerry

    der liniarmoter soll erst bei einer einstellbaren einschaltung des motors geschaltet werden

    Mir ist nicht klar, was du mit "einstellbaren Einschaltung" meinst. Ich vermute bei einschalten vs. ausschalten, also eines von beiden konfigurierbar. Vielleicht nutzt du einen Plus 1PM und willst lastabhängig den Linearmotor per Polwenderelais laufen lassen.

    1. Was du erreichen willst, ist mit Sicherheit auch per Shelly Skript implementierbar. Weder ein Shelly noch ein darauf laufendes Skript sind per se auf eine Internetverbindung angewiesen.
    2. Per Skript ist leicht ein HTTP-Server Endpoint zu implementieren.
    3. Da der SW Eingang entweder offen oder mit GND verbunden wird, sollte die Schaltung problemlos funktionieren.

    Fazit:

    Deine Bemühungen, die eigene "Firmware" zu installieren sind vermutlich deiner Unkenntnis in der Erstellung eines Shelly Skripts geschuldet. Ich kann die Nutzung der Shelly Firmware mit einem Skript empfehlen. Das API ist durchaus ausgereift und gut dokumentiert. Die RPC (Remote Procedure Call) Methoden sind leicht test- und nutzbar, wenn man diese einmal verstanden hat. Zusätzlich könnte ein solchermaßen angepasster Shelly bei Gelegenheit auch leicht mit anderen Systemen kommunizieren.

    Bei Bedarf bin ich gerne bereit, auf Fragen zum Shelly Scripting einzugehen.

    Tasmota32 bietet einige Möglichkeiten, insbesondere bei Nutzung der ereignisgesteuerten Rules und zusätzlichen Berry Funktionen. Auf einem Shelly täte ich aber die Nutzung der Original Firmware + Skript bevorzugen, wenn ich keine spezifischen Sensoren einsetzen möchte, die vom Hersteller/Entwickler nicht vorgesehen sind. Deine Schaltung hat nichts außergewöhnliches, was Tasmota32 oder eine eigene Firmware erforderlich machen täte.

    DirtyHaerry

    1. Hat ein solchermaßen genutzter Shelly bei deiner Beschaltung mit der Shelly Firmware funktioniert?
      Bzw. funktioniert die Schaltung mit der Shelly Firmware?
    2. Wie sieht deine Beschaltung aus? Bitte Skizze, kein Foto!
      Vielleicht liegt hier ein Problem vor. Dies wäre am einfachsten mit der Shelly Firmware testbar.

    Ich habe lange nichts mehr in C++ auf einem ESP32 programmiert. Bin unsicher, ob die GPIO Nummer (hier 4 bzw. 5) im C++ Code passt. Evtl. ist hierfür eine andere Nummer geeignet, weiß aber nicht mehr, welche dafür in Frage kommt.

    Ich kann dir generell empfehlen, im EventHandler das Einschalten des Verbrauchers, also Component "switch:0" statt Component "input:0", zu verwenden.

    Dann arbeitet das Skript unabhängig von der auslösenden Quelle. Entscheidend ist nur das Einschalten. Somit sollte dir auch die Lösung per HomeKit (mir unbekannt) einfallen.

    Btw, auch das Einschalten per Sprachassistent wird auf diese Weise verarbeitet.

    Soweit ich Schreddl verstand, sucht er eine unintelligente Lösung per einstellbarem binären Feuchtesensor, welcher möglichst direkt ein einzelnes Ventil steuert.

    Dann darf er lange mit der passenden Einstellung experimentieren, weil er nichts aufzeichnen und so kaum etwas auswerten kann. </Sarkasmus> ;)

    Aber möglich ist das und es kann fast jeder nutzen, der feinfühlig genug einen Schraubendreher handhaben kann. (Mir täte so etwas nicht gefallen, muss es ja auch nicht.)

    Die entscheidenden Hinweise hat DIYROLLY bereits in #5 gegeben.

    Den Schalter schließt du an einem Shelly Eingang (SW) an. Der Shelly schaltet die Pumpe und muss dauerversorgt sein.

    Der Rest ist per Software auf einem übergeordneten System oder auf einem skriptfähigen Shelly zu implementieren.

    Sicherheitsrelevante Einrichtungen sollten per se nicht auf eine Cloud angewiesen sein.

    Schreddl

    Was willst du denn mit einem binären Wert feucht vs. trocken anfangen? Willst du einen solchen Sensor etwa nur in einem Topf einsetzen? Der Titel lässt einen anderen Schluss zu.

    Ein Feuchtigkeitswert kann ja, für welche Zwecke auch immer, verarbeitet werden und entsprechende Maßnahmen signalisiert oder automatisiert ausgelöst werden. Wirklich trocken täte sehr oft bedeuten, dass eine Pflanze unrettbar verloren wäre, also eine Bewässerung dann eh zu spät käme.

    gexle

    Afaik verwendest du kein übergeordnetes System. Solange eine solche Berechnung + Anzeige keinesfalls sicherheitsrelevant ist, wäre evtl. eine Szene in's Auge zu fassen, womit ich mich aus naheliegenden Gründen wenig auskenne. Per Skript(erweiterung) gelänge so etwas durchaus - bspw. per MQTT Nachricht, oder auch per kleiner Webseite, welche das Skript liefert.

    Mir ist aber noch völlig unklar, wie du von 50°C und 60°C auf 54% kommst. Das arithmetische Mittel ist 55°C - und nicht etwa 54°C. Welche Bezugstemperatur willst du festlegen? Bedenke auch, dass ein Mittelwert hierfür nicht sehr aussagekräftig ist und schon gar nicht für eine Sicherheitsabschaltung taugt.

    richard-os

    Hast du denn die von dir gewünschte Priorisierung schon implementiert? Vermutlich gelingt dies nicht per Action (=Webhook), weil das Schalten per Kommunikation nicht sperrbar sein dürfte. Vielleicht gelänge solches per Szene, wovor ich aber abrate. Mit einem Skript wird eine solche Priorisierung jedenfalls implementierbar sein.

    Zur Abschalttemperatur wissen andere mehr. Ich täte mich darum bemühen, die SSR an anderer Stelle zu platzieren, wenn diese als entscheidende Wärmequelle feststehen. Eine benachbarte Dose/Gehäuse wäre bereits dafür geeignet. Zur Sicherheit sollte darin die Temperatur überwacht und bei Überschreitung von bspw. 60°C abgeschaltet werden. Auch solches gelänge per Skript oder vermutlich auch Action.

    Mit FW 1.2.2 hatte ich es getestet. Nun habe ich FW 1.3.1 drauf.

    Btw, ich habe in meiner Dokumentation die Möglichkeit aufgezeigt, Messdaten und Zeitstempel in zwei Dateien zu speichern, wobei i.d.R. die Zeitstempeldatei nur eine oder bei Stromausfall nur sehr wenige Zeilen umfasst. Erst bei der Übertragung wird der Zeitstempel zu jedem Messwert generiert. Ein Copy & Paste würde damit aufwändiger.

    Vielleicht wäre mit deinen Datensätzen auch eine Komprimierung möglich.

    Du kannst meinem Skript entnehmen, dass ich dort das Limit auf 20480 setze (=20k). Dieses Limit der Dateigröße hat sich bewährt, ist aber dem Einsatzzweck angepasst. Meine Experimente ergaben, dass bei wesentlich größerer Datei, soweit ich erinnere um die 30k, irgendwann ein Skriptabbruch die Folge war.

    Die API Dokumentation schweigt sich darüber aus. Ein Forenmitglied hatte mir einmal mitgeteilt, dass die experimentell maximale Größe bei 48k läge und die verfügbaren Speicherressourcen seit Firmware Version 1.x (?) fest auf die 10 möglichen Skripte aufgeteilt seien. Nach meinen Erfahrungen teilt sich vermutlich diese Größe von ca. 48k auf Skriptlänge und Arbeitsspeicher auf. Um solches herauszufinden, bleiben offenbar nur eigene Experimente.

    In einem anderen Projekt scheiterte mein Vorhaben jedenfalls an der ram_size von 260016, welche bei nicht laufendem Skript angezeigt wird. Dies ist aber nicht die maximale Größe einer Datei.

    Das Speichern im Shelly hat insbesondere dort seinen Vorteil, wo irgendwelche Informationen zur Auswertung gespeichert werden sollen, wo keine Kommunikation mit anderen Geräten oder Internet verfügbar ist.

    Da bis zu 10 Skripte möglich sind, sollte bis zu theoretisch 9*20k Byte Speicherkapazität ohne Probleme nutzbar sein. Solche Versuche habe ich bisher nicht durchgeführt, weil ich dazu keinen Anlass hatte.

    Das hat nichts mit dem i4 zu tun, sondern mit dem empfangenden Rollladen-Shelly.

    Der URL .../roller/0?go=stop u.ä. gehören zur ersten Generation der Shelly wie der 2.5 und sollte in den Shelly ab zweiter Generation noch abwärtskompatibel sein. In den neueren Shelly gibt es hierfür die wesentlich flexibler nutzbaren RPC-Methoden.

    Ich empfehle eine allmähliche Umstellung auf RPC-Methoden bei Shelly ab zweiter Generation.

    Ein Rolladen ("Rolladen Haustür") reagiert seit ein paar Wochen nicht mehr auf "Rolladen Haustür schließen". Alexa antwortet dann mit "ich bin mir leider nicht sicher".

    Hast du auch mal eine andere Benennung versucht wie bspw. "Rolltür" statt "Rollladen Haustür"?

    Hast du ein anderes Gerät mit ähnlich klingendem Namen eingesetzt? "Haustür schließen" ist ein wenig verdächtig.;)

    Das Skript biete ich nicht zum herunterladen an, da es in meiner Fassung recht spezifisch ist und für andere Anwendungen anzupassen wäre. Ich stelle es aber bei Interesse gerne zur Verfügung.

    Versuch einer einfachen Beschreibung der Skript-Arbeitsweise

    Einige Dinge sind optional, was ich dann jeweils erwähne. Sie können somit bei Nichtbedarf entfernt/weggelassen werden.

    1. Es nimmt Messdaten als Ereignisse entgegen, die von der Firmware geliefert werden. Statt Messdaten können beliebige andere anwendungsspezifische Daten erfasst werden.
    2. Zur Speicherung wird eine feste Abtastfrequenz per Schedule Job (Zeitplan) verwendet, was optional ist.
    3. Aus den zwischen zwei Speicherungen eintreffenden Messwerten wird sukzessive der arithmetische Mittelwert gebildet, ebenfalls optional.
    4. Die Daten werden in einer Skriptdatei namens "data" gespeichert, weil die Firmware hierfür Methoden bereit hält. Diese Datei ist allerdings kein Skript, sie ist aber unter Skripte einsehbar und somit können die Aufzeichnungsdaten per Copy & Paste kopiert und an gewünschter Stelle eingefügt werden.
    5. Zusätzlich habe ich auf Grund der Wünsche des befreundeten Anwenders eine Datenübertragung per MQTT implementiert, was optional ist. Der Anwender suchte eine einfache Möglichkeit, die gespeicherten Daten nach ca. einer Woche vom Messort ohne Internetzugang nach Hause zu übertragen. Dies gelingt mit einem öffentlichen MQTT Broker und der Android App MQTT Dash. Dabei wird der Hotspot des Smartphone/Tablet genutzt.
    6. Es liest Konfigurationswerte ein, die per Web UI unter KVS (Key Value Storage) leicht angelegt und geändert werden können. Eine solche Konfiguration sowie deren Verarbeitung ist auf die jeweilige Anwendung anzupassen.

    Hier der aktuelle Inhalt der von mir für Testzwecke gespeicherten Daten. Vorne steht der Unix Timestamp, nach dem Komma der gemittelte Temperaturmesswert.

    Das Skript im Anhang dürfte für deine Zwecke nicht 1:1 nutzbar sein.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.