Zitat von 87insane

Das topic stellt immer nur den Namen bereit.

Ein topic in MQTT, - wie ich es verstanden habe -, ist der Name inklusive der Struktur.

Aber du hast dennoch recht, da "Shelly" ja nicht das topic zur Änderung anbietet, sondern "nur" das prefix. Genau das habe ich ja falsch interpretiert.

Ob das am Ende gut so ist, liegt wohl im Auge des Betrachters, bzw., wie man den MQTT Broker verwenden und einrichten möchte.

Zum OT Thema:

Es gibt für MQTT 3 Absicherungsebenen

• Security auf Protokollebene (TLS, kann Shelly Original FW nicht)
• Authentifizierung (User : Password)
• Autorisierung (welche topics der Client senden und/oder abonnieren darf, funktioniert aber meines Wissens nach nicht mit MQTT2_SERVER )

Ist das korrekt?

Wenn ich maximale Sicherheit und keine Cloud verwenden möchte, müßte ich einen mosquitto Broker korrekt und vollständig mit TLS und Autorisierungen für die Clients einrichten und die Shelly FW durch z.B. durch tasmota ersetzen.

Vielleicht kannst du mir da auch weiter helfen.

Vielen Dank,

Gernot

Ich habe im forum.fhem.de den Hinweis erhalten, dass das CUSTOM MQTT PREFIX ausschliesslich die Shelly ID ersetzt. Ab der 43. Stelle wird das Topic zu lang und kappt alles folgende, u.a. auch das Vorgabe Topic "/online". Ab der 50. Stelle ist endgültig Schluss.

Es ist wohl für die optimale MQTT Nutzung doch besser z.B. tasmota zu flashen.

Gernot

Ein freundliches "Hallo in die Runde",

hat einer von Euch auch die neue Möglichkeit zur Vorgabe eines eigenen Prefix für MQTT ausprobiert?

Das Ergebnis war bei mir eher überraschend, - da anders als in meiner Erwartung -, wirkt sich das custom Prefix nur auf die Struktur "unter" dem Hauptprefix "shellies/" aus:

Des weiteren frage ich mich, woher das topic:

shellies/home/20_KELLERGESCHOSS/25_VORFLUR/25_Dec

kommt und was der Wert aussagt?

Es scheint so als würden die ersten 5 Zeichen der letzten Ebene (bei mir Gerätename) genommen um einen für mich nicht nachvollziehbaren "boolean value: true | false" auszugeben.

Gibt es für diese Einträge und Funktion eine Erklärung?

Danke,

Gernot

Hallo @ReinP,

Die Aussage:

Zitat

Also lieber nochmal 50 Euros investiert als ellenlange Fehlersuche.

finde ich nicht gut, aber, Im Ergebnis, dass die Steuerung im richtigen Verhältnis zu den eingesetzten Sensoren und Aktoren dimensioniert sein sollte, stimme ich Dir jedoch zu.

lg

Gernot

Hallo Bernd, Guzzi-Charlie,

bei einer solch' berufenen Unterstützung sollte es doch schnell gelöst sein.

lg

Gernot

Hallo Bernd,

es fällt mir schwer zu glauben, dass die „Nachrichtenflut“ von 50 nur Geräten den RPi3+ so sehr belasten.
Hast Du denn vorher analysiert wer oder was diese Systemlast erzeugt. Auf Systemebene zeigt Dir z.B. "top" die größten Lasterzeuger an. Sollte tatsächlich fhem ganz oben stehen, hilft "apptime count all" in der Fhem Befehlszeile dabei das/die verursachenden Module in Fhem herauszufinden. Noch detaillierter zeigt "strace [PID von Fhem]" auf Systemebene an, was passiert.

lg

Gernot

Ach ja, hätte ich fast vergessen, das funktioniert nur, wenn Dein Mosquitto Broker nicht z.B. mit User und Passwort oder Zertifikat oder ... abgesichert ist.

lg

Gernot

Hallo StealthAngle,

der MQTT2_SERVER ersetzt den mosquito MQTT Broker.
Da Dein Mosquitto Broker auf dem gleichen Rechner, wie Fhem läuft, brauchst Du nur diesen nur zu beenden und dafür zu sorgen, dass er bei dem Systemstart nicht mehr gestartet wird.

Danach übernimmt der MQTT2_SERVER die Funktion des Brokers.

Mit aktiviertem autocreate werden zu allen eingehenden Messages zu den Topics automatisch die entsprechenden MQTT2_DEVICE angelegt. Nachdem Du diesen devices ein entsprechendes Template zugeordnet hast, sollten diese auch aufbereitet angezeigt und bedienbar sein.

Meiner Ansicht nach werden hier unterschiedliche Normen diskutiert (s. z.B. hier)

Derzeit reicht das ce Kennzeichen für die Erfüllung der Rauchmelderpflicht aus. Hier wird nicht auf fest eingebaute Batterien geprüft!

Anderes gilt für

Die VdS 3131 und vfdb 14-01 Richtlinie (Q)!

Zitat von SparkyMaster

Nicht wirklich!

1. Die Leuchte würde nie leuchten! -> nur N

2. immer zwei Schaltvorgänge -> SW + Taster

3. Welcher Sinn steckt hinter N auf SW?

1. rechts, blau = N und links von O, lila = L

2. ?

3. Taster schließt SW und I

Aber, Du bist der Experte, ich ändere meinen Beitrag.

lg, Gernot

Um bei der Zeichnung von michis0806 zu bleiben.

Wäre das eine möglicher Lösungsansatz?

Nein, lt. SparkyMaster !

So wie im Anhang sollte es funktionieren

Nächster Versuch ...

Zitat von Guzzi-Charlie

Ich weiß, HTTMOD ist ein Riesen Akt. Ich hole darüber die Benzinpreise nach FHEM. Es ging hauptsächlich um die Bestätigung das es anders im Moment nicht geht.

Du brauchst dich doch gar nicht mit httpmod zu quälen. Ich habe doch hier und im fhem Forum eine myUtils zur Verfügung gestellt. Das Ergebnis ist, dass du mit einem einfachen set Befehl auf das mqtt2-Device einen beliebigen http Befehl an ein Shelly senden kannst und die json Antwort in readings umgewandelt werden.

lg, Gernot

Nein, ich habe nur "Uralte“, die wahrscheinlich nicht HF haben.

Wenn ich neue kaufen müßte, sollten sie ohne die Erweiterung mit einem Shelly "smart" sein.

Na, wenn es dann wirklich nichts hilft, und alles korrekt installiert ist, würde ich den Support kontaktieren. Da ist doch bestimmt noch Gewährleistung drauf, oder?

Prinzipiell bräuchte man in deinem Fall ein vernünftiges Logging bzw. Debugging.

Da habe ich bisher noch nichts gefunden. Gibt es sowas bei der Originalfirmware?

In einem anderen Fall habe ich tasmota geflasht, um das konkreter zu erfahren, was passiert.

unverbindlich und ohne konkrete Idee warum:

Auf die schnelle, habe ich es nicht wieder gefunden, aber, ich bin mir relativ sicher, dass ich es gelesen habe:

Die Stabilität hat sich bei einem Benutzer mit AP's deutlich erhöht, wenn er den AP als Gateway eingetragen hatte.

Zitat von Flo

...

Nein.

Das, was ich mir da ausgedacht habe, funktioniert meiner Meinung nach folgendermaßen:

Der Shelly hängt immer an Phase (braun, Klemme L) und Null (blau, Klemme N). Damit ist er immer in Betrieb und kann jetzt über den Eingang SW Schaltsignale empfangen.

Sorry, ich hatte den Text falsch interpretiert. Du hat recht, BWM + Schalter sind mit SW verbunden.

Zitat von Flo

- Taster an SW1: Einstellungen Kanal 1: Momentary

- PIR an SW2: Activation Switch

Das funktioniert wie gewünscht, aber:

Das Ausschalten der Leuchte über einen Taster funktioniert nur nach Ablauf des Timers von Channel 2 oder dem Ausschalten des Relais 2 per Software! Solange wäre die Statusanzeige von Relais 1 ggf. nicht korrekt.

Hierzu könnte doch, - für die vollständige Kontrolle durch die Taster -, durch die Actions: "BUTTON SWITCHED OFF URL" und "OUTPUT SWITCHED OFF URL" der Software Schaltbefehl "OFF" an den Channel 2 gesendet werden.

Dann müsste auch der Status von Channel 1 immer korrekt sein, oder?

Zu 1):

Meines Wissens nach schaltet nur das Relais den Ausgang.

Das Relais wiederum erhält die Schaltbefehle nur von der Software.

Hier kann definiert werden, wie auf den Eingang Sw reagiert werden soll.

Die Hauptfunktion, schalten des Relais per WLAN, steuert ebenfalls das Relais.

Dein als logischer empfundene Vorschlag würde den Shelly ausschalten (stromlos schalten), oder?!

Zu 2):

Kommst du mit dem "Activation Switch - use it for motion sensor. Any input turns "ON" and resets Auto OFF timer." zum gewünschten Ergebnis?

Bei deiner Theorie zum Shelly 2.5 würdest du O1 mit Sw2 verbinden um eine eindeutige Aussage zum tatsächlichen Schaltzustand der Beleuchtung zu erhalten, oder?

z.B. in Fritz Begriffen: Filterlisten, Zugangsprofile, Priorisierungen u.v.m. steuern.

Ich vermute es handelt sich um Watts per Minute für:

counters/1 aktuell (heutiger Tag)

counters/2 gestern

counters/3 vorgestern

Liege ich damit richtig, und wann werden diese zurückgesetzt bzw. wie kann man diese zurücksetzen?

Zitat

Wherever the URL is to control (CMD EXEC fields and scripts), the IP must be

Username Password@

preceded.

f I'm not completely wrong, the colon between <user>: <password> is important. In your example it is correct.

Please do not interpret as criticism, it is only meant well ...