MQTT2 attrTemplate für Shelly TRV

[Beta-User]

Hmm, diese firmwares sind echt gruselig, die die immergleichen Infos über mehrere Topics an jeweils einer anderen Stelle verpacken... (zumindest sieht das auf die Schnelle so aus).

Kommt denn immer gleich der "volle Status" (settings?). Dann würde es reichen, immer nur den auszuwerten, da scheint ja alles drin zu sein?

Würde mal vorschlagen, das mode:auto,manual-Ding angzugehen. Also zum einen ein passendes jsonMap zu belegen und zum anderen dann aus "true" vorneweg "auto" zu machen etc..
Muster dafür:

Code Auswählen Erweitern


attr DEVICE readingList $\DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); if defined ($ret->{state}) { $ret->{state}=$ret->{state} eq 'true' ? 'closed' : 'open' }; return $ret }


PS: Man kann sich auch am MQTT2_SERVER z.B. mit einem Kommandozeilen-Tool wie mosquitto_sub lesend aufschalten und damit alles in eine Datei pipen.

[casoe]

Ich befürchte, dass übersteigt meine Fähigkeiten. Ich hab das als neuen Inhalt für readingList ausprobiert, aber es kommen Fehlermeldungen.

Kannst du mir konkreter sagen, was ich machen soll?

[Beta-User]

Na ja, das war nicht für copy/paste gedacht, sondern zur Anpassung. Hier also nochmal der ausführlichere Weg:

- Wir definieren einen setter "mode" (statt shedule). Die Zeile sollte (editiert im Attribut-Feld) dann so aussehen:

Code Auswählen Erweitern

mode:auto,manual {my $val=$EVTPART1 eq 'auto'?1:0; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}
Damit sollte auf dem ESP schedule ein- und ausschaltbar sein.

Zurück kommt aber (vermutlich!) über den Topic settings eine Info zu "thermostats_1_schedule", die "true" oder "false" ist. Das korrigieren wir für FHEM an zwei Stellen:
- zum einen muss jsonMap ergänzt werden, damit aus "thermostats_1_schedule" wieder "mode" wird.
- zum anderen muss in der readingList dann aus "mode"=>"true" wieder "on" werden... Diese Zeile lautet dann in etwa so:

Code Auswählen Erweitern

$DEVICETOPIC/settings:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); if (defined $ret->{mode}) { $ret->{mode}=$ret->{mode} eq 'true' ? 'auto' : 'manual' }; for (qw(accelerated_heating boost)) { next if !defined $ret->{$_}; $ret->{$_}=$ret->{$_} eq 'true' ? 'on' : 'off' }; return $ret }


Wie du siehst, ist hier gleich noch eine Schleife eingebaut, die das "true" nach "on" gleich noch für zwei andere keys machen würde (unterstellt, die sind vorhanden.

Für jeden "Fehler" muss man jetzt also in genau der beschriebenen Reihenfolge vorgehen, damit am Ende was "FHEM-konformes" rauskommt. Kommst du damit weiter?

[casoe]

Ich komme erst heute wieder zum Testen.

Das mit dem mode funktioniert nach meinem Dafürhalten schon sehr gut. Ich hab den Setter, die jsonMap und das Reading ergänzt bzw. verändert. Wenn ich "mode" auf auto stelle, wird der Schedule eingeschaltet und mode als Reading richtig auf true gesetzt. Beim Setzen auf manual geht schedule in der Shelly-Weboberfläche auf disabled und das Reading mode geht auf false.

Ich hab dann noch in der jsonMap "thermostats_1_target_t_accelerated_heating:accelerated_heating" ergänzt. Damit wird mit dem setter accelerated_heating dann auch das gleichnamige reading auf on bzw. auf off gesetzt. Das klappt auch wie erwartet.

Damit bleibt noch boost offen. Hier scheint der Shelly TRV ja etwas anders zu funktionieren. Man schaltet den boost mit der Angabe von Minuten ein und kann ihn über 0 Minuten ausschalten. Ansonsten gibt es noch den Setter für den Default-Boost. Wie wollen wir damit umgehen?

[casoe]

Ich hab über Shelly-Oberfläche folgende Sachen mit dem Boost gemacht:

1. Boost time auf 25min gestellt
2. Boost eingeschaltet
3. Boost ausgeschaltet

Dabei ergab sich der angehängte MQ Traffic.

[Beta-User]

Habe mal was eingecheckt, kannst ja wieder testen.

Damit sollte boost funktionieren (mit den ansonsten auch häufig als default anzutreffenden 5 Minuten).

Wenn ich "mode" auf auto stelle, wird der Schedule eingeschaltet und mode als Reading richtig auf true gesetzt. Beim Setzen auf manual geht schedule in der Shelly-Weboberfläche auf disabled und das Reading mode geht auf false.

Auf true oder auto (bzw. false => manual)? Soll wäre auto (nach der Asuwertung der Rückmeldung), sonst empfinde ich das nicht als "richtig". Der Code müßte das eigentlich bereits hergeben...?

Ansonsten gibt es noch den Setter für den Default-Boost. Wie wollen wir damit umgehen?

Habe ihn mal drin gelassen, aber an sich kann er raus, wenn er keine Funktion hat... Vielleicht mal bei der Fa. nachhaken, was das eigentlich bewirken soll?

[casoe]

Okay, ich das eins der Devices gelöscht und dann darauf gewartet, dass der MQTT-Server es neu anlegt.

Beim Anwenden der Vorlage kommt folgende Fehlermeldung:

Code Auswählen Erweitern

MQTT2_shellytrv_BC33AC034B28: bad reading name $MQTT2_shellytrv_BC33AC034B28TOPIC/settings:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); if (defined $ret->{mode}) { $ret->{mode}=$ret->{mode} eq 'true' ? 'auto' : 'manual' }; if (defined $ret->{set_boost_minutes}) { $ret->{boost}=$ret->{set_boost_minutes}?'on' : 'off' }; for (qw(accelerated_heating boost)) { next if !defined $ret->{$_}; $ret->{$_}=$ret->{$_} eq 'true' ? 'on' : 'off' }; return $ret } (contains not A-Za-z/\d_\.- or is too long)

Nach dem Anwenden der Vorlage ergibt sich folgende RAW-Definition:

Code Auswählen Erweitern

defmod MQTT2_shellytrv_BC33AC034B28 MQTT2_DEVICE shellytrv_BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 devicetopic shellies/shellytrv-BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 genericDeviceType thermostat
attr MQTT2_shellytrv_BC33AC034B28 icon temp_control
attr MQTT2_shellytrv_BC33AC034B28 jsonMap bat:0 bat_value:batteryPercent bat_voltage:batteryVoltage target_t_value:desired-temp thermostats_1_tmp_value:temperature thermostats_1_valve_min_percent:valve_min_percent thermostats_1_target_t_accelerated_heating:accelerated_heating thermostats_1_schedule:mode
attr MQTT2_shellytrv_BC33AC034B28 model shelly_TRV
attr MQTT2_shellytrv_BC33AC034B28 readingList shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/status:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/info:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/settings:.* { json2nameValue($EVENT) }
attr MQTT2_shellytrv_BC33AC034B28 room MQTT2_DEVICE
attr MQTT2_shellytrv_BC33AC034B28 setList accelerated_heating:on,off {my $val=$EVTPART1 eq 'on'?1:0;; qq($DEVICETOPIC/thermostat/0/command/accelerated_heating $val)}\
  mode:auto,manual {my $val=$EVTPART1 eq 'auto'?1:0;; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}\
  schedule_profile:slider,1,1,5,1 $DEVICETOPIC/thermostat/0/command/schedule_profile $EVTPART1\
  desired-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/target_t $EVTPART1\
  external-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/ext_t $EVTPART1\
  valve:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_pos $EVTPART1\
  valve_min_percent:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_min_percent $EVTPART1\
  boost:on,off {my $val=$EVTPART1 eq 'on'?5:0;; qq($DEVICETOPIC/thermostat/0/command/boost_minutes $val)}\
  boost_minutes $DEVICETOPIC/thermostat/0/command/boost_minutes $EVTPART1\
  set_boost_minutes $DEVICETOPIC/thermostat/0/command/set_boost_minutes $EVTPART1
attr MQTT2_shellytrv_BC33AC034B28 setStateList on off
attr MQTT2_shellytrv_BC33AC034B28 stateFormat Measured: temperature Battery: batteryPercent %
attr MQTT2_shellytrv_BC33AC034B28 webCmd desired-temp

[casoe]

Vor diesem Test hab ich meine alte Config wiederhergestellt.

Auf true oder auto (bzw. false => manual)? Soll wäre auto (nach der Asuwertung der Rückmeldung), sonst empfinde ich das nicht als "richtig". Der Code müßte das eigentlich bereits hergeben...?

Hast recht. Das reading mode geht beim Setzen über den setter auf auto oder manual. Wenn ich dann aber einen Moment warte und z. Bsp. die Temperatur über die Shelly-Weboberfläche setze, das das reading ganz kurz auf false, dann wieder auf manual und dann wieder auf false. Wenn ich dann noch mal Temperatur verändere, wechselt er kurz auf true, geht dann wieder auf manual und bleibt da. Irgendwie verwirrend.

[Beta-User]

Den "bad reading" Fehler dürfte ich eben gefixt haben. Das mit den wechselnden Werten dürfte damit zu tun haben, dass dazu in diesen Fällen was auf einem anderen Topic kommt, da solltest du ja jetzt wissen, wie es zu fixen wäre?
Das ist irgendwie allgemein etwas "speziell", dass dieselben Infos zu einem guten Teil auf verschiedenen Topics kommen, aber jeweils  etwas anders strukturiert.

Fühlt sich jetzt aber von FHEM aus jetzt schon deutlich runder an, die Sache, oder?

(Der Clou wäre, wenn man auch die Wochenprogramme irgendwie manipuliert bekäme, aber das ist ein sehr spezielles Thema).

[casoe]

Jetzt sieht es gut aus. Der Fehler taucht nicht mehr aus. Ich hab alle Devices noch mal neu angelegt und alle Setter durchgetestet. Das mit dem Boost funktioniert auch wie erwartet.

Das mit den wechselnden Werten dürfte damit zu tun haben, dass dazu in diesen Fällen was auf einem anderen Topic kommt, da solltest du ja jetzt wissen, wie es zu fixen wäre?

Ehrlich gesagt nicht. Ich bin ein Noob. Aber so lange es funktioniert, ist mir das auch nicht so wichtig.

Fühlt sich jetzt aber von FHEM aus jetzt schon deutlich runder an, die Sache, oder?

Die Integration funktioniert schon seit einer Weile sehr gut. Aus meiner Sicht ist das rund so und auf jeden Fall nicht mehr experimentell. Vielen, vielen Dank für dein Engagement. Das war echt super.

(Der Clou wäre, wenn man auch die Wochenprogramme irgendwie manipuliert bekäme, aber das ist ein sehr spezielles Thema).

Ich möchte die Heizprogramme nicht über die Shellys, sondern zentral über FHEM steuern. Dazu will ich mir weekprofile als Nächstes ansehen. Ist das kompliziert? Meine Hoffnung war, dass damit dann einfach geht. Muss mich aber da noch einlesen und mich damit beschäftigen.

[Beta-User]

Jetzt sieht es gut aus. Der Fehler taucht nicht mehr aus. Ich hab alle Devices noch mal neu angelegt und alle Setter durchgetestet. Das mit dem Boost funktioniert auch wie erwartet.

Ok, dann sind wir wieder einen Schritt weiter .

Ehrlich gesagt nicht. Ich bin ein Noob. Aber so lange es funktioniert, ist mir das auch nicht so wichtig.

Na ja, wenn wirklich zwischendurch noch ein true oder false zu sehen ist, kommt das von der MQTT-Seite, und zwar über einen anderen Topic als den mit unserem "umbenennen"-Code. Ergo müßte man entweder da auch nich etwas (entsprechenden) Code reinbasteln (um "falsche" Events zu verhindern), oder wir könnten überlegen, ob man den betreffenden Topic überhaupt braucht. Irgendwie ist ja sowieso alles doppelt und dreifach. Die Frage ist nur, ob das dann was an Info verwerfen würde, die uns doch interessiert, oder ob das so viel schneller geht wie die Status-Message.
Dazu habe ich aber kein Gefühl...

Die Integration funktioniert schon seit einer Weile sehr gut. Aus meiner Sicht ist das rund so und auf jeden Fall nicht mehr experimentell. Vielen, vielen Dank für dein Engagement. Das war echt super.

Gerne! Den Text passe ich bei Gelegenheit noch an.

Ich möchte die Heizprogramme nicht über die Shellys, sondern zentral über FHEM steuern. Dazu will ich mir weekprofile als Nächstes ansehen. Ist das kompliziert? Meine Hoffnung war, dass damit dann einfach geht. Muss mich aber da noch einlesen und mich damit beschäftigen.

Na ja, ohne direkte Umsetzung weekprofile => MQTT2_DEVICE (+Code, der passende payloads darauf generiert), braucht man dazwischen dann halt noch einen WeekdayTimer. Ist auch nicht allzu kompliziert, läuft aber halt nicht "autonom" auf dem Shelly. Manche legen da Wert drauf, dass das auch durchläuft, wenn/solange FHEM ggf. mal down wäre...

[ReneR1986]

Super! Danke euch!
Ich war schon länger auf der Suche nach einem Thermostat, der über WLAN eingebunden werden kann und auch in FHEM integriert werden kann.
Hab jetzt direkt mal einen Shelly TRV bestellt  Leider nicht ganz billig die Dinger..

[casoe]

Joa, aber z. Bsp. die Dinger von Fritz sind gar nicht zu bekommen oder kosten mindestens das Gleiche. Für viele Alternativen bist du auf eine Bridge angewiesen und/oder wirst zwingend an eine Hersteller-Cloud gebunden. Insofern finde ich das Angebot von Shelly fair. Außerdem finde ich den eingebauten Akku gut. Bei sehr vielen anderen Modellen musst du mit Batterien herumtüddeln, was weder aus ökologischen noch aus Kostengründen aus meiner Sicht sinnvoll ist.

[ReneR1986]

Habe ich aber richtig verstanden, dass es ein Attribut Template für MQTT2_DEVICE ist, richtig?
Wie heißt es denn? Habe gerade ein Update gemacht aber kann es auf Anhieb gerade nicht finden oder ich hab Tomaten auf den Augen...

[casoe]

Das attrTemplate heißt shelly_TRV. Du bindest den Shelly über MQTT ein. Dann sollte das Device automatisch angelegt werden. Anschließend solltest du den Shelly steuern können.