ebusd.mqtt2.template: Fragen, Anregungen

Beta-User · 21 Januar 2020, 11:15:32

Hallo zusammen,

nachdem sowieso ein paar Änderungen für weitere Tests hier und anderswo sinnvoll waren, habe ich vorhin einiges ins svn geschubst, die in leicht veränderter Form das hier umsetzen sollte:

Zitat von: Beta-User am 17 Januar 2020, 13:46:57
Mit dieser Option würde ich jetzt Folgendes vorschlagen:
- Das separate attrTemplate-File erhalten, Download aus dem svn nur bei Bedarf (=durch Anwenden des in der allg. File enthaltenen Basis-templates).
- die myUtils käme dann erst, wenn man auch eines der readingsGroup-Devices via attrTemplate generiert?
- für die attrTemplate-Sachen lege ich ein neues Verzeichnis in contrib (AttrTemplate) an und trage mich mal als Maintainer für das Verzeichnis ein. Wer einzelne Dateien darau "haben will", kann das gerne tun.
- Den Code aus dem Wiki (https://wiki.fhem.de/wiki/EBUS-MQTT2#myUtils-Code) übernehme ich in eine eigene myUtils-Datei, Namensschema tendenziell sowas wie "99_attrT_ebus_Utils.pm", der Funktionsname muß dann aber etwas "spezieller und generischer" werden, damit besser erkennbar ist, wo eine Funktion herkommt. Ich tendiere zu sowas wie "attrT_ebus_<Funktion>()", konkret also "attrT_ebus_createBarView".

(Zur Funktion selbst würde ich gerne noch zwei optionale Parameter sehen, [...]

Das "Problem" dabei ist Folgendes: Es ist bisher noch nicht getestet...

Notfalls hole ich das selbst nach, aber es wäre super, wenn sich da jemand für den ebus-Teil freiwillig melden würde und optimalerweise auch gleich den Wiki-Teil entsprechend aktualisieren, wenn es funktioniert wie gewünscht...?

Danke vorab!

Beta-User · 11 Februar 2020, 11:58:29

Zitat von: Beta-User am 21 Januar 2020, 11:15:32
Notfalls hole ich das selbst nach, aber es wäre super, wenn sich da jemand für den ebus-Teil freiwillig melden würde und optimalerweise auch gleich den Wiki-Teil entsprechend aktualisieren, wenn es funktioniert wie gewünscht...?

Danke vorab!

Nachdem das an anderer Stelle (valetudo) ganz ordentlich funktioniert hat, und hier bisher keiner gemeldet hat, dass es nicht funktionieren würde: Im Wiki habe ich jetzt an drei Stellen (in den Praxisbeispielen und 2x in dem ebus-Artikel) den Hinweis aufgenommen, dass man jetzt nicht mehr den Code von hier holen muß, sondern dass das beides aus dem svn nachgeladen wird.

Es wäre nett, wenn jemand anderes sich den ebus-Artikel nochmal vonehmen könnte, um zukünftige Verwirrung zu vermeiden und die user darauf hinzuweisen, dass sie sich hierher wenden können, wenn Vorschläge dazu sind...?

Beta-User · 18 Juni 2020, 12:40:25

Hallo zusammen,

nachdem Rudi vor einiger Zeit "periodicCmd" eingeführt hat, kurz die Frage, ob das at, auf das hier https://forum.fhem.de/index.php/topic,84636.msg1065426.html#msg1065426 verwiesen wird so weiter Bestand haben soll:

Code Auswählen

periodicCmd <cmd1>:<period1> <cmd2>:<period2>... 
 periodically execute the get or set command. The command will not take any arguments, create a new command without argument, if necessary. period is measured in minutes, and it must be an integer.

Damit könnte man die Timer direkt in die templates mit einbauen. Weiß aber nicht, inwieweit wir damit ein Henne-Ei-Problem bekommen, denn afai remember mußte man erst eine Anfrage starten, um entsprechende Werte zurückzubekommen (und damit die Geräte von der bridgeRegexp anlegen zu lassen)?

Kann man sicher mit einem einmaligen Commando auch erreichen, vielleicht hat ja jemand eine zündende Idee dazu?

Grüße,

Beta-User

TomLee · 18 Juni 2020, 14:32:11

Lieg ich so daneben wenn ichs sage hier hat mal jemand eine zündende Idee gehabt ?

Hab ich gestern nämlich erst ausprobiert, bei mir klappt das irgendwie nicht mit dem getter, hab mich aber auch nur kurz mit beschäftigt und wieder sein lassen

Beta-User · 18 Juni 2020, 14:40:48

Hmm, hatte nur kurz ab hier reingesehen: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/mqtt2.ebus.template#L42

Da gibt's ne getList, und Klagen kamen dazu bisher auch nicht. (Ansonsten habe ich mich wirklich schon sehr lange nicht mehr mit diesen templates beschäftigt...).

Eventuell sollte man sich auch noch das Thema ignoreRegexp am IO in dem Zusammenhang mal ansehen, das ist auch was neues... (die get-Anweisungen brauchen wir eigentlich nicht in der readingList am Device, oder?)

TomLee · 28 Juni 2020, 07:15:54

Habs mir eben nochmal angeschaut, man muss die getList schon richtig definieren

, dann klappt das mit periodicCmd problemlos.

Code Auswählen

attr MQTT2_ebusd_bai getList Hc1Heizkurveget:noArg Hc1Heizkurve ebusd/700/Hc1HeatCurve/get
attr MQTT2_ebusd_bai jsonMap Hc1HeatCurve_0_value:Hc1Heizkurve
attr MQTT2_ebusd_bai periodicCmd Hc1Heizkurveget:10

Beta-User · 28 Juni 2020, 08:59:13

Habe eben versucht, das irgendwie einem konkreten template zuzuordnen und bin etwas ratlos... Es müßte eigentlich zu eBus_4xx_devStateIcon_HeatCurve_HwcTemp hin, nicht zum bai-Gerät?
Aber wenn ich mir das so anschaue, ist das irgendwie gefühlt "noch nicht fertig", oder täuscht mich das?

Was die Namensvergabe des Readings (bzw. allg. der setter und (etwas weniger) der getter, sofern die wirklich unterscheidlich sein müssen (denke eigentlich nicht?)) angeht, bin ich auch nicht wirklich zufrieden. Eigentlich müßte man das mMn. ähnlich angehen wie im AV-Bereich und sowas wie standardisierte (englische) Readingnamen einführen.
Würe hier evtl. zu heatCurve führen, hat man mehrere, müßte man eben für jede je ein eigenes Device generieren und den Rest mittels "jsonMap xy:0" ausblenden.

Wie dem auch sei, im Moment weiß ich noch nicht so recht, wie ich mit der Info weitermachen kann. Hier wäre es wirklich gut, einen kompletten Vorschlag zu haben...

TomLee · 28 Juni 2020, 09:52:13

Da gibts nix zuzuordnen, hab die Templates nie wirklich genutzt/ausprobiert, ich hab mir ein Device (das heißt halt jetzt MQTT2_ebusd_bai) erstellt, welches mir alle nötigen Daten anzeigt, fertig.
Und das mit dem getList werd ich jetzt so in dem Device einbauen das ich mir das AT noch spare.
Mehr brauch und will ich nicht.

TomLee · 04 August 2020, 20:49:23

ZitatHi,

ausnahmsweise mal PM.

Beschäftigst dich doch auch mit dem Ebusd.

Wegen dem getter:

Der ist dort sehr nützlich und man spart sich das AT in Kombination mit periodicCmd:

@Otto123

die Ausnahme gefällt mir im Nachhinein nicht, hier oder sonst wo, wenn überhaupt, bitte weiter mit Rückmeldungen.

Gruß

Thomas

mr_petz · 04 November 2020, 18:01:32

Hi @Beta-User,
Gerne antworte ich dir zum Beitrag/Anfrage von dir hier:
https://forum.fhem.de/index.php/topic,115185.msg1098310.html#msg1098310

Ich hatte da schonmal bei justme1968 wegen Sprachsteuerung was angefragt.
siehe hier:
https://forum.fhem.de/index.php/topic,110531.0.html
Hier ging es mir um die Anzeige in der Alexa-App der einzelnen Modi´s (heat, auto etc...)
Ich habe halt in der server.js von HEAT auf current umgeschrieben, weil vorher immer HEAT in der App stand und erst nach Änderung alle Modi´s angezeigt wurden.

Hier habe ich das mapping aufgezeigt:
https://forum.fhem.de/index.php/topic,110531.msg1080791.html#msg1080791
alexa-fhem version 0.5.27

ZitatDas geht bei mir per Sprachbefehl:
"Alexa wie ist die Themperatur von der Heizung" (bei mir Aussentemperatur)
"Alexa wie ist der Status von der Heizung" (bei mir Aussentemperatur)
"Alexa wie ist die Heizung eingestellt" (Antwort= Modus+TargetTemperature)
"Alexa auf was ist die Heizung gestellt" (Antwort= Modus+TargetTemperature)
"Alexa stelle Heizung auf Auto"
"Alexa stelle Heizung auf Heizen"
"Alexa stelle Heizung auf Eco"
"Alexa stelle Heizung auf Kühlen" (Kühlen = Aus, habe ich auch so im mapping. Aus wird nicht unterstützt sagt sie sonst. k.a. warum).

TargetTemperature ist bei mir die Vorlauftemp. (nur als Anzeige).
Edit: was mir gerade auffällt, für TargetTemperature habe ich keine setlist, aber die Vorlauftemp. wird trotzdem angezeigt..
setList von Heizmodus:

Code Auswählen

Heizmodus:uzsuDropDown,on,off,auto,eco,low ebusd/hc/SetMode/set $EVTPART1
und userReading vom heatingState:

Code Auswählen

heatingState { if (ReadingsVal($name,"Mode_hcmode1_value","-") eq "off"){"OFF"} 
elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "on"){"HEAT"} 
elsif (ReadingsVal($name,"Mode_hcmode1_value","auto") eq "auto"){"AUTO"} 
elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "low"){"COOL"} 
else {"ECO"}}

Ich hatte auch schon zum Testen der TargetTemperature in der setList das:

Code Auswählen

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

hier noch der link zu meiner hcmode:
https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908

Alle anderen Einstellungen mache ich am Tablet.
Die Heizung ist Aussentemperaturgeführt, also nicht mit Raumthermostat.
Wenn du sonst noch Infos brauchst oder ich was testen soll, dann sag Bescheid.

mfg mr_petz

Beta-User · 04 November 2020, 22:24:56

Hmm, muß mir das mal intensiver ansehen.

Grundsätzlich würde ich lieber jsonMap nutzen, um "standardkonforme" Readings zu bekommen (und die dann auch in der setList zu verwenden), als herzugehen und ziemlich spezielle Mappings mit den automatischen Readingnamen vorzunehmen - eigentlich sollte es nämlich genügen, sowohl den Brenner wie einen (virtuellen?) Raumthermostaten als "thermostat" in genericDeviceType zu kennzeichen. Ggf. "müssen" wir auch sonst noch drumrum das eine oder andere anfassen, von daher würde ich das Angebot gerne annehmen, dass du da etwas rumtestest.

Von daher wäre meine Vorgehensweise mal die, dass ich einen Vorschlag für ein neues "Raumthermostat" mache. Dann könntest du dein bestehendes einfach kopieren und mit dem als Testgerät loslegen, dann wird evtl. manches klarer.

Zur Vorbereitung könntest du mal die Threads zu ems-esp und dem Fröhlich-Holzscheit-Ding suchen und durchsehen, falls du magst - da sind viele Aspekte in die Richtung schon verarbeitet...

Grundsätzlich würde ich dann künftig immer ein RAW-list vom ganzen Device benötigen, aber bitte erst, wenn ich den o.g. Vorschlag vorgelegt habe...

mr_petz · 04 November 2020, 23:16:33

Zitat von: Beta-User am 04 November 2020, 22:24:56
Hmm, muß mir das mal intensiver ansehen.

Grundsätzlich würde ich lieber jsonMap nutzen, um "standardkonforme" Readings zu bekommen (und die dann auch in der setList zu verwenden), als herzugehen und ziemlich spezielle Mappings mit den automatischen Readingnamen vorzunehmen

Ich glaube das geht auch ohne mein userReading, da mir ja das Reading "Mode_hcmode1_value" alle Modis anzeigt (on,off,auto etc..). muss ich nochmal testen und das mapping anpassen.

Zitat von: Beta-User am 04 November 2020, 22:24:56
Zur Vorbereitung könntest du mal die Threads zu ems-esp und dem Fröhlich-Holzscheit-Ding suchen und durchsehen, falls du magst - da sind viele Aspekte in die Richtung schon verarbeitet...

ok, schaue ich mir an.

Beta-User · 05 November 2020, 09:38:21

Hmm, jetzt bin ich zugegebenermaßen etwas ratlos...

Wie sieht denn ein "simples Raumthermostat" aus? (Oder von mir aus auch: Ein Gerät, bei dem man die Warmwassertemperatur einstellen kann?) (Als RAW, bitte)

Aus dem Link zu https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908 werde ich nur insoweit schlau, als da auch schon "User-spezifische" settings bereits auf der Ebus-Seite vorhanden sind, oder deute ich das falsch?
Wenn ja: wäre es ein Problem, das eher wieder auf "übliche Standards" zurückzudrehen (so es so etwas gibt...(?))?

Ziel sollte sein, dass ein "Neu-User" möglichst wenig rumfrickeln muss, sondern einfach auf (fast) allen Ebenen mit den "defaults" arbeitet und dann ein funktionierendes Ergebnis hat. Ggf. muss man dann auf der FHEM-Seite noch eventMap setzen, damit es "deutsch" (oder dänisch, französisch...) aussieht, aber auf der funktionalen Ebene würde ich versuchen wollen, eher die "technischen" Begrifflichkeiten zu verwenden...

mr_petz · 05 November 2020, 12:03:01

Zitat von: Beta-User am 05 November 2020, 09:38:21
Aus dem Link zu https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908 werde ich nur insoweit schlau, als da auch schon "User-spezifische" settings bereits auf der Ebus-Seite vorhanden sind, oder deute ich das falsch?
Wenn ja: wäre es ein Problem, das eher wieder auf "übliche Standards" zurückzudrehen (so es so etwas gibt...(?))?

Ja meine ist "User-spezifisch" und es ist möglich eine Standard zu nehmen.
Aber von der Standard hcmode.inc bekomme ich nur das Datum und die Außentemperatur. da müssten wir mit john30 zusammen arbeiten das er im git die Dateien anpasst.
Originaldatei sud github von john30:
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/hcmode.inc
Ich habe die VR630 und kann halt nur mit meiner hcmode.inc wie in meinem Link die Werte die wir brauchen lesen/setzen.

Zitat von: Beta-User am 05 November 2020, 09:38:21
Ziel sollte sein, dass ein "Neu-User" möglichst wenig rumfrickeln muss, sondern einfach auf (fast) allen Ebenen mit den "defaults" arbeitet und dann ein funktionierendes Ergebnis hat. Ggf. muss man dann auf der FHEM-Seite noch eventMap setzen, damit es "deutsch" (oder dänisch, französisch...) aussieht, aber auf der funktionalen Ebene würde ich versuchen wollen, eher die "technischen" Begrifflichkeiten zu verwenden...

Ja, aber da müssten wir noch andere Vaillant-Nutzer mit ins Boot holen aufgrund der verschiedenen csv´s und inc´s... siehe hier (DE):
https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant
und hier (EN):
https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/en/vaillant
Da müssten wir von jeden Vaillantgerat (egal ob Raum- oder Witterungsgeführt) die set/get der Betriebsmodi, Raumtemperatur oder Außentemperatur und der SetRaumtemperatur (desired-temp) raussuchen bzw wissen.

Beta-User · 05 November 2020, 12:17:26

Grübel, ....

Also: wir müssen irgendwo erst mal "einen Nagel einschlagen" und bestimmte Dinge als "given" akzeptieren. Wenn sich "deine" cvs an die "üblichen" (deutschen) Gepflogenheiten hält, ist das m.E. auch ok.
(Ich kenne diese ganzen Mechanismen nicht aus eigener Anschauung und muß daher viel raten, z.B. auch was die Funktionsweise der cvs angeht. Aber allgemein gesagt: je besser der input an john30 ist (insbesondere: konsistent zu allem anderen, was schon da ist), desto eher kann er die Dinge dann auch für alle verfügbar machen, btw..).

Ggf. dann das "de"-template anzupassen und eines für "en" draus zu machen, ist nicht das große Problem, wenn dieser Dualismus schon in den cvs angelegt ist...