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.

    steffda

    Meine bisherigen Tests ergaben, dass es vermutlich mit Szenen nicht gelingen wird. Ich nutze keine Szenen und bin deshalb nicht sehr vertraut damit. Ich löse Fernzugriffe per VPN.

    Es dürfte am einfachsten sein, per Skript nur die Verfügbarkeit der Cloud zu prüfen, was bspw. ca. 5s dauern kann. Diese Verzögerung spielt aber bei Fernzugriff wohl keine Rolle.
    Bei Auslösen einer lokalen Action (an das Skript gerichtet), kann das Skript die Cloud-Verfügbarkeit prüfen und die Action nur dann ausführen, wenn die Cloud nicht verfügbar ist.

    Ich kenne das Cloud-Thermostat nicht aus eigener Erfahrung und weiß deshalb nicht, ob sich dieses mit Actions auf dem H&T beißen täte, vermute aber eher nicht.
    Das solltest du selbst herausfinden!

    steffda

    Wenn dir dieses Feature wichtig ist, habe ich folgende Idee dafür. Dafür ist ein Skript unabdingbar.

    1. Per Cloud wirst du eh Szenen einrichten.
    2. Du erstellst zum selben Zielgerät eine Szene, die alle paar Minuten eine Nachricht an das Skript sendet bspw. alle 3 Minuten - bisher ungetestet.
    3. Das Skript führt an es selbst gerichtete Action-Nachrichten nur dann aus, wenn die letzte spezifische, zeitgesteuerte Nachricht (s. 2) aus der Cloud 4 Minuten alt oder älter ist.

    Das ist alles ungetestet, sollte aber möglich sein. Der Vorteil wäre, dass du selbst per spezifischer Nachricht aus der Cloud eine solche Priorisierung aktivieren könntest. Das Zeitintervall ließe sich auch kürzer parametrieren, ich bin halt kein Freund von hohem Traffic.

    Die reine Verfügbarkeit meines Cloud-Servers kann ich inzwischen abfragen. Das genügt aber vermutlich nicht zur Priorisierung.

    Eine Art Vorrangschaltung wäre da schön, so dass die Cloud Priorität hat, und wenn die nicht verfügbar ist, dann die Actions greifen.

    So etwas als fertiges Feature ist mir unbekannt. Per Skript lässt sich eine solche Priorität implementieren, da ein sog. Event auch die Quelle des Event in seiner Information mitliefert. Ein von der Cloud ausgelöstes Event hat als "src" Wert "SHC" (vermutlich von SHelly Cloud) und ließe sich priorisieren. Dann müssten allerdings die Actions das Skript ansprechen, damit dieses solche Actions ggf. unterdrücken könnte.

    Eine Cloud-Verfügbarkeit habe ich bisher in keinem Skript abgefragt und weiß deshalb nicht, wie dies gelingen kann. Ich las an anderen Stellen etwas, was darauf hindeuten könnte, dass so etwas möglich sei.

    Fazit: Es sollte möglich sein. Dazu müsste sich jemand der Mühe unterziehen, solches zu testen - vielleicht ich. ;) Mal sehen ...

    Jan_Stfbg

    Das Prinzip (zum Verstehen) der MQTT Kommunikation per Shelly Generation 2+ Firmware: Request and Response

    1. HomeMatic muss eine MQTT Nachricht senden mit
      a) einem Identifier zwecks eindeutiger Zuordnung der Shelly Antwort zur gesendeten Nachricht,
      b) eine Quellenangabe, hier das HomeMatic, welche in der Shelly Antwort als Pre-Topic verwendet wird,
      c) die RPC Methode, ggf. ergänzt durch Parameter
    2. Die Shelly Firmware wird wie folgt antworten, wenn Request verarbeitet werden konnte.
      Topic: <Quellenangabe aus 1.b)>/rpc, Payload: eine Information zur Verarbeitung des Request

    Beispiel (unabhängig von HomeMatic):

    zu 1. MQTT Request Nachricht:
    Topic: <im Shelly eingetragenes MQTT prefix>/rpc
    Payload: '{"id":"mein_Versuch","src":"aha/so_gehts/also","method":"switch.set","params":{"id":0,"on":true}}'
    Die Payload lässt den Ausgang 0 einschalten.

    zu 2. MQTT Response Nachricht vom Shelly:
    Topic: "aha/so_gehts/also/rpc"
    Payload: '"result":{"was_on":false}' ... und weiteres wie der "id" Wert "mein_Versuch" ...
    wenn vor dem Einschalten ausgeschaltet war.

    Vielleicht habe ich eine kleine Abweichung in der MQTT Response eingebaut, was aber wenig relevant ist. Alles andere dürfte stimmen und die Antwort ist per Topic leicht überprüfbar.

    Vermutlich baut HomeMatic seinen eigenen "src" Wert ein.

    Edit:
    Vermutlich ließe sich notfalls ein Adapter per Node-RED Flow implementieren. Blockly ist nicht meins - zuviel drumherum für wenig Code. Ich glaube in HomeMatic heißt es statt Node-RED "Red-Matic".

    Zur Component MQTT in der Dokumenttion

    Reveive notifications over MQTT

    Send command over MQTT example

    Darüber ist einiges in der Dokumentation zu finden. Zusätzlich ließen sich noch Anwender definierte Topics und Payloads, so heißen die Bestandteile von MQTT Nachrichten (was du als Pfade bezeichnetest), per Skript verwenden.

    Die per Firmware verwendeten Nachrichten basieren auf dem Request/Response Prinzip, wozu MQTT nicht zwingend gedacht ist.

    Da ich kein fertiges übergeordnetes System nutze, kann ich dir zur CCU3 bzw. HomeMatic(?) nichts mitteilen. Ich weiß aber, dass darin auch eine Node-RED Variante zur Verfügung steht ...

    Super Dankeschön werde ich so machen ....wer hat dann vorrang Shelly oderWetterstation ?

    Ich habe keine Wetterstation, aber die Anleitung zu deiner Station gelesen.

    Die Station meldet etwas an den Shelly, welcher darauf reagiert, wenn der von der Station kommende URL verarbeitbar ist. Wenn die Station den URL zum einfahren der Markise sendet, wird der Shelly dies tun, unabhängig vom Zeitplan. Ebenso umgekehrt. Es gibt auf diesem Weg keine Priorität. Prinzipiell könnte eine Prioritätenliste per Skript implementiert werden, aber ...

    Wozu brauchst du eine Priorität und welche Aktionen sollten darunter fallen?


    Nachfrage:
    Ich sah mir die Fotos von dieser Wetterstation an. Sieht alles nach Kunststoff aus und die Windmesserflügel haben filigrane Ärmchen, die schnell altern und abbrechen dürften, wenn diese aus Kunststoff sind.
    Gibt es dbzgl. mit dieser Station bereits Langzeiterfahrungen oder sonstige Erfahrungen?

    Du entscheidest über deinen (längeren ;)) Code.

    Bereits in C ist das Resultat eines booleschen Ausdrucks ein Wahrheitswert. Aber Hauptsache ist, dass du mit deinem Skript zurechtkommst und dich sicher fühlst.
    Vermutlich ist die eigene Lesart entscheidend. Ich lese x = y > 0 so: x ist definiert als "Der y Wert ist größer als 0".

    Konntest du etwas über die Ursachen der Skript Stopps herausfinden?

    Diese URL hast du aber bereits in den beiden Actions auf dem H&T eingesetzt, sollten somit wie gewünscht funktionieren.
    Stimmt vielleicht die IP Adresse des Shelly nicht, der schalten soll?


    Btw, die Ausgabe von Webhook.ListSupported kannte ich noch nicht. Diese kann ich zwar verstehend lesen, aber keinem Webhook (=Action) zuordnen.

    akreienbring

    Du hast die Aufrufstruktur passend aufgezeigt.

    Und dann gibt es noch HTTPServer Endpoints, im Empfängerskript einzubauen. Diese können sowohl per GET als auch per POST Nachrichten empfangen.
    Vorteil: Ein Skript wird bei einem Fehler nicht angehalten, es wird dann halt nicht das Gewünschte ausgeführt.

    Wenn bspw. bei Methode "Script.Eval" ein Tippfehler im Funktionsnamen innerhalb des URL vorliegt, stoppt die Firmware das angesprochene Skript.

    Für ein solches Skript bräuchte bspw. ich klare Beschreibungen der Voraussetzungen, des Anliegens und der vorhandenen Ausstattung ... und vielleicht auch ein wenig der eigenen Fähigkeiten des Auftraggebers. ;)

    Btw, es gibt hier noch andere, die ein solches Skript erstellen können.