Beiträge von eiche

Ungetestet aber ziemlich wahrscheinlich funktionstüchtig:

In irgendeinem Frontend (Bedienungsoberfläche) einen Schalter für Abwesenheit oder "Urlaub" bereitstellen.

Wird der virtuelle Schalter auf ein/aktiv gestellt, zwei (oder mehr?) Nachrichten per HTTP oder MQTT oder ??? an alle betreffenden Shellies senden, die

1. deren Scheduling deaktiviert und
2. die Urlaubswerte einstellen

Wird der Schalter auf aus/inaktiv gestellt, per Nachricht das Scheduling auf den betreffenden Shellies aktivieren.

Ich täte es mit Node RED - in Homematic afaik RedMatic - und MQTT lösen, per HTTP dürfte es aber auch gelingen, falls kein MQTT zur Verfügung steht.

Btw. ähnliches habe ich per Node RED für meine lokalen Heizungssteuerungen so gelöst. Mein System ist gemischt mit TRVs und Shelly 1 + Addon realisiert. Allerdings nutze ich das Scheduling nur in den TRVs.

Nachtrag:

Die Urlaubswerte lassen sich in einem Konfigurationsknoten leicht verwalten und von dort holen, sowohl global als auch Flow bezogen. Optional können solche Daten persistent gespeichert (Dateisystem) und beim starten von Node RED in die Konfiguration geladen werden.

Ok, das könnte nicht schaden. Ich frage mich aber auch, warum jemand das von dir Erwähnte einfach mal so versucht, offenbar ohne Kenntnisse in Elektrotechnik/Elektronik. Aber gut, er hat ja Hinweise dazu erhalten.

Meine Frage wäre ...

Zitat von maschuett

Plötzlich wird bei beiden das Addon nicht mehr erkannt.

Wie stellst du dieses Nichterkennen fest, soll heißen was verwendest du dafür?

Btw ich verstehe die Beliebtheit der App-Nutzung außerhalb er Cloud nicht.

Ich habe soeben auf 5 Plug S ein Firmware Update durchführen lassen - keinerlei Probleme, Konfigurationen und Funktionen blieben erhalten.

Vielleicht gab es bei dir während des Updates eine Störung im Stromnetz.

Btw ich verwende die App nie für lokale Zugriffe. Dafür sind imho die WebUI am besten geeignet.

WebUI auf meinem Smartphone, Shelly Plus 2PM mit Firmware 0.12.0:

... oder eine Messbrücke

Ich habe den Plus Add-On auch (noch) nicht.

@66er Ich kannte den RuuviTag bisher nicht. Interessant daran scheint mir dessen Witterungsfestigkeit und die Reichhaltigkeit an Sensoren. So würde ich den RuuviTag vielleicht anstatt eines Plus Addon im Außenbereich einsetzen.

Neugierig - darf ich fragen, wie und/oder wo du den RuuviTag einsetzt?

Those data should be stored in the NVM (non volatile storage). Afaik is this feature at the todo list, but not yet implemented.

Noch eines:

Antriebe von Rollläden, die von Shellies gesteuert werden sollen, in Reihenschaltung zu betreiben ist imho eine sehr schlechte Idee, es sei denn, du hast etliche Sensoren an den Rollladenführungen, was ich mal ausschließe. Hmm, vielleicht wäre auch eine Abstandsmessung möglich ... nur brainstorming

Die Shellies können die Positionierung selbstverständlich nur über Einschaltdauern realisieren - und btw dazu müssen sie auch immer mal wieder Referenzpunkte anfahren (ganz offen oder ganz geschlossen) - und sie müssen kalibriert werden, was ja bereits vorgesehen ist.

Wie aber können drei Rolllädenläufe zugleich kalibriert werden? Wenn es überhaupt gelänge, vielleicht möglich, wäre die Nutzung der Kalibrierung zumindest relativ unsicher.

Fazit: Jeder Rollladenantrieb ist einzeln zu betreiben und durch je einen Shelly anzusteuern.

Wenn die Rollläden unbedingt zugleich gefahren werden sollen, dann lässt sich dies per Szene (oder) per Nachrichten an alle beteiligten Shellies implementieren.

Mal ohne Einzelheiten, nur grobes Prinzip:

Auf dem i4 ein Skript erstellen mit der Implementation einer Schrittkettensteuerung.

Ob das auch per Szene in der Cloud ginge, weiß ich nicht.

Die Implementation per Skript würde ich hinkriegen. Allerdings habe ich dafür keinen Bedarf.

Nachgereicht:

Der i4 hat, wie der Name sagt, 4 Eingänge, kann also von 4 Tasten angesteuert werden. Willst du genau eine Taste von vier mit der gewünschten Funktionalität belegen oder nutzt du nur einen Eingang des i4?

Im zweiten Fall könnte es vielleicht für dich interessant sein, 4 Taster dafür einzusetzen.

Ich habe ein Skript erstellt, welches auf jede der 4 Tasten reagiert und die Dauern der Tastendrücke ausgewertet werden - statt Mehrfachdrücken. Das Skript ist durch Einträge darin konfigurierbar. Irgendwo in diesem Forum habe ich es zur Verfügung gestellt. Vermutlich kann es unter Skripte gefunden werden.

Problem: Wer Null Kenntnisse vom Programmieren bzw. von Datenstrukturen hat, wird sich damit nicht leicht tun.

Ein mit Tasmota geflashter Shelly kann das auch - ohne irgendeinen Cloud Account. Ich habe mich bisher nie dafür interessiert, wie dies erreicht wird, aber es funktioniert total verlässlich, wenn ein Zeitserver genutzt wird.

Schon deshalb erscheint mir der Cloud-Zugriff dafür unerheblich. Evtl. sind die Geodaten, einmal notiert, dafür einzutragen, so sicher weiß ich das nicht mehr.

Es sei die Frage gestattet, warum du bei einer Neu?)-Installation nicht gleich auch ein Computernetz aufgebaut hast bzw. aufbauen ließest und auf die Pro Linie der Shellies gesetzt hast. Funk ist nie so gut wie Leitungen - wenn Leitungen verlegbar sind.

Zu deinen Fragen:

zu 1. und 2. Die SSID der Shellies lassen sich in der aktuellen Firmware nicht ändern, was imho auch gut ist, da sie keine brauchbaren Accesspoints implementieren und nur als Notlösungen für entfernte Shellies einen Einsatzzweck haben. Namen kannst du aber zuweisen. Wenn die Shellies irgendwelche beobachtbaren Aktoren steuern/schalten, ist selbstverständlich eine solche Zuordnung möglich, wenn die Taster mit den Shellies fest verdrahtet sind, also keine "Intelligenz" wie einen Plus i4 besitzen.

zu 4. Wenn du dir das Menü auf den Websites der Shellies genauer ansiehst, wirst du erkennen, dass man vor "Password protected AP Network" einen Haken setzen kann und dann für dieses bandbreitenarme WLAN ein Kennwort festlegen kann. Dies erscheint mir für deine aktuelle Umgebung vor Ort als einziges zweckmäßig. Ich würde für alle diese Shellies das gleiche Kennwort vergeben.

zu 5. Ja klar, so als ob die Shellies soeben installiert worden wären. Man kann ja auch jeden Shelly bzgl. der Konfiguration in den Auslieferungszustand versetzen - wenn nicht komplett, dann zumindest so, dass man ihn neu einrichten kann.

Nur Punkt 4 erscheint mir beachtenswert. Alles andere kannst du sein lassen, solange dort noch kein Internetzugriff möglich ist. Ohne diesen Zugriff kannst du die Firmware nicht aktualisieren, was eine der ersten Aktionen sein sollte.

Vorgehensweise für jeden Shelly:

1. Mit dem Shelly eigenen WLAN verbinden, damit überhaupt konfiguriert werden kann.

2. Per Webbrowser die Website des Shelly laden, nicht die Shelly App dafür nutzen wollen!

3. Bei Bedarf erste kleine Funktionstests durchführen, aber nicht übertreiben.

4. Den Shelly mit dem vorhandenen LAN/WLAN verbinden/koppeln.

5. Die Firmware aktualisieren, Shelly rebooten.

6. Die erforderlichen weiteren Konfigurationen vornehmen.

7. Abschließende Funktionstests vornehmen.

8. Optional: Skripte erstellen ...

Empfehlung:

Verwende möglichst nicht diese merkwürdigerweise allzu oft eingesetzten Class C Netzadressen (192.168.xxx.yyy)! Setze am besten gleich auf Class B (172.16.xxx.yyy, statt 16 auch andere Werte möglich, aber nicht alle) oder Class A (10.xxx.yyy.zzz) Netzadressen. Das gibt dir für die Zukunft erheblich mehr Flexibilität. Und ich kann dir statische IP-Adressen empfehlen, die du vor deren Verwendung gut planen und dokumentieren solltest. Berücksichtige dabei, dass dein Netzwerk vielleicht so weit wachsen wird, wie du es dir gegenwärtig noch nicht vorstellen magst! Eine gute Planung darf Stunden oder Tage dauern, sie ist eine gute Investition, welche deine spätere Arbeit am Netzwerk unterstützen wird.

Na dann viel Spaß, Ausdauer und Experimentierfreude mit den Shellies, sie sind es wert

Nun, dein Verfahren per JSON.stringify() verwendet den kompletten String. Per includes() Methode kann nicht zwischen key und value unterschieden werden. Per Knoten switch und change werden eindeutig keys verwendet. Das macht das Vefahren robuster. Prinzipiell wäre ein value "switch:0" oder "switch:1" möglich, welcher per replace() in der Nachricht verändert würde. Das sind die Gründe, warum ich auf das Verfahren mit den Knoten setzen würde.

Hier meine 3 Knoten, allerdings für die MQTT Nachrichten von einem Plus H&T. Die Teile sollten für dich leicht anpassbar sein.

[
    {
        "id": "a795fdbf4b88cc48",
        "type": "change",
        "z": "1d57fbc98cc72f61",
        "name": "temperature",
        "rules": [
            {
                "t": "set",
                "p": "payload",
                "pt": "msg",
                "to": "payload.params.temperature:0.tC",
                "tot": "msg"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 870,
        "y": 420,
        "wires": [
            []
        ]
    },
    {
        "id": "933fce3faee525d2",
        "type": "switch",
        "z": "1d57fbc98cc72f61",
        "name": "has key",
        "property": "payload.params",
        "propertyType": "msg",
        "rules": [
            {
                "t": "hask",
                "v": "temperature:0",
                "vt": "str"
            },
            {
                "t": "hask",
                "v": "humidity:0",
                "vt": "str"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 640,
        "y": 440,
        "wires": [
            [
                "a795fdbf4b88cc48"
            ],
            [
                "b7f8ead8af088ca7"
            ]
        ]
    },
    {
        "id": "b7f8ead8af088ca7",
        "type": "change",
        "z": "1d57fbc98cc72f61",
        "name": "humidity",
        "rules": [
            {
                "t": "set",
                "p": "payload",
                "pt": "msg",
                "to": "payload.params.humidity:0.rh",
                "tot": "msg"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 860,
        "y": 480,
        "wires": [
            []
        ]
    }
]

Ich habe hier noch nie einen JSON String aus Node RED hineinkopiert und weiß deshalb nicht, ob das so funktioniert. Nach einem gelungenen Test: Node RED -> Import, dort einkleben aus der Zwischenablage -> Import

Wenn du den JavaScript Quellcode bevorzugst, könnte vielleicht der von martner, Post #4, geeignet sein, allerdings würde ich diesen von unnötigem Müll (default ist überflüssig) befreien. Und dieser wäre für deinen Zweck anzupassen und zu erweitern.
Problem: Die Topics zu den Temperatur- und Luftfeuchtigkeit-Informationen von meinem Plus H&T sind andere.

Ich halte diese Notation mit dem Doppelpunkt auch für suboptimal, zumal im switch Objekt meiner Erinnerung nach die Id enthalten ist. Jedenfalls ist es beim Plus H&T mit temperature und humidity der Fall.

In meinen mJS Skripten für die Plus Geräte hatte ich auch damit zu kämpfen.

Du kannst statt deiner Funktion auch eine Kombination aus einem switch Knoten und zwei change Knoten verwenden.

Im switch msg.payload.params has key bzw. hat Schlüssel switch:0 auf Ausgang 1 und switch:1 auf Ausgang 2.

In den change Knoten sind bspw. msg.payload die Werte von msg.payload.params.switch:0 bzw. msg.payload.params.switch:1 zuzuweisen.

Dann braucht keine Konvertierung in einen string durchgeführt zu werden und du erhälts sofort den gewünschten Wert.

Falls der von mir notierte JSON Pfad nicht ganz stimmen sollte, wirst du ihn für deinen Zweck sicher anpassen können.

Sorry, ich habe überarbeitet. Ich testete es mit einer MQTT Nachricht von einem Plus H&T. has key funktioniert wohl nur mit einem einfachen Schlüssel, also nicht mit params.switch:0 ...

Verständlich

Wenn ich einen Assistenten einsetzen werde, wird es openHAB sein.

Bisher konnte ich alles, was ich implementieren wollte, mit Node RED schaffen - mit Einsatz von MQTT, HTTP und Influx -, auch ein Dashboard, welches meiner Frau zusagt und zu welchem sie aktiv Wünsche äußerte.

Devil Ich sprach bzgl. HomeAssistant, ioBroker und ähnlichen smart home Assistenten nach meiner Erinnerung nicht von "nicht offen", und in diesen Thread ohnehin nicht. Ich las aber in einigen Foren, dass Nutzer immer wieder mit irgendwelchen Tricks beschäftigt sind, welche solche Assistenten dazu bringen sollten, das Gewünschte zu tun. Dazu bräuchte ich imho zuviel Einzelwissen (Vielwisserei). Mich schreckt es ab, wenn Leute hier und da und dort "wissen", wie man etwas zum laufen bringt, das aber allzu oft mehr mit trial and error zu tun hat als mit Durchdringung der Hintergründe. Deshalb setze ich lieber auf etwas, dessen Grundlagen ich verstehen kann und dessen Bausteine ich flexibel zusammensetzen kann.

Ich kann erheblich besser Zusammenhänge erfassen und nutzen als einzelnes know how im Gedächtnis zu halten. Und ich liebe die Flexibilität, die mir Programmierung bietet.

Ich sah mir tatsächlich nur kurz FHEM und ioBroker an, mit openHAB habe ich mich etwas tiefer beschäftigt und kam zu dem Schluss, dass für mich openHAB das derzeit einzige interessante Assistentensystem ist. Aus Zeitgründen habe ich es allerdings auf Eis gelegt, weil ich mit genügend anderen Baustellen beschäftigt bin. Solche Assistentensysteme sind meinem Eindruck nach in erster Linie für rezeptartige Nutzung erstellt, was von vielen Anwendern sicher begrüßt wird. Ich allerdings mag nur selten rezeptartiges Vorgehen und bevorzuge flexible Eigenkreativität.

Ein Freund hat erheblich mehr smart home Elektronik als ich und eine Laborausstattung, welche ich noch nie annähernd besaß. Trotzdem kann ich die smart home Geräte sicherer und kreativer einsetzen als er, weil ich mich immer wieder darum bemühte, Dinge und Zusammenhänge zu verstehen.

Btw. genauso könnte ich bspw. fragen, warum jemand die wirklich taugliche, nicht proprietäre App mqtt dash nicht einsetzt. Damit habe ich mich sehr eingehend beschäftigt und könnte sie schon deshalb empfehlen, weil sie auch auf alten Smartphones läuft. Dies mag ich, weil mich der überbordenden Konsum abschreckt und ich diesen für schädlich halte.

Ich hoffe, du verstehst, dass ich lieber eigene Wege gehe, als mich einem Assistentensystem unterzuordnen.

Auch sehe ich bspw., dass häufig dieses Blockly (Heißt es so?) eingesetzt wird. Ich habe mich ein wenig damit beschäftigt. Es ist nichts für mich und ich finde, dass es Node RED nicht das Wasser reichen kann. Ich beherrsche ganz gut Quellcode und kann mich in Programmiersprachen einarbeiten.

...

Danke für deine Aufmerksamkeit

P.S.: Aus oben genannten Gründen setzte ich lieber einen MQTT broker, Node RED, Influx Datenbanken und Grafana als eigenständige Dienste ein, als diese von einem Assistentensystem verwalten zu lassen.

Wenn ich ein, noch zu kaufendes, LSC Gerät nicht zur Kommunikation mit Node RED bewegen kann, werde ich es voraussichtlich nicht einsetzen.

Ergänzung

openHAB beinhaltet viele Adapter für verschiedene Protokolle und besitzt ein sehr flexibles Konzept mit interessanter Modellierung.

Nachteil: Um es flexibel nutzen zu können, muss man sich etwas tiefer einarbeiten, was Zeit kostet.

Deshalb habe ich vorläufig openHAB auf Eis gelegt und nutze Node RED, InfluxDB und Grafana - alles läuft auf einem einzigen Raspberry Pi wunderbar.

Ich nutze keine Apple Geräte. Ich sah aber vorhin kurz, dass es ein Youtube Video gibt, in welchem tuya in Homekit integrierbar sein soll.

Nein, die Shelly App ist afaik ausschließlich für Selly Geräte und insbesondere die Shelly Cloud konzipiert.

Ich nutze für solche Zwecke ein von mir erstelltes Node RED Dashboard. Vermutlich kann für dich openHAB interessant sein.

Wenn du Node RED, bspw. auf einem Raspberry Pi, nutzt oder dies zumindest in Erwägung ziehst und die Adaption tuya -> MQTT (oder HTTP) per Node RED funktioniert, sollte auch eine cloudlose Verwendung möglich sein.

Und ja, diese LSC Leuchten arbeiten wohl mit tuya.

Sobald ich weitere Erkenntnisse gewonnen habe, werde ich dies mitteilen.