Beiträge von bp4willi

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.

    War ich beim Kauf der Meinung, dass ich damit mein WLAN erweitern könnte...

    Es war doch klar, das LoRa eine ganz andere Technik ist, und keine WLAN repeater Funktion.

    Oder hattest du dich nur missverständlich ausgedrückt?

    Natürlich kann LoRa dafür genutzt werden Shelly Bausteine anzusteuern, die außerhalb der WLAN Reichweite liegen. Das hat aber dann nichts mehr mit WLAN zu tun.

    Ob der ferne LoRa-Shelly dann als Bluetooth oder WLAN Kontakt für weitere Shelly (und nur Shelly, keine anderen WLAN Clients) dienen kann, ist wohl noch nicht eruiert worden.

    Meine Schätzung aufgrund persönlicher Nutzung und Batterieentleerung im Testobjekt, liegt bei ca 1000 Fensteröffnungen.

    Was leider für meinen Anwendungsfall echt nicht viel ist.

    Ich hätte mir das zehnfache erhofft.


    Habe es denn eine Möglichkeit, die Anzahl der Meldevorgänge in einem Shelly zu zählen?

    Da müsste ja ein Blu Door mit einem Shelly verknüpft werden, damit dieser per Skript in einem virtuellen counter zählen kann. Oder so....

    Ich habe einen mechanischen End-taster gebastelt, der aktiviert wird , wenn das Garagentor zu ist.

    Den habe ich mit dem SW Eingang des Shelly 1 Mini verbunden, der auch das Tor steuert. Der SW Eingang ist aber auf detached gestellt.

    Jetzt zeigt mir der kleine rote oder grüne Strich im Button des Shelly Mini an (das ist die Anzeige des Eingangs Status), ob das Tor auf oder korrekt zu ist.

    Ich würde davon abraten den Shelly Mini stromlos zu halten und nur zum schalten mit Strom zu versorgen. Das kann unschöne unerwartete Nebeneffekte haben.

    Besser den Shelly Mini immer am Strom lassen, und nur den SW Eingang über Taster/Schalter schalten.

    Für die Weiterleitung einer Aktion auf die Shelly PlugS, muss nicht einmal das Relais im Shelly Mini aktiviert werden.

    Es reicht, den SW Eingang Status über die Aktion abzufragen und den SW Eingang im Shelly Mini auf detached zu stellen.

    Der Eingangszustand SW am Mini dient dann einer Aktion im Shelly Mini als Trigger für die Aktivierung der Shelly Plug . (ohne dass das Relais im Mini Strom braucht)

    PS. Da sich Home und Remote Shelly , wenn sie zeitgleich senden ins Gehege kommen, haben wir in die Sendefunktion für Wiederholungen des Paket sendens, eine Zeitvariabilität eingebaut, dass die Wiederholungen zufällig im Range von 10 bis 20 Sekunden passieren, damit die Gegenstelle auch Zeit hat durchzukommen und ihr Sendepaket abzusetzen. Die Anzahl der Wiederholungen ("MAX_RETRIES") hatten wir in unserem Beipiel auf der Remote Seite auf 100 und auf der Home Seite auf 8 gesetzt. Bei einer stabilen Funkverbindung reichen vieleicht auch 4.

    Aufgrund der vermuteten Begrenztheit der Shelly Kapazität, haben wir die Anzahl der parallel zum Versand anstehenden Texte/Befehle auf maximal 4 begrenzt ("MAX_CONCURRENT_CALLS = 4").
    Sonst kommen sich die Sende-Wiederholungen und die Acknowledgements der Gegenseite ggf. zu sehr ins Gehege und blockieren sich dann gegenseitig. wir hatten festgestellt, dass ein Paket senden etwa 2-3 sekunden braucht.

    Hier die von uns verwendeten LoRa Skripte auf der Home und Remote Seite.
    Beide Seiten sind sowohl Sender, wie auch Empfänger.

    Auf beiden Seiten werden im Shelly virtuelle Komponenten genutzt, als Mittler zwischen der LoRa-Funk-Welt und den Shelly Aktionen auf die physikalischen Shelly-Funktionen im Heimnetz.
    Das versprach Flexibilität in der Anwendung, weil über LoRa beliebige Texte transportiert werden, die dann je nach definiertem Text, für jede Menge variabler Funktionen als Trigger dienen können, -- über ein einzelnes Text Ein- oder Ausgabefeld.
    Es werden einfach die Texte in den Aktionen definiert, die gesendet werden, - oder die als Trigger für eine Aktion fungieren.
    Im Beispiel geht es um die Fernalarmierung einer Statusänderung am Remote Shelly.
    Durch den Home Shelly kann dann wiederum eine Aktion am Remote Shelly getriggert werden.

    Home Shelly:
    virtual Components:
    button:200 , button:201 -- zur Steuerung einer Remote Komponente;
    text:200 -- zur Darstellung empfangener (remote Shelly) Textnachricht auf dem Home Shelly
    (z.B. Eingangs-Status remote Shelly)
    number:200 , number:201 -- zur Darstellung des Packet transmission fail


    Remote Shelly:
    virtual Components:
    text:200 , text:201 -- zur Darstellung von zu sendenden (remote Shelly) oder empfangenen (Home Shelly) Textnachricht ;
    (z.B. senden des remote Shelly Eingangs-Status ; Empfang des Kommandos vom Home Shelly)
    number:200 , number:201 -- zur Darstellung des Packet transmission fail


    Für die Encryption muss bitte jeder seinen eigenen persönlichen encryption key definieren (lange Zeichen+Ziffernfolge), und an der Skriptstelle KEY_RAW zwischen den Gänsefüßchen einfügen.

    Wir hoffen, dass dies hilfreich ist für neue LoRa Projekte.


    Mit Reichweiten-Test bin ich noch nicht weitergekommen.
    Die bisherigen Ergebnisse waren ernüchternd, und eher im Range von 500m (und nicht 5km).

    Habe dieses WE die LoRa module mit zwei Shelly1 Gen3 getestet. Mein Informatik talentierter Sohn hat mit den Skripten geholfen.

    Basierend auf den Beispiel-Skripten zum encrypted send und Receiver, haben wir erst eine Methode über virtuelle Komponenten als Mittler entwickelt.

    Da LoRa ja Text überträgt, haben den Shellys virtuelle Textfelder hinzugefügt. Über Texte die man dort über Kommandos in Aktionen, Szenen oder rpc calls einträgt, kann die LoRa Übertragung getriggert werden. Und die Texte können als Kommandos auf der Empfangsseite genutzt werden.

    Damit haben wir dann die Reichweite getestet. Weiter als 500m sind wir noch nicht gekommen. Standen aber Gebäude und natürlich die Fensterscheibe dazwischen.

    Außerdem war dann der Signalempfang, und entsrechende Schaltvorgänge nicht zuverlässig.

    Da von Hause aus kein automatischer Rückkanal mit Acknowledge vorgesehen ist,

    hat mein Sohn encrypted send und receive in einem Skript kombiniert und mit einem Paket Tracking und einer automatischen Sendewiederholung programmiert. Das ganze wird über counter als virtuelle Komponenten dokumentiert. Paket acknowledgement pending, und paket acknowledge failed, nachdem die einstellbare Zahl an re-tries nicht erfolgreich zu einem Acknowledge des Empfängers führte.

    Damit will ich demnächst neue mobile Reichweiten Tests ausführen.

    Hi,

    In der Anleitung vom 1 Mini Gen3 stand noch der Hinweis, dass keine SELV/PELV Kleinspannungskomponenten an die Lastanschlüsse angeschl ssen werden dürfen.

    In der Anleitung zum 1 Mini Gen4 fehlt dieser Hinweis.

    Heißt das, dass der Mini Gen4 so konstruktiv optimiert wurde, dass die nötigen Abstände der Leiterbahnen im Gerät eingehalten werden, und SELV/PELV Geräte sicher damit betrieben werden können ??

    Ok, da liegt ein Missverständnis vor.

    Zuerst war die Spannungsversorgung des Mini1 an den Ausgang des Mini1PM angeschlossen. Hat sich nicht bewährt, da der Mini1PM zu häufig geschaltet hat (weil in Aktionen keine Zeitsperre haben) und der nachrangige Mini1 deshalb in den Anlernmodus ging.

    Danach hatte ich den Mini1 direkt an der Phase für die Stromversorgung, und der Ausgang des Mini1PM hat den SW Eingang des Mini1 angesteuert. (Detached mode) Gleichzeitig war der Ausgang des Mini1PM parallel über den NTC mit dem Ladegerät verbunden. Das hat sich auch nicht bewährt, weil anscheinend Spannung der Eingangsstufe des Ladegerätes auf den SW Eingang des Mini1 rückgewirkt hat. Der Mini1 Eingang blieb "grün" und das Relais eingeschaltet.

    Deshalb in letzter Konsequenz die physikalische Kopplung der Mini1PM und Mini1 gekappt, und die Ansteuerung des Mini1 durch den Mini1PM nur durch eine Aktion realisiert. Das funktioniert bisher verlässlich.

    Ich hoffe das klärt es hinreichend.

    Hinter den Shelly mini 1PM Gen3, der eigentlich das Ladegerät einschaltet, habe ich an den Lastausgang
    einen Shelly mini 1 Gen3 angeschlossen, den ich so konfiguriert habe, dass er automatisch nach 1sec einschaltet, sobald er mit Strom versorgt wird (vom 1PM). Der Shelly mini 1 braucht also nur Strom (Verlustleistung 0,6W), wenn der Shelly mini 1PM eingeschaltet ist.

    Das hat sich leider nicht bewährt. In Konstellation mit Aktionen können die Shelly ja unverzögert hin und her schalten, je nach erfüllter Bedingung.

    Der Mini 1PM hat heute wohl den Mini 1 mehr als 4x in einer Minute mit Strom versorgt und wieder ausgeschaltet. Das hat dazu geführt, dass der Mini1 wieder in den Anlernmodus gegangen ist (rote LED blinkt) und gar nichts mehr geschaltet hat.

    Mal wieder eine neue Shelly (un)Funktion gelernt, die nicht im Handbuch/Beipackzettel steht.

    (Doof. Es gibt doch den Resettaster)

    Habe jetzt umverkabelt. Sowohl Mini1PM und nachgeschalteter Mini1 sind jetzt permanent am Strom.

    Verzögerte Aktivierung und sofortige Deaktivierung des Mini1 durch den Mini1PM über Aktionen. Nicht über die Steuerleitung des Mini1.

    Denn die Eingangskondensatoren des nachgeschalteten Ladegerätes haben über den durchgeschalteten Mini1 Relaiskontakt auch den SW Eingang des Mini1 auf "on" gehalten. Der schaltete gar nicht mehr ab. Auch als detached Eingang nicht.

    Bei den Shellys muss man schon ziemlich um die Ecke denken, um das Geraffel ans laufen zu bringen.

    crazyman69 ja , leider geht das nur mit Szenen via Cloud, also mit Internetverbindung (und funktionierendem Server in Bulgarien).

    Mit lokalen Aktionen geht das nicht. Da können die Shellys wild hin und her schalten, da sie sich direkt über http Befehle ansprechen. Und im http Befehlssortiment ist keine Funktion implementiert, die für eine definierte Zeit nachfolgende Befehle ignorieren würde.

    Das wäre echt hilfreich für viele Anwendungen und zu schön um wahr zu sein.