ebusd.mqtt2.template: Fragen, Anregungen

[mr_petz]

Start

Code Auswählen Erweitern


[07/11/2020, 18:25:12] [FHEM] MQTT2_ebusd_test is thermostat
[07/11/2020, 18:25:12] [FHEM] MQTT2_ebusd_test has
[07/11/2020, 18:25:12] [FHEM]   TargetTemperature [desired-temp]
[07/11/2020, 18:25:12] [FHEM]   CurrentTemperature [measured-temp]
[07/11/2020, 18:25:12] [FHEM]   CurrentHeatingCoolingState [undefined]
[07/11/2020, 18:25:12] [FHEM]   StatusActive [signal]
[07/11/2020, 18:25:12] [FHEM]   history [undefined]
  2020-11-07 18:25:12 caching: MQTT2_ebusd_test-desired-temp: 47.19
  2020-11-07 18:25:12 caching: MQTT2_ebusd_test-measured-temp: 7.25
[07/11/2020, 19:01:03] [FHEM]     caching: TargetTemperature: 54.25 (as string; from '54.25')
  2020-11-07 19:01:03 caching: MQTT2_ebusd_test-desired-temp: 54.25
[07/11/2020, 19:01:03] [FHEM]     caching: TargetTemperature: 28 (as number; from '54.25')

AppScreenshot:

[Beta-User]

  2 von 3, wenn ich das richtig deute. Das ist doch schon mal was ...

measured-temp müßte man ja eh' nur abfragen können, desired-temp dann setzen und auslesen? Also: Funktioniert da der "Kreis" und werden die richtigen (Hex-) Adressen angesprochen/abgefragt?

Was CurrentHeatingCoolingState und StatusActive angeht:
Gibt es dafür "default" ReadingNamen?

Und sind die Setz-Werte für CurrentHeatingCoolingState irgendwie normiert? Soll/kann man das "übersetzen"?...?

(Mit size habe ich keine Ahnung, was das für eine Bedeutung hat; ist einfach übernommen aus dem was da war (wie signal)).

Grundsätzlich: Ist denn die Vorgehensweise klarer jetzt, nachdem das mit den ersten beiden zu funktionieren scheint?

[TomLee]

Aus https://wiki.fhem.de/wiki/Homebridge_einrichten

Über eine history Characteristic lässt sich für bestimmte Service-Typen eine Eve-Kompatible history aktivieren:

Die Angabe ist nur relevant wenn man die EVE-App nutzt.

[mr_petz]

Was CurrentHeatingCoolingState und StatusActive angeht:
Gibt es dafür "default" ReadingNamen?

Und sind die Setz-Werte für CurrentHeatingCoolingState irgendwie normiert? Soll/kann man das "übersetzen"?...?

Hatte ich schon was dazu geschrieben.
    bei den Raumreglern vr400,450 ist der Betriebsmodus: Hc1OPMode
    bei dem Raumregler 350 ist der Betriebsmodus: OperatingMode
    bei meiner VR630 Heizungsregelung ist der Betriebsmodus: Status02_hwcmode
    oder Mode_hcmode1(nur bei mir)
die values sollten gleich sein denke ich:
Bei mir kommts klein: off,on,auto,eco,low

Grundsätzlich: Ist denn die Vorgehensweise klarer jetzt, nachdem das mit den ersten beiden zu funktionieren scheint?
Ich kann halt nicht die Temperatur einstellen, weil der

Raumtemperatur geht nicht zu setzen, weil der Readingname durch mein Benutzerdef. Sachen jetzt nicht stimmt.
Es müsste eigendlich 26 stehen. Steht aber 28.

Edit:
geht nur so zu setzen:
statt

Code Auswählen Erweitern

desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
so

Code Auswählen Erweitern

desired-temp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1

[Beta-User]

@TomLee: Danke für den Einwurf, da war doch noch was...
https://wiki.fhem.de/wiki/Alexa_und_Mappings

Es scheint demnach für "thermostate" noch kein "generelles mapping" für den "allgemeinen Betriebsmodus" zu geben. (@mr_petz: Das Umbenennen im MQTT2_DEVICE ist erst Stufe 2, das dockt dann "nur" daran an, was insbesondere das alexa-mapping gerne hätte - wie bei desired-temp)

MAn. sollte man dazu eine kurze Anfrage im Sprachsteuerungsbereich starten, insbesondere Richtung justme1968. Kann das einer von übernehmen? Ist nicht eben meine Kernkompetenz...

(Den Rest schaue ich mir später an, für heute ist erst mal Schluß).

[mr_petz]

MAn. sollte man dazu eine kurze Anfrage im Sprachsteuerungsbereich starten, insbesondere Richtung justme1968. Kann das einer von übernehmen? Ist nicht eben meine Kernkompetenz...

Hatte ich schonmal erfolglos gemacht wegen den Betriebsmodis:
https://forum.fhem.de/index.php/topic,110531.0.html

[TomLee]

@TomLee: Danke für den Einwurf, da war doch noch was...
https://wiki.fhem.de/wiki/Alexa_und_Mappings

Komm hier nur halb mit, homebridgeMapping und ich werden wsl. nie Freunde 
Meine Heizung ist witterungsgeführt und ich hab keine Raumregelung, ich hab bisher keinen Bedarf die Heizung per Sprache zu steuern.
OK, die Warmwassertemperatur abfragen hab ich mir eingerichtet nutz ich aber wirklich selten / gar nicht.
Und für die Aussentemperatur abzufragen hab ich draussen einen DS18B20 (1-Wire).
Darum lese ich hier nur interessiert mit 

Falls die Frage auf alexaMapping zielt und du nicht weißt das einzuordnen, das ist nur für den Custom-Skill relevant (den nutzt mMn. fast keiner mehr).
Hier gehts aber ausschließlich um den Smart-Home-Skill und da mappt man mit homebridgeMapping.

[Beta-User]

Komm hier nur halb mit, homebridgeMapping und ich werden wsl. nie Freunde 

...was diese mappings angeht, stehe ich auch gefühlt völlig im Wald... Wenn man im Wiki nach homebridgeMapping stöbert, landet man auch wieder auf den alexa-Seiten, oder?

Na jedenfalls habe ich im Wiki bisher nichts vernünftiges gefunden, was für diesen Fall hier zu passen scheint.

Hatte ich schonmal erfolglos gemacht wegen den Betriebsmodis:
https://forum.fhem.de/index.php/topic,110531.0.html

Aus dem Link von mr_petz und dem, auf das justme1968 verwiesen hat (https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-property-schemas.html#thermostat-mode), meine ich, dass das Reading "thermostatMode" heißen sollte. Also bitte mal testweise in dem Vorschlag von hier

Umbenanntes Testdevice: [...]

heatingState durch thermostatMode ersetzen.

Bitte ggf. checken, ob das Device auch auf der Ebene der betreffenden Sprachsteuerung dann wieder neu initialisiert worden ist (will sagen: kann sein, dass man da die Erkennung neu starten muss oder den Dienst).

(Falls das nicht klappt, wäre ein weiterer Test mit "thermostat-mode" nett, aber ich würde tippen, dass "the winner" "thermostatMode" heißt).

[mr_petz]

Vorschlag von hierheatingState durch thermostatMode ersetzen.

gemacht

Bitte ggf. checken, ob das Device auch auf der Ebene der betreffenden Sprachsteuerung dann wieder neu initialisiert worden ist (will sagen: kann sein, dass man da die Erkennung neu starten muss oder den Dienst).

CurrentHeatingCoolingState [undefined]

(Falls das nicht klappt, wäre ein weiterer Test mit "thermostat-mode" nett, aber ich würde tippen, dass "the winner" "thermostatMode" heißt).

CurrentHeatingCoolingState [undefined]

[Beta-User]

Hmm, schade eigentlich...

Da das aber die "quais-offizielle" Benennung für diesen Datenpunkt zu sein scheint, würde ich das Reading jetzt trotzdem so benennen wollen, vielleicht kann man dann ja die weiteren Mappings weglassen? Ansonsten machen wir die halt auch noch dazu, die Devise war ja "nur", wegzulassen, was nicht erforderlich ist.

Wäre nett, wenn du justme1968 in dem Thread noch den Hinweis (mit Link hierher) gibts, dass wir das in diese Richtung vorhaben, erfahrungsgemäß wird er sich dann melden, wenn wir hier in die falsche Richtung laufen... Das gleiche Problem stellt sich btw. auch im ems-esp-Thread, von daher wäre mir an einer einheitlichen Lösung gelegen.

[Beta-User]

Bezugnehmend auf die Antwort von justme1968 aus dem anderen Thread: bitte nochmal testen mit "mode"...

[mr_petz]

bitte nochmal testen mit "mode"...

leider auch

Code Auswählen Erweitern

[10/11/2020, 20:16:18] [FHEM]   CurrentHeatingCoolingState [undefined]

[Beta-User]

Na ja, wie dem auch sei, dann nennen wir das Kind jetzt trotzdem "mode".

Jetzt wäre also die Frage, mit welcher "Baugruppe" wir denn beginnen wollen...?

[Beta-User]

@Reinhart:
[...]
Vielleicht noch eine Sache, [...]: Das Verwalten von Temperaturlisten geht TYPE-übergreifend und sehr komfortabel über weekprofile, sowohl, was die Einrichtung angeht wie auch das Anwenden von Änderungen (z.B. Wechsel von "normalem Tagesprogramm" auf "Ferien" oder "Urlaub", "Kurzarbeit",...; eventuell wäre es den Versuch wert, auch dafür eine Schnittstelle zu basteln (der ganze Mechanismus mit den x dummy-Devices usw. kommt mir reichlich "von Hand" vor). Kommt aber darauf an, was so eine Therme überhaupt wie oft verarbeiten kann (EEPROM-wearout).
Da [...] sollte es "möglich" sein...

Zwischenzeitlich habe ich noch etwas mit Code gespielt, um zwischen CUL_HM-tempList- Formaten und weekprofile Daten hin- und herzuschaufeln. Falls da also Interesse besteht, sowas wie eine Schnittstelle zwischen den Welten zu basteln: feel free. Sollten wir aber ggf. in einen separaten Thread auslagern.

Benötigen würde ich Infos, wie die Readings nach den get-Anfragen konkret aussehen, um sie ggf. nach weekprofile transferieren zu können. Das Sendeformat ist ja in der template-file eigentlich gut zu erkennen, aber auch da wäre "etwas Theorie" ggf. hilfreich...

Vorab wäre dann natürlich noch gut zu wissen, ob die Regelung es eigentlich verträgt, wenn man da immer mal wieder was umstellt. Es dürfte User geben, die ggf. Probleme haben, passende Event-Handler zu bauen und dann unbeabsichtigt sehr häufig umschalten; sowas sollte möglichst nicht dazu führen, dass die Heizung dann vorzeitig aussteigt...

(EDIT: link zu dem CUL_HM-Code ergänzt)

[mr_petz]

Jetzt wäre also die Frage, mit welcher "Baugruppe" wir denn beginnen wollen...?

für die 630/620 können wir mit der hc anfangen.
Und für mich zum Verständnis, wie im Detail willst du beginnen?