Beiträge von eiche

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.

Diese Ergänzung ist für mich zwar interessant, entscheidend ist jedoch die Nutzbarkeit von MQTT, die ich per Node RED Adaptierung noch testen will.

Ah ja. Dann sollte ich dafür auch cloudlos Node RED verwenden können. Ich mag diese fertigen Systeme weniger und liebe Freiheiten, die mir MQTT und flexible Programmiermöglichkeiten bieten (bspw. Node RED, Skripte, ...).

Danke

Devil Ich habe bisher nichts mit tuya gemacht. Ich fand aber tuya Erweiterungen in Node RED. Was genau meinst du mit "übergeordnetes System"?

Was ich bisher fand, legt die Vermutung nahe, dass eine Cloud verwendet wird bzw. werden muss. Ich will versuchen, mehr dazu in Erfahrung zu bringen.

OK, mit fester IP Adresse meine ich immer statische IP Adresse. Wäre es dann nicht auch besser von "IP Adresse" zu sprechen als nur von "die IP"? Weil es nur das IP gibt.

Interessant. Danke für den Hinweis. Steht irgendetwas über ein Protokoll in der Installations-/Bedienungsanleitung?

Krauskopp Du bist außerordentlich freundlich (Ende Sarkasmus).

Das war kein Spruch sondern eine Richtigstellung, die durchaus für den TE von Bedeutung ist. Er hat ja auch geschildert, dass die Signalleuchte benötigt wird.

Am Ventillator ist nichts zu ändern. Du kannst aber ein RC-Glied (RC snubber) parallel zum Ventillator schalten, um Funkenbildung am Shelly Relais zu unterdrücken/vermindern.

Mit L und N vertauschen solltest du zurückhaltend sein. thgoebel hat die Schaltungen genauer untersucht und teilte an anderer Stelle mit, dass so die Elektronik noch wärmer würde.

Zum Shelly-Ort: Ich setze gerne auch eine separate Dose dafür ein, wenn es sonst zu eng ist. Manchmal lässt sich ein Shelly auch in der Abzweigdose unterbringen, die den geschalteten Außenleiter (Phase) beinhaltet.

Die Shelly Plus (2. Generation) sind nicht kleiner. Das Problem bleibt also. Es ist aber schon erstaunlich, welch kleinen Raum ein solcher Shelly beansprucht.

Ich nutze die Shelly App ausschließlich für den Zugriff per Cloud. Und nachdem ich hier manches zur App bzgl. lokalem Zugriff las, werde ich bis auf weiteres daran nichts ändern. Der imho verlässlichste und zugleich einfache Zugriff, insbesondere für Konfigurationen, ist der über den Geräte Webserver, also direkt per Browser und Geräte IP-Adresse.

Für die Bedienung setze ich selbstredend i.d.R. nicht diesen Webzugriff sondern akustische Assistenten und übersichtlichere Frontends ein wie App->Cloud, Node RED und MQTT dash (ältere Android App).

Fazit: Klammere dich möglichst nicht an diese App! Sie ist am besten für die Cloud-Nutzung geeignet.

Logischer Fehler: Wenn er den Lüfter aus der Ferne bedienen KANN, kann daraus nicht geschlossen werden, dass er die Glimmlampe sowieso nicht mehr sieht. Er kann durchaus neben dem Schalter stehen und sogar den Schalter betätigen.

In aller Freundschaft

Interessant. Die vom Plus H&T des Freundes verwendeten publish Topics sahen alle anders aus. Ich hatte aber nur einen Abend Zeit dafür

Ich erwarte noch die Lieferung eines Plus H&T. Damit werde ich dann ausgiebiger experimentieren können.

martner und andere: Der Quellcode wird übersichtlicher bei Verwendung eines Code (</>) Abschnitts.

derrapf Ich vergebe auch für Server und IoT Geräte feste IP Adressen. Allerdings habe ich mich noch vor smarthome entschieden, 172er Adressen zu verwenden. Das ergibt mehr Freiräume bei der Zuweisung fester IP Adressen. Du hast ja bereits ein bestimmtes Schema dafür, welches im Adressraum 192.168.xxx weniger Freiräume bietet. Ob es möglich ist, zur Netzadresse 192.168 eine subnet mask von bspw. 255.255.0.0 zu verwenden, weiß ich derzeit nicht und habe auch nicht vor, dies zu testen. Afaik gibt es die frühere Festlegung von Class A bis C so nicht mehr. Ich kenne aber nicht die Konsequenzen. Jedenfalls fahre ich mit 172.xxx und subnet 255.255.0.0 nach wie vor gut und flexibel. Ich weiß, dass eine Umstellung auf eine andere Netzadresse viel Arbeit und insbesondere viel Sorgfalt erfordert. Vielleicht denkst du trotzdem gelegentlich über die Änderung der Netzadresse nach.

Viel Erfolg