Beiträge von eiche

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.

    puhx666 Das wird nun hier off topic. Vielleicht sollte ein Moderator deinen und meine Beiträge separieren.

    Zu deinem Anliegen helfe ich gerne weiter. Dazu muss ich deine beteiligten Geräte genauer kennen.

    1. Wie stellst du die (störende) Sonneneinstrahlung messtechnisch fest?
    2. Mit welchen Mitteln steuerst du ansonsten deine Rollläden?
    3. Nutzt du bisher VPN?

    SiloBau

    Neue Skriptversion - die Beschreibung des Verhaltens wie in #39.

    Zusätzlich wird der Eingang mit dem Schaltensperren auch gesperrt und mit dem Schaltenfreigeben auch freigegeben. Du kannst diesen Zusatz mit

    Code
    InpCfg = false

    auch deaktivieren - Zeile 6 im Skript.

    Vorteil:

    Damit wird die Wirkung des Eingangssignals während der Einschaltsperrphase ebenfalls verhindert und danach wieder aktiviert. Damit kannst du auch das Eingangssignal mit einem "sichtbaren" Shelly schalten, wodurch der "unsichtbare" und schaltende Shelly wirkungsmächtig während der Sperrphase am Schalten gehindert wird - dann gibt es auch kein sehr kurzes Einschalten während der Sperrphase.

    Nachteil:

    Mit jedem Einschalten wird etwas in den nichtflüchtigen Speicher geschrieben, welcher bekanntermaßen deutlich weniger Schreibzugriffe verträgt als flüchtiger Speicher (RAM). Vermutlich wird der Shelly trotzdem lange genug leben bzw. nicht aus diesem Grund sterben (Elkos dürften problematischer sein, allerdings austauschbar).

    Was du bevorzugst, musst du selbst entscheiden. Je häufiger eingeschaltet wird, desto schneller altert der nichtflüchtige Speicher.

    Das Skript

    Soeben fällt mir eine noch bessere Variante ein, welche ich nachreichen will und die nicht in den nichtflüchtigen Speicher schreibt.

    Dazu wird der Eingang von der direkten Wirkung auf den Ausgang entkoppelt (Eingang als "detached" konfigurieren). Der Eventhandler check() kann dann Signaländerungen am Eingang erfassen und passend entscheiden, ob der Ausgang eingeschaltet wird oder nicht. Das kann ich aber erst testen, wenn ich wieder zu Hause bin.

    Gibt es eine "Plattform" , die ich sämtliche Daten aus Fronius, Shelly und dem Speicher bündeln kann?

    Ich nutze für so etwas Node-RED. Das ist eine Programmierumgebung, die oftmals das Programmieren durch grafische Symbole deutlich erleichtert. Damit kann ich sehr viel experimentieren und herausfinden. Bei Bedarf schiebe ich mir damit auch Adapter zusammen, allerdings zumeist auch mit JavaScript Code.

    Ein übergeordnetes System (openHAB, ioBroker, HomeAssistant, ...) könnte dich bei deinen Anliegen unterstützen.

    SiloBau

    Hier nun mein erster Entwurf. Beschreibung des Verhaltens:

    1. Es wird eingeschaltet.
      1. Regulär, d.h. außerhalb der Sperrzeit (Schalten ist freigegeben) -> Nach 5s wird ausgeschaltet und Sperren gestartet.
      2. Irregulär, d.h. innerhalb der Sperrzeit (Schalten ist gesperrt) -> Es wird sofort ausgeschaltet, ohne Sperren zu manipulieren.
    2. Es wird ausgeschaltet.
      1. Weil Einschaltdauer abgelaufen -> Sperren gestartet, nach 2min wird Sperren beendet
      2. Weil vom Anwender "dazwischengefunkt" (irregulär) -> nichts sonst
    3. Einschaltdauer abgelaufen (mit oder ohne schalten) -> Sperren gestartet, nach 2min wird Sperren beendet

    Irreguläres Schalten hat keinerlei Sperr-/Freigabewirkung. Reguläres (vorgesehenes) Einschalten schaltet nach Ablauf der Einschaltdauer aus und startet die Sperrphase. Nach Ablauf der Sperrphase wird das reguläre Einschalten freigegeben.

    Damit findet kein retriggern statt.

    Hiermit wird ein sehr kurzes, irreguläres Einschalten nicht verhindert, weil dies mit einem Shelly per se unmöglich ist. Stattdessen wird ein irreguläres Einschalten sofort beendet.

    Der Anwender kann jederzeit ausschalten, aber das Sperren wird erst nach Ablauf der Einschaltdauer gestartet.

    Vermutlich wird dir dieses Verhalten bereits genügen. Andernfalls siehe in #36

    Noch einmal der Hinweis zur Alternative: ...

    Das Skript

    Hinweis: Die Console Ausgaben via print kannst du dazu nutzen, das Verhalten genauer zu prüfen. Dabei solltest du die Zeitstempel am rechten Rand jeder Ausgabe hinzuziehen. Daran kannst du das Zeitverhalten erkennen. Testen kannst du mit einem Schalter/Taster am Eingang oder einem weiteren Browser Tab, in welchem du die Startseite des Shelly dazu verwendest, um zu schalten - oder auch mit der App.

    SiloBau

    In aller Freundschaft - im Skript fehlt der für die Funktion wesentliche Teil des sofortigen Ausschaltens nach dem verbotenen Einschalten.

    Ich werde ein komplett neues Skript dafür schreiben, welches du dann testen solltest.


    Noch einmal der Hinweis zur Alternative:

    Deinen jetzigen Shelly soweit wie möglich verstecken - keine Cloud, keinen Link dorthin, keine Weitergabe der IP Adresse. Sein Ausgang darf ausschließlich via Eingang geschaltet werden!

    Zweiten Shelly mit potentialfreiem Ausgang (Shelly 1 der Generation 1 täte genügen) einsetzen, der parallel zu deinem Schalter den schaltenden Shelly an dessen Eingängen ansteuert. Dieser zweite Shelly darf so sichtbar sein, wie du es haben willst.

    Mit dieser Kombination lässt sich weitgehend ein Einschalten sperren, weil der Eingang des schaltenden Shelly (temporär) gesperrt werden kann.

    Du willst vermutlich die Ausgaben des Skripts sehen.

    Der Weg dorthin auf der Webseite des Shelly, nicht die App:
    (Falls du ein Smartphone verwendest, musst du ggf. wiederholt auf das "Hamburger Menü", kurz HM, (=3 Striche untereinander) klicken/drücken.)

    Startseite (Home) -> (HM ->) Scripts -> alle gespeicherten Skripte werden untereinander aufgelistet (bei dir vermutlich nur eines) -> Das Skript (Name) anklicken -> Der Skript Code erscheint in einem Fenster mit weißem Hintergrund, darunter das Console Fenster, in dem die print Ausgaben erscheinen.

    Über virtuelle Komponenten?

    Mit virtuellen Komponenten hat das nichts zu tun.

    Was meinst Du mit (Konversationen (=PM/PN). Da stehe ich auf dem Schlauch...

    Schau mal oben rechts die beiden Sprechblasensymbole. Wenn du darauf klickst, kannst du eine Konversation "unter vier Augen" starten, auch personal massage (PM) oder persönliche Nachricht (PN) genannt.

    habe das Zeitrelais-script etwas geändert, das zweite Einschalten auf switchOff, natürlich wird nachgetriggert.

    Du meinst vermutlich eines der Skripte von tvbshelly . Eine Retriggerung ist weder "natürlich" noch "selbstverständlich", kommt aber leicht (versehentlich) vor. ;)

    Ich werde mir das letzte Skript dbzgl. genauer ansehen.

    Besser: Poste hier bitte das von dir geänderte Skript!

    Was kann man mit diesem Code wo was machen ?

    Dieser von dir genannte "Code" ist eine Struktur von Daten - Messdaten, Zustandsdaten, Zeitdaten (evtl. Konfigurationsdaten).

    Diese braucht man, wenn man an bestimmten Informationen interessiert ist. Dazu muss man diese Struktur kennen (lesen können), um auf einzelne Teile darin passend zugreifen zu können.

    Das kam heraus als ich oben die Adresse eingegeben habe:

    Welche Adresse hast du eingegeben? In diesem Thread sind zumindest zwei verschiedene angegeben.

    Denke ohne Script geht es nicht?

    So sehe ich das, ja.

    Du solltest dich hier ein Stück weit von deiner SPS Erfahrung lösen. Bei SPS erstellst du ja das zyklisch abzuarbeitende Programm, ähnlich der Arduino Programmierung (loop()). Hier tut das die Firmware, die "nur" offen dafür ist, RPC Aufrufe entgegenzunehmen, Zeitpläne abzuarbeiten und Ereignisse (für Skripte und Aktionen) mitzuteilen. Deshalb kannst du hier nicht den kompletten Ablauf grundlegendst steuern, sondern nur bei Bedarf und Aktion/Skript eingreifen lassen.

    Insgesamt halte ich dieses Konzept für sehr gut und insbesondere die API Kommunikation sehr gut dokumentiert. Weitere Vorstellungen und Wünsche könnte ich einbringen, was aber die allermeisten Anwender nicht interessierte, weil sie in erster Linie auf einfachste Weise ein Ziel erreichen wollen.

    Ich hoffe hiermit ein wenig in deinen Vorstellungen aufgeräumt haben zu können. Du darfst aber gerne weiter nachfragen, ggf. auch per Konversationen (=PM/PN).

    depty24

    Per Skript (jaha, immer noch ;)) gelingt das zumindest annähernd.

    Damit kann (die Quelle des Schaltens erfasst - hier unwesentlich und) der Eingangszustand abgefragt werden.

    Sobald ausgeschaltet wird, prüft das Skript den Eingangszustand und schaltet ggf. sofort wieder ein.

    Per Aktion? Mhh ... wäre zu prüfen.

    SiloBau Was soll "einschaltwischend gestartet" bedeuten? Vermutlich Ausgang temporär einschalten.

    Das sollte mit folgenden Maßnahmen (fast) gelingen. Ich dachte zunächst nur an eine Aktion, was aber nicht gelingen dürfte.

    Einschränkung: Es ist afaik bisher ausschließlich möglich, den Eingang zu deaktivieren und unmittelbar nach dem Einschalten sofort wieder auszuschalten. Ein Schalten per App, WebUI, ... kann bisher nicht verhindert werden. Ich setze voraus, dass das Einschalten immer 15s dauern und das Schalten nicht periodisch eigenständig generiert werden soll.

    1. Stelle den Einschalttimer auf 15s! Kleines Uhrsymbol auf der Startseite des WebUI -> Timers ...
    2. Optional: Eine Aktion, die auf das Einschalten hin den Eingang disabled.
      http://localhost/rpc/input.setc…enable%22:false}
      Dies macht das Signal am Eingang unwirksam, verhindert aber nicht das Schalten per WebUI ...
      Optional ist das, weil es auch per ohnehin erforderlichem Skript erledigt werden kann.
    3. Ein Skript, welches wie folgt reagiert.
      1. Mit dem Einschalten wird der Eingang disabled - s.o. 2.
      2. Eine boolesche Variable "Enable" wird auf false gesetzt
      3. Mit dem Ausschalten wird ein Timer gestartet, der nach 30s "Enable" auf true setzt.
      4. Ein sog. Eventhandler erfasst das Einschalten. Wenn "Enable" = false ist, schaltet er sofort wieder aus. Damit dürfte der Ausgang für geschätzt max. 50ms eingeschaltet bleiben (Relais abhängig). Besser dürfte es nicht gelingen, weil bisher die Firmware kein Ereignis sendet, welches das Schalten ankündigt oder um Erlaubnis dafür nachfragt. Auch kann der Ausgang nicht disabled werden.

    Bei Muße kann ich ein passendes Skript nachreichen.

    Du könntest den Shelly im WLAN für weniger Wissende "verstecken", nicht in die Cloud einbinden und einen zusätzlichen, "sichtbaren" Shelly davor setzen, der ausschließlich den Eingang des anderen Shelly parallel zu einem Taster/Schalter steuert. Damit kann relativ sicher ein sehr kurzes Einschalten verhindert werden.