gassistant basic parameter

[Matthias-56]

Hallo,

ich versuche seit längerer Zeit erfolglos Messwerte bzw. Sollwerte aus dem Modul THZ per Device Type Dummy und gassistant mit GoogleHome zu verbinden.
Es gelingt Schalter in GoogleHome zu generieren, indem unter Attribut "setlist On Off eingetragen wird.
Es gelingt mir nicht mithilfe von userreadings Werte zu übergeben, damit GoogleHome nach entsprechender Interpretation ein Sensorwidget bzw. Thermostatwidget bereitstellt und diese Werte entsprechend als currentValue bzw. setValue verarbeitet.
Ich habe diverse Schlüsselworte wie "Temperature" CurrentTemperature" "desired-Temperature" "..." in Attribut setlist probiert.
Resultat ist stets die Meldung im Log von gassist "No mappings (e.g. on/off) found for..." .
"e.g. on/off" ist der Knackpunkt. Was muss man denn eintragen, um z.B. ein Temperaturwidget zu bekommen und wie werden die Werte übergeben?

Ich habe das Attribut genericDeviceType probiert, ebenso homebridgeMapping. Allerdings fehlen mir Informationen, wie das korrekt zu verwenden ist und ob es in diesem Fall überhaupt erforderlich ist.
Das Modul THZ habe ich testweise in den Raum "gassistant" gestellt. Das funktioniert erwartungsgemäß nicht. Das Gerät THZ hat sehr viele Parameter und ist sicher ein Spezialfall, der nicht von gassistant behandelt werden wird. Deshalb der Umweg über Device Dummy.

Hier ein Beispiel meiner prinzipiellen Vorgehensweise:

define THZ_Temp_3 dummy
setuuid THZ_Temp_3 66ebd165-f33f-907d-61e1-29d471d8bdb21d26
attr THZ_Temp_3 room GoogleAssistant,Sysintern
attr THZ_Temp_3 setList Temperature
attr THZ_Temp_3 userReadings Temperature:THZ Mythz sHC1.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[1]},

Gibt es irgendwo ein Beispiel einer ähnlichen Konfiguration, die funktioniert, so dass ich das Prinzip besser verstehen kann?

Danke, Matthias

[MadMax-FHEM]

Hallo, auch hier: ein list wäre besser, statt "nur" dem define...

Ich selbst nutze kein gassistant, sondern alexa-fhem.
Sollte aber vom Prinzip her ähnlich sein...

Nur eine Anmerkung: userReadings bei einem dummy machen eigentlich keinen Sinn. Wie sollen die denn "gefüllt" werden? userReadings wird nur "ausgeführt", wenn beim Device wo sie definiert sind Events kommen (die zum Trigger passen). Bei einem dummy tut sich ja eigentlich nix!?
Und wenn man bei einem dummy Werte setzt, damit der dummy per userReadings andere Readings "erzeugt", warum dann nicht gleich dort wo die "anderen Readings" gesetzt werden gleich die gewünschten setzen?

In einem list würde man auch die Readings und deren Werte etc. sehen...

Welche Informationen erbeten/hilfreich sind, hatte ich in dem anderen Thread (Doppelthread statt verschieben?) verlinkt...

Gruß, Joachim

[Matthias-56]

Danke, Deine Hinweise werde ich versuchen zu verstehen und dann ggf. noch einmal nachfragen.
In der Tat sind mir verschiedene grundlegende Zusammenhänge nicht vollständig klar. Z.B. Readings vs userReadings und generell die Sichtbarkeit von Daten im Gesamtsystem. Also was ist global gültig, was lokal.

Gruß Matthias

[Beta-User]

Gibt es irgendwo ein Beispiel einer ähnlichen Konfiguration, die funktioniert, so dass ich das Prinzip besser verstehen kann?

Schau dir mal readingsProxy an.

Generell würde ich aber ggf. versuchen, das THZ-Device direkt als "Thermostat" anzusteuern.

[MadMax-FHEM]

Danke, Deine Hinweise werde ich versuchen zu verstehen und dann ggf. noch einmal nachfragen.

Klar.
Du kannst auch einfach mal lists oder "copy for forum" Infos posten, dann kann man evtl. Vorschläge machen

Gruß, Joachim

[Matthias-56]

Hallo, ich habe in Anlehnung an die gemachten Vorschläge einiges probiert.
ReadingsProxy sieht gut aus, ich schaffe es aber nicht, richtig zu parametrieren.

Insbesondere irritiert mich 

attr Template:
generic template to set attributes for identifying this device by speech speechcontrol software. This template will call several sub-templates - dependent on the speech speechcontrol solutions which are in use in your installation. Pls. do not use one of the subtemplates directly. Call e.g. with set xy attrTemplate speechcontrol_general_naming_master_template

Keine Beschreibung dazu gefunden und das muss auch nicht das Problem sein.
Warum es nicht funktioniert, habe ich nicht herausgefunden.

Code Auswählen Erweitern

define mygaThz readingsProxy Mythz:AussenTemp
attr mygaThz devStateIcon .*:noicon
attr mygaThz eventMap AussenTemp:AussenTemp
attr mygaThz gassistantName Aussentemperatur
attr mygaThz genericDeviceType sensor
attr mygaThz homebridgeMapping {"CurrentTemperature": {"Reading": "AussenTemp"}
attr mygaThz room Sysintern
attr mygaThz setList CurrentTemperature
attr mygaThz stateFormat state °C
#  DEF        Mythz:AussenTemp
#  DEVICE    Mythz
#  FUUID      66eee750-f33f-907d-b5a5-a36336c123f773ff
#  NAME      mygaThz
#  NOTIFYDEV  global,Mythz
#  NR        123
#  NTFY_ORDER 50-mygaThz
#  READING    AussenTemp
#  STATE      16.9 °C
#  TYPE      readingsProxy
#  eventCount 303
#  CONTENT:
#    Mythz      1
#  READINGS:
#    2024-09-22 10:44:43  lastCmd        CurrentTemperature
#    2024-09-25 15:45:37  state          16.9
#
setstate mygaThz 16.9 °C
setstate mygaThz 2024-09-22 10:44:43 lastCmd CurrentTemperature
setstate mygaThz 2024-09-25 15:45:37 state 16.9
So wie hier gelistet, ist zwar mein Zielwert "AussenTemp" enthalten und wird auch aktualisiert, aber in GoogleHome passiert nichts.


Im Forum habe ich einen funktionierenden code unter Verwendung von Dummy gefunden.
39_gassistant.pm (Google Assistant, Google Home) - Seite 196 (fhem.de)
Das funktioniert. In googleHome wird ein Thermostat angelegt.
Meinen Zielwert "AussenTemp" habe ich in die userReadings eingefügt.
"AussenTemp" erscheint in googleHome.

Code Auswählen Erweitern

define hTest dummy
attr hTest assistantName Aussen
attr hTest devStateIcon .*:noicon
attr hTest eventMap AussenTemp:AussenTemp
attr hTest genericDeviceType thermostat
attr hTest homebridgeMapping {\
  "ThermostatModes": {\
    "reading": "gMode",\
    "cmds": ["off:gMode off", "heat:gMode heat", "eco:gMode eco"],\
    "values": ["gMode=/eco/:eco", "gMode=/off/:off","gMode=/heat/:heat"]\
  },\
  "TargetTemperature": {\
    "reading": "desiredTemperature",\
    "cmd": "desiredTemperature"\
  },\
  "CurrentTemperature": {\
    "reading": "AussenTemp"\
  }\
}
attr hTest readingList desiredTemperature gMode AussenTemp
attr hTest room GoogleAssistant,Sysintern
attr hTest setList desiredTemperature gMode
attr hTest userReadings state {ReadingsVal("hTest","gMode",0) eq "on" ? ReadingsVal("hTest","desiredTemperature",0)." °C" : ReadingsVal("hTest","gMode",0)} , AussenTemp {ReadingsVal("Mythz","AussenTemp",15)}
#  FUUID      66f116a4-f33f-907d-116f-a56daf5225c845da
#  NAME      hTest
#  NR        125
#  STATE      heat
#  TYPE      dummy
#  eventCount 64
#  READINGS:
#    2024-09-25 15:43:06  AussenTemp      16.8
#    2024-09-24 16:53:02  Temperature    22
#    2024-09-24 16:34:43  desiredTemperature 21
#    2024-09-25 15:24:57  gMode          heat
#    2024-09-25 15:43:06  state          heat
#
setstate hTest heat
setstate hTest 2024-09-25 15:43:06 AussenTemp 16.8
setstate hTest 2024-09-24 16:53:02 Temperature 22
setstate hTest 2024-09-24 16:34:43 desiredTemperature 21
setstate hTest 2024-09-25 15:24:57 gMode heat
setstate hTest 2024-09-25 15:43:06 state heat


Problem: "AussenTemp" wird nicht getriggert. Aktualisierung nur , wenn ich mit set etwas setze.
Einen Trigger für "AussenTemp" in das userReading einzubauen, hat nicht funktioniert.

Z.B. AussenTemp: .*sGlobal {ReadingsVal("Mythz","AussenTemp",15)}

Den Trigger ".*sGlobal" gibt es im event monitor.
Wo ist der Fehler?

Grundsätzlich möchte ich ja lediglich Temperaturen in googleHome anzeigen, um sie per Sprache abfragen zu können.
Dafür scheint mir genericDeviceType "Sensor" geeignet.
Zu diesem Device habe ich allerdings kein Beispiel gefunden, welches mir weiterhilft.
Wie muss "Sensor" parametriert werden, um in googleHome ein Thermometer zu bekommen?
Ich hatte versucht, im homebridgeMapping nur den Teil "CurrentTemperature..." zu verwenden. Hat nicht funktioniert.

Kann mir jemand helfen?

Gruß
Matthias

 

[MadMax-FHEM]

Ok, bei Templates bin ich "raus"

Aber ein paar weitere Anmerkungen (auch Wiederholungen   ).

userReadings bei einem dummy -> ohne Event BEIM DEVICE WO DAS userReadings "HÄNGT" (also dem dummy selbst) passiert mit dem userReadings nix!
Einen Trigger zu setzen bei userReadings -> "einschränken", damit das userReadings nicht bei ALLEN EVENTS des Devices, sondern nur bei (einem) bestimmten "berechnet" wird...
Ein Event eines anderen Devices -> geht nicht! Dazu wäre dann ein notify der Weg...
(hatte ich schon mal wo erläutert   )

Beim readingsProxy: es gibt kein Reading AussenTemp was aber in deinem homeBridgeMapping verwendet wird...
Ich denke hier wäre ein userReadings möglich/ausreichend. D.h. wenn du per userReadings ein Reading namens temperature oder CurrentTemperature "erzeugst".
(dann kann verm. das homebridgeMapping ganz weg / bei alexa-fhem wäre das so)
Ändern würde ich (dann) den genericDeviceType in thermometer oder thermostat (wenn du auch temp. regeln willst/kannst), dann auch noch ein Reading desiredTemperature oder desired-temp (o.ä.) <- mal bei anderen Devices schauen, z.B. Homematic CUL_HM (die werden mWn autom. erkannt)

Evtl. so:

Code Auswählen Erweitern

attr mygaThz userReadings temperature {return ReadingsNum($name, "state", 0)}
und

Code Auswählen Erweitern

attr mygaThz genericDeviceType thermometer


Dein dummy: wie geschrieben -> wo kein Event da auch keine "berechnung" des userReadings. Wie du selbst gemerkt hast passiert das nur, wenn du etwas mit set setzt, dann gibt es einen Event usw.

Gruß, Joachim

[Beta-User]

Keine Beschreibung dazu gefunden und das muss auch nicht das Problem sein.

Das mit attrTemplate ist ein Hilfsmittel, das dir hier aber nicht weiterhilft, weil du es nicht mit einem "bekannten" Gerät zu tun hast, sondern eben selbst was konfigurieren willst.

readingsProxy ist gedacht für _ein Reading_, nicht für eine Vielzahl. Vermutlich kann man es irgendwie hintricksen, da auch irgendwas mit "desiredTemperature" hinzubiegen, aber dazu müßtest du klären, ob du einen "thermostat" (=> temperature, desiredTemperature und "valve" (bzw. on/off)) oder nur einen Temp-Sensor. Das wäre (zumindest bei RHASSPY) ein "thermometer", und das abzufragende Reading wäre dann eben (derzeit) "state"...

PS: es bringt dich nicht weiter, wenn du es mit rumprobieren angehst, statt zu versuchen, dir ein systematisches Verständnis anzueignen. Angaben wie diese eventMaps sind kontraproduktiv, wenn man nicht versteht, was sie bewirken (hier: nichts!).

[MadMax-FHEM]

Vermutlich könnte man das (alles) (besser) beim "Original Device" (verm. Mythz?) anpassen...
...wenn mann denn ein list davon hätte (wie schon öfter angefragt)...

Gruß, Joachim

[Matthias-56]

Hallo Joachim und Beta-User und danke für die Infos. Das geht schnell bei Euch!
Dieses "Rumprobieren" mag ich absolut nicht, auch nicht diese Fragerei nach dem Urschleim.
Das mache ich nur sehr ungern, erst nach sehr langem Suchen und Probieren.
Gerade bei Readings fehlt mir immer noch das Grundverständnis, obwohl ich schon dachte, ich hätte es.
Ich werde mich weiter rantasten.

Der Vorschlag Original Device - das Modul THZ stammt von Immi. Ich werde ihn mal fragen, ob es vielleicht schon etwas gibt.
Gesehen habe ich nichts, aber eigentlich ist mein Wunsch die Hzg. Temperaturen per Sprache abzufragen nicht so exotisch, dass das nicht schon jemand vor mir gelöst haben könnte - und dann vielleicht mit mehr Ahnung ...

Gruß
Matthias

[Beta-User]

Der Maintainer kann vielleicht helfen, aber das ist m.e. der falsche Ansatz: Sprachsteuerung ist was davon unabhängiges.

Aber wenn du kein list/Copy for Forum zeigen magst, kann dir eben keiner helfen, der "nur" generisch könnte ..

[MadMax-FHEM]

Der Vorschlag Original Device - das Modul THZ stammt von Immi. Ich werde ihn mal fragen, ob es vielleicht schon etwas gibt.

Device: das was du in fhem SELBST angelegt hast, also die "Nutzung" eines Moduls!

Modul: das was ein Entwickler zur Nutzung (in fhem) zur Verfügung stellt.


Gemeint ist hier: Anpassungen am Device (userReadings, homebridgeMapping, ...) aber eben am "Original-Device" (DEVICE! Nicht Modul!), weil warum die Daten/Readings "weiterkopieren" (dummy, readingsProxy, ...), wenn es die Daten (Readings) doch schon gibt (nur gassistant sie nicht "versteht")...

Gruß, Joachim