Beiträge von eiche

    AlexSchmitz

    Es wird gerne zwischen "feste" und "statische" IP Adresse unterschieden.

    Eine feste IP Adresse ist eine, welche der DHCP Server (bspw. eine FRITZ!Box) an Hand der MAC Adresse des Client diesem Client immer wieder zuweist. Diese liegt somit im DHCP IP Adressbereich des Servers.

    Eine statische IP Adresse hat nichts mit DHCP zu tun und darf, wie Captain_Byte andeutete, nicht im IP Adressbereich des DHCP Servers liegen. Bei Verwendung einer statischen IP Adresse, was ich bevorzuge, musst du somit den Adressbereich des DHCP Servers kennen, um sicher keine IP Adresse aus diesem Bereich zu vergeben.

    Dieser URL ist rückwärtskompatibel zu Shelly Geräten der ersten Generation.

    Versuche es auch mal mit dem originären URL für einen Plus Plug S (zweite Generation) - am besten per Web Browser Adresszeile, um die Reaktion des Plus Plug S zu testen!

    Code
    http://<IP Adresse des Plus Plug S>/rpc/switch.set?id=0&on=true

    Zum Ausschalten am Ende ...&on=false.

    Wenn der Plus Plug S sich wie gewünscht verhält, kannst du diesen URL im Button 1 eintragen und entsprechend testen. Danach sollte feststehen, welches der beiden Geräte ggf. nicht funktioniert.

    Zum Dimmer siehe die Dokumentation.

    Edit: API Dokumentation zum schalten von Shelly Geräten ab Generation 2. Hier spielt die Component Switch die entscheidende Rolle.

    Zunächst ein paar Hinweise und eine Frage zu deinem Skript/Anliegen.

    1. Ich sehe keinen triftigen Grund, die Berechnungsfunktion (calculateDewPoint) lokal in loop zu definieren. Man kann so etwas tun, es macht den Code aber unübersichtlicher.
    2. Solange ich kein Skriptproblem wegen Abbruchs vorfinde, lasse ich Ausnahmebehandlungen (try, catch) weg. Das ist zwar Ermessenssache, nach meiner Kenntnis aus C++ brauchen Ausnahmebehandlungen aber Ressourcen, weshalb ich solches nicht ohne Not einsetze, zumal dein Skript recht kurz ist.
    3. Für eine explizite, zyklische Abfrage der Messwerte sehe ich keinen Grund. Hier täte ich einen EventHandler einsetzen, welcher sofort auf das von der Firmware gelieferte Event reagiert.
    4. Konstanten sollten nur dort definiert werden, wo sie gebraucht werden. Dies kann durchaus global sein, in deinem Skript werden a und b nur in der Berechnungsfunktion gebraucht und sollten dort lokal definiert werden. Du kannst diese auch global definieren, dann aber mit aussagekräftigen Namen statt a und b.
    5. Auf Grund welchen Ereignisses soll der Shelly einschalten und wie soll dieses Einschalten erfolgen - manuell oder automatisiert? Im zweiten Fall wären zwei Referenzwerte für eine Hysterese zielführend.

    Wie eine Nachricht (an die Shelly App) gesendet werden kann, weiß ich nicht. Aber die Stelle, an welcher dies erfolgen kann, steht fest. Ich täte dazu MQTT einsetzen, andere vermutlich ein übergeordnetes System. Wie der Ausgang eines Shelly ab zweiter Generation geschaltet werden kann, ist in der API Dokumentation zu finden.

    Auf der Grundlage deines Skripts gelänge dies wie folgt.

    Ich habe dein Skript weitgehend so belassen. Den Einsatz eines EventHandlers magst du selbst prüfen. Bei Bedarf kann ich eine solche Alternative gerne ergänzen. Informationen dazu in der API-Dokumentation.

    Frage: Wie hast du denn ein solches Skript per trial and error zustande gebracht - ohne Programmierkenntnisse? Solches erscheint mir recht abenteuerlich. ;)

    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.

    Code
    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:

    GitHub - mongoose-os-libs/cron
    Contribute to mongoose-os-libs/cron development by creating an account on GitHub.
    github.com
    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:

    Code
    @sunset-2h * * *

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

    schedule_via_web_ui.JPG

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

    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:

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

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

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

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

    ...

    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.

    Aus #16 (Eine gute Community ...)

    Flexibilität und Anpassungsfähigkeit: Eine gute Community ist in der Lage, sich an Veränderungen anzupassen und flexibel auf neue Herausforderungen zu reagieren.

    Dies sollte für jeden Erdenbürger gelten. Wie wir wissen, sind diese beiden Fähigkeiten nicht sehr breit verteilt anzutreffen, um es vorsichtig auszudrücken. ;)

    Das Tier Mensch stagniert offenbar in seiner Entwicklung ... (Vielleicht in diesem Forum etwas weniger als sonstwo.)

    Ich nehme hier Engagement, manchmal Zuversicht und gelegentlich Toleranz wahr - nach meiner Lebenserfahrung (geringfügig) überdurchschnittlich. Das genügt mir b.a.w. 8o

    Ich werde weiterhin nichtkommerziell mitwirken.