[GELÖST] MQTT_GENERIC_BRIDGE: mqttpublish und zweite payload-Ebene?

[frankreed]

Hallo,

Ich hatte diese Frage unter https://forum.fhem.de/index.php/topic,123570.msg1181304.html#msg1181304 bereits gestellt, soll es aber hierher verschieben.

ich habe ein Device vom typ VCONTROL300, das mit brav Readings gefüllt wird.

Code: [Auswählen]

defmod vito VCONTROL300 192.168.xxx.xxx:8888 /opt/fhem/V200KW2_300.cfg 120 kw
attr vito icon sani_boiler_temp
attr vito room Keller
attr vito stateFormat BR: BrennerState ZIR: ZirkulationsState
attr vito userReadings BrennerState {if(ReadingsVal("vito","Brenner","") eq "Aus (0)") {return 0}\
elsif (ReadingsVal("vito","Brenner","") eq "An (1)") {return 1} else {return -1}},\
ZirkulationsState {if(ReadingsVal("vito","Zirkulationspumpe","") eq "Aus (0)") {return 0}\
elsif (ReadingsVal("vito","Zirkulationspumpe","") eq "An (1)") {return 1} else {return -1}}\

attr vito vitotronicType 200_KWx

setstate vito BR: 0 ZIR: 0
setstate vito 2021-10-24 13:05:08 AnlagenTyp 2098
setstate vito 2021-10-24 13:05:07 Betriebsart Heizen_und_Warmwasser (03)
setstate vito 2021-10-24 13:05:08 BetriebsartCode 3
setstate vito 2021-10-24 13:05:08 Brenner Aus (0)
setstate vito 2021-10-24 13:05:09 BrennerStunden2 3.25
setstate vito 2021-10-24 13:05:08 BrennerStunden_Today 2.07
setstate vito 2021-10-24 00:01:09 BrennerStunden_Yesterday 3.23
setstate vito 2021-10-24 13:05:09 TempAussen 8.6
setstate vito 2021-10-24 13:05:07 TempKesselIst 67.3
setstate vito 2021-10-24 13:05:08 TempKesselSoll 62.6
setstate vito 2021-10-24 13:05:08 TempRaumSollNormal 17
setstate vito 2021-10-24 13:05:09 TempRaumSollReduziert 18
setstate vito 2021-10-24 13:05:08 TempWarmWasserIst 59.3
setstate vito 2021-10-24 13:05:09 TempWarmWasserSoll 60
setstate vito 2021-10-24 13:05:07 TempWarmWasserSollParty 16
setstate vito 2021-10-24 13:05:09 UpdateStatus Inactive
setstate vito 2021-10-24 13:05:09 UpdateTime 2021-10-24_13:05:09
setstate vito 2021-10-24 13:05:09 VorlaufTemp 53.5
setstate vito 2021-10-24 13:05:07 VorlaufTempM2 53.6
setstate vito 2021-10-24 13:05:09 ZirkulationsState 0
setstate vito 2021-10-24 13:05:07 Zirkulationspumpe Aus (0)
.....

Jetzt möchte ich einige dieser WErte über die MQTT_GENERIC_BRIGDE als mqtt-Nachricht versenden.
Dazu gibt es ja das Attribut mqttpublish.
Soweit alles klar.

Um das ganze in Home-Assistant weiter verwenden zu können, muss aber die payload einem bestimmten Format entsprechen, z.B.

Code: [Auswählen]

{
"TempAussen": 10,
"TempKesselIst": 60,
"Stunden": {
"BrennerStunden2": 43.0,
"BrennerStunden_Today": 0.8500,
"BennerStunden_Yesterday": 1.25
},
"TempRaumSoll": "False",
"BetriebsartCode": "False"
}

Und das soll unter dem topic "vito/werte" veröffentlicht werden.

Ich blicke nicht durch, wie ich das jetzt machen muss. Das Beispiel in der CommandRef hilft mir da nicht weitef...

Danke im Voraus für die Hilfe

frankreed

[hexenmeister]

Mit 'toJSON' kann man das z.B: so erledigen (habe zum Testen ein HM Wandthermostet verwendet, Prinzip ist jedoch das selbe):

Code: [Auswählen]

desired-temp|measured-temp!json:topic={"test/thermostat/json"}
desired-temp|measured-temp!json:expression={toJSON({"temperature"=>ReadingsVal($device,'measured-temp', undef),
                                       "desired-temp"=>ReadingsVal($device,'desired-temp', undef),
                                       "battery"=>{"state"=>ReadingsVal($device,'battery', undef),
                                                   "voltage"=>ReadingsVal($device,'batteryLevel', undef)}})}

Hier wird ein HASH im HASH erzeugt und an toJSON übergeben.
Ergebniss unter dem Topic 'test/thermostat/json'

Code: [Auswählen]

{
  "battery": {
    "state": "ok",
    "voltage": "2.7"
  },
  "desired-temp": "21.0",
  "temperature": "21.5"
}
Ich weiß nicht ob Homeassistant mit den Strings bei Zahlenwerten in JSON klarkommt, denke aber schon.
Auch eine Lösung nur auf der Seite von HASS müsste möglich sein, den kann man ja recht flexibel umbiegen, wie die Werte zu interpretiren sind (templates).

Achtung! Beim testen habe ich noch ein Bug in MQTT_GENERIC_BRIDGE gefunden. Betrifft AUswertung in expressions bei mehreren eineinander gelegten geschweiften Klammern. Hier hat die Variablenersetzung nur zum Teil funktioniert. Die Korrektur kommt morgen per Update, alternativ kann man die angehängte Datei nehmen.


Update:
Ausprobiert in HASS - kommt wunderbar mit Strings statt Zahlen klar.

Code: [Auswählen]

sensor:
- platform: mqtt
  name: "test"
  state_topic: "test/thermostat/json"
  value_template: "{{ value_json.temperature }}"


[frankreed]

Super, erst mal vielen Dank!

Mein mqttpublish (auf Basis der im ersten Beitrag raw-def meines Devices) lautet:

Code: [Auswählen]

attr vito mqttPublish BetriebsartCode!json:topic={"fhem/vito"}\
BetriebsartCode!json:expression={toJSON({"BetriebsartCode"=>ReadingsVal($device,'BetriebsartCode', undef),\
                                       "Temperaturen"=>{"TempAussen"=>ReadingsVal($device,'TempAussen', undef),\
                                                   "TempKesselIst"=>ReadingsVal($device,'TempKesselIst', undef)}})}

Und das liefert mir unter dem topic "fhem/vito" folgende payload:

Code: [Auswählen]

{
   "BetriebsartCode": "3",
   "Temperaturen": {
      "TempAussen": "10.7",
      "TempKesselIst": "60"
   }
}

Damit kann ich in Home Assistant einen Sensor anlegen (hier in confguration.yaml):

Code: [Auswählen]

sensor:
- platform: mqtt
  name: "vito"
  state_topic: "fhem/vito"
  value_template: "{{ value_json.BetriebsartCode }}"
  json_attributes_topic: "fhem/vito"
  json_attributes_template: "{{ value_json.Temperaturen | tojson }}"

So wird festgelegt, dass mein Reading "BetriebsartCode" als state-value und die Readings "TempAussen" und "TempKesselIst" als Attribute beim Home-Assistant Sensor mit dem Namen "vito" auftauchen.
Ab dann kann man sich mit diesem Sensor weiter in Home Assistant austoben.

Vielen Dank an hexenmeister.

PS: Mal schauen ob ich das in einen WIKI-konformen Beitrag gießen kann als Ergänzung zur MQTT_GENERIC_BRIDGE. Beispiele sind ja beliebt.

Schönen Abend

frankreed

[frankreed]

Das Nonplusultra wäre natürlich, wenn man auf der zweiten Paylod-Ebene per Wildcard alle Readings veröffentlichen könnte. So à la:

Code: [Auswählen]

{
   "State Reading": statevalue,                         
   "Readings": {
      "Reading 1": Readingvalue 1,
      "Reading 2": Readingvalue 2,
      "Reading 3": Readingvalue 3,
      .....
   }
}

Klar bekommt man das Ergebnis auch hin, wenn man die Definition oben von hexenmeister manuell um alle Readings ergänzt, es würde einem aber doch viel Tipparbeit ersparen.

Aber ich will ja nicht unverschämt sein :-)

[hexenmeister]

MQTT_GENERIC_BRIDGE ist in diesem Fall nur für den Transport zuständig, nicht für den Inhalt. Du benötigst für toJSON ein Hash mit allen gewünschten Werten. Die Bridge kann diesen nicht liefern. Du kannst Dir alternativ eine Routine erstellen, die so ein Hash für ein gewünschtes Gerät zusammenbaut und in der mqttPublish-Definition verwenden.

Irgendwie sowas (habe jetzt nicht mit der Bridge getestet):

Code: [Auswählen]

{my $a=$defs{$device}->{'READINGS'};; my %r = map { $_ => $a->{$_}->{'VAL'} } grep {substr($_,0,1) ne "\."} keys %{$a};; toJSON(\%r)}In %r wird ein Hash mit allen Readings (außer versteckten (das sind dijenigen, die mit einem Punkt anfangen)) eines Gerätes ($device) erstellt.

Grundsätzlich halte ich nicht viel daon, immer alles zu übertragen, man gibt dabei die KOntrolle ab. Als eine einmalige Aktion, kann man auch genau die gewünschte Namen benennen. Muss aber jeder für sich selbst entscheiden.

Ich verwende auch Homeassistant und zeige dort Werte aus FHEM an. Allerdings übertrage ich readings als flache Strukturen und mit Hilfe von NodeRed (da läuft die meiste meiner Logik) erstelle (neben Einträgen in InfluxDB) mqtt auto discovery Einträge für Homeassistant.

[frankreed]

Um eines zu sagen:
Es gibt nichts in HomeAssistant, was man nicht alleine mit FHEM machen könnte. HomeAssistant ist zwar vielleicht etwas hübscher mit der Lovelace-Oberfläche, aber das ist eine Geschmacksfrage.
Wenn ich sehe, was manche über FTUI und HTML/css auf den Bildschirm zaubern mitsamt der Logik dahinter: Da kann man neidisch werden.

Ja das habe ich verstanden, dass die MQTT_GENERIC_BRIDGE "nur" für den Transport zuständig ist. Sprich für das, was Richtung Broker gereicht wird, bin ich selber zuständig.

Klar hat das Konstrukt FHEM-->Broker-->NodeRed-->Broker-->HomeAssistant seinen Charme und man hat die Möglichkeit, das Beste aus allen drei Welten zu haben und ich habe es mir auch schon überlegt. Aber FHEM, NodeRed, HomeAssistant, Portainer, InfluxDB, Grafana und Nextcloud (alles über Docker per IOTStack) zusammen auf einem RPI4 kann schon etwas eng werden (Memory).

Und ehrlich:
Ich mit meinen rudimentären perl-Kenntnissen für FHEM und noch geringeren YAML-Kenntnissen für HomeAssistant bin schon jetzt überfordert. Dazu auch noch Javascript für NodeRed? Hut ab für hexenmeister und meinen Respekt dafür. Ich bewundere Leute, die das können.

Danke nochmal ausdrücklich an hexenmeister für seine Hilfe

Grüße
frankreed

[hexenmeister]

Mit FHEM kann  man alles mögliche machen, ich gehe aber oft den Weg des geringsten Wiederstandes (bin eben in machwen Dingen etwas faul ).
Was mir an dem HASS gut gefällt, dass man eine recht ansehliche Oberfläche ohne Vorkenntnisse sehr schnell zusammenzaubern kann. Und eine große Zahl der grafischen Drittkomponenten ist auch beeindruckend. Das Sahnehäubchen ist dann das wirklich gute App. Mehr mache ich mit HASS auch nicht.

FHEM ist sehr gut als eine Art Treiber für manche Hardware. Und in NodeRED kann man seine Logik übersichtlich gestallten. Man muss sich da schon ein wenig einarbeiten, macht man aber einmal halbwegs sauber, wird man das auch Monate später durchblicken.

Läuft auch alles in Docker, der Pi (bzw. CubieTruck) ist mir schon lange zu eng geworden. Läuft jetzt auf einer Synology DS720 mit 10GB RAM.