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.

    Man könnte doch einfach items[0] nehmen und dann hat man wieder key/value - oder?

    Erst einmal danke für diese fast einmalige (;)) Rückmeldung.

    Nein, leider nicht. Die Komponente key adressiert nicht value, beide stehen nebeneinander im Datenfeldelement. Es handelt sich somit hier um keine map, weil der value nicht nativ per key gefunden werden kann - tatsächlich kein KVS mehr. Das ist eine merkwürdige Änderung und vielleicht einem anderen (doofen) übergeordneten System geschuldet.

    Ich habe es per Iteration über das Datenfeld gelöst. Ich lasse von allen Elementen des Resultats (Datenfeld mit laufendem Index) die Komponente key mit den von mir definierten Schlüsselnamen vergleichen. Bei Übereinstimmung verwende ich die value Komponente. Ich konnte bisher keine andere Lösung finden.

    Alternativ ließe sich KVS.List verwenden, da hier eine map als Resultat geliefert wird. Ich bevorzuge allerdings zwecks Selektion einen Pre-Teil im key, bspw. "app_". Dies liefert mir nur die für mein Skript bedeutsamen Werte und nicht etwa alle.

    Gibt es da nicht eine einfachere Möglichkeit?

    "Einfacher" als was? Womit vergleichst du?

    Wie willst du das Beregnen anstoßen? Per Taster/Schalter, per Web-UI eines Shelly oder App?

    Was soll nach dem Triggern im einzelnen ablaufen?

    Wie sieht deine IoT-Umgebung aus. Was hast du dort bereits?

    Anregung:

    Es tun bereits alte Shelly 1 und/oder alte Shelly Plug S zum schalten. Wenn du ein übergeordnetes System hast, kannst du damit die Shelly steuern. Ansonsten kannst du einen Skript fähigen Shelly (Plus Plug S) nehmen und darin ein Steuerprogramm unterbringen.

    Ich nutze nach wie vor temporär auch einen Shelly Plus Plug S in der Einspeisung hinter dem Deye Wechselrichter. Bisher hatte ich damit keinerlei Probleme. Sobald ich einen EM habe und diesen hinreichend testete, will ich dort den Plug S ersetzen. Der Plug S liefert mir seit ca. 1/2 Jahr verlässlich Daten für eine Influx Zeitreihendatenbank.

    Mir ist klar, dass für diesen Einsatzzweck der Plug S nicht optimal ist. Ich investiere aber aus Kosten- und Effizienzgründen nicht ständig in neue Shelly.

    Die von mir erwartete Lieferung enthält auch einen EM. 8o

    Ich stellte soeben mit Verwunderung fest, dass eine afaik undokumentierte Änderung im Resultat der KVS Methode "KVS.GetMany" vorliegt. Imho stellt dies eine gewisse Inkonsistenz dar. Die Dokumentation dazu ist allerdings korrekt - seit wann? Im Changelog fand ich dazu nichts.

    Warum sehe ich dort eine gewisse Inkonsistenz - in der Resultatsstruktur?

    In Firmware 1.4.4 lieferte KVS.GetMany ... eine verschachtelte Objektstruktur. Auf deren Elemente konnte man per Keys zugreifen. Die gleiche Struktur lieferte KVS.List.

    In der Firmware 1.5.1 liefert KVS.GetMany ... hingegen ein Datenfeld mit numerischem Index. Der Zugriff auf Werte gelingt nun nicht mehr per Keys, sondern per Datenfeldindex. Die von mir angemerkte Inkonsistenz besteht in abweichender Resultatsstruktur von KVS.List. Letzte ist nach wie vor ein verschaltetes Objekt. Das ist insofern unschön, als dass Skripte, welche obige Methoden verwenden, nun angepasst werden müssen.

    Ich finde es widersprüchlich, wenn sich beide Resultatstypen unterscheiden, was sie bis Firmware 1.4.4 auch nicht taten.

    horkatz

    Ist ja fast alles stimmig, was du schreibst.

    Der passt hardwaremäßig aber nicht zum Rollladen. Bei DC-Betrieb schaltet er den Minus, hier wird der Plus gebraucht. Man könnte zwar mit zusätzlichen Relais arbeiten, aber wozu?

    Ich hatte nur diesen Hinweis notiert, für den Fall, dass der TE später mal ein Rollladen-UI und/oder einen Sprachassistenten nutzen möchte. Solches gelingt mit dem Uni schlicht nicht. Ich habe einem anderen Mitglied zwei Skripte zur Verfügung gestellt, weil dieser u.a. die Sprachsteuerung für sein Garagentor wollte. Dabei stellte sich heraus, dass solches mit einem Shelly 2 PM und einem externen Relais durchaus gelingt.

    Lds_Shell

    Ich teste gerade erstmalig einen Shelly Plus Uni. Er ist offenbar nicht in einem Rollladenmodus betreibbar.

    Ich möchte die App nutzen, und bei Bedarf den vorhandenen physischen Taster. Keine Sprachsteuerung oder ähnliches. Und als Funktion einfach nur auf/stop/zu, keine programmierten Zwischenpositionen.

    Ok, soweit klar.

    Trotzdem noch dieser Hinweis:

    Wenn du ein Rollladen-UI möchtest, oder gar einen Sprachassistenten, dann ist der Uni die falsche Wahl. Dafür ist ein Shelly 2 PM prädestiniert.

    Lds_Shell

    Wie hier bereits angemerkt wurde, sollte ein Shelly Plus Uni geeignet sein. Ich habe allerdings noch nicht getestet, ob dieser auch per Sprachassistent steuerbar ist. Ein Shelly 2 PM (ab Gen. 2) ist es auf jeden Fall. Und beide lassen sich zumindest per Skript dazu bringen, den Rollladen zu steuern - ohne Kalibrierung, also ausschließlich öffnen, stop, schließen.

    Du hast nicht beschrieben, WIE du den Shelly nutzen willst. Per Taster, per App, per Sprachassistent?

    Ich habe zwei Skripte erstellt, durch welche bspw. per Sprachassistent ein Garagentor gesteuert werden kann, deren manuelle Steuerung ausschließlich mit EINEM Taster erfolgt. Somit gibt es für deine Ziele (?) sicher eine Lösung, notfalls per zusätzlicher, externer Relais.

    Siggi-Morello

    Ich habe (noch) kein EM.

    1. Du könntest ein Relais mit Umschaltkontakten verwenden.
    2. Per Skript sollte solches möglich sein. Ein Eventhandler registriert das Schalten des Ausgangs, untersucht die Quelle dieses Schaltens und ändert ggf. den Schaltzustand am Ausgang.

    Zu 2.: Hast du sonst irgendein Skript am laufen?

    Edit: Mit einem Skript lässt sich ein sehr kurzes "falsches" Schalten nicht verhindern, weil der Eventhändler vom System nicht voher "gefragt" wird. Er kann somit nicht vorher, sondern nur unmittelbar danach eingreifen und Umschalten.

    Edit 2:

    Ich habe Punkt 2 versucht zu testen. Dabei musste ich feststellen, dass nicht jeder schaltende Shelly im Schaltereignis die auslösende Quelle beinhaltet. Ein Shelly Plus 1 hat diese Information nicht. Ein Shelly Plus 2 PM im Cover Modus hat diese Information. Wann die Info der auslösenden Quelle vom System bereitgestellt wird und wann nicht, weiß ich derzeit nicht. Es kann somit sein, dass Punkt 2 das Ziel nicht implementieren kann. Da ich keinen EM habe, kann ich dies nicht prüfen.

    uxtuner

    Mir sagt HomeBridge nichts, offenbar ist das ein Apfelstückchen. ;)

    Lässt sich dort nichts konfigurieren oder skripten, was auf Komponenten von JavaScript Objekten zugreift?

    Nutzt du auch MQTT oder irgendetwas Flexibles wie Node-RED oder ...?

    Man kann auf Shelly ab Generation 2 auch Skripte laufen lassen. Ich stelle hier mal ein grundlegendes Skript dafür vor.

    Das Skript stellt eine simple Webseite zur Verfügung, deren Inhalt (body) den Schalter-/Tasterzustand am Add-On liefert, also schlicht false/true.

    Nach dem Start des Skripts gibt es zwecks Info den passenden URL im Console Fenster unterhalb des Skript Editierfensters aus.

    Die Webseite wird aufgerufen mit

    Code
    http://<IP-Adresse des Shelly>/script/1/data

    Darin ist die 1 die Skript Id und kann auch anders lauten, wenn du bereits Skripte dort abgelegt hast.

    Ob dieses Skript das liefert, was du brauchst, weiß ich nicht. Das musst du selbst herausfinden. Jedenfalls wird eine syntaktisch korrekte Webseite geliefert.

    MQTT täte mir besser gefallen. Mit Node-RED lassen sich sehr gut Adapter bauen. Nur mal so ... 8)

    2025Frank Ergänzung zu den Hinweisen von horkatz

    Quelle: https://www.rohrmotor24.eu/Relais-/-Trenn…Einzelbedienung

    Zitat

    Als Zentralbedienung können Jalousie-/Rollladenschalter und Jalousie-/Rollladentaster, sowie Jalousie-/Rollladen-Zeitschaltuhren und diverse Steuerungen mit potentialfreien Kontakten eingesetzt werden.

    Die Einschränkung der Potentialfreiheit stimmt mich bedenklich. Deshalb folgender Vorschlag - unverbindlich.

    Vorbehalt: Du solltest Elektrotechnikkenntnisse haben oder jemanden mit solchen zu Rate ziehen.

    Ich halte es für zielführend, zunächst sowohl die Schaltuhr als auch das Trennrelais durch einen Shelly 2 PM zu ersetzen - testweise an einer Jalousie. Die Taster sind mit den Eingängen des Shelly zu verbinden. Der Antriebsmotor ist mit seinen Anschlüssen (Auf/Ab) an die Shelly Ausgänge O1, O2 anzuklemmen. Shelly im Cover Modus!

    Es ist zu erwarten, dass der Shelly kalibrieren kann - unbedingt frühzeitig prüfen! Gelingt das Kalibrieren, ist alles gut und du kannst jede deiner baugleichen Jalousien mit einem solchen Shelly betreiben. Die Daten des Antriebmotors liegen uns aber bisher nicht vor (?). Sollte das Kalibrieren nicht gelingen, kann die Steuerung trotzdem funktionieren. Dann solltest du den Betrieb zunächst über eine längere Dauer testen - bspw. 1 Monat lang. Besser ist es, wenn du die Motordaten des Antriebs hast und vorlegst.

    Ein Problem könnte die erforderliche Umschaltverzögerung von 0,5s darstellen. Der Shelly schaltet zügig um. Vermutlich wird es bei der empfohlenen Schaltung keine Probleme geben.

    Der Shelly kann locker die Zeitschaltuhr und vermutlich auch das Trennrelais ersetzen. Er bietet erheblich mehr Möglichkeiten als eine übliche Zeitschaltuhr.

    tvbshelly

    Ok. Vermutlich ist dies aber nicht das, was haitauer haben will.

    Meine Interpretation: Er will ein spezifisches Protokoll, welches aus einem Skript heraus erstellt wird, bis zum löschen persistent gespeichert bleibt und aus welchem man möglichst (frei interpretiert) noch kopieren kann - ggf. zwecks Dokumentation.

    Nicht dass ich wüsste. Aber ...

    Du kannst eine vermeintliche Skriptdatei dazu verwenden, um ein eigenes Protokoll zusammenzustellen.

    Schau dazu mal hier: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Script

    Ich habe mal ein Skript zum offline sammeln von Messwerten erstellt. Darin habe ich solches verwendet.

    (Gruß an Ostfriese alias Michael, leider hier nicht mehr dabei.)

    haitauer

    Falls dich mehr zu meinem dbzgl. Projekt interessiert: Autarke Temperaturmessung ...

    Ohne hier in Einzelheiten des betreffenden Skripts gehen zu wollen, fand ich ausschließlich eine Iteration über die Keys in einer definierten Map.

    Code
    for(key of Object.keys(topicMap)) {
    	// ...
    	MQTT.publish(topic, value, mqttQOS);
    	// ...
    }

    Diese Schleife alleine lässt zunächst kein Problem erwarten. Es bleibt noch zu prüfen, ob es gut ist, zu jedem definierten Key eine MQTT Nachricht zu senden. Ich kann das Skript leider immer noch nicht testen - kein Shelly BLU. :(;)

    Meine vorläufige Strategie: Anwendungsorientierung
    Das Skript ist eine Art "Eier legende Wollmilchsau". Es sollte je nach Anwendungsfall auf die erforderlichen Nachrichten (Map verkleinern) reduziert werden.

    Zusätzlich ist zu prüfen, ob wenige (bis hin zu einer) MQTT Nachricht mit (je) einer JSON Payload geeignet ist und ggf. die Subscriber das Gebrauchte selektieren.

    Auch wenn eine Wiederholungsstruktur in einer Ereignis gesteuerten Umgebung nicht grundsätzlich "verboten" ist, so ist sie doch mit skeptischen Blicken zu betrachten. Stattdessen lässt sich eine Kombination aus Timer und Status nutzen, welcher in der Timer callback Funktion geprüft wird ...

    Hoffentlich kommen meine bestellten Teile bald an, damit ich das Skript mal selbst testen und zielführend analysieren kann.