Autor Thema: ebusd.mqtt2.template: Fragen, Anregungen  (Gelesen 31989 mal)

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 198
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #210 am: 07 November 2020, 18:50:40 »
Start
[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:
« Letzte Änderung: 07 November 2020, 19:03:41 von mr_petz »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #211 am: 07 November 2020, 19:09:40 »
 :) 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?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 2851
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #212 am: 07 November 2020, 19:28:58 »
Aus https://wiki.fhem.de/wiki/Homebridge_einrichten

Zitat
Ü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.



Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 198
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #213 am: 07 November 2020, 20:29:27 »
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
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1so
desired-temp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
« Letzte Änderung: 07 November 2020, 20:39:51 von mr_petz »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #214 am: 07 November 2020, 20:36:44 »
@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ß).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 198
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #215 am: 07 November 2020, 20:47:20 »
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
« Letzte Änderung: 07 November 2020, 22:24:27 von mr_petz »

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 2851
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #216 am: 07 November 2020, 21:34:19 »
Zitat
@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  ;D
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #217 am: 09 November 2020, 10:19:19 »
Komm hier nur halb mit, homebridgeMapping und ich werden wsl. nie Freunde  ;D
...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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 198
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #218 am: 09 November 2020, 17:28:57 »
Vorschlag von hierheatingState durch thermostatMode ersetzen.
gemacht
Zitat
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]

Zitat
(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]

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #219 am: 09 November 2020, 17:44:36 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #220 am: 10 November 2020, 16:33:29 »
Bezugnehmend auf die Antwort von justme1968 aus dem anderen Thread: bitte nochmal testen mit "mode"...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 198
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #221 am: 10 November 2020, 20:20:59 »
bitte nochmal testen mit "mode"...
leider auch
[10/11/2020, 20:16:18] [FHEM]   CurrentHeatingCoolingState [undefined]

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #222 am: 12 November 2020, 12:20:44 »
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...?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13231
  • "Developer"?!? Meistens doch eher "User"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #223 am: 13 November 2020, 11:51:01 »
@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)
« Letzte Änderung: 13 November 2020, 11:58:49 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 198
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #224 am: 13 November 2020, 18:22:19 »
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?

 

decade-submarginal