Weiter zum Inhalt
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. ioBroker Allgemein
  4. Problem mit retained MQTT Nachrichten bei Shelly TRV

NEWS

  • Neuer ioBroker-Blog online: Monatsrückblick März/April 2026
    BluefoxB
    Bluefox
    8
    1
    678

  • Verwendung von KI bitte immer deutlich kennzeichnen
    HomoranH
    Homoran
    10
    1
    523

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    18
    1
    1.1k

Problem mit retained MQTT Nachrichten bei Shelly TRV

Geplant Angeheftet Gesperrt Verschoben ioBroker Allgemein
2 Beiträge 1 Kommentatoren 321 Aufrufe 1 Beobachtet
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • B Offline
    B Offline
    Bhenyamin
    schrieb am zuletzt editiert von
    #1

    Moin zusammen,

    Mit welchen Einstellungen im MQTT Adapter bzw. welcher Architektur kann ich sicherstellen, dass ein Topic A nur einmal, TOPIC B jedoch bei jeder erneuten Verbindung an den Client übertragen wird?

    Shelly TRV ist für 2 Topics subscribed: Zieltemperatur und Boost-Minutes, die dann im Shelly ablaufen und das Ventil voll öffnen. Zieltemperatur kann / soll ja bei jeder Neuverbindung mit dem Broker übertragen werden. Die Boostdauer soll aber nicht jedes mal neu auf X Minuten hoch gesetzt werden.

    Hier nochmal ausführlich:


    Zur Erklärung:
    ich habe 2 Shelly TRV (Heizkörperthermostate) im Bad über dem MQTT Adapter angebunden.
    Zuvor habe ich das über die HTTP - Befehle gemacht, was oft nicht gut funktioniert hat, da die TRVs oft nicht im Netzwerk erreichbar waren und der Befehl entsprechend nicht ausgeführt wurde. Im Ergebnis oft morgens ein kaltes Bad / kalter Boden.

    Im Zuge der Einrichtung zweier Sonoff NS-Panels (wer's kennt - in der geflashten Tasmota Variante mit dem Lovelace UI) habe ich also auf MQTT umgestellt, was auch dahingehend viel besser funktioniert, dass die Commands immer bei den TRV Thermostaten umgesetzt werden.
    Aktuell publishe ich also an 2 Command-Topics:

    • shellies/shellytrv-Rad-Bad/thermostat/0/command/target_t
    • shellies/shellytrv-Rad-Bad/thermostat/0/command/boost_minutes

    Ich kann so also die Zieltemperatur und die Boost - Restzeit (Ventil voll auf) des TRV ändern, was zuverlässig und mit meist sehr geringer Latenz (bis einige Sekunden) funktioniert. Mehr Kommunikation mit den TRVs brauchts nicht. Die ganze Logik der Automatisierung (Fensterkontakt zur Badlüftung, automatische Heizphasen je nach Jahrszeit und Abwesenheit usw... habe ich über Blockly Skripte realisiert).

    Nachdem ich nun schon ewig rätsel, warum sich die TRVs (jetzt im Sommer) immer wieder wie von Geisterhand in den Boost begeben und diesen auch nicht mehr verlassen, stelle ich fest, dass es mit "[shellytrv-2C1165DAADA1] connection closed: Error: read EHOSTUNREACH" zusammenhängt.
    Danach wird die Verbindung wiederhergestellt und das TRV erhält die letzte Nachricht auf dem Boost_minutes - Topic erneut.

    Mit welchen Einstellungen im MQTT Adapter kann ich sicherstellen, dass das Boost_minutes Topic nur einmal an den Client übertragen wird, während die zuletzt gesetzte target_t (Temperatur) bei jeder Verbindung übermittelt werden soll?

    B 1 Antwort Letzte Antwort
    0
    • B Bhenyamin

      Moin zusammen,

      Mit welchen Einstellungen im MQTT Adapter bzw. welcher Architektur kann ich sicherstellen, dass ein Topic A nur einmal, TOPIC B jedoch bei jeder erneuten Verbindung an den Client übertragen wird?

      Shelly TRV ist für 2 Topics subscribed: Zieltemperatur und Boost-Minutes, die dann im Shelly ablaufen und das Ventil voll öffnen. Zieltemperatur kann / soll ja bei jeder Neuverbindung mit dem Broker übertragen werden. Die Boostdauer soll aber nicht jedes mal neu auf X Minuten hoch gesetzt werden.

      Hier nochmal ausführlich:


      Zur Erklärung:
      ich habe 2 Shelly TRV (Heizkörperthermostate) im Bad über dem MQTT Adapter angebunden.
      Zuvor habe ich das über die HTTP - Befehle gemacht, was oft nicht gut funktioniert hat, da die TRVs oft nicht im Netzwerk erreichbar waren und der Befehl entsprechend nicht ausgeführt wurde. Im Ergebnis oft morgens ein kaltes Bad / kalter Boden.

      Im Zuge der Einrichtung zweier Sonoff NS-Panels (wer's kennt - in der geflashten Tasmota Variante mit dem Lovelace UI) habe ich also auf MQTT umgestellt, was auch dahingehend viel besser funktioniert, dass die Commands immer bei den TRV Thermostaten umgesetzt werden.
      Aktuell publishe ich also an 2 Command-Topics:

      • shellies/shellytrv-Rad-Bad/thermostat/0/command/target_t
      • shellies/shellytrv-Rad-Bad/thermostat/0/command/boost_minutes

      Ich kann so also die Zieltemperatur und die Boost - Restzeit (Ventil voll auf) des TRV ändern, was zuverlässig und mit meist sehr geringer Latenz (bis einige Sekunden) funktioniert. Mehr Kommunikation mit den TRVs brauchts nicht. Die ganze Logik der Automatisierung (Fensterkontakt zur Badlüftung, automatische Heizphasen je nach Jahrszeit und Abwesenheit usw... habe ich über Blockly Skripte realisiert).

      Nachdem ich nun schon ewig rätsel, warum sich die TRVs (jetzt im Sommer) immer wieder wie von Geisterhand in den Boost begeben und diesen auch nicht mehr verlassen, stelle ich fest, dass es mit "[shellytrv-2C1165DAADA1] connection closed: Error: read EHOSTUNREACH" zusammenhängt.
      Danach wird die Verbindung wiederhergestellt und das TRV erhält die letzte Nachricht auf dem Boost_minutes - Topic erneut.

      Mit welchen Einstellungen im MQTT Adapter kann ich sicherstellen, dass das Boost_minutes Topic nur einmal an den Client übertragen wird, während die zuletzt gesetzte target_t (Temperatur) bei jeder Verbindung übermittelt werden soll?

      B Offline
      B Offline
      Bhenyamin
      schrieb am zuletzt editiert von
      #2

      @bhenyamin

      Sorry, irgendwie war ich da einfach zu blind.
      Mit QoS 2 scheint das ja alles gut zu klappen.
      Kann man wohl als erledigt betrachten, wie es scheint.

      1 Antwort Letzte Antwort
      0

      Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.

      Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.

      Mit deinem Input könnte dieser Beitrag noch besser werden 💗

      Registrieren Anmelden
      Antworten
      • In einem neuen Thema antworten
      Anmelden zum Antworten
      • Älteste zuerst
      • Neuste zuerst
      • Meiste Stimmen


      Support us

      ioBroker
      Community Adapters
      Donate
      FAQ Cloud / IOT
      HowTo: Node.js-Update
      HowTo: Backup/Restore
      Downloads
      BLOG

      297

      Online

      32.8k

      Benutzer

      82.9k

      Themen

      1.3m

      Beiträge
      Community
      Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
      ioBroker Community 2014-2025
      logo
      • Anmelden

      • Du hast noch kein Konto? Registrieren

      • Anmelden oder registrieren, um zu suchen
      • Erster Beitrag
        Letzter Beitrag
      0
      • Home
      • Aktuell
      • Tags
      • Ungelesen 0
      • Kategorien
      • Unreplied
      • Beliebt
      • GitHub
      • Docu
      • Hilfe