Beiträge von Deti_Hkln

    So. Alle Änderungen gemacht. Rechner aus. Mist. Der Drucker ist ja noch an. Naja, App laden, Drucker aus.

    Geht aber auch "einfacher". Die Möglichkeit, Scripte beim Herunterfahren von Win$-Rechnern hat M$ ganz schön versteckt.

    Rufen Sie dazu in der Suche (o.ä.) die Datei GPEDIT.MSC (Gruppenrichtlinie) auf. Führen Sie die Änderungen als Admin durch, wenn Sie es nicht sowieso schon sind.

    Navigieren Sie im Fenster "Struktur" zu "Computerkonfiguration, Windows-Einstellungen" zu "Scripten". Rechts finden Sie dann einen Eintrag "Herunterfahren".

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

    Darauf einen Doppelklick. Darauf startet ein Dialog, der zunächst ein - bis auf einige Buttons - leeres Fenster zeigt.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
    Hier klicken Sie auf "Hinzufügen", um den Scriptnamen einzutragen. Den können Sie sich merken (inklusive Pfad) oder Sie durchsuchen die Platte mit dem entsprechenden Knopf.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
    Im Endeffekt kann jede Datei ausgewählt werden, nur darf die keine Eingaben erwarten. Und ein Fenster aufblitzen sehen sieht auch nicht schick aus. Daher am besten die .vbs-Datei auswählen.

    Alle Fenster schließen, und schon geht der Drucker aus, wenn Sie den Rechner herunterfahren.

    Schlecht nur, wenn nun noch jemand drucken möchte. Daher funktioniert das nur in einer Einplatzumgebung ohne Probleme.

    Gruß

    Detlev

    Stimmt.

    Auf was man alles achten muss, tztztz. Da muss ich beim nächsten Posting besser drüber lesen. Klar müssen die gleich sein, sind sie bei mir ja auch. Aber abtippen ist dann doch nicht ganz so einfach :)

    LG Detlev

    Hallo,

    mMn könnte genau das Gegenteil eintreten: da kein (warmer) Rücklauf, kühlt die Wassersäule mehr und mehr aus. Dadurch erkennt die Heizung (der Mischer, die Hochenergiepumpe, ..., was auch immer) eine 100%-Ausnutzung der anstehenden Vorlaufwärme und gibt so richtig Vollgas. Hängt aber auch von der genauen Ausprägung der spezifischen Messtechnik ab.

    Warmwasser ist etwas anderes - da geht es i.d.R. "nur" um eine Zirkulationsleitung, d.h., wenn diese Pumpe nicht läuft, dauert es eben (unzulässigerweise) länger, bis warmes Wasser aus der Zapfstelle strömt.

    Gruß

    Detlev

    Hallo

    @7of9,

    klar geht das geht auch, aber das Problem dabei: es wird dann in einem sichtbaren Fenster aufgerufen. Selbst "minimiert" kann man es dann in der Taskleiste sehen. Fand ich unschön.

    Nebenbei: will man das z.B. in den Taskplaner mit aufnehmen, geht das nur über die .vbs. Eine .bat nimmt der nicht.

    SparkyMaster

    klar, kein Problem.

    Gruß

    Detlev

    Hallo,

    nun, ist es tatsächlich ein Notschalter - oder nur ein Wartungsschalter? Aber egal: mit einem Shelly würde es zwar gehen, man rennt aber in die Problematik, das die Schalterstellung dann nicht mehr zwingend den Betriebszustand darstellt, was aber laut VDE 0116 notwendig ist. Außerdem ist im Falle eines Notschalters eine allpolige Trennung (bis auf PE) vom Netz vorgeschrieben - das kann ein Shelly so nicht.

    Nebenbei: man handelt sich dann auch noch ziemliche Auskühlverluste in der Wohnung ein. Je nach Wetterlage und Dauer kann das dann schon mal mit einem großen Kühlschrank gleichgesetzt werden. Und das wieder hochzuheizen dauert. Außerdem ist i.d.R. das Brauchwasser dann auch "eiskalt", und alle anderen Umwälzpumpen usw. stellen ebenfalls den Dienst ein. Im Falle einer Solarthermie gibt das dann schon mal Probleme.

    Ich würde es lassen, maximal den "abgesenkten Betrieb" aktivieren und gut ist.

    Gruß

    Detlev

    Wer wie ich häufig am Windows-Rechner sitzt, möchte ggf. den Drucker einschalten - oder das Bürolicht. Und der Weg zum Schalter ist sooo weit. Da gibt es eine kleine Lösung: ein Shelly (in meinem Fall "PlugS" und "1" kann ohne großen Aufwand von einem Windows-10-Rechner aus mit Bordmitteln angesprochen werden.

    Zunächst erstelle man eine kleine ".bat"-Datei, beispielsweise "Buerolicht_schalten.bat". Wichtig dabei: keine Umlaute, Leerzeichen oder Sonderzeichen (#, $, ...), weder im Dateipfad noch in dem Dateinamen selber.

    Der Inhalt dieser Datei ist recht einfach:

    Code
    powershell -command "Invoke-WebRequest -Uri http://192.168.2.75/relay/0?turn=toggle -Method POST"

    Damit beim Aufruf das dann nicht ständig im Fenster abläuft, wird noch eine winzige "Buerolicht_schalten.vbs" angelegt:

    Code
    Set wshShell = wscript.CreateObject("WScript.Shell")
    wshShell.Run "c:\users\xxxxxx\Documents\Buero_Licht_schalten.bat",0,True

    Diese Datei kann dann auf dem Desktop platziert werden. Wenn's jetzt dunkel wird, reicht ein doppelklick auf die Ikone, und schon geht das Licht an (oder der Drucker oder ...)

    HTH

    Detlev

    Hallo,

    das Problem ist nicht das Einstellen des Codes, sondern Exportieren desselben. In den HTTP-Requests sind die Namen der Variablen und Scripte in einem internen Format abgelegt, so das ein einfaches Verteilen mittels Dateien schon problematisch werden kann.

    Aber fangen wir mal an:

    Zunächst läuft der "Flow" "Zuhause_AnAus" auf dem Handy. Leider gibt es da keinen Quellcode zu, nur den Flow oder ein Bild.

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

    Zum Abmelden läuft "Zuhause_Logoff" ("Abmeldung vom Netzwerk"). Damit wird die aktuelle Zeit in einer statischen Variablen gespeichert:

    Code
    // holen aktuelles Datum und Uhrzeit 
    var jetzt = (new Date());
    
    // umsetzen in laufenden Wert 
    var jetztzeit = jetzt.getTime();
    
    // und merken (in Millisekunden seit dem 1.1.1970)
    setVariable("Zuhause_Datum", jetztzeit);

    Zum Anmelden - also beim Wiedereintritt in den umzäunten Bereich, läuft "Zuhause_Logon" ("Anmeldung am Netzwerk"). Dieser ist nur der Aufrufer für den eigentlichen Teil der Arbeit:

    Code
    // aufruf des eigentlichen Scripts
    triggerShortcut("Zuhause_Logon_Aktion");

    In dem Script "Zuhause_Logon_Aktion" ("Anmeldung am Netzwerk: Geräte holen, in Schleife abarbeiten") wird der logische Teil der Arbeit durchgeführt:

    Im folgenden Request "Zuhause_Logon_Aktion_Status" ("Anmeldung am Netzwerk: Gerät Status auslesen") wird der Status abgefragt.

    Hier wird dann auch der 1. HTTP-Request auf einen Shelly abgesetzt:

    Code
    http://{SH_IP_URL}/{SH_IP_Typ}/{SH_IP_Relais}/status

    Nach der Ausführung wird der Response abgearbeitet. Auch der Kommentar am Anfang darf nicht weggelassen werden, da hier durch den Parser Variablen erkannt werden, die später noch Verwendung finden:

    Wenn im Response festgestellt wurde, das eine Aktion erfolgen muss, wird das im letzten HTTP-Request "Zuhause_Logon_Aktion_Exec" ("Anmeldung am Netzwerk: Gerät schalten mit Timer") ausgeführt:

    Code
    http://{SH_IP_URL}/{SH_IP_Typ}/{SH_IP_Relais}/?turn={SH_OnOff}&timer={SH_Duration}

    Im Bereich der HTTP-Request-App müssen diverse statische Variablen definiert werden. Zum Teil werden diese als Speicher verwendet, zum Teil als Parameterübergabe:

    Der Inhalt der Variablen für die Parameterübergaben ist zweitrangig, da diese in den Scripten überschrieben werden

    Code
    SH_IP_URL                // IP des Shellys
    SH_IP_Typ                // Typ des Shellys ("relais")
    SH_IP_Relais             // Nummer des Relais (0)
    SH_OnOff                 // Ein- oder Ausschalten ("on")
    SH_Duration              // Dauer des Einschaltens in Minuten (7)

    Interessanter werden die Variablen, die als Speicher dienen.

    Code
    Zuhause_Datum             // Datum der letzten Abmeldung - Inhalt wird vom Script aktualisiert
    Zuhause_73                // Definition eines Gerätes
                              // IP ; Typ ; Nummer ; Nachzeit ; on/off ; Dauer;
                              // 192.168.2.xx;relais;0;7;on;60
    Zuhause_Geraete           // Summe der Zuhause_xx
                              // {Zuhause_73}"{Zuhause_74}

    Die Variable "Zuhause_Datum" ist der Speicher der letzten Abmeldung. Dagegen wird beim nächsten Wiedereintritt verglichen, ob etwas gestartet werden soll.

    "Zuhause_73" ist vom Namen her unerheblich, sie dient nur der Speicherung der Parameter für einen Shelly, der beim Wiedereintritt beackert wird. Es kann davon (fast) beliebig viele geben.

    "Zuhause_Geaete" ist die von den Scripten ausgewertete Variable, welche die Summe der einzelnen Geräte enthält. Hier werden die einzelnen Variablen eingefügt und durch ein Hochkomma (") getrennt.

    HTH

    Detlev

    Hallo zusammen,

    ich möchte hier mal vorstellen, was mit der HTTP-Request-App im Shellyversum so alles möglich ist:

    Es gab einige Bedingungen, die (für mich) erfüllt werden sollten:

    - kein übergeordnetes System, nur Smartphone und Shelly

    - kein VPN, da bei DS-Lite das schon mal problematisch sein kann, insbesondere bei eingehenden Verbindungen aus dem Mobilfunknetz

    - Geolocation und Geofencing sollten die Trigger sein

    Folgende Apps werden auf dem Smartphone benötigt - zumindest in meinem Lösungsansatz:

    - HTTP-Request

    mit dem letzten Update vom 18.3. - davor laufen Schleifen mit Mehrfachaufrufen nicht ganz sauber durch, wodurch nicht mehrere Shellys hintereinander geschaltet werden können

    - AUTOMATE

    als Überwachungsinstanz für Geolocation und Geofencing und Auslöser für die Scripte. In der "freien" Version können 30 "Blöcke" aktiv laufen, aber das reicht für dieses Projekt. Auch hier sollte die neueste Version genutzt werden, da Google in den neueren Android-Versionen den Benutzern die Intelligenz abspricht, den WLan-Status per App setzten zu lassen.

    Da ich ja den Rest in HTTP-Request laufen lasse, sollte es auch mit Tasker o.ä. funktionieren.

    So, nun mal los:

    Auf dem Smartphone wird in Automate ein so genannter "Flow" geladen und gestartet - der bleibt auch "für immer" aktiv.

    In diesem Flow wird mittels GPS geprüft, ob ich zu Hause bin oder nicht. Verlasse ich nun mein Haus und gehe durch das virtuelle Zauntörchen, wird dies erkannt und über den Aufruf eines HTTP-Request dieser Zeitpunkt im Smartphone vermerkt.

    Irgendwann komme ich wieder nach Hause (hoffe ich jedenfalls). Beim klettern über'n Zaun wird auch das wieder erkannt. Zu diesem Zeitpunkt wird ein weiter HTTP-Request aufgerufen.

    Dieser HTTP-Request (an und für sich nur Scripting) kümmert sich dann um folgendes:

    - Auslesen einer Variablen, in der alle Shellys aufgelistet sind, die ich schalten möchte.

    - Je Shelly wird geschaut, nach welcher Zeit der Abwesenheit er aktiviert oder deaktiviert werden soll - und für wie lange.

    So wird beispielsweise die Wallbox frühestens nach einer halben Stunde der Abwesenheit eingeschaltet.

    - Bei positiver Prüfung wird dann der Shelly geschaltet, wobei hier eine Rolle spielt, ob der Status der gleiche ist, wie der zu erzeugende. Wenn ja, passiert nichts. Warum: wenn jemand das Außenlicht schon angeschaltet hat, ist es nicht sinnvoll, das es 10 Minuten nach meinem Eintreffen aus geht; dann sollte es besser an bleiben.

    Was noch fehlt, ist die Zeitabhängige Steuerung.

    Bei Interesse kann ich versuchen, hier mal die Scripte zu hinterlegen - gestaltet sich komplizierter als gedacht.

    Gruß

    Detlev

    Hallo,

    wer - wie ich - einen Shortcut in einer Schleife mit unterschiedlichen Werten für eine Variable aufrufen wollte, hatte das Problem, das die Übergabe erst nach mehrmaligen Durchläufen richtig funktionierte. Dieser Käfer wurde nun in der Version 2.2.0 vom 14.3. durch Roland festgenagelt.

    Danach funktioniert der Mehrfachaufruf einwandfrei.

    Gruß Detlev

    Hallo,

    zu 2: wenn es das ist, was ich vermute (wissen kommt nach Installation und Tests), dann kann ich es nun mit HTML, CSS, Canvans und Javascript schaffen, eine (einfache) Visualisierung in eigenen Netz im Browser zu erschaffen. Und dies ohne ein "übergeordnetes System".

    Warum nicht vorher: angenommen, mein Browser läuft auf IP 192.168.2.113, mein Shelly auf 192.168.2.74. Dann hat der Browser wegen der CORS-Richtlinien (IP 113 <> 74) hier mit einem gewissen "Unverständnis" reagiert, da der Shelly nicht mitteilen konnte, das dies "erlaubt" ist.

    Gruß Detlev

    Hallo,

    ok, dann mal ein Versuch:

    Wenn es keine Schaltrelais gibt, dann Bild lässt mich dein Bild vermuten, das es sich um einen Kreuzschalter handelt.

    Am Anfang der Kette steht ein Wechselschalter, dann kommen 4 Kreuzschalter, und am Ende wieder ein Wechselschalter, von wo der "Lampendraht" abgeht. Diese Dose gilt es zu finden - um dann festzustellen, das weder "L" noch "N" vorliegt :(

    Ich hab's mal grob aufgezeichnet. Vielleicht hilft es ja. Wie gesagt: für den Shelly brauchst du eine dauerhafte Spannungsversorgung - ohne "L" geht's vielleicht noch. Für die Beschaltung desselben bitte in den Anschlussplänen nachsehen.

    HTH

    Detlev

    Hallo Christian,

    wie unter den HTTP-Requests angegeben:

    Schalten Shelly1 Relais EIN mit Timer in Sekunden

    http://192.168.xxx.xxx/relay/?turn=on&timer=30

    Dieser Befehl wird in beiden Motions eingetragen, so das einer von beiden den Shelly1 triggert.

    Wenn der Shelly "an" war, wird er erneut eingeschaltet mit 30 Sekunden Nachlaufzeit. Die sollte auf jeden Fall länger sein als die Zeit in einem der Motions - sonst schaltet der Shelly1 ab, bevor wieder auf eine Bewegung reagiert wird.

    HTH Detlev