Hallo zusammen,
ich habe aktuell ein Shelly PlusHT neu im Einsatz mit der Firmware 0.12.0. Die Kommunikation mit meinem Timberwolf-Server über MQTT klappt soweit prima.
Ich vermisse aber die Möglichkeit die Parameter QOS und RETAIN zu beeinflussen. Bei den Shellies der Gen1 finde ich das, bei dem PlusHT und auch beim Plus1PM allerdings nicht. 
Hat hier jemand einen Überblick?
Beste Grüße
Jens
Hello,
yesterday I received my first Shelly Plus 1PM. I updated the firmware to Version to "0.10.1". I am missing the switch to activated the "retain"-Flag as well. Is there still now answer/solution?
Kind regards
Jens
Weiß auch nicht, Lochstreifen hätte ich noch einsetzen können, aber Disketten… 
Und das Internet wird gelöscht...... 
Menno, wie peinlich ist das denn wieder..... wer den Kalender lesen kann...... uff 
Hallo Detlef,
das stimmt mich nachdenklich, gerade erst hierher gefunden, die Unterstützung schätzen gelernt und dann leider diese Nachricht.
Tausend Dank für den Einsatz und die Hilfsbereitschaft aller hier.
Alles Gute! 
Jens
Hi Schubbie, ich habe da bisher immer nur eine "0" gesehen.
Mein SNTP-Setting habe ich auch bereits auf diversen Settings probiert. Angefangen von "time.google.com" über "fritz.box" und "pool.ntp.org". Jeweils sauber gespeichert und mit Reboot.
Eigentlich ist das ja in den Zeilen 15 und 16 des JSONs auch vorgesehen. Ich habe halt hier schlicht nie einen Inhalt.
Seven of Nine, das Device hat aber doch eine SNTP-Konfig und im JSON ist das doch auch vorgesehen, daher sollte man doch den Werte erwarten dürfen, oder?
Beste Grüße
Jens
Hallo zusammen,
hier mal der Aufbau des JSONs im .../info-Topic:
{
"wifi_sta":{
"connected":true,
"ssid":"",
"ip":"123.123.123.123",
"rssi":-56
},
"cloud":{
"enabled":false,
"connected":false
},
"mqtt":{
"connected":true
},
"time":"",
"unixtime":0,
"serial":1,
"has_update":false,
"mac":"XXXXXXXXXXXX",
"cfg_changed_cnt":0,
"actions_stats":{
"skipped":0
},
"is_valid":true,
"tmp":{
"value":21.38,
"units":"C",
"tC":21.38,
"tF":70.47,
"is_valid":true
},
"hum":{
"value":40,
"is_valid":true
},
"bat":{
"value":100,
"voltage":2.93
},
"act_reasons":["sensor"
],
"connect_retries":0,
"sensor_error":0,
"update":{
"status":"unknown",
"has_update":false,
"new_version":"",
"old_version":"20220324-134040/v1.11.8-HT-fix-g60b9bd1"
},
"ram_total":51520,
"ram_free":40288,
"fs_size":233681,
"fs_free":155871,
"uptime":1
}Hi Seven of Nine, mit dem Argument finde ich dann die Lieferung der Werte von den anderen Devices zumindest in gewissem Maße inkonsequent. Ich hatte gehofft, dass die Möglichkeit an die Info zu kommen, durchgängig über die Inhalte im JSON gelänge. Ist jetzt z.B. eine Visu am Start, müsste die explizit auch über eine Funktion verfügen, die Information zum Zeitstempel aus dem Broker abzuholen. Sonst muss ich mir in meinem Timberwolf eine Logik bauen, die den Zeitstempel des letzten Empfangs protokolliert und den dann wieder ablegt. Geht alles, ginge so nur stressfreier, eben wie bei den anderen Devices.
Beste Grüße
Jens
Hallo zusammen,
ich habe zwei H&T-Devices jeweils nebst USB-Netzteil im Einsatz und mittels MQTT sende ich die Daten an meinen Timberwolf-Server.
Klappt alles soweit prima, jedoch bekomme ich leider keine Info im JSON zur Uhrzeit zu der die HTs ihre Daten gesendet haben.
Ist das bewusst so, oder habe ich da was übersehen?
Beste Grüße
Jens
Hallo zusammen,
ich vermute die Ursache zu kennen. Ich habe in meiner Umgebung auch zwei Buttons im Einsatz. ich habe die allerdings via MQTT in meine Steuerung mittels Timberwolf-Server integriert. Der Button wacht tatsächlich zyklisch von allein auf. Der Buton liefert dann Informationen auf dem folgenden Topic:
shellies/shellybutton1-<deviceid>/input_event/0: reports input event and event counter, e.g. {"event":"S","event_cnt":2}
Ich habe das erst in den Griff bekommen, nachdem ich explizit auf Änderungen im Feld „event_cnt“ reagier habe. Bei den „Geisterevents“ blieb der Counter unverändert, bei einem gewollten Event wurde der Inhalt entsprechend erhöht.
Ich vermute, dass das bei euch die identische Ursache ist, ihr in dem anderen Protokollszenario nur entsprechend reagieren müsstet.
Beste Grüße
Jens
Hallo zusammen,
jetzt habe ich das wohl hoffentlich abschließend begriffen.
Ich habe nun das Topic:
shellies/thermostat/0/command
mit exakt diesem Dateninhalt (ohne Quotierung) beschickt:
settings
Damit ist das Verhalten nun wie gewünscht.
Danke für die Hilfe.
Beste Grüße
Jens
Hallo zusammen,
ich muss leider noch mal nachfassen.
Ich habe nun versucht mal alle TRVs zum Senden ihrer Settings zu veranlassen.
Dazu habe ich das Topic "shellies/thermostat/0/command/settings" mal als boolschen Wert betrachtet und mit einem "true" bzw. "on" beschickt. Aber ich bekomme da nicht wirklich von allen verlässlich was zurück...
Gibt es da eine Zeitspanne in der die antworten sollten?
Beste Grüße
Jens
Danke für die Info.
Dann werde ich das mal entsprechend umsetzen.
Wenn das im Wohnzimmer nicht wie geplant funzt, ruiniert mir das sonst womöglich den WAF .
Ich habe den Timberwolf 2600 im Einsatz und bin wirklich sehr zufrieden. Habe vom WiregateServer migriert. Der Multiprotokollsupport, der architekturelle Aufbau und das sorgenfreie Update der ganzen Betriebssystembasis hatten mich überzeugt. Das Teil schnurrt einfach.
Beste Grüße
Jens
Hallo zusammen,
ich nutze die Cloudanbindung der Devices nicht, sondern habe die Ersten jetzt mittels MQTT mit meinem lokalen Timberwolf-Server verbunden. Klappt soweit.
Jetzt habe ich im Wohnzimmer zwei Heizkörper. Wenn ich die Zieltemperatur jetzt bei beiden immer gleich vorgebe und den tatsächlichen Messwert auch für beide Devices von einem separaten Fühler identisch durchreiche, sollte das doch sauber klappen, oder?
Oder kommen sich die beiden Devices da gegenseitig ins Gehege, weil ja keinerlei weitergehende Information zur Gruppierung der Geräte in einem Raum vorhanden ist?
Danke.
Beste Grüße
Jens
Ah, jetzt verstehe ich das. Danke für die Klarstellung.
Dann kann ich die anderen Daten nicht über MQTT beschreiben. Hat für mich in der Praxis jetzt auch nicht wirklich Relevanz.
Beste Grüße
Jens
Hallo zusammen,
ich habe das nun mal probiert....
Auf das Topic "shellies/shellytrv-<id>/thermostat/0/command/settings"
habe ich nun das JSON
[script]{"display": {"flipped": true}}[/script]
geschickt. Fazit, im MQTT-Explorer ist das genau so zu sehen, aber das Thermostat schert sich nicht drum.
In der Doku macht mich die Formulierung hier "settings will trigger piblishing the content of http /settings endpoint" halt auch ein wenig stutzig.
Der grundsätzliche Weg klappt. Das Beschicken von "shellies/shellytrv-<id>/thermostat/0/command/target_t" mit der gewünschten Zieltemperatur wird sofort umgesetzt.
Beste Grüße
Jens
Besten Dank für die Ansätze.
Ich werde mal mein Glück probieren und berichten.
Beste Grüße
Jens
Hallo zusammen,
ich wünsche euch allen zunächst mal ein frohes neues Jahr. 
Als absoluter Frischling hier in der Runde habe ich mal ein paar Fragen zu o.g. Thema. Ich habe gestern 7 TRVs geliefert bekommen und bin nun dabei die in meine Hausautomation zu integrieren. Als Zentrale dient mit dazu ein Timberwolf 2600. Das Ding beherrscht MQTT und auf dem guten Stück läuft auch der mosquitto-MQTT-Broker im Container. Diverse andere Shelly-Devices verrichten bereits sauber ihre Arbeit, sind integriert und problemlos ansteuerbar.
Allerdings bereitet mir nun die Aktualität der MQTT-API-Doku leider ein wenig Kopfschmerz. Unter den dort benannten Topics sendet das TRV mit der o.g. Firmware definitiv nicht mehr. Dazu habe ich an anderer Stelle der Doku Hinweise gefunden und mit den entsprechenden Tools wie dem MQTT-Explorer kann ich die für mich zum Lesen relevanten Informationen identifizieren. Also nicht wirklich ein Problem.
Aber wie sieht das mit dem Schreiben aus?
Also "shellies/shellytrv-<id>/thermostat/0/command/" und dann? Muss ich vorher via HTTP-API was vorbereiten und dann via "shellies/shellytrv-<id>/thermostat/0/command/settings" was triggern, oder muss ich mir das JSON als Payload zusammenbauen, wie unter der HTTP-Doku beschrieben und dann über das "shellies/shellytrv-<id>/thermostat/0/command/settings"-Topic senden?
Mir ist klar, dass das Device noch nicht wirklich soooo ultimativ verbreitet ist und die MQTT-Anbindung dann noch dazukommt. Aber eventuell könnt ihr mir ja schon weiterhelfen.
Danke!
Beste Grüße
Jens