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

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 1791
ebusd.mqtt2.template: Fragen, Anregungen
« am: 28 Februar 2019, 17:04:14 »
Hallo,

mit Reinharts Beispiel-Templates hatte ich vor 2 Wochen gespielt und konnte auch die WW-Temperatur setzen.

Jetzt versuche ich das in meinem u.a.  Device umzusetzen, das temp1_value wie in Reinharts Beispiel mein ich ist bei mir das
SetMode_hwctempdesired_value, das setzen klappt aber nicht.

Kann mir da wer weiterhelfen ?

Zitat
defmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
attr MQTT2_Test_Ebusd devStateStyle style="text-align:right"
attr MQTT2_Test_Ebusd event-on-change-reading .*
attr MQTT2_Test_Ebusd icon icoTempHeizung
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:1_Vorlauf Status01_0_name:0 Status01_1_value:1_Ruecklauf Status01_1_name:0 Status01_2_value:1_OutdoorstempSensor Status01_2_name:0 Status01_3_value:Fragez Status01_3_name:0 Status01_4_value:1_HwctempSensor Status01_4_name:0 Status01_5_value:1_Pumpe Status01_5_name:0 WaterPressure_press_value:WaterPressure WaterPressure_sensor_value:0 FlowTempDesired_temp_value:FlowTempDesired CirPump_onoff_value:CirPump Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:HeatCurve z1DayTemp_tempv_value:z1DayTemp
attr MQTT2_Test_Ebusd model E_04a_eBus_Test_Status01+SetMode+WaterPressure+CirPump+Hc1HeatCurve+z1DayTemp
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }
attr MQTT2_Test_Ebusd setList SetMode_hwctempdesired_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/bai/HwcTempDesired/set $EVTPART1
attr MQTT2_Test_Ebusd stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>WW-Temperatur: %.1f <br>Aussentemperatur.: %.1f <br>Pumpe: %s <br>Fragez: %.1f <br>Druck: %.1f <br>WW-Set: %s <br>Zirk.pumpe: %s", ReadingsVal($name,"1_Vorlauf",0), ReadingsVal($name,"1_Ruecklauf",0), ReadingsVal($name,"1_HwctempSensor",0),ReadingsVal($name,"1_OutdoorstempSensor",0), ReadingsVal($name,"1_Pumpe",0), ReadingsVal($name,"Fragez",0), ReadingsVal($name,"WaterPressure",0), ReadingsVal($name,"FlowTempDesired",0), ReadingsVal($name,"CirPump",0))}
attr MQTT2_Test_Ebusd webCmd SetMode_hwctempdesired_value
attr MQTT2_Test_Ebusd webCmdLabel WW-Set


setstate MQTT2_Test_Ebusd Vorlauf: 66.0 <br>Ruecklauf: 0.0 <br>WW-Temperatur: 51.0 <br>Aussentemperatur.: 20.4 <br>Pumpe: off <br>Fragez: 0.0 <br>Druck: 2.4 <br>WW-Set: 0 <br>Zirk.pumpe: off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_HwctempSensor 51.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_OutdoorstempSensor 20.438
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_Pumpe off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_Vorlauf 66.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:42 CirPump off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 Fragez 0.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 HeatCurve 2.05

setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehc_value 1
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehwcload_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehwctapping_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_flowtempdesired_value 0.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_hcmode_value auto
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_hwctempdesired_value 55.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_releaseBackup_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_releaseCooling_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_remoteControlHcPump_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 WaterPressure 2.372
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 z1DayTemp 22

Gruß

Thomas
« Letzte Änderung: 04 März 2019, 12:10:08 von TomLee »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:ebusd.template: Fragen, Anregungen
« Antwort #1 am: 28 Februar 2019, 17:35:00 »
Hi Thomas,

leider habe ich nicht die große Ahnung vom ebusd und von den templates dafür, würde aber gerne auch ein oder zwei Beispiele aus eurem template-file in die allgemeinen Templates übernehmen; der ebusd scheint im Moment der einzige Fall zu sein, bei dem das JSONMAP seine volle Wirkung zeigen kann :) .

Vielleicht vorab zwei Dinge:
- ich verstehe nicht ganz, für was die bridgeRegexp in dem ebus-Device sinnvoll ist. M.E. macht eine solche zwar großen Sinn, wenn man einen externen Broker nutzt, aber dann als separates Device (ein template dafür habe ich vor nicht allzu langer Zeit aufgenommen und die Praxisbeispiele entsprechend ergänzt. Das ist m.E. aber gar nicht erforderlich, wenn man den MQTT2_SERVER nutzt und sollte daher nicht Teil eines Geräts oder templates für ebusd sein).
Vorschlag (bitte config vorher mal zur Sicherheit als Kopie wegspeichern): Ein beliebiges MQTT2_DEVICE kopieren, und auf das dann das allg. Bridge-template anwenden (für Nutzer des MQTT2_CLIENT). Und dann diesen Teil aus dem ebusd-Gerät entfernen.

- v.a. wenn einzelne Dinge nicht erwartungsgemäß funktionieren, macht es m.E. immer Sinn, die Optionen im IO-Device zu nutzen.
Konkret hieße das hier:
-- An deinem MQTT2_CLIENT-Gerät das rawEvents-Attribut setzen und dann mal den Verkehr in einem separaten EVENT-Monitor mit Begrenzung auf dieses IO beobachten.
-- Darüber kann man dann auch den set-Befehl mit einem direkten publish mal testen. Geht der raus wie gedacht, hat aber keine Auswirkung, liegt es entweder am Zielgerät, dem Übertragungsweg dahin oder der Syntax. Damit würde ich hier mal anfangen.

Dann hätte ich noch eine Bitte: der ebusd-Thread ist ziemlich unübersichtlich. Ist das template von Reinhart in seinem ersten Thread jetzt eigentlich die beste Basis, oder hast du da noch weitere Anpassungen gemacht, die du gut findest?
Zunächst wäre es hilfreich, wenn wir eine Art Basis-Template hätten, das für alle Arten von ebusd-Nutzern hilfreich sein könnte.

Hoffe, das hilft erst mal weiter und ist (halbwegs) versändlich geschrieben.

Gruß, 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, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Reinhart

  • Hero Member
  • *****
  • Beiträge: 2063
Antw:ebusd.template: Fragen, Anregungen
« Antwort #2 am: 28 Februar 2019, 21:56:05 »
Zunächst einmal danke das uns Beta-User seine Unterstützung zur Entwicklung von eBus Templates anbietet! Er hat auch schnell erkannt, das der eBus die ideale Spielwiese für diese von Rudi entwickelte Technologie ist.

Ich habe ja vor einigen Woche dieses Beispiel-Template in den eBus Thread gestellt und gehofft das Thema MQTT2 etwas zu forcieren weil ich glaube das MQTT generell hohes Potential hat. Was bei ESP8266 schon lange Standard ist kann auch eBusd schon lange, John hat dafür schon vorgesorgt. Mir ist schon klar, das gerade Neueinsteiger lieber alte Wiki Einträge benutzen als sich jetzt auch noch mit MQTT oder gar Mosquitto auseinander zu setzen. Wieder was installieren, ohjeh!
Aber eigentlich ist es das Gegenteil, hoher Komfort wie ihn sonst nur GAEBUS bietet ist damit möglich und das mit einem Protokoll das von vielen SmartHome Umgebungen gesprochen wir.
 
Aber ich glaube wir sollten bevor wir die Unterstützung von Beta-User benutzen wollen, zunächst das Ziel von eBusd Templates festlegen zu versuchen. Ich habe ja bei den ersten Beispielen bewusst nur jene Datenpunkte ausgewählt, wo ich glaube das diese Datenpunkte bei einer großen Anzahl von Geräten vorkommen.

Beispiel: wer nur ein Brennwertgerät hat wird auch keine Heizkurve setzen können. Wer eine reine Therme hat wird auch keinen Warmwasserkessel haben. Daher ergeben sich aus solchen Vorgaben schon die Art der einzeln benötigten Templates.

Ich finde wir sollten daher zuerst eine Art Bestandsaufnahme durchführen um überhaupt die Art und Menge der benötigten Templates einmal grob zu definieren. Bei den Templates geht es ja in erster Linie um die Ausgabe (printf) am Display und die kann sich aus verschiedenen Variablen zusammen setzen. Je mehr Variablen und mehr Automatismus enthalten ist, desto vielfältiger läßt sich so ein Template dann einsetzen.
Schön wäre ohnehin ein einziges Template das alles kann, doch wer will einen Wulst von Daten in einem Reading? Dann doch lieber eine Unterteilung die logisch Sinn macht und darüber sollten wir uns hier abstimmen zu versuchen.
Dazu ist natürlich die Mitarbeit von möglichst vielen Anwendern gefragt, jeder hat andere Wünsche oder Ideen.

Ich stelle daher einmal die generelle Frage, sollten wir die Templates nach dem Typ der Datenpunkte (Warmwasser, Heizkurve, Datum, Zeit etc.) oder eher nach der Art der Heizgeräte Hardware (zB: Calormatic, 430, 470, 350) unterteilen.

@TommLee

so richtig verstehe ich dein Problem nicht warum das nicht funktionieren sollte.

#ebus Hcurve+HwcTempDesired Messages.
name:E_03c_eBus_Hc1HeatCurve+HwcTempDesired
filter:TYPE=MQTT2_DEVICE
par:BASE_DEV;base topic set in config;{ AttrVal("DEVICE","readingList","") =~ m,ebusd/([^/]*)/, ? $1 : undef }
desc:Applies settings to ebus Heatingcurve and Hotwater
attr DEVICE icon message_tendency_steady
attr DEVICE webCmd curve_value:temp1_value
attr DEVICE webCmdLabel Hc1HeatCurve:HwcTempDesired
attr DEVICE setList\
    curve_value:0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/BASE_DEV/Hc1HeatCurve/set $EVTPART1\
    temp1_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/BASE_DEV/HwcTempDesired/set $EVTPART1
deletereading DEVICE .*
Ich habe ja im Template "E_03c_eBus_Hc1HeatCurve+HwcTempDesired" auch schon die HwcTempdesired verwendet und die funktioniert bei meiner HW und läßt sich setzen. Du hast sicher schon auf Command Ebene den Befehl getestet ob er auch bei deiner Umgebung funktioniert.
Zuerst mit "ebusctl" und dann mit Mosquitto in der Befehlszeile. Nur so kann ich schnell feststellen wo ein Fehler herkommt.

LG
Reinhart
FHEM auf Raspy4 mit Buster + SSD, mit FS20, Homematic, ESP8266, Sonoff, Electrodragon, eBus, RPi mit COC,NanoCUL, MapleCUL, HM-CFG-LAN Adapter, MQTT2, Alexa

Offline Reinhart

  • Hero Member
  • *****
  • Beiträge: 2063
Antw:ebusd.template: Fragen, Anregungen
« Antwort #3 am: 28 Februar 2019, 22:05:37 »
- ich verstehe nicht ganz, für was die bridgeRegexp in dem ebus-Device sinnvoll ist.

das kommt von solchen Json Strings, hier eine typische Statusmeldung wie sie als als Broadcast ankommt.

Client mosqsub/3355-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status01', ... (271 bytes))
ebusd/bai/Status01 {
     "0": {"name": "temp1", "value": 23.0},
     "1": {"name": "temp1", "value": 23.0},
     "2": {"name": "temp2", "value": 9.250},
     "3": {"name": "temp1", "value": 25.0},
     "4": {"name": "temp1", "value": 26.0},
     "5": {"name": "pumpstate", "value": "off"}}

Die Regexp zerlegt uns nun in "0_name" und "0_value". Und genau hier ist das Problem warum wir auch JSONMAP benötigen, weil Status02 macht gleiche Namen.
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }

Client mosqsub/3355-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status02', ... (221 bytes))
ebusd/bai/Status02 {
     "0": {"name": "hwcmode", "value": "auto"},
     "1": {"name": "temp0", "value": 60},
     "2": {"name": "temp1", "value": 70.0},
     "3": {"name": "temp0", "value": 70},
     "4": {"name": "temp1", "value": 54.0}}

LG
« Letzte Änderung: 28 Februar 2019, 22:11:27 von Reinhart »
FHEM auf Raspy4 mit Buster + SSD, mit FS20, Homematic, ESP8266, Sonoff, Electrodragon, eBus, RPi mit COC,NanoCUL, MapleCUL, HM-CFG-LAN Adapter, MQTT2, Alexa

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:ebusd.template: Fragen, Anregungen
« Antwort #4 am: 01 März 2019, 08:00:37 »
Guten Morgen zusammen,

@Reinhart vorab: Danke für die Vorschußlorbeeren...

Gleich auch ein paar Anmerkungen:
das kommt von solchen Json Strings, hier eine typische Statusmeldung wie sie als als Broadcast ankommt.
Da würde ich dir gerne eine Wette dagegen  anbieten, aber das wäre vermutlich unfair :D .

Bitte setzt mal den Vorschlag aus meinem ersten Post um und definiert ein allgemeines Bridge-Gerät. (Für später hinzugestoßene: Das gilt nur für user, die MQTT2_CLIENT als IO verwenden, für MQTT2_SERVER ist das nicht erforderlich. Allgemein: Wer neu in das Thema MQTT einsteigt, sollte direkt MQTT2_SERVER verwenden, das macht es m.E. einfacher, nicht nur in der Handhabung, auch in der Installation; man kann ggf. später umstellen, wenn man doch mosquitto oä. verwenden will).

Für das weitere brauchen wir vermutlich auch "Echtgeräte", allerdings sollte das die Funktionalität der bestehenden Definitionen möglichst nicht beeinträchtigen. Dazu würde ich vorschlagen, dass ihr dazu dann mind. zwei bzw. drei Geräte (defines) habt:
- (Nur MQTT2_CLIENT: eines, auf das A_00_MQTT2_CLIENT_general_bridge angewendet wurde - da würde mich eh' interessieren, ob das funktioniert wie erwartet)
- ein "unangetastetes" Normalgerät für den regulären Betrieb, in das ggf. dann Verbesserungen manuell eingepflegt werden;
- eines zum "Spielen" mit den templates. Da kann es sein, dass wir noch ein paar mehr brauchen...
Daraus ergeben sich leider ein paar Nebenwirkungen, die man im Auge haben sollte: Vorhandene Readings werden zwar in allen MQTT2_DEVICE-Geräten aktualisiert, wenn ein publish eingeht, autocreate wirkt aber ggf. nur auf eines ein - wenn jemand irgendwas bei einem bisher unbekanntem Topic in einer readingList "fehlt", sollte er also immer in allen Geräten nachsehen, wo es ggf. angelegt worden ist. Am "Normalgerät" sollte daher autocreate abgeschaltet werden.

Generell finde ich den Ansatz gut, ggf. erst mal einige wenige Grundtypen zu definieren und da in das template jeweils nur das reinzuschreiben, was auch mit einiger Sicherheit "da" sein wird.

Was mir zum Ganzen generell als Neuerung bei den attrTemplates im Kopf rumschwirrt, wäre ggf. die attrTemplate-Methode zu nutzen, um eine vorhandene readingList, setList oder JSONMAP zu _erweitern_. Das hat auch einen Nachteil: Es könnte zu Doppeleinträgen kommen. Da brauchen wir evtl. eine neue allgemeine Routine oder eine myUtils.pm, um da wieder für Ordnung zu sorgen. Von daher wäre es ggf. auch (später?) sinnvoll, das in den MQTT-Bereich zu verschieben, damit Rudi sich dazu eine Meinung bilden kann.

Weiterer Gedanke: Es wäre auch möglich, statt eines "Großdevices", das alle Readings enthält, auch Teile abzuspalten, und  Funktionsgruppen separat darzustellen. Als logische Klammer könnten wir das Reading associatedWith nutzen, und in der Darstellung in FHEMWEB das Gruppen-Attribut, ggf. mit einer Sortierpriorität innerhalb der Gruppe. Konkret könnte das so aussehen, dass man ein template auf das "Stammdevice" anwendet, und das dann ein abgeleitetes Device mit den passenden Readings für eine Funktionsgruppe anlegt, das ganze im selben Raum wie das "Stammdevice", mit dem associatedWith-Reading zum Stammdevice und derselben Gruppenzugehörigkeit.

Dann hätte ich noch die Frage, ob es weitere "setter" geben sollte? Beispiel: ich habe  eine Junkers (die leider nicht "ebus" spricht). Da nervt mich z.B. sehr, dass die dort verbaute Uhr so ungenau ist und die Zeitumstellung noch nicht kennt...
Das allererste, was ich der beibringen würde, wäre jeden Monat bzw. zu den Umstellungsdaten die aktuelle Zeit ;D . Ist doch bestimmt beim ebus möglich...

Zur JSONMAP: Wäre es evtl. sinnvoll, sich an die Terminologie zu halten, die der/die Hersteller auch in ihren Handbüchern verwenden? Dann sprecht ihr dieselbe Sprache wie eure Servicetechniker und Heizungsbauer ;) .

Was die Bereitstellung der templates und den Verbreitungsweg angeht, muß ich mir mal die Funktionalität des filter-Parameters ansehen. Evtl. wäre es möglich, die ebus-Templates nur mit anzuzeigen, wenn das Gerät, auf das der attrTemplate-?-Befehl angewendet wird, der devspec "model=E_03.*_eBus_.*" entspricht... Dann könnte man die file ohne weiteres größer machen bzw. eine ebus-spezifische template-file via svn ausliefern, ohne dass das den großen Rest irgendwie stört. Nur einmal ein ebus-Basistemplate drüber, schon erhält man Zugriff auf die anderen :) . (muß ich mir mal für tasmota... auch ansehen, das würde die Übersichtlichkeit insgesamt vielleicht erhöhen).

Apropos testen:
Um selbst irgendwas auszutesten, würde ich bei Gelegenheit mal ein paar RAW-Definitionen von ebus-Geräten benötigen, sonst habe ich nichts, wogegen ich template-Versuche laufen lassen kann. (am besten eine file, die ich direkt irgendwo wegspeichern kann).

Bitte fragt nach, wenn was nicht verständlich sein sollte, das waren jetzt sehr viele Dinge auf einmal, die auch bei mir noch nicht ausgereift sind.

Einen netten Tag wünscht euch

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, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Reinhart

  • Hero Member
  • *****
  • Beiträge: 2063
Antw:ebusd.template: Fragen, Anregungen
« Antwort #5 am: 01 März 2019, 19:54:01 »
Apropos testen:
Um selbst irgendwas auszutesten, würde ich bei Gelegenheit mal ein paar RAW-Definitionen von ebus-Geräten benötigen, sonst habe ich nichts, wogegen ich template-Versuche laufen lassen kann. (am besten eine file, die ich direkt irgendwo wegspeichern kann).

... das war jetzt viel, kann ich auf einmal gar nicht beantworten.
Wegen der Testumgebung hast PN von mir bekommen. Da kannst du alles testen was das Herz begehrt.

Beim Aufbau der Testumgebung habe ich viel mit dem MQTT2_Server getestet. Das wäre ja eine total einfach zu konfigurierende Sache. Er macht ja ohne Regexp schon sehr viel, aber halt leider mit dem Problem des überschreiben bei Namensgleichheit wenn kein Jsonmap gesetzt wird. Was ich da stark vermisse ist die Möglichkeit Templates anzuwenden oder muss man da dann zwingend auch die Bridge installieren?

Der Mosquitto ist zwar besser zum debuggen, aber auch das Log beim MQTT2_Server ist sehr aussagekräftig. So wie ich bis jetzt sehe, wäre das schon der richtige Weg und gleich von Start weg auf Mosquitto verzichten.

LG
« Letzte Änderung: 01 März 2019, 19:55:47 von Reinhart »
FHEM auf Raspy4 mit Buster + SSD, mit FS20, Homematic, ESP8266, Sonoff, Electrodragon, eBus, RPi mit COC,NanoCUL, MapleCUL, HM-CFG-LAN Adapter, MQTT2, Alexa

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:ebusd.template: Fragen, Anregungen
« Antwort #6 am: 02 März 2019, 08:45:47 »
Moin zusammen,

@TomLee:
Hattest du mal Gelegenheit, den direkten publish-Versuch zu testen? M.E. brauchst du damit nicht zu warten, bis template-mäßig was feststeht...

@Reinhart:
Danke für die Idee mit der Testumgebung, vermutlich kann ich mich irgendwann im Lauf des Tages da mal aufschalten.

Vorab hatte mich das aber schon mal motiviert, mich zum einen gedanklich mal mit den Unterschieden zwischen dem MQTT2_SERVER und MQTT2_CLIENT zu befassen, und da du jetzt schreibst, dass mit dem -er-Server alles viel einfacher war:
Wir packen als erstes das general-Client-template an ;) . Das sollte sich so verhalten wie der MQTT2-Server, indem es ebus-Infos und anderes sauber trennt. Also das erste bridgeRegep-Element so ändern, dass es _nicht_ auf ebus-Infos paßt und ein zweites dazu, dass alles an das ebus-Gerät weitergibt.
(und dann würde ich mal eine bridgeRegexp am ebus-Gerät testen, die alles, was nicht zum zentralen Steuergerät gehört auf eigene Geräte weiterverteilt).

Ins unreine gesprochen wäre es dann eventuell noch sehr hilfreich, wenn man mit "autocreate = 2" (oder so) dann autocreate anweisen könnte, die "extended version" von json2nameValue() zu verwenden. Ich hätte da noch weitere Ideen, aber da müssten wir ggf. erst mal noch testen, was da sinnvoll ist.

Anderer Punkt aus der pm: haben beide CLIENTs (Testsystem und Hauptsystem) unterschiedliche clientID-Werte per Attribut oder haben unterschiedliche Namen?

soviel mal vorab, bis später :) .
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, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Reinhart

  • Hero Member
  • *****
  • Beiträge: 2063
Antw:ebusd.template: Fragen, Anregungen
« Antwort #7 am: 02 März 2019, 09:48:20 »
wenn du mit ClientID die CID meinst, ja die sind unterschiedlich.

Hauptsystem: CID        ebusd_bai
Internals:
   CID        ebusd_bai
   DEF        ebusd_bai
   DEVICETOPIC MQTT2_ebusd_bai
   FUUID      5c65cd25-f33f-27bd-80dc-329a8ac7822ec5a5
   IODev      ebusMQTT
   LASTInputDev ebusMQTT
   MSGCNT     45584
   NAME       MQTT2_ebusd_bai
   NR         2824
   STATE      Vorlauf: 36.0 <br>Ruecklauf: 36.0 <br>Warmwasser: 36.0 <br>Aussentemp.: 5.1 <br>Pumpe: off <br>HWC-maxTemp: 60.0 <br>HWC-Regler_Max: 70.0 <br>HWC-CurrentTemp: 54.0 <br>HWC-Mode: auto
   TYPE       MQTT2_DEVICE
   ebusMQTT_MSGCNT 45584
   ebusMQTT_TIME 2019-03-02 09:36:17
   Helper:
     DBLOG:
       0_name:
         myDbLog:
           TIME       1551464601.34015
           VALUE      hwcmode
       0_value:
         myDbLog:
           TIME       1551515372.93913
           VALUE      18
       1_name:
         myDbLog:
           TIME       1551464601.34015
           VALUE      temp0
       1_value:
         myDbLog:
           TIME       1551464601.34015
           VALUE      60
       2_name:
         myDbLog:
           TIME       1551464601.34015
           VALUE      temp1
       2_value:
         myDbLog:
           TIME       1551464601.34015
           VALUE      70.0
       3_name:
         myDbLog:
           TIME       1551464601.34015
           VALUE      temp0
       3_value:
         myDbLog:
           TIME       1551464601.34015
           VALUE      70
       4_name:
         myDbLog:
           TIME       1551464601.34015
           VALUE      temp1
       4_value:
         myDbLog:
           TIME       1551464601.34015
           VALUE      54.0
       5_name:
         myDbLog:
           TIME       1551464596.25372
           VALUE      pumpstate
       5_value:
         myDbLog:
           TIME       1551464596.25372
           VALUE      on
       Status01_0_name:
         myDbLog:
           TIME       1551515772.81137
           VALUE      temp1
       Status01_0_value:
         myDbLog:
           TIME       1551515772.81137
           VALUE      36.0
       Status01_1_name:
         myDbLog:
           TIME       1551515772.81137
           VALUE      temp1
       Status01_1_value:
         myDbLog:
           TIME       1551515772.81137
           VALUE      36.0
       Status01_2_name:
         myDbLog:
           TIME       1551515772.81137
           VALUE      temp2
       Status01_2_value:
         myDbLog:
           TIME       1551515772.81137
           VALUE      5.125
       Status01_3_name:
         myDbLog:
           TIME       1551515772.81137
           VALUE      temp1
       Status01_3_value:
         myDbLog:
           TIME       1551515772.81137
           VALUE      36.0
       Status01_4_name:
         myDbLog:
           TIME       1551515772.81137
           VALUE      temp1
       Status01_4_value:
         myDbLog:
           TIME       1551515772.81137
           VALUE      39.0
       Status01_5_name:
         myDbLog:
           TIME       1551515772.81137
           VALUE      pumpstate
       Status01_5_value:
         myDbLog:
           TIME       1551515772.81137
           VALUE      off
       Status02_0_name:
         myDbLog:
           TIME       1551515747.75541
           VALUE      hwcmode
       Status02_0_value:
         myDbLog:
           TIME       1551515747.75541
           VALUE      auto
       Status02_1_name:
         myDbLog:
           TIME       1551515747.75541
           VALUE      temp0
       Status02_1_value:
         myDbLog:
           TIME       1551515747.75541
           VALUE      60
       Status02_2_name:
         myDbLog:
           TIME       1551515747.75541
           VALUE      temp1
       Status02_2_value:
         myDbLog:
           TIME       1551515747.75541
           VALUE      70.0
       Status02_3_name:
         myDbLog:
           TIME       1551515747.75541
           VALUE      temp0
       Status02_3_value:
         myDbLog:
           TIME       1551515747.75541
           VALUE      70
       Status02_4_name:
         myDbLog:
           TIME       1551515747.75541
           VALUE      temp1
       Status02_4_value:
         myDbLog:
           TIME       1551515747.75541
           VALUE      54.0
       bdate_value:
         myDbLog:
           TIME       1551515757.68888
           VALUE      -.-.-
       btime_value:
         myDbLog:
           TIME       1551515757.68888
           VALUE      20:12:24
       dcfstate_value:
         myDbLog:
           TIME       1551515757.68888
           VALUE      nosignal
       disablehc_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      0
       disablehwcload_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      1
       disablehwctapping_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      0
       flowtempdesired_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      42.5
       get:
         myDbLog:
           TIME       1551515687.96452
           VALUE     
       hcmode_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      auto
       hoursum2_value:
         myDbLog:
           TIME       1551515372.8757
           VALUE      6088
       percent0_value:
         myDbLog:
           TIME       1551515367.41397
           VALUE      53
       power_value:
         myDbLog:
           TIME       1551515372.83192
           VALUE      18
       press_value:
         myDbLog:
           TIME       1551515757.74431
           VALUE      1.869
       releaseBackup_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      0
       releaseCooling_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      0
       remoteControlHcPump_value:
         myDbLog:
           TIME       1551515777.6922
           VALUE      0
       sensor_value:
         myDbLog:
           TIME       1551515757.95559
           VALUE      ok
       state:
         myDbLog:
           TIME       1551515372.93913
           VALUE      0_name:
       temp0_value:
         myDbLog:
           TIME       1551515373.00076
           VALUE      29
       temp2_value:
         myDbLog:
           TIME       1551515757.68888
           VALUE      5.125
       temp_value:
         myDbLog:
           TIME       1551515757.95559
           VALUE      36.50
       tempmirror_value:
         myDbLog:
           TIME       1551515757.95559
           VALUE      64951
   OLDREADINGS:
   READINGS:
     2019-03-02 09:29:32   0_name         
     2019-03-02 09:29:32   0_value         18
     2019-03-02 09:36:12   Status01_0_name temp1
     2019-03-02 09:36:12   Status01_0_value 36.0
     2019-03-02 09:36:12   Status01_1_name temp1
     2019-03-02 09:36:12   Status01_1_value 36.0
     2019-03-02 09:36:12   Status01_2_name temp2
     2019-03-02 09:36:12   Status01_2_value 5.125
     2019-03-02 09:36:12   Status01_3_name temp1
     2019-03-02 09:36:12   Status01_3_value 36.0
     2019-03-02 09:36:12   Status01_4_name temp1
     2019-03-02 09:36:12   Status01_4_value 39.0
     2019-03-02 09:36:12   Status01_5_name pumpstate
     2019-03-02 09:36:12   Status01_5_value off
     2019-03-02 09:35:47   Status02_0_name hwcmode
     2019-03-02 09:35:47   Status02_0_value auto
     2019-03-02 09:35:47   Status02_1_name temp0
     2019-03-02 09:35:47   Status02_1_value 60
     2019-03-02 09:35:47   Status02_2_name temp1
     2019-03-02 09:35:47   Status02_2_value 70.0
     2019-03-02 09:35:47   Status02_3_name temp0
     2019-03-02 09:35:47   Status02_3_value 70
     2019-03-02 09:35:47   Status02_4_name temp1
     2019-03-02 09:35:47   Status02_4_value 54.0
     2019-03-01 19:29:31   associatedWith  MQTT2_ebusd_bai
     2019-03-02 09:35:57   bdate_value     -.-.-
     2019-03-02 09:35:57   btime_value     20:12:24
     2019-03-02 09:35:57   dcfstate_value  nosignal
     2019-03-02 09:36:17   disablehc_value 0
     2019-03-02 09:36:17   disablehwcload_value 1
     2019-03-02 09:36:17   disablehwctapping_value 0
     2019-03-02 09:36:17   flowtempdesired_value 42.5
     2019-03-02 09:34:47   get             
     2019-03-02 09:36:17   hcmode_value    auto
     2019-03-02 09:29:32   hoursum2_value  6088
     2019-03-02 09:29:27   percent0_value  53
     2019-03-02 09:29:32   power_value     18
     2019-03-02 09:35:57   press_value     1.869
     2019-03-02 09:36:17   releaseBackup_value 0
     2019-03-02 09:36:17   releaseCooling_value 0
     2019-03-02 09:36:17   remoteControlHcPump_value 0
     2019-03-02 09:35:57   sensor_value    ok
     2019-03-02 09:29:32   temp0_value     29
     2019-03-02 09:35:57   temp2_value     5.125
     2019-03-02 09:35:57   temp_value      36.50
     2019-03-02 09:35:57   tempmirror_value 64951
Attributes:
   IODev      ebusMQTT
   autocreate 1
   bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
   devStateStyle style="text-align:right"
   icon       icoTempHeizung
   model      E_01_eBus_Status
   readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/bai/SetMode:.* { json2nameValue($EVENT) }
ebusd/bai/DateTime:.* { json2nameValue($EVENT) }
ebusd/bai/WaterPressure/get:.* get
ebusd/bai/FlowTemp/get:.* get
ebusd/bai/ReturnTemp/get:.* get
ebusd/bai/OutdoorstempSensor/get:.* get
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }
ebusd/bai/FlowTemp:.* { json2nameValue($EVENT) }
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT) }
ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT) }
ebusd/bai/WPPWMPower:.* { json2nameValue($EVENT) }
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT) }
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT) }
ebusd/bai/FanHours:.* { json2nameValue($EVENT) }
ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }
ebusd/bai/HcHours:.* { json2nameValue($EVENT) }
ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }
ebusd/bai/PartloadHcKW:.* { json2nameValue($EVENT) }
ebusd/bai/DeactivationsIFC:.* { json2nameValue($EVENT) }
ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT) }
ebusd/bai/HwcSetPotmeter:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>Warmwasser: %.1f <br>Aussentemp.: %.1f <br>Pumpe: %s <br>HWC-maxTemp: %.1f <br>HWC-Regler_Max: %.1f <br>HWC-CurrentTemp: %.1f <br>HWC-Mode: %s", ReadingsVal($name,"Status01_0_value",0), ReadingsVal($name,"Status01_1_value",0), ReadingsVal($name,"Status01_3_value",0), ReadingsVal($name,"Status01_2_value",0), ReadingsVal($name,"Status01_5_value",0), ReadingsVal($name,"Status02_1_value",0), ReadingsVal($name,"Status02_2_value",0), ReadingsVal($name,"Status02_4_value",0), ReadingsVal($name,"Status02_0_value",0))}


Testsystem: CID        ebusd_3.2_20376
Internals:
   CID        ebusd_3.2_20376
   DEF        ebusd_3.2_20376
   DEVICETOPIC MQTT2_ebusd_3.2_20376
   IODev      MQTT2Server
   LASTInputDev MQTT2Server
   MQTT2Server_MSGCNT 7118
   MQTT2Server_TIME 2019-03-02 08:35:14
   MSGCNT     7118
   NAME       MQTT2_ebusd_3.2_20376
   NR         51
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-03-02 08:34:53   0_name          temp1
     2019-03-02 08:34:53   0_value         38.0
     2019-03-02 08:34:53   1_name          temp1
     2019-03-02 08:34:53   1_value         37.0
     2019-03-02 08:34:53   2_name          temp2
     2019-03-02 08:34:53   2_value         5.125
     2019-03-02 08:34:53   3_name          temp1
     2019-03-02 08:34:53   3_value         36.0
     2019-03-02 08:34:53   4_name          temp1
     2019-03-02 08:34:53   4_value         39.0
     2019-03-02 08:34:53   5_name          pumpstate
     2019-03-02 08:34:53   5_value         off
     2019-03-02 08:34:53   bdate_value     -.-.-
     2019-03-02 08:34:53   btime_value     20:11:23
     2019-03-02 08:30:53   curve_value     1.00
     2019-03-02 08:35:13   date_value      02.03.2019
     2019-03-02 08:34:53   dcfstate_value  nosignal
     2019-03-02 03:30:19   disablehc_value 0
     2019-03-02 03:30:19   disablehwcload_value 1
     2019-03-02 03:30:19   disablehwctapping_value 0
     2019-03-02 03:30:19   flowtempdesired_value 42.5
     2019-03-02 03:30:19   hcmode_value    auto
     2019-03-02 08:29:29   hoursum2_value  5207
     2019-03-02 05:59:29   percent0_value  53
     2019-03-02 08:34:48   press_value     1.869
     2019-03-02 03:30:19   releaseBackup_value 0
     2019-03-02 03:30:19   releaseCooling_value 0
     2019-03-02 03:30:19   remoteControlHcPump_value 0
     2019-03-01 18:31:02   running         true
     2019-03-02 08:34:48   sensor_value    ok
     2019-03-01 18:31:02   signal          true
     2019-03-02 08:30:54   temp1_value     55.0
     2019-03-02 08:34:53   temp2_value     5.125
     2019-03-02 08:34:48   temp_value      37.81
     2019-03-02 08:34:48   tempmirror_value 64930
     2019-03-02 08:35:13   time_value      08:53:41
     2019-03-02 08:35:14   uptime          59875
     2019-03-01 18:31:02   version         "ebusd 3.2.v3.2-30-gb2c63ac"
Attributes:
   IODev      MQTT2Server
   readingList ebusd_3.2_20376:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/global/uptime:.* uptime
ebusd_3.2_20376:ebusd/bai/Status01:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FlowTemp:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/430/Hc1HeatCurve:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/HcHours:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/global/running:.* running
ebusd_3.2_20376:ebusd/global/signal:.* signal
ebusd_3.2_20376:ebusd/global/version:.* version
ebusd_3.2_20376:ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/430/HwcTempDesired:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FanSpeed:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/SetMode:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FanHours:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/WPPWMPower:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

Ich habe auch beim Testsystem (denn da läuft MQTT2_Server) das direkte Publishen getestet, funktioniert.

Befehl:
set MQTT2Server publish ebusd/430/Hc1HeatCurve/get
Log:
2019.03.02 08:41:56 4: MQTT2Server_10.0.0.8_38002 ebusd_3.2_20376 PUBLISH ebusd/430/Hc1HeatCurve:{ "curve": {"value": 1.00}}
2019.03.02 08:41:56 5: MQTT2Server: dispatch autocreate:ebusd_3.2_20376:ebusd/430/Hc1HeatCurve:{ "curve": {"value": 1.00}}
2019.03.02 08:41:56 4: MQTT2_DEVICE_Parse: MQTT2_ebusd_3.2_20376 ebusd/430/Hc1HeatCurve => { json2nameValue($EVENT) }
2019.03.02 08:41:56 5: Starting notify loop for MQTT2_ebusd_3.2_20376, 1 event(s), first is curve_value: 1.00
2019.03.02 08:41:56 5: End notify loop for MQTT2_ebusd_3.2_20376


Hier habe ich auch eine zeitgesteuerte Abfrage (alle 5min) eingebaut, weil ja sonst der eBus von sich aus nur Broadcasts (Statusmeldungen) liefert.
+*00:05:00 {
  fhem("set MQTT2Server publish ebusd/430/Hc1HeatCurve/get");
  fhem("set MQTT2Server publish ebusd/bai/WaterPressure/get");
  fhem("set MQTT2Server publish ebusd/bai/FlowTemp/get");
  fhem("set MQTT2Server publish ebusd/bai/ReturnTemp/get");
  fhem("set MQTT2Server publish ebusd/bai/OutdoorstempSensor/get");
  fhem("set MQTT2Server publish ebusd/430/HwcTempDesired/get");
 }
eine beliebige Test Zusammenstellung von 2 verschiedenen Topics ( bai/430 )

LG
Reinhart
FHEM auf Raspy4 mit Buster + SSD, mit FS20, Homematic, ESP8266, Sonoff, Electrodragon, eBus, RPi mit COC,NanoCUL, MapleCUL, HM-CFG-LAN Adapter, MQTT2, Alexa

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:ebusd.template: Fragen, Anregungen
« Antwort #8 am: 02 März 2019, 13:12:50 »
wenn du mit ClientID die CID meinst, ja die sind unterschiedlich.
(Wieder erst mal zu wenig Zeit)
Das waren die lists von den MQTT2_DEVICEs. Mir ging es um das clientID-Attribut am IO-Device (TYPE=MQTT2_CLIENT).

Ich würde es auch gerne mit dieser IO-Art an's Laufen bekommen, auch wenn es richtig sein müßte, dass es mit MQTT2_SERVER sehr viel einfacher geht. Der Unterschied zwischen beiden IO's ist "nur" der, dass SERVER die Herkunft der Daten kennt, CLIENT nicht. Deswegen benötigen wir ja dieses eine MQTT2_DEVICE, das für CLIENT als IO aus dem Topic-Tree die Herkunft ableitet... Das ist die Funktion dieses ersten templates. Gestalten wir das richtig, verringert sich der Unterschied zwischen den IO-Optionen deutlich. Dazu müssen wir "nur" die bridgeRegexp erweitern, wie in der cref zu MQTT2_DEVICE beschrieben:
Zitat
multiple tuples of <regexp> newClientId are separated by newline
Wenn es dir nicht vorher gelingt, würde ich mich mal später am Tag daran machen, das hier umzusetzen:
Wir packen als erstes das general-Client-template an ;) . Das sollte sich so verhalten wie der MQTT2-Server, indem es ebus-Infos und anderes sauber trennt. Also das erste bridgeRegep-Element so ändern, dass es _nicht_ auf ebus-Infos paßt und ein zweites dazu, dass alles an das ebus-Gerät weitergibt.
(und dann würde ich mal eine bridgeRegexp am ebus-Gerät testen, die alles, was nicht zum zentralen Steuergerät gehört auf eigene Geräte weiterverteilt).
Zum publish: Die Frage war so gemeint, ob es TomLee jetzt gelungen ist, den passenden publish-Befehl zu finden, indem er das erst mal direkt über das IO macht. Paßt das und die Therme reagiert auch, können wir untersuchen, ob der Sendebefehl im MQTT2_DEVICE richtig zusammengestellt wird. Vorher macht das keinen Sinn.

Jetzt will ich erst noch ein paar Kleinigkeiten im Garten erledigen...
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, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Reinhart

  • Hero Member
  • *****
  • Beiträge: 2063
Antw:ebusd.template: Fragen, Anregungen
« Antwort #9 am: 02 März 2019, 13:51:32 »
beim eBusd haben wir die Möglichkeit direkt Kommandos in der Konsole absetzen zu können, daher empfiehlt sich für TomLee zuerst ein "ebusctl" mit seinen gewünschten Aktionen, wenn das klappt dann sollte die Syntax für MQTT kein Problem sein.

pi@raspberrypi:~ $ ebusctl f -f HwcTempDesired
r,430,HwcTempDesired,gewünschte Temperatur Warmwasserkreis,,15,b509,0d4400,temp1,s,D1C,,°C,setpoint of domestic hot water circuit
r,bai,HwcTempDesired,d.06 Brauchwassersollwert,,08,b509,0dea03,temp,s,D2C,,°C,Gewünschte Warmwasser Solltemperatur

pi@raspberrypi:~ $ ebusctl r -f HwcTempDesired
55.0

pi@raspberrypi:~ $ ebusctl r -f -c 430 HwcTempDesired
55.0

pi@raspberrypi:~ $ ebusctl f HwcTempDesired
430 HwcTempDesired = 55.0
bai HwcTempDesired = no data stored
wie man sieht, gibt es das Register "HwcTempDesired" zweimal, einmal in der Therme und einmal im Steuergerät (Calormatic). Es sind zwar unterschiedliche Register, aber derselbe Wert. Das Steuergerät greift ja auch auf das Register in der Therme (bai) zu und speichert den Wert nochmals bei sich.

Der Typ ist beide male gleich:
TYPE MQTT2_CLIENT


LG
« Letzte Änderung: 02 März 2019, 13:54:52 von Reinhart »
FHEM auf Raspy4 mit Buster + SSD, mit FS20, Homematic, ESP8266, Sonoff, Electrodragon, eBus, RPi mit COC,NanoCUL, MapleCUL, HM-CFG-LAN Adapter, MQTT2, Alexa

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:ebusd.template: Fragen, Anregungen
« Antwort #10 am: 03 März 2019, 12:08:17 »
So,

mal ein kurzer Zwischenstand  (dient auch dazu, dass ich das ggf. auch ins Wiki bekomme...):

1. Bei MQTT2_CLIENT als IO-Device sollte man
-- sicherstellen, dass die ClientID dieses Devices gegenüber dem MQTT-Server (mosquitto) nicht irgendwo doppelt belegt ist; am einfachsten dort das entsprechende Attribut setzen (wichtig, wenn man mehrere FHEM-Installationen betreibt und auf mehreren ein MQTT2_CLIENT vorhanden ist mit demselben Namen!)
-- das erste Gerät, das reinkommt, wird als Genera-Bridge genutzt. Die bridgeRegex sollte sein:
attr MQTT2_testsystemMQTT2CLIENT bridgeRegexp tele[/]([^/]+)[/]?.*:.* "$1"\
  cmnd[/]([^/]+)[/]?.*:.* "$1"\
  shellies[/]([^/]+)[/]?.*:.* "$1"\
  (ebus[^/])[/]([^/]+)[/].*:.* "$1"
Damit bekommt man dann auch z.B. Tasmotas und (hoffentlich) shellys besser in den Griff, der MQTT2_CLIENT verhält sich dann ähnlich wie ein MQTT2_SERVER beim autocreate (hoffe ich zumindest). Dazu mache ich demnächst noch einen separaten Post im MQTT-Bereich auf, das ist ein allgemeines Thema, vermutlich kommt das dann mit dem nächsten update der templates.

2. Ebus-Basis
Dann sollte mit den nächsten eingehenden Nachrichten von ebus-Seite dann ein weiteres Gerät angelegt werden, typischerweise mit der CID "ebus".
Das sollte dann auch eine bridgeRegexp bekommen - anschließend repräsentiert es (so jedenfalls mein bisheriges Verständnis) den ESP:
attr MQTT2_ebusd bridgeRegexp [^/]+[/](bai)[/].* "ebusd_bai"\
[^/]+[/](broadcast)[/].* "ebusd_bai"\
[^/]+[/]([\d]+)[/].* "ebusd_$1"

3. Weitere Geräte
Nach dem nächsten Satz Infos vom ebus werden dann mind. zwei weitere Geräte angelegt, eines für das "bai"-Dingens, eines für jedes Zusatzgerät, das sich hinter einer Nummer verbirgt.

Bei dem "bai"-Gerät sollte dann noch die readingList mit der Langversion von json2nameValue genutzt werden, z.B.:attr MQTT2_ebusd_bai readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }

Soviel mal vorab.

Fragen, bevor es ggf. weitergeht:
- Wäre die Gerätestruktur, die damit grundlegend angelegt werden würde aus eurer Sicht ok? Also: kann man damit was anfangen, oder bin ich gedanklich auf dem Holzweg?
- Dann wäre nicht schlecht, wenn jemand die Schritte 2 bis Ende mal mit dem MQTT2_SERVER nachvollziehen könnte. Müßte eigentlich gleich sein, kann aber auch sein, dass da irgendwas noch angepaßt werden muss, weil mehr/weniger über die CID bekannt ist.

Hoffe, das hilft euch weiter, ich muß mich jedenfalls erst mal sehr bei Reinhart bedanken! Das Testsystem hat mir im Verständnis des MQTT2_CLIENTS und der bridgeRegepx-Anwendung sehr weitergeholfen.
(Du könntest den Zugang jetzt erst mal wieder schließen, wir können das ja ggf. wiederholen, wenn weiterer Bedarf bestehen sollte).

Gruß, 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, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 1791
Antw:ebusd.template: Fragen, Anregungen
« Antwort #11 am: 03 März 2019, 13:05:22 »
Hallo,

wie man an meinem gezeigten Beispiel sieht hatte ich nach viel Spielerei und ausprobieren am Ende über den SetMode_hwctempdesired_value Wert den ich aus Setmode geholt hatte versucht die Temperatur zu setzen, da hab ich dann wohl was durcheinander gebracht.

Es klappt wenn man wie Reinhart schon erwähnt hat den Wert aus HwcTempDesired holt und nicht aus Setmode, so hatte ich das scheinbar anfangs auch getestet.

Hier jetzt ein funktionierendes Beispiel das mit 2 verschiedenen Topics funktioniert.

defmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
attr MQTT2_Test_Ebusd devStateStyle style="text-align:right"
attr MQTT2_Test_Ebusd event-on-change-reading .*
attr MQTT2_Test_Ebusd icon icoTempHeizung
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:1_Vorlauf Status01_0_name:0 Status01_1_value:1_Ruecklauf Status01_1_name:0 Status01_2_value:1_OutdoorstempSensor Status01_2_name:0 Status01_3_value:1_Fragez Status01_3_name:0 Status01_4_value:1_HwctempSensor Status01_4_name:0 Status01_5_value:1_Pumpe Status01_5_name:0 WaterPressure_press_value:WaterPressure WaterPressure_sensor_value:0 FlowTempDesired_temp_value:FlowTempDesired CirPump_onoff_value:CirPump Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:Hc1HeatCurve z1DayTemp_tempv_value:z1DayTemp HwcTempDesired_tempv_value:HwcTempDesired
attr MQTT2_Test_Ebusd model E_04a_eBus_Test_Status01+WaterPressure+CirPump+HwcTempDesired+Hc1HeatCurve+z1DayTemp
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }
attr MQTT2_Test_Ebusd setList Hc1HeatCurve:2.0,2.05,2.10 ebusd/700/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired:50,51,52,53,54,55,56,57,58,59,60 ebusd/700/HwcTempDesired/set $EVTPART1\
z1DayTemp:20,21,22,23,24 ebusd/700/z1DayTemp/set $EVTPART1
attr MQTT2_Test_Ebusd stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>WW-Temperatur: %.1f <br>Aussentemperatur.: %.1f <br>Pumpe: %s <br>Fragez: %.1f <br>Druck: %.1f <br>Zirk.pumpe: %s", ReadingsVal($name,"1_Vorlauf",0), ReadingsVal($name,"1_Ruecklauf",0), ReadingsVal($name,"1_HwctempSensor",0),ReadingsVal($name,"1_OutdoorstempSensor",0), ReadingsVal($name,"1_Pumpe",0), ReadingsVal($name,"Fragez",0), ReadingsVal($name,"WaterPressure",0), ReadingsVal($name,"CirPump",0))}
attr MQTT2_Test_Ebusd webCmd Hc1HeatCurve:HwcTempDesired:z1DayTemp
attr MQTT2_Test_Ebusd webCmdLabel Heizkurve:Warmwasser:Raumtemperatur

setstate MQTT2_Test_Ebusd Vorlauf: 54.0 <br>Ruecklauf: 0.0 <br>WW-Temperatur: 49.0 <br>Aussentemperatur.: 13.7 <br>Pumpe: 68 <br>Fragez: 0.0 <br>Druck: 2.2 <br>Zirk.pumpe: off
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_Fragez 0.0
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_HwctempSensor 49.0
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_OutdoorstempSensor 13.688
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_Pumpe 68
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_Vorlauf 54.0
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:02 CirPump off
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 Hc1HeatCurve 2.05
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 HwcTempDesired 55
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 WaterPressure 2.240
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 z1DayTemp 22


« Letzte Änderung: 03 März 2019, 13:21:26 von TomLee »

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 1791
Antw:ebusd.template: Fragen, Anregungen
« Antwort #12 am: 03 März 2019, 15:19:30 »
Zitat
- Wäre die Gerätestruktur, die damit grundlegend angelegt werden würde aus eurer Sicht ok?

Deine vorgeschlagene bridgeRegexp hab ich mal in meiner General-Bridge angewendet.

attr MQTT2_testsystemMQTT2CLIENT bridgeRegexp tele[/]([^/]+)[/]?.*:.* "$1"\
  cmnd[/]([^/]+)[/]?.*:.* "$1"\
  shellies[/]([^/]+)[/]?.*:.* "$1"\
  (ebus[^/])[/]([^/]+)[/].*:.* "$1"

(Bemerkung am Rande die Leerzeichen sind ja immer noch da  :P )

Daraufhin wird folgendes Device wie von dir beschrieben angelegt.
defmod MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev MQTT2_CLIENT
attr MQTT2_ebusd readingList ebusd/global/uptime:.* uptime\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT) }\
ebusd/700/Hc1HeatCurve/get:.* get\
ebusd/700/z1DayTemp/get:.* get\
ebusd/700/HwcTempDesired/get:.* get\
ebusd/bai/WaterPressure/get:.* get\
ebusd/bai/FanSpeed/get:.* get\
ebusd/bai/HwcStarts/get:.* get\
ebusd/bai/HwcHours/get:.* get\
ebusd/bai/HcHours/get:.* get\
ebusd/bai/HcStarts/get:.* get\
ebusd/bai/FanHours/get:.* get\
ebusd/bai/CirPump/get:.* get\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT) }\
ebusd/bai/Status01:.* { json2nameValue($EVENT) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT) }
attr MQTT2_ebusd room MQTT2_DEVICE

setstate MQTT2_ebusd 2019-03-03 14:53:19 0_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 0_value 41.0
setstate MQTT2_ebusd 2019-03-03 14:53:19 1_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 2_name temp2
setstate MQTT2_ebusd 2019-03-03 14:53:19 2_value 13.688
setstate MQTT2_ebusd 2019-03-03 14:53:19 3_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 3_value 0.0
setstate MQTT2_ebusd 2019-03-03 14:53:19 4_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 4_value 55.0
setstate MQTT2_ebusd 2019-03-03 14:53:19 5_name pumpstate
setstate MQTT2_ebusd 2019-03-03 14:53:19 5_value off
setstate MQTT2_ebusd 2019-03-03 14:52:02 associatedWith MQTT2_General_Bridge
setstate MQTT2_ebusd 2019-03-03 14:53:29 bdate_value 03.03.2019
setstate MQTT2_ebusd 2019-03-03 14:53:29 btime_value 14:53:31
setstate MQTT2_ebusd 2019-03-03 14:52:29 date_value 03.03.2019
setstate MQTT2_ebusd 2019-03-03 14:53:29 dcfstate_value valid
setstate MQTT2_ebusd 2019-03-03 14:52:01 get
setstate MQTT2_ebusd 2019-03-03 14:52:02 hoursum2_value 459
setstate MQTT2_ebusd 2019-03-03 14:52:02 onoff_value off
setstate MQTT2_ebusd 2019-03-03 14:52:01 press_value 2.355
setstate MQTT2_ebusd 2019-03-03 14:52:01 sensor_value ok
setstate MQTT2_ebusd 2019-03-03 14:53:29 temp2_value 13.688
setstate MQTT2_ebusd 2019-03-03 14:52:01 tempv_value 55
setstate MQTT2_ebusd 2019-03-03 14:52:29 time_value 14:52:30
setstate MQTT2_ebusd 2019-03-03 14:53:36 uptime 172426

auf dieses wiederum das bridgeRegexp angewendet:

attr MQTT2_ebusd bridgeRegexp [^/]+[/](bai)[/].* "ebusd_bai"\
[^/]+[/](broadcast)[/].* "ebusd_bai"\
[^/]+[/]([\d]+)[/].* "ebusd_$1"

Werden diese Geräte automatisch erstellt

MQTT2_ebusd_700
MQTT2_ebusd_broadcast
MQTT2_ebusd_bai
MQTT2_ebusd_global
MQTT2_ebusd_scan (Neustart vom Ebusd vorausgesetzt)

Das passt glaube ich so wie du dir das vorgestellt hast. MQTT2_SERVER hab ich/nutz ich nicht.

Trotzdem hat man das ganze zuvor genauso auch ohne ein zusätzliches Bridge-Device  gehabt.


« Letzte Änderung: 03 März 2019, 15:28:39 von TomLee »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:ebusd.template: Fragen, Anregungen
« Antwort #13 am: 03 März 2019, 16:45:58 »
Das passt glaube ich so wie du dir das vorgestellt hast. MQTT2_SERVER hab ich/nutz ich nicht.

Trotzdem hat man das ganze zuvor genauso auch ohne ein zusätzliches Bridge-Device  gehabt.
Erst mal ganz lieben Dank für's ausprobieren!

Im Moment kann ich noch nicht beurteilen, ob jetzt ein "Einheitsdevice" oder dieses aufgeteilte "besser" ist, du also recht hast, wenn du "trotzdem" schreibst. Für's "vertemplaten" ist vermutlich die gesplittete Variante einfacher, weil ähnliche Geräteklassen dann ganz easy dasselbe template verwenden können sollten, in der Einheitsvariante muß mehr Intelligenz her.
Mal schauen.

Wenn du wieder dein "Einheitsdevice" nutzen willst (was ok ist!), würde ich allerdings vorschlagen, die General Bridge ("MQTT2_testsystemMQTT2CLIENT") weiter so zu lassen. Im ebus-Device wird dann keine bridgeRegexp mehr benötigt.

Bezogen auf dein Einheitsdevice noch das Fragment einer getList:
attr MQTT2_Test_Ebusd getList
Heizkurve:noArg Hc1HeatCurve ebusd/700/Hc1HeatCurve/get\
HwcTempDesired:noArg HwcTempDesired ebusd/700/HwcTempDesired/get\
z1DayTemp:noArg z1DayTemp ebusd/700/z1DayTemp/get
Könnte man um die bai-Anfragen erweitern, dann sollte sich ein at zum regelmäßigen Abholen auf
get MQTT2_Test_Ebusd .* reduzieren lassen...
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, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 1791
Antw:ebusd.template: Fragen, Anregungen
« Antwort #14 am: 03 März 2019, 16:59:49 »
Bezogen auf dein Einheitsdevice noch das Fragment einer getList:
attr MQTT2_Test_Ebusd getList
Heizkurve:noArg Hc1HeatCurve ebusd/700/Hc1HeatCurve/get\
HwcTempDesired:noArg HwcTempDesired ebusd/700/HwcTempDesired/get\
z1DayTemp:noArg z1DayTemp ebusd/700/z1DayTemp/get
Könnte man um die bai-Anfragen erweitern, dann sollte sich ein at zum regelmäßigen Abholen auf
get MQTT2_Test_Ebusd .* reduzieren lassen...

Habs noch nicht umgesetzt aber gefällt mir, Danke.