Beiträge von eiche

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

Ich hatte letztens bei einem Freund genau dieses Problem in Node RED lösen können. Es geht. Schubbie's Hinweis auf den switch node möchte ich aus meiner Erinnerung bestätigen.

Ich verwende ausschließlich solches Subnetting, also 172er Adressen. Selbstverständlich geht das. Die Subnet mask ist dann zweckmäßigerweise auf /16 bzw. 255.255.0.0 oder ähnlich einzustellen. Ähnlich, wenn du kleinere Teilnetze einrichten willst.

Das kann ja auch nicht. Dazu musst du den Shelly neu in dein WLAN bringen, also neu einrichten.

...

@66er Ich nutze 2.5er im Roller Shutter Modus mit Button Type Detached Switch, da ich daran keinen Taster angeschlossen habe, Steuerung per i4.

Habe ich da etwas falsch verstanden?

Hmm ... und ab welcher Wartedauer wird einfach nur geschaltet? Rhetorische Frage XD

Soweit ich es verstanden habe, sucht Stefan nur die Möglichkeit, ein zweimaliges kurzes Tasterdrücken auswerten zu können.

Meine Shelly 2.5 sind alle als Shutter verbaut. Ich weiß derzeit nicht, ob deren Firmware ein zweifach Drücken auswerten kann.

Tasmota könnte es.

Das stimmt nicht ganz. Ein Reset startet den Mikrocontroller neu, ohne die Konfiguration zu ändern. Für das Rücksetzen der Konfiguration wäre somit ein weiterer Knopf erforderlich oder bspw. ein langes Drücken eines Reset-Knopfes. In den reinen Funk-Shellies, die oftmals in Leerdosen oder hinter Schaltern verbaut werden, ist

1. wenig bis kein Platz mehr und
2. deren Ausbau oft aufwändiger, als ein paarmal einen Schalter oder Taster zu drücken.

Das 2s Warten ist mir allerdings neu. An den Shellies der erste Generation konnte ich bisher die Konfiguration immer mit oftmaligen Schalter-/Taster-Drücken in den Auslieferungszustand versetzen.

Fehlende Datumsinformation auf den Shelly Plus

Hier beschreibe ich (lückenhaft) ein ursprüngliches workaround, das auch als nützlicher Dienst nutzbar ist.

Zur Gewinnung eines Datums, bspw. aus einem Shelly Plus Script. Grundlage ist ein Linux Computer(chen) - ich nutze einen Raspberry Pi - mit mosquitto als MQTT Broker und selbstredend MQTT. Zusätzlich wird jq als JSON "Interpreter" verwendet und muss auf dem Server installiert werden.

Das folgende kurze Shellskript ist als Service gestartet. Auf eine MQTT Nachricht sendet es die gewünschte Zeitinformation - lokal auf dem Raspberry - im gewünschten Format. Das Topic lautet "time/format" und ist ggf. auf eigene Bedürfnisse abzuändern.

Die Payload muss im JSON Format das seitens des Service (shellscript) zu verwendende Topic und die Formatierung für das Linux date Kommando enthalten. So kann jede Anwendung (Shelly Script) ihr spezifisches MQTT Subscriber Topic verwenden und erhält Geräte bzw. Script zielgerichtet die gewünschte Zeitinformation.

#!/bin/sh
mosquitto_sub -h localhost -t time/format -q 1 | while read p
do
        t=$(echo $p | jq -r .t)
        f=$(echo $p | jq -r .f)
        d=$(date +"$f")
#       echo received:$p, topic:$t, format:$f, transmit:$d
        mosquitto_pub -h localhost -t $t -q 1 -m "$d"
done

Es folgen Schnipsel aus einem meiner Shelly Scripts, in welchem das Datum angefordert wird. Falls mehr Informationen oder auch das komplette Script gewünscht ist, kann ich dieses gerne zur Verfügung stellen.

Allerdings verwende ich insgesamt drei Skripte, die als virtuelle Geräte arbeiten. Alle Topics sind beispielhaft und auf eigene Bedürfnisse anzupassen.

In Zeile 20, die tatsächlich in einer Funktion stehen sollte, wird die passende MQTT Nachricht veröffentlicht - mit dem Service-Antworttopic "ButzeDecke/swdate/0" und dem Formatstring "%_d. %b" für das Linux date Kommando.

In der Subscriber Funktion ist wesentlich, per importierter payload die Zeitinformation irgendwie abzuspeichern bzw. zu verarbeiten, siehe Zeile 26.

// the topics

let Pre = 'ButzeDecke/'; // the MQTT pretopic

let Pub = { // publisher
  LastOn: Pre+'laston/',
  Switch: Pre+'switch/', 
  ServTime: 'time/format',
  Circuits: Pre+'circuits',
  SwitchLog: Pre+'switchlog'
};

let Sub = { // subscriber
  Switch: Pre+'switch/cmd/+',
  Date: Pre+'swdate/'
};

// an MQTT publisher example using the time service, usually a call within a function, it asks for the date information
// the JSON payload consists of "t" for the wished topic and "f" for the wished time format, using the linux date format
MQTT.publish(Pub.ServTime, '{"t":"'+Sub.Date+'0'+'","f":"%_d. %b"}', 0, false);

// the MQTT subscriber getting the day information
MQTT.subscribe(Sub.Date+'+',
  function(topic,payload){
    let obj = ObjList.get(getId(topic));
    if(obj!==null) obj.Date = payload; // get the day
  }
);

Falls zu meiner Implementation stärkeres Interesse bestehen sollte, kann ich gerne gelegentlich mehr dazu schreiben.

Frohe Tage