Beiträge von Sprinterfreak

Die Frage hab ich noch übersehen, sorry.

Zitat von marco.gr

Gibt es einen Grund, weshalb du MQTT verwenden möchtest?

Ja, Interoperabilität. Alles über einen Broker. Das macht es für Multi-Site einfacher und erlaubt einfachere Einbindung weiterer Software.
Mqtt ist halt minimaler Implementierungsaufwand (im Gegensatz zum Websocket), kleinstmöglicher Overhead, Eventbasiert (im Gegensatz zu http polling) und sehr weit Verbreitet. Ich kann da je nach Bedarf einfach noch ein telegraf dran hängen, wenn ich einzelwerte detailierter loggen will oder notfalls eine eigene bridge zu irgendwas dessen Hersteller die lokale Verwendung eines Gerätes nicht vorgesehen hat hin hacken. Nicht immer will man den Homeassistant überall dazwischen haben. z.B. Lastmanagement mit ner Ecoflow Cloud-Frei oder so. Ja, auch die Ecoflow spricht mqtt nativ. Halt nur nicht zu seinem Besitzer, sondern zum Hersteller.

Im Bezug auf Shellies habe ich da mit der Shelly-Integration für HASS eher hakelige Erfahrungen gesammelt. Große Latenzen, instabile Verfügbarkeit. Mqtt läuft einfach stabil und latenzfrei. Ganz abgesehen davon, dass solche Integrationen schnell mal fallen gelassen werden und dann solche non-standart api's nicht mehr funktionieren in neuren Versionen vom System. Also im Homeassistant so wenig externe Software wie möglich, dann brichts auch nicht bei Updates.

Und dann Zuverlässigkeit. Son Broker kann man recht einfach hochverfügbar machen oder restoren im Desaster-Fall. Wenn alles per Rest direkt miteinander spricht ist das mehr Aufwand, das wieder alles zusammen zu bekommen.

Hi Marco,

Zitat von marco.gr

Ich habe bisher nicht hinterfragt, weshalb du ein MQTT Gerät in der YAML konfigurierst. Gibt ja durchaus Anwendungsfälle dafür.

Ich komme noch aus einer Zeit, wo man Heimautomatisierung in Bash, Perl oder PHP selber geschrieben hat. Selbst weit bevor mqtt existierte. Da habe ich keine Angst vor vim. Und yaml ist in git versioniert. Oft kann man auch in dieser grafischen Block-Programmierung die einfachsten Dinge nicht umsetzen, weil nicht alle nötigen Attribute zugänglich sind. Wie z.B. in dem generic_thermostat die min/max-Temp oder step's.

Es lag tatsächlich an meinem alten Firmwarestand. Jetzt funktioniert das auch mit den MQTT-Topics und es gibt ein MQTT-Control. Sieht jetzt auch so aus wie in Deinem Screenshot. Auf der Packung steht auch "Shelly Plus Plug S (White) v2", sieht für mich nach Gen2 aus. Offensichtlich hatte Shelly da einen Schluckauf beim Firmware-Development. Will ich das jetzt nochmal umbauen? Hm...

Natürlich hat das Ding selbst keine Internetverbindung. Wäre ja auch grob fahrlässig.

Wenn es nach expliziter Prüfung sagt, dass die Firmware auf dem letzten Stand ist, muss man davon ausgehen, dass dies via Browser geprüft wurde und richtig ist. Andernfalls müsste richtigerweise ein Fehler angezeigt werden bzw. nicht eine Falschinformation anzeiegt werden. (Screenshot)

apreick Kudos

Hi,

Captain_Byte nö. Der Shelly hat auf mqtt nichts nach homeassistant/# geschrieben. Also kann da auch nichts autodiscovert haben.

marco.gr Leider hat mein Shelly die ganzen Optionen die Du zeigst halt einfach nicht. Und dementsprechend existieren auch die Topics die Du beschreibst, was ich geschrieben habe auch schon probiert zu haben, einfach nicht.

Das wars, was ich an Optionen hab.

Zum Abgleich der Firmwarestand:

Ich nehme an marco.gr , Du hast noch eine ältere Firmware. Solltest Du dann lieber nicht updaten, weil dann ist bei Dir alles in den Fritten...
Übrigens die Template-Expression in den Double-Curly-Brackets nennt sich Jinja2. Ansich sehr geil. Aber man sollte das halt nicht brauchen müssen um eine simple Aktion wie "Relais Ein" auszuführen.

Das mit den regelmäßigen Status-Updates hat sich jetzt auch geklärt. Ich hatte keinen NTP eingerichtet. Das Ding hatte keine Uhzeit. (Brauch es auch bei meiner Anwendung nicht!) Weil jetzt aber in diesen Be.... JSON-Payloads auch Energiemesswerte jedes Mal übertragen werden ist dabei wohl die Software auf dem Shelly beim erstellen der Payload kaputt gegangen. Wieder total unnötig, wenn ich nur den Status eines Relais haben will.

Hi,

zum 2. Mal habe ich jetzt mit der neuen Firmware massive Probleme bei der Einbindung in Systeme.
Diese super unzweckmäßigen json-payloads erzwingen ein massiven Overhead für einfache Aufgaben.

Meine erste Begegnung mit dieser neuen Strukturlosen Kreation hatte ich, als ich einen Shelly 2.5 nach Defekt tauschen musste. Zum Haare raufen.

Was will ich?

Ich habe ein Shelly PLUS Plug S, dessen Relay via mqtt aus Home Assistant als switch oder fan ein und ausgeschaltet werden können soll.

Früher war das einfach (Gen 1 Shelly): Ein einfacher Switch mit Status-Rückmeldung

mqtt:
- platform: switch
  unique_id: "baddehumidifier"
  command_topic: shellies/shellyplug-s-BC7479/relay/0/command
  state_topic: shellies/shellyplug-s-BC7479/relay/0
  payload_on: "on"
  payload_off: "off"
  name: "Bad Entfeuchter"
  icon: mdi:air-humidifier

Mit dem PLUS Plug S bekomme ich das jetzt erst nach stundenlangem probieren hin

mqtt:
- platform: fan
  name: "Küche Heizung Boost Lüfter"
  unique_id: kuche_heizung_boost_fan
  icon: mdi:fan
  command_topic: shellies/shellyplusplugs-kitchenboostfan/rpc
  command_template: '{"method":"Switch.Set", "params":{"id":0,"on": {{ value }} } }'
  payload_on: 'true'
  payload_off: 'false'
  availability_topic: shellies/shellyplusplugs-kitchenboostfan/online
  payload_available: 'true'
  payload_not_available: 'false'
  state_topic: 'shellies/shellyplusplugs-kitchenboostfan/status/switch:0'
  state_value_template: "{{ iif(value_json['output'], 'true', 'false') }}"

Dieses ganze templating ist sowas von überflüssig. Warum kann das nicht einfach "einfach" gemacht werden, wie mqtt ursprünglich gedacht ist?
Ein Topic, ein Wert. Fertig. Super easy zu implementieren, statt jetzt irgendwelche Payloads parsen und craften zu müssen.
Das ist wie wenn man eine mysql-Tabelle mit nur einer Spalte anlegt und dann die strukturierten Daten als json-text alle in die eine Spalte schreibt.
Eine für mich wirklich nicht erklärbare Design-Entscheidung

Übrigens was in der Developer-Doku steht, funktioniert auch nicht.

https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Mqtt schreibt
> <topic_prefix>/command/<component:id> where individual components accept specific commands

In meinem Fall also:
shellies/shellyplusplugs-kitchenboostfan/command/switch:0

Ich hab versucht diverse Dinge hin zu schreiben

* on
* on,0
* true
* 1

auf nichts hat der Shelly reagiert. Auch habe ich versucht switch durch output oder relay zu ersetzen. Geht alles nicht.
Das wäre noch ein akzeptables Topic, was auch von anderen Microcontrollern aus dezentral ansprechbar wäre und in $homeassistant keine harakiri workarounds zum payload craften braucht. Und leider ist das jetzt so unnötig verfrickelt in der neuen Firmware, dass nichtmal mehr chatgpt ansatzweise durchsteigt.

hmpf. Und der neue Shelly PLUS Plug S ist nicht sonderlich gesprächig. Von den alten Shellies war ich gewohnt, dass die alle paar Sekunden mal wieder ein status-Update von sich gegeben haben. (sehr löblich)

Hat von euch das jemand hinbekommen, die neuen Shellies per mqtt anzusprechen ohne davor jedes Mal googlen zu müssen? Dieses JSON-Zeug in mqtt ist echt Krebs.