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.

    In der Anleitung sind zwar ein paar Fehler versteckt, aber das werde ich dann ändern.

    Ich konnte bisher keine Fehler entdecken.

    Da steht bei jede Stufe 1500Watt, was ja Blödsinn sein muß. Oder sehe ich das falsch?

    Das ist im allgemeinen kein Blödsinn. Wer weniger PV Peakleistung hat, kann ja bspw. 1kW Heizungen wählen, wer mehr hat bspw. 3kW.

    Ich habe mir nun von der E-Heizung drei Heizstäbe mit je 1500 Watt bestellt.

    Das ist mit Sicherheit gegenüber je 4kW für deine Zwecke die bessere Wahl. Vielleicht wären für deine Anlage je 1kW noch passender.

    Zur Anleitung aus der Shelly Wissensdatenbank:
    Die Shelly Leute wollen ihre Cloud bewerben. Ich halte zwar die angebotene Anleitung für prinzipiell gut und auch einfach umsetzbar, täte aber keinesfalls Cloud Szenen dafür nutzen. Das sollte mit lokalen Aktionen bereits gelingen. Falls nicht, genügt dazu ein kleines Skript, welches bspw. ich beisteuern könnte.

    Ob du zum schalten Shelly Ausgänge oder dahinter liegende Schütze nutzten willst, bleibt dir überlassen.

    Ob die Gesamtleistung in einer Aktion abgefragt/genutzt werden kann, weiß ich nicht, weil ich kein 3 EM habe. Das kannst du aber leicht herausfinden, indem du eine Aktion anlegst und nach der Gesamtleistung als Teil der Bedingung (Gesamtleistung unter -1.5kW) suchst. Per Skript ist sie jedenfalls abfragbar und damit die drei Heizungen schaltbar.

    Ich täte im Wohnwagen/Wohnmobil statt eines Relais ein SSR (Solid State Relay, reine Halbleiterschaltung) verwenden, weil ein SSR mit sehr schwachen Steuerströmen arbeitet und nebenbei den Ausgang des Plus Uni auch kaum belastet. Die Freilaufdiode kann auch dort nicht schaden.

    die Idee war den Arbeitsbereich statt 0-10V auf 5-15V zu verschieben

    Solches hatte ich mit Spannungsteiler nicht gemeint. Ein Spannungsteiler besteht aus einer Reihenschaltung aus mindestens zwei Widerständen. Am Mittelabgriff ist die Spannung gegenüber der Gesamtspannung reduziert (geteilt). Das Anheben einer Spannung gelingt damit nicht. Deine Wortwahl lässt darauf schließen, dass du sehr wohl Spannungsteiler kennst, mh ...

    Welche Logik setzt du da voraus?

    Ich sehe die Cloudansicht. Shelly, die als nicht in der Cloud konfiguriert sind, können doch wohl von dort nur als offline gesehen werden.

    Vielleicht täuscht dich da der Cache des Browsers?

    In aller Freunschaft ...

    Tja, dann sehe ich keine Lösung für deinen konkreten Wunsch.

    Btw, zeigt das wieder einmal, dass Endkunden von solchen Herstellern keine Möglichkeit geboten wird, etwas so einfaches, wie die Abfrage von Messwerten umzukonfigurieren, offenbar nicht einmal gegen Verlust einer Garantie. Umkonfigurieren kann mit Timestamp im nichtflüchtigen Speicher des Speichers abgelegt und somit von einer authorisierten Person leicht festgestellt werden. Solches zu implementieren, ist kein Kunststück. Dazu müsste der Hersteller aber erst einmal etwas von Kundenfreundlichkeit verstehen.

    Ob dein Elektriker da vielleicht eingreifen könnte? Zunächst als Rhetorische Frage zu verstehen.

    Das sind die Gründe, weshalb mir das relativ offene Konzept von Shelly gefällt.

    Meine laufende Analyse deines Skripts ...

    Vermutlich werde ich diesen Post nach und nach erweitern. Wenn am Ende das Wort "fertig" steht, habe ich meine Analyse (vorläufig) abgeschlossen.

    Nicht alles, was ich anmerke, hat unmittelbar mit der Funktionalität zu tun.

    1. Alter URL zu neuem Dimmer - ab Zeile 139, s.a. deine Zeile 93.

    Code
    Shelly.call(
                "http.get",
                { url: "http://" + deviceIp + "/relay/0?turn=toggle" },
                null,
                null
            );

    Dieser URL funktioniert, solange die Rückwärtskompatibilität erhalten bleibt und sich das auch auf die Component Light auswirkt. Ich täte stattdessen "https://shelly-forum.com/rpc/light.toggle?id=0" verwenden, was dafür vorgesehen ist. Und wozu die zwei überflüssigen null Werte? Das macht das Skript nur unübersichtlicher.

    Bspw. führt eine kurze Variante zu mehr Übersichtlichkeit und kann von anderen leichter gelesen werden:

    Code
    else if (logicalConfig.type === "switch" && event.info.state) {
            logMessage("Button " + logicalId + ": Sending toggle switch command.");
            Shelly.call("http.get", {url: "http://" + deviceIp + "/rpc/light.toggle?id=0"});
        }

    2. Eine andere Sequenz, die viel Platz einnimmt ab Zeile 111. Mein Vorschlag muss dir nicht gefallen. Er soll zeigen, wie ein Skript erheblich kürzer und imho übersichtlicher gestaltet werden kann.

    Mein Vorschlag mit derselben Funktionalität - 7 statt 21 Codezeilen:

    Code
            else if (event.info.event === "long_push") {
                dimstate[logicalId] = true;
                let up = up[logicalId];
                up[logicalId] = !up;
                logMessage("Button " + logicalId + ": Sending dimming " + (up?"down":"up") +" command.");
                Shelly.call("http.get", {url: "http://" + deviceIp + "/rpc/Light.Dim" + (up?"Down":"Up")+"?id=0&fade_rate=3"});
            }

    Wenn du bisher (wohlwollend) gelesen hast, kommt vermutlich hier die Belohnung. ;)

    S.a. API Dokumentation: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Light

    In Zeile 82 steht:

    Code
              { url: "http://" + deviceIp + "/rpc/Light.Stop?id=0" },

    Statt Light.Stop muss es Light.DimStop lauten.

    Code
              { url: "http://" + deviceIp + "/rpc/Light.DimStop?id=0" },

    Bin gespannt ...

    fertig

    timothydalton Ich bin auf die Doku angewiesen, weil ich (wie so oft) keinen Dimmer Gen 3 habe.

    da ich keinen Status Befehl nur für den Wert "Brigthness" finde, sondern nur den generellen Status.

    Wo ist das Problem?

    Für brightness sollte folgendes passen:

    https://shelly-api-docs.shelly.cloud/gen2/Component…tstatus-example

    Also

    Code
    http://<IP Adr. des Dimmers>/rpc/Light.GetStatus?id=0

    Auf die aktuellen Werte von Schaltzustand und Helligkeit greifst du somit wie folgt zu - error Infos lasse ich weg.

    Code
    Shelly.call("light.getstatus", {id:0}, function(res) {
    	let st = res.output; // st enthält den Schaltzustand - false = aus, true = ein
    	let br = res.brightness; // br enthält die Helligkeit in %
    }

    Zusätzlich sollte sich das Dimmziel abfragen lassen per

    Code
    let brTarget = res.transition.target.brightness;

    Ich schaue mir dein Skript mal genauer an. Bisher fiel mir deutlich einiges an Redundanz auf, was normalerweise total überflüssig ist. Die Funktionalität will ich noch analysieren, testen kann ich ja nicht.

    pa-nic

    Vorbehalt: Ich habe beide Shelly Geräte nicht, kann also nur Hinweise zur höchstwahrscheinlichen Machbarkeit geben.

    Mit der WLAN Verbindung zwischen EM Mini und dem Pro 3EM sowie einem sehr einfachen Skript auf dem Pro 3EM sollte das gelingen. Falls der EM Mini keine brauchbare WLAN Verbindung zu deinem Haus WLAN hat, sollte das WLAN des aktiven Access Point des Pro 3EM - selbstverständlich passwortgeschützt - oder auf dem Pro 3EM aktivierte Range Extender (wenn ein solcher zur Verfügung steht) genutzt werden.

    Der EM Mini Gen 4 sendet den Messwert ($value) an das Skript auf dem Pro 3EM per Methode "Script.Eval". Das empfangende Skript veröffentlicht dann per Funktion MQTT.publish und selbst gewähltem Topic den Messwert.

    Das Skript (ungetestet):

    Code
    function send(msg) {
    	MQTT.publish("mytopic", JSON.stringify(msg));
    }

    Ersetze das Topic "mytopic" durch das, was du brauchst! Abhängig von dem, was der Topic Abonnent erwartet, muss ggf. die Payload (msg) durch zusätzliche Komponenten erweitert werden. Die MQTT Nachrichten via Firmware enthalten solche zusätzlichen Komponenten. Es kann auch sein, dass der EM Mini indirekt auf eine vom Pro 3EM empfangene MQTT Nachricht antworten soll. Dazu ist mehr Information von deiner Seite erforderlich, weil das obige Skript dann komplexer werden muss.

    Der URL der Aktion auf dem EM Mini (ungetestet):

    Code
    http://<IP Adr. des Pro 3EM>/rpc/script.eval?id=1&code="send($value")

    Darin ist id=1 die Skript Id des Pro 3EM und $value ergibt sich aus dem die Aktion auslösenden Messwert.
    Bei Verwendung des Pro 3EM AP ist die IP Adresse 192.168.33.1. Dazu muss der URL um eine Authentifizierung ergänzt werden.

    Wenn komplexere Datenstrukturen per MQTT veröffentlicht werden sollen, gelingt dies mit Hilfe eines weiteren Skripts auf dem EM Mini. Dieses kann alle möglichen Daten des EM Mini abfragen und alles, was gewünscht ist, an das obige Skript übertragen. Ein solches Skript kann ich nicht mal schnell liefern, weil ich die Messdaten nicht kenne.

    Geht leider nicht und bei den lokale Aktionen ist die Konfig vom schaltenmöglichkeiten sehr eingeschränkt.

    Dies bezieht sich auf meinen Workaround Vorschlag, wenigstens zum testen.

    Nach https://shelly-api-docs.shelly.cloud/gen1/#shelly-3em-overview besitzt der 3EM einen Schaltausgang, welchen du zum testen ja auch nutztest.

    Bei einem Shelly 1 der Generation 1 gibt es im WebUI Menü den Punkt "I/O URL actions" und darunter u.a. die Einträge "OUTPUT SWICHED ON URL" sowie "OUTPUT SWITCHED OFF URL". Die gleichen Einträge gibt es auch in der Cloud/App. Gibt es diese beim 3EM etwa nicht?

    Wenn es diese beiden gibt, dann kann der Shelly Pro 2 darüber geschaltet werden.

    Zum einschalten:

    Code
    http://<IP Adr. Pro 2>/rpc/switch.set?id=0&on=true

    Zum ausschalten:

    Code
    http://<IP Adr. Pro 2>/rpc/switch.set?id=0&on=false

    Diese beiden URL sind im 3EM unter "OUTPUT SWICHED ON URL" bzw. "OUTPUT SWITCHED OFF URL" einzutragen.

    Informationen zu diesen URL gibt es hier: https://shelly-api-docs.shelly.cloud/gen2/Component…itchset-example

    Wenn dieses Workaround funktioniert, muss so etwas auch direkt auf den Pro 2 wirkend über Szenen gelingen. Allerdings gebe ich mir Szenen betreffend keine echte Mühe, diese genauer kennenzulernen, weshalb bei Szenen meine Unterstützung endet.

    Noch ein paar Hinweise/Fragen zu deiner Skizze:

    1. Der Stalllicht Shelly stellt den beiden anderen seinen AP zur Verfügung und ist zugleich mit dem Haus WLAN verbunden.
      Er bietet somit eine Kombination aus Insel und Range Extender.
    2. Die anderen beiden Shelly sind auf zwei Wegen erreichbar.
      1. Direkt per Haus WLAN.
      2. Über den Stalllicht Shelly und Port.

    Zum testen mag das zweckmäßig sein. Auf Dauer solltest du dich für einen der beiden Kommunikationswege entscheiden.

    Ist der Stalllicht Shelly immer gut erreichbar?
    Wenn ja, kommuniziere mit den anderen beiden Shelly über Stalllicht und Ports!
    Wenn nein, versuche diesen oder einen zusätzlichen AP Shelly näher an das Haus WLAN zu platzieren!

    Die Kommunikation über einen Shelly mit AP und Range Extender ist vermutlich die bessere Lösung gegenüber den direkten Wegen über das Haus WLAN, zumal diese näher beieinander platziert sind.