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.

  • Garagentorantrieb mit shelly plus 1, brauche Eure Hilfe

    Die +12V hast du bestimmt bei offenem Taster/Relaisschalter gemessen. Diese 12V können aber nur über einen Pull Up Widerstand geführt sein, weil es sonst einen Kurzschluss gäbe.

    Zitat

    Verbinde ich dann noch die beiden Relais-Anschlüsse mit den beiden Kontakten "F" des vorhandenen Tasters, knallt der shelly einmal und haucht sein Leben aus. ;(

    Dann verwendest du vermutlich einen Shelly Plus 1 PM, was in deinem Fall schlicht falsch ist, weil du potentialfreie Kontakte brauchst. Solche bietet der Shelly Plus 1 (ohne PM) wie bspw. auch der Shelly Plus Uni, welcher hier auch einsetzbar ist.

    Wie steuerst du bisher das Tor?

    Was tut E43U?

    Nutzt du keinen Taster?

  • Frequenzfenster

    Ich nutze die Cloud ausschließlich für meine Sprachassistenten (Amazon Echo). Szenen brauche ich nicht und lehne solche für mich selbst bisher ab. Dafür nutze ich lokal Aktionen und/oder Skripte und Zeitpläne (Schedule Jobs). Damit ist mein Smart Home auch ohne Internetzugang oder ohne Cloudverfügbarkeit - auch Cloudfehler gibt es - in seinen grundlegenden Funktion betriebssicher.

    Auch nutze ich sehr selten die App und stattdessen das WebUI des Shelly, womit u.a. Aktionen konfiguriert werden können.

    Zitat von Tiroler63

    Das möchte ich dann als Fehler gemeldet bekommen.

    Auf welche Weise möchtest du den Fehler gemeldet bekommen? LED am ersten Ausgang des Uni? MQTT Nachricht, die weiterverarbeitet werden kann - es gibt passende Apps, zumindest für Android? Irgendetwas anderes?

    Die Grundfunktion zur Bereitstellung einer solchen Meldung sowie das Rücksetzen des Zählers können per Aktion, Zeitplan und Skript implementiert werden. Ein Skript ist dann nicht erforderlich, wenn die Fehlermeldung schlicht per freiem Ausgang erfolgen soll.

    • Der Zeitplan setzt alle volle Stunde den Zähler auf 0 zurück.
    • Die Aktion löst bei Überschreitung des Zählerstandes von bspw. 8 etwas geeignetes aus.
    • Das Skript kann bspw. genutzt werden, um eine per freiem Ausgang gesteuerte Lampe blinken zu lassen.
    Zitat von Tiroler63

    Gibt es da irgendwo genauere Infos bezüglich der einzelnen Menüpunkte und deren Funktion ?

    Ich kenne keine solche Infos und habe bisher in meinen Tests experimentieren müssen. Auch die API Dokumentation gibt speziell hierzu nicht viel her.

    Sobald ich erfahre, wie du dir die Fehlermeldung vorstellst, kann ich vielleicht eine (fast) fertige Lösung zusammenstellen.

  • Frequenzfenster

    Tiroler63

    Kannst du uns bitte mehr mitteilen?

    1. Nutzt du zum schalten der Pumpe bereits einen Shelly? Wenn ja, welchen?
    2. Womit kommuniziert der ggf. genutzte Shelly?
    3. Wie ist der ggf. vorhandene Shelly verdrahtet - Schaltskizze?
    4. Alternativ: Welchen Shelly hast du dafür vorgesehen?

    Viel Information bietet gute Basis für zielorientierte Auskunft. ;)

  • BLU Daten per Shelly Gen 3 und MQTT senden - ohne oder mit Skript

    Ach so, ja. Das habe ich anfangs auch so gemacht und die Firmware MQTT Kommunikation genutzt. Das gefiel mir weniger, weil je Gerät ein Topic erforderlich ist. Außerdem sind die Firmware MQTT Nachrichten überdimensioniert, weil sie P2P Kommunikation over MQTT nachbilden. Dies ist aber im Falle der BThome Geräte völlig unnütz.

    Dehalb transformiert mein erstes Skript BThome Nachrichten in schlanke MQTT Nachrichten, wozu es nur einen MQTT in Node braucht.

    Hier ein Test Flow Auszug mit noch vielen (teilweise überflüssig gewordenen) Debug Nodes:

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

    Die noch wenigen BThome Daten werden in meinem Dashboard verlässlich angezeigt.

    Der switch Node verteilt nach msg.payload.id, was schlicht die bthomesensor id ist.

  • BLU Daten per Shelly Gen 3 und MQTT senden - ohne oder mit Skript

    Zitat von martner

    meine BLU Sensoren gleich in Node-red weiter zu verarbeiten

    Kann man in Node-RED Bluetooth Node(s) installieren, möglichst auch noch BTHome kompatibel?

    Ich täte auf einem Gen 3+ ein kurzes Skript nutzen, welches die BThome Nachrichten in MQTT- oder HTTP- Nachrichten transformiert. Beide kann Node-RED bekanntermaßen empfangen und verarbeiten.

    Zitat von martner

    Weißt du (oder jemand anderes gerne auch), wie viele BLU Sensoren ich auf einem Shelly Gen3 über Components anlegen kann?

    Ich weiß es derzeit nicht. In der API Dokumentation fand ich auch nichts darüber.

  • Wohnwagen mit Shelly

    Zitat von Tom-DD

    Die Shelly Plus haben auch eine Möglichkeit Scripts einzufügen. Sind diese nicht oder nur eingeschränkt nutzbar?

    Die Plus Geräte gehören der Generation 2 an und unterstützen keine BThome Geräte (Shelly BLU ...). Dazu müsste ein etwas aufwändiges Skript genutzt werden, was ab Generation 3 nicht gebraucht wird. Und ja, die Plus Geräte können Skripte abarbeiten, weshalb du denen auch entsprechende Aufgaben zuordnen kannst, wenn du solche ohnehin nutzt - Lastenverteilung.

    Homeassistant nutze ich nicht, weiß aber, das solche Systeme den Anwender weitgehendst von Programmierarbeit verschonen. Wenn du dich nicht vor der Erstellung und Pflege von Skripten scheust, solltest du ein solches übergeordnetes System im Wohnwagen nicht nutzen, da es relativ viel Strom braucht.

  • Skript zum dimmen, Shelly dimmer gen3 mit Blu button4

    Ich will nicht ausführlich auf das "Skript" von Chat GPT eingehen. Eines fällt aber sofort auf und ist geradezu dilettantisch:

    Die Variable bt_mac wird viermal im selben Gültigkeitsbereich angelegt, was nicht nur syntaktisch ein Fehler ist. So etwas darf nicht einmal einem Anfänger in dieser Dichte passieren.

    Außerdem hat offenbar diese KI geringe "Kenntnis" von Datenstrukturen.

    Eine Funktion Bluetooth.onScanResult kenne ich nicht und diese gibt es vermutlich auch nicht.

    Der Rest ist relativ überzeugend und sollte nach Adaption verwendet werden können.

    Mehr kann ich derzeit zu deinem Projekt nicht sagen, weil ich noch wenig Erfahrung in der Verarbeitung von BLU Nachrichten habe und ich deshalb testen müsste. Ich bin aber derzeit verhindert.

  • Netzbezug trotz Einspeisung?

    Zitat von Jo_Be

    ob das mit dem Pro3EM im Laufe welchen Zeitraums möglich ist: Gibt es dazu Erfahrungen oder sogar Angaben?

    Ich habe keinen Pro 3 EM. Es wäre aber sehr verwunderlich, wenn das KVS sich dort anders verhielte als in den anderen Shelly ab Generation 2.

    KVS = Key Value Storage ist tatsächlich eine Speicherstruktur, durch welche per Key auf den Value zugegriffen wird, wobei der Value wieder eine Key Value Struktur haben kann. Dies ist auch bekannt in JavaScript Objekten und in JSON. Shelly nutzt dafür aber ausschließlich den NVS (Non Volatile Storage/Memory), womit KVS Variable immer persistent sind.

    Vermutlich ist dir bekannt, dass NVS deutlich weniger Schreibzugriffe verträgt als flüchtiger Speicher. Deshalb sollte in solche Variable nicht zu hochfrequent geschrieben werden.

    Ich nutze bspw. in meinem Nebenuhr Projekt das KVS und lasse dort einmal pro Minute hineinschreiben. Bisher ging es gut. Auch kann es sein, dass dabei die Speicherstelle geändert wird, je nach Reserve, und nicht jedes Mal an dieselbe Stelle im NVS geschrieben wird. Von solcher Strategie las ich mal an anderer Stelle. Ansonsten kann man prinzipiell so oft man will und es die RPC Aufrufe gestatten in das KVS schreiben. In meinem obigen Skript täte ich das bspw. alle 10 Minuten - immer dann, wenn die "integrierten" Energien per Nachricht übertragen werden.

    Es kann aber nicht schaden, darauf zu achten, dass das KVS nicht zu hochfrequent genutzt wird - insbesondere, wenn man viele oder umfangreiche Variable dort nutzen will.

  • In URL enthaltene %20 werden nicht mehr in Leerzeichen dekodiert.

    Das funktioniert tatsächlich. Der einzige Unterschied zu meinem Link ist die Codierung des Anführungszeichens. Dies überrascht mich schon deshalb, weil uncodierte Anführungszeichen in den Links mit älteren Firmware Versionen immer gelang. Meine dbzgl. Webseiten sind ja bereits etwa 2 Jahre alt und haben sich bewährt.

    Wie auch immer, ich werde die Umstellung auf codierte Anführungszeichen testen.

    Danke!

  • Netzbezug trotz Einspeisung?

    Jo_Be

    Ok, kann man nehmen. Ich wundere mich immer mal wieder über die Nichtnutzung von Schedule Jobs, obwohl diese für manche Dinge geradezu prädestiniert sind. Eine Persistenz habe ich auch vorgesehen, meines Grundlagenskripts aber noch weggelassen. Ein Runden kann man einbauen, nun ja.

    Meine Kritik an diesem Skript - nach erstem Eindruck:

    Positiv

    1. Vielfältigere Kommunikation bereitgestellt.
    2. Persistenz durch Speicherung im nichtflüchtigen Speicher (KVS).

    Negativ

    1. Die Werte 500, 0.5 stehen im Ablaufcode, wo sie bei Änderungswunsch erst zu suchen sind -> geringe Servicefreundlichkeit.
    2. Wenn der Autor schon das KVS nutzt, warum nicht dort auch die Konfiguration ablegen (Abfrageperiode, Nachkommastellen)?
    3. Das Rücksetzen erfolgt ausschließlich per Timer und Zählwerte, wo ein Schedule Job dies besser kann.

  • In URL enthaltene %20 werden nicht mehr in Leerzeichen dekodiert.

    So sieht der Link aus:

    http://172.16.7.1/rpc/schedule.create?timespec="0 0 0 * * *"&calls=[{"method":"switch.set","params":{"id":0, "on":true, "toggle_after":60}}]

    Dies erscheint in der Adresszeile: (Hier musste ich die %20 selbst einbauen. Warum die Asterisk hier tiefergestellt wurden (->Multiplikationssymbol), weiß ich nicht.)

    http://172.16.7.1/rpc/schedule.create?timespec="0%200%200%20*%20*%20*"&calls=[{"m1":switch.set,"params":{"id":0,%20"on":true,%20"toggle_after":60}}]

    Und dies ist die Antwort: {"code":-103,"message":"Invalid argument 'timespec': Failed validation!"}