Beiträge von eiche

Zitat von nurmaso

Ich suche aber nach einer Möglichkeit, dass man nicht zyklisch überwachen muss, sondern der i4 das sofort mitkriegt, wenn eine Lampe eingeschaltet wird.

Ich habe nur eine Shelly Duo zum testen und tat dies für ein Forumsmitglied auch bereits.

Dazu kannst du in der Shelly Leuchte eine Action anlegen, welche bspw. auf das Einschalten reagiert. Im Skript des i4 verwendest du im einfachsten Fall eine Funktion oder etwas besser einen HTTPServer Endpoint. Die Action auf der Leuchte lautet bspw. so.

http://172.16.8.1/rpc/script.eval?id=1&code="sync()"
allg.
http://<IP Adresse des Zielgerätes (i4)>/rpc/script.eval?id=<Skript Id>&code="sync()"

Im Skript muss die Funktion, welche auf die Action reagieren soll, in diesem Beispiel sync() lauten und das abarbeiten, was du erreichen willst.

Auf diese Weise meldet die Leuchte das Einschalten oder das, was sie melden soll, bspw. auch das Ausschalten. Ohne die Leuchte per polling abzufragen, da die Leuchte selbst das Ereignis der Änderung mitteilt. Das Abfragen der Leuchtenzustandsparameter musst du selbstverständlich in sync() noch selbst coden, bspw. so wie der Link von ThomasHRO zeigt. Allerdings täte ich darin ein Array aus IP-Adressen verwenden und zum synchronisieren eine Schleife abarbeiten lassen.

Edit:
Nicht alle Änderungen einer Shelly Leuchte können in einer Action verwendet werden.
Wäre eine solche Leuchte mit einem ESP32 ausgestattet, wäre sie vermutlich skriptfähig. Dann könnte jegliche Änderung per Skript mitgeteilt werden.

Das ist hier relativ ausführlich beschrieben:

https://github.com/mongoose-os-libs/cron

Zitat

• @sunset-1h30m 1 * * : Run 1.5 hours before the sunset every 1th day of month;

Für deinen Zweck lautet der timespec Wert also:

@sunset-2h * * *

Dies lässt sich auch per Web UI einstellen, solange man keine spezifischen Methoden wie "Script.Eval" einsetzen will.

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

nurmaso

Zitat von nurmaso

Meine Funktion arbeitet aber von 120 Minuten vor Sunset bis zum Sundet zyklisch.

Solches kann leicht per Schedule Job alias Zeitplan realisiert werden.

Aus meinem Beitrag #16:

Zitat

Die Firmware 1.3.1 lässt im Web UI keine Änderung von KVS Variablen mehr zu. Damit ist für manche Anwender die KVS Nutzung kaum noch möglich. Hoffentlich wird dies noch geändert. Ob dies per RPC Methode gelingt, habe ich bisher nicht getestet.

Zwischenzeitlich testete ich, ob eine KVS Variable per RPC änderbar ist - via Web Browser Adresszeile.

Ergebnis: Ja, das ist möglich. Diese Einschränkung betrifft also nur das Web UI.

Ob diese Einschränkung in 1.3.2 beseitigt ist, weiß ich allerdings nicht.

Edit: Soeben getestet und für schlecht befunden. Auch in Firmware 1.3.2 sind KVS Variable nicht per Web UI änderbar.

Mein Verdacht: Auf Entwicklerseite wird dies entweder nicht ernst genommen oder dies ist beabsichtigt.

Die Freilaufdiode (1N4004) am Türöffner (4) erscheint wegen induktiver Last angemessen.

Ich verstehe nicht, was mit "Tür" in rot gemeint ist. Vermutlich ist das der Türöffner, welcher bereits in schwarz im Plan enthalten ist.

(4) wird nie geschaltet? Irgendwie ist der Plan an dieser Stelle sinnfrei.

nurmaso

Hinweis zur Zeitsteuerung, auch gekoppelt mit sunset ...

Die Shelly Firmware beinhaltet einen Scheduler und bietet den Einsatz von Schedule Jobs.

Damit lassen sich gewünschte Aktionen sehr verlässlich und effizient triggern. Es lassen sich bis zu 20 Schedule Jobs anlegen und editieren. Dies gelingt am flexibelsten per RPC und der Web Browser Adresszeile (URL). Bei Bedarf kann ich weitere Informationen dazu liefern.

Hierzu habe ich einen kurzen Beitrag erstellt ...

Danke für die Info.

Bei Szenen bin ich weitgehend ebenso raus wie Michael. Auch verstehe ich deine Beweggründe kaum. Ein vor Ort Lichteinfall kann afaik ausschließlich per Lichtsensor vor Ort erfasst werden und nicht etwa aus einer großflächigen Wetterlage. Schon deshalb erscheint mir eine Szenen-Lösung eher abwegig.

Falls in einer Szene, was ich zunächst vermute, aber nicht weiß, auch URL eintragbar sind, ließe sich, trotz meiner Bedenken, ein parametrierter Aufruf einer Skriptfunktion implementieren.

Etwa so:

http://<IP Adresse des Shelly>/script/<Skript Id>/<HTTPServer Endpoint Name> ...

Der HTTPServer Endpoint Name ist nach eigenem Belieben wählbar, die abschließenden drei Punkte stehen für ergänzbare Parameter.

Solche URL können selbstverständlich auch von anderen Devices im lokalen Netz ohne Cloud Erfordernisse genutzt werden, bspw. von einem "intelligenten" Lichteinfall-Sensor.

RB0815

Willst du ausschließlich die beiden fest im Skript verankerten Positionen anfahren lassen, um die Lamellen ein wenig zu drehen?

Ich halte das Skript für suboptimal, weil es so nicht gestattet, die Lamellen nach dem Fahren auf eine beliebige Position noch zu drehen.

Deshalb schlage ich folgende Variante vor, welche imho zielführender arbeitet und zudem wegen Parametrierbarkeit besser pflegbar ist - u.U. auch flexibler nutzbar.

1. Eine äußere Anweisung zum Anfahren einer parametrierten Position - Shelly.call(...).
2. Innere Anweisungen zum kurzzeitigen fahren (öffnen/schließen) der Jalousie. Diese Anweisungen müssen in der callback Funktion von 1. stehen.
   Grund; Wie bereits von ostfriese angemerkt, arbeiten die RPC-Aufrufe (Shelly.call(...)) asynchron.
   Diese Platzierung der Anweisungen innerhalb der callback Funktion von 1. lässt die Anweisungen in kürzestmöglichem Zeitabstand zum Positionsanfahren ausführen.

Zu 2.

Zur Parametrierung der inneren Anweisungen ist der user defined Parameter (=zusätzlicher, letzter Parameter in Shelly.call() Aufrufen) zielführend einsetzbar. Dafür täte ich vorzeichenbehaftete Zahlen vorsehen, welche die Drehung der Lamellen bestimmt.

Für die relative Zeitsteuerung sind zwei Anweisungen erforderlich.

1. Ein Shelly.call() Aufruf zum öffnen/schließen der Jalousie, abhängig vom Vorzeichen des user defined Parameters.
2. Ein Timer.set() Aufruf mit dem Betrag des user defined Parameters und in der callback Funktion nach Timer Ende das Anhalten der Jalousie.

Dies sind bisher planerische Gedanken/Vorstellungen, welche in einem Skript sehr wohl implementierbar sind und imho als best practicable zielführend eingestuft werden können. Über die erreichbare Präzision beim abschließenden Lamellendrehen liegen meinerseits keinerlei Erfahrungen vor. Letzteres wäre per geeigneten Tests herauszufinden.

Falls du zum Skript konkretere Code-Teile brauchen solltest, kann ich solche gerne beisteuern - allerdings kann ich mangels Verfügbarkeit solcher Jalousien nicht selbst testen.

oldchiefphil

Diese Steuerbox hat nach den Aussagen von @Benjidoggi ein internes Enable, welches verhindert, das der Antriebsmotor gleichzeitig Spannung zum Hoch- und zum Herunterfahren erhält - jedenfalls interpretiere ich es so.

Dann ist zunächst ein gegenseitiges Verriegeln auf dem Plus Uni nicht zwingend erforderlich. Eine Kalibrierung des Lifts gelänge ausschließlich mit Hilfe von Zeitmessungen und dem Eintragen deren Ergebnisse in ein Skript oder in das KVS, welches von einem Skript gelesen werden sollte. Dann stünden fast beliebig viele Zwischenpositionen zur Verfügung, was aber nicht ohne Skript gelänge. Theoretisch wären insgesamt sechs Zeitmessungen zielführend, in jeder Fahrtrichtung drei. Ganz nach unten/oben und in jeder Fahrtrichtung zwei zusätzliche zu Zwischenpositionen. Letztere wären für die Anlaufdauern erforderlich, was ein wenig zusätzliche mathematische Berechnung (linearer Funktionen) erforderlich macht. Alles kein Hexenwerk. Ich habe es nur durchdacht, aber selbst noch nicht angewendet. Vermutlich geht die Kalibrierung auf einem Shelly Plus 2PM etwas redundant so vor + Erkennung des automatischen Abschaltens seitens eines Rollladenantriebs.

Ein solches Skript müsste sich die letzte Position merken, um die Einschaltdauer für eine neue Zwischenposition ermitteln zu können. Nach Skriptstart muss eine Referenzposition angefahren werden. Es ist anzunehmen, dass die vorhandene Steuerbox-Elektronik den Antrieb bei erreichen einer Endposition automatisch ausschaltet. Dann sollte der Plus Uni zur Steuerung der Box geeignet sein - ein passendes Skript vorausgesetzt. Da aber der Plus Uni per se kein Gerät zur Ansteuerung eines Rollladens, einer Markise oder eines Lifts ist, kann hierfür zunächst kein Sprachassistent genutzt werden. Dann wäre für jede Zwischenposition eine separate Routine ein Workaround - nicht schön, aber vielleicht möglich.

Edit:
Ich empfehle, zunächst die Nutzbarkeit eines Shelly Plus 2PM zu prüfen. Dieser kann zwar bei Einsatz einer unüblichen Spannungsversorgung nicht automatisiert kalibrieren, aber vielleicht ist eine solche Kalibrierung per Konfiguration über Fahrdauern möglich (?). Ansonsten kann auch auf einem Plus 2PM ein Skript genutzt werden.

Nach meiner Erinnerung gibt es unterschiedliche Pin Maps. Ich bin dbzgl. nicht auf dem Laufenden. Deshalb kann ich dir hierbei nicht direkt weiterhelfen.

Ich täte ein reduziertes Programm schreiben (setup() und loop()), welches nach einem Reset alle möglichen Pin Nummern einmal durchläuft. Zu jeder Pin Nummer täte ich den Signalzustand per serieller Schnittstelle auf den Monitor übertragen lassen.

Sobald der zur Verfügung stehende Eingang (SW) zwischen zwei Reset geändert wird, könnte ich daran die passende Pin Nummer erkennen. Etwas komfortabler wäre bspw. der Empfang einer MQTT Nachricht, auf Grund welcher der Eingangszustand der gewünschten Pin Nummer ebenfalls per MQTT Nachricht übertragen würde.

Beispiel:

Zu veröffentlichte MQTT Nachricht für den Shelly: (Diese kann bspw. über einen öffentlichen MQTT Broker vertöffentlicht werden.)

Topic: ShellyPlus1-<MAC Adresse>/input/number
Payload: <Pin Nummer>

Vom Shelly veröffentlichte Nachricht nach dem Empfang der obigen Nachricht:

Topic: ShellyPlus1-<MAC Adresse>/input/status
Payload: <Eingangszustand>

Solches kann mit MQTT fx, MQTT Explorer, Abdroid App MQTT Dash oder Node-RED praktiziert werden.

Der Rest obliegt deiner Kreativität.

Btw, auch ein per Taster ausgelöster Interrupt könnte hierfür eingesetzt werden. Die ISR setzt eine boolean Variable auf true, woraufhin loop() die Eingänge "abklappert", sachlich als polling bezeichnet.

...

Soweit habe ich deinen Code nicht analysiert. Vermutlich liegt es an der Pin Nummer.

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.

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.

function httpEndpoint(request, response) {
  response.code = 200;
  response.headers = [["Content-Type", "text/html"]];
  if(request.method==='GET') {
    // Parameter stecken in request.query.
    let para = request.query;
  	// Parameter als String verarbeiten.
  }
  else if(request.method==='POST') {
  	// Parameter stecken in request.body.
  	print(request.body);
  	let para = JSON.parse(request.body);
  	// Parameter Objekt verarbeiten.
  }
  // http body für die Antwort zusammenstellen
  response.body = ...
  // Antwort senden
  response.send();
}

HTTPServer.registerEndpoint("ctrl", httpEndpoint);

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

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

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

Ich plädiere dafür, dass im weiteren Diskussionsverlauf nur noch Fachjuristen oder Versicherer Antworten geben und ziehe mich deshalb ab nun hier heraus.