eBus Schaltung V2 in Betrieb nehmen

TomLee · 31 Dezember 2019, 14:42:19

Hallo nochmal,

mein Missgeschick hatte ich auch gleich genutzt für ein update auf Nectarine .

version: ebusd 3.4.v3.3-51-g57eae05
access: *
signal: acquired
symbol rate: 22
max symbol rate: 123
min arbitration micros: 41
max arbitration micros: 72
min symbol latency: 3
max symbol latency: 5
reconnects: 0
masters: 3
messages: 632
conditional: 0
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/bai.0010010674.inc" ([PROD='0010010678']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

Der Ebusd ist bei mir per MQTT(2) eingebunden, mit der neuen Version (zuvor hatte ich Version 3.2 irgendwas) hab ich folgendes bei den zyklisch abgefragten Werten festgestellt:

Daten werden angefragt (verbose 5 Log):

Code Auswählen

2019.12.28 14:16:55 5:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 => ebusd/700/z1DayTemp/get:
2019.12.28 14:16:55 5: out: PUBLISH: 0(25)(0)(23)ebusd/700/z1DayTemp/get
2019.12.28 14:16:55 5:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 => ebusd/700/z1NightTemp/get:
2019.12.28 14:16:55 5: out: PUBLISH: 0(27)(0)(25)ebusd/700/z1NightTemp/get
2019.12.28 14:16:55 5:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 => ebusd/700/Hc1HeatCurve/get:
2019.12.28 14:16:55 5: out: PUBLISH: 0(28)(0)(26)ebusd/700/Hc1HeatCurve/get
2019.12.28 14:16:55 5:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 => ebusd/700/HwcTempDesired/get:
2019.12.28 14:16:55 5: out: PUBLISH: 0(30)(0)(28)ebusd/700/HwcTempDesired/get

Die Daten werden laut ebusd.log gelesen und geschickt:

Code Auswählen

2019-12-28 14:16:59.044 [update notice] sent read 700 z1DayTemp QQ=31: 22
2019-12-28 14:16:59.044 [mqtt notice] read 700 z1DayTemp:
2019-12-28 14:16:59.205 [update notice] sent read 700 z1NightTemp QQ=31: 22
2019-12-28 14:16:59.206 [mqtt notice] read 700 z1NightTemp:
2019-12-28 14:17:00.571 [update notice] sent read 700 Hc1HeatCurve QQ=31: 0.7
2019-12-28 14:17:00.571 [mqtt notice] read 700 Hc1HeatCurve:
2019-12-28 14:17:00.737 [update notice] sent read 700 HwcTempDesired QQ=31: 50
2019-12-28 14:17:00.737 [mqtt notice] read 700 HwcTempDesired:

Die Daten kommen in FHEM an:

Code Auswählen

2019.12.28 14:16:59 5: in:  PUBLISH: 03(0)(19)ebusd/700/z1DayTemp{(10)     "tempv": {"value": 22}}
2019.12.28 14:16:59 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/z1DayTemp:{
     "tempv": {"value": 22}}
2019.12.28 14:16:59 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/z1DayTemp\000{\n     "tempv": {"value": 22}}
2019.12.28 14:16:59 5: in:  PUBLISH: 05(0)(21)ebusd/700/z1NightTemp{(10)     "tempv": {"value": 22}}
2019.12.28 14:16:59 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/z1NightTemp:{
     "tempv": {"value": 22}}
2019.12.28 14:16:59 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/z1NightTemp\000{\n     "tempv": {"value": 22}}
2019.12.28 14:17:00 5: in:  PUBLISH: 0?(0)(22)ebusd/700/Hc1HeatCurve{(10)     "0": {"name": "", "value": 0.7}}
2019.12.28 14:17:00 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/Hc1HeatCurve:{
     "0": {"name": "", "value": 0.7}}
2019.12.28 14:17:00 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/Hc1HeatCurve\000{\n     "0": {"name": "", "value": 0.7}}
2019.12.28 14:17:00 5: in:  PUBLISH: 08(0)(24)ebusd/700/HwcTempDesired{(10)     "tempv": {"value": 50}}
2019.12.28 14:17:00 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/HwcTempDesired:{
     "tempv": {"value": 50}}
2019.12.28 14:17:00 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/HwcTempDesired\000{\n     "tempv": {"value": 50}}

Bis hier her alles in Ordnung, doch weshalb kommen die Daten wenige Sekunden später nochmal rein ?:

Code Auswählen

2019.12.28 14:17:04 5: in:  PUBLISH: 0:(0)(24)ebusd/700/HwcTempDesired{(10)     "tempv": {"value": 50.0}}
2019.12.28 14:17:04 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/HwcTempDesired:{
     "tempv": {"value": 50.0}}
2019.12.28 14:17:04 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/HwcTempDesired\000{\n     "tempv": {"value": 50.0}}
2019.12.28 14:17:04 5: in:  PUBLISH: 05(0)(19)ebusd/700/z1DayTemp{(10)     "tempv": {"value": 22.0}}
2019.12.28 14:17:04 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/z1DayTemp:{
     "tempv": {"value": 22.0}}
2019.12.28 14:17:04 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/z1DayTemp\000{\n     "tempv": {"value": 22.0}}
2019.12.28 14:17:04 5: in:  PUBLISH: 07(0)(21)ebusd/700/Hc1FlowTemp{(10)     "tempv": {"value": 48.0}}
2019.12.28 14:17:04 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/Hc1FlowTemp:{
     "tempv": {"value": 48.0}}
2019.12.28 14:17:04 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/Hc1FlowTemp\000{\n     "tempv": {"value": 48.0}}
2019.12.28 14:17:04 5: in:  PUBLISH: 07(0)(21)ebusd/700/z1NightTemp{(10)     "tempv": {"value": 22.0}}
2019.12.28 14:17:04 4:   MQTT2_Server_192.168.188.34_52296 ebusd_3.4_4901 PUBLISH ebusd/700/z1NightTemp:{
     "tempv": {"value": 22.0}}
2019.12.28 14:17:04 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_4901\000ebusd/700/z1NightTemp\000{\n     "tempv": {"value": 22.0}}

Im ebusd.log ist davon nichts zu sehen, das ist nach jeder Abfrage so, die Werte kommen dann aber oft ( nicht immer ) nicht als Ganzzahl, sondern als Kommazahl (siehe oben), die Werte stehen in setList aber als Ganzzahl ( wie sie im ebusd.log stehen und auch schon zu Version 3.2 Zeiten), womit in webCmd dann das select-Widget keine Werte anzeigen kann (siehe Bild im Anhang).
Weshalb kommen die Werte ein zweites mal rein und warum steht davon nichts im ebusd.log ?

Code Auswählen

attr MQTT2_ebusd_bai setList Hc1Heizkurve:0.7,0.75,0.8,0.85,0.9,0.95,1,1.05,1.1,1.15,1.2,1.25,1.3,1.35,1.4,1.45,1.5,1.55,1.6,1.65,1.7,1.75,1.8,1.85,1.9,1.95,2.0,2.05,2.1,2.15,2.2,2.3,2,45,2,5 ebusd/700/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired:50,51,52,53,54,55,56,57,58,59,60 ebusd/700/HwcTempDesired/set $EVTPART1\
z1DayTemp:20,20.5,21,21.5,22,22.5,23,23.5,24 ebusd/700/z1DayTemp/set $EVTPART1\
z1NightTemp:18,18.5,19,20,21,22,23,24 ebusd/700/z1NightTemp/set $EVTPART1\
Hc1MinFlowTempDesired:25,26,27,28,29,30 ebusd/700/Hc1MinFlowTempDesired/set $EVTPART1\

Weitere Feststellung ist das der angeforderte Hc1HeatCurve Wert jetzt (mit Version 3.2 war das nicht so) immer erst korrekt übertragen wird, ist dieser allerdings auf einen zweistelligen Wert nach dem Komma eingestellt, kommt dieser beim zweiten Mal immer abgerundet beim MQTT2_Server an.

Beispiel:

verbose 5 Log :

Code Auswählen

2019.12.31 13:38:25 5:   MQTT2_Server_192.168.188.34_52508 ebusd_3.4_10040 => ebusd/700/Hc1HeatCurve/get:
2019.12.31 13:38:25 5: out: PUBLISH: 0(28)(0)(26)ebusd/700/Hc1HeatCurve/get

ebusd.log:

Code Auswählen

2019-12-31 13:38:30.602 [update notice] sent read 700 Hc1HeatCurve QQ=31: 0.65
2019-12-31 13:38:30.606 [mqtt notice] read 700 Hc1HeatCurve:

verbose 5 Log:

Code Auswählen

2019.12.31 13:38:30 5: in:  PUBLISH: 0@(0)(22)ebusd/700/Hc1HeatCurve{(10)     "0": {"name": "", "value": 0.65}}
2019.12.31 13:38:30 4:   MQTT2_Server_192.168.188.34_52508 ebusd_3.4_10040 PUBLISH ebusd/700/Hc1HeatCurve:{
     "0": {"name": "", "value": 0.65}}
2019.12.31 13:38:30 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_10040\000ebusd/700/Hc1HeatCurve\000{\n     "0": {"name": "", "value": 0.65}}

Code Auswählen

2019.12.31 13:38:34 5: in:  PUBLISH: 0?(0)(22)ebusd/700/Hc1HeatCurve{(10)     "0": {"name": "", "value": 0.6}}
2019.12.31 13:38:34 4:   MQTT2_Server_192.168.188.34_52508 ebusd_3.4_10040 PUBLISH ebusd/700/Hc1HeatCurve:{
     "0": {"name": "", "value": 0.6}}
2019.12.31 13:38:34 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.4_10040\000ebusd/700/Hc1HeatCurve\000{\n     "0": {"name": "", "value": 0.6}}

Zitat von: john30 am 08 Oktober 2019, 08:10:50
mal im mosquitto log schauen, ob da was zu finden ist, bzw. dessen log level erhöhen

Hier bin ich noch nicht weiter, das Problem gibts auch noch mit Nectarine, Mosquitto-Log hab ich nicht wegen MQTT2 und den MQTT2-Server 2-3 Tage auf verbose 5 stellen mag ich nicht.

Guten Rutsch

Thomas

john30 · 03 Januar 2020, 09:14:13

Zitat von: TomLee am 31 Dezember 2019, 14:42:19
Bis hier her alles in Ordnung, doch weshalb kommen die Daten wenige Sekunden später nochmal rein ?:

weil das eine die direkte Antwort auf die via MQTT Anfrage ist und das andere das reguläre Update, das an der Message entstanden ist.

Zitat von: TomLee am 31 Dezember 2019, 14:42:19
Weitere Feststellung ist das der angeforderte Hc1HeatCurve Wert jetzt (mit Version 3.2 war das nicht so) immer erst korrekt übertragen wird, ist dieser allerdings auf einen zweistelligen Wert nach dem Komma eingestellt, kommt dieser beim zweiten Mal immer abgerundet beim MQTT2_Server an.

würde mal tippen, dass das zwei verschiedene Messages sind. Schau mal nach.

TomLee · 03 Januar 2020, 10:48:26

Zitatweil das eine die direkte Antwort auf die via MQTT Anfrage ist und das andere das reguläre Update, das an der Message entstanden ist.

und ? bekommt man das hin das die MQTT-Antwort und das reguläre Update gleich formatierte Werte zurückgeben ?
War ja vor meinem update nicht so.

Zitatwürde mal tippen, dass das zwei verschiedene Messages sind. Schau mal nach.

Wo soll ich denn noch nachschauen ? Im ebusd.log stehen doch nur die via MQTT angeforderten Anfragen und Antworten, die durch das "reguläre Update" nicht, wie oben geschrieben.
Auch wenns zwei verschiedene Messages sind sollten doch gleiche Werte zurückkommen, die Heizkurve steht ja im obigen Beispiel auf 0.65 und nicht 0.6.
Heute, sehe ich gerade wird übrigens aufgerundet und nicht abgerundet.

john30 · 04 Januar 2020, 10:59:57

Zitat von: TomLee am 03 Januar 2020, 10:48:26
und ? bekommt man das hin das die MQTT-Antwort und das reguläre Update gleich formatierte Werte zurückgeben ?

erstmal muss man ausschließen, dass es nicht wirklich so am Bus vorbeigekommen ist.

Zitat von: TomLee am 03 Januar 2020, 10:48:26
Wo soll ich denn noch nachschauen ? Im ebusd.log stehen doch nur die via MQTT angeforderten Anfragen und Antworten, die durch das "reguläre Update" nicht, wie oben geschrieben.
Auch wenns zwei verschiedene Messages sind sollten doch gleiche Werte zurückkommen, die Heizkurve steht ja im obigen Beispiel auf 0.65 und nicht 0.6.

ok, dann beantworte ich mal wieder die von mir gestellte Frage selbst: es scheint keine zweite Nachrichtendefinition zu geben.
Dann brauche die beiden HEX Messages dazu, um das eingrenzen zu können.

TomLee · 04 Januar 2020, 23:40:11

Bisher war ein zusammenlöten des (RPI-)Adapters, die ebusd-Installation und die Aktivierung von MQTT für meine Zwecke (Dank Reinhart) ausreichend.

Was die Telegramme angeht befinde ich mich nach wie vor in der Findungsphase.(Es gibt bei mir unknown-Messages die ich doch irgendwann -so mein Ziel- 'entschlüsseln' kann)

Ich versuche zu verstehen welche 2 HEX Messages du von mir sehen willst, es gelingt mir mangels Kenntnissse aber nicht, auch wenn ich heute versucht habe mittels --enablehex ----enabledefine und ----loglevel=debug mich dem Thema zu nähern.

Kann denn niemand der die MQTT2-Einbindung nutzt und mehr Erfahrung hat meine Feststellungen mit Nectarine 3.4 bestätigen ?

Gruß

Thomas

john30 · 05 Januar 2020, 11:07:42

Zitat von: TomLee am 04 Januar 2020, 23:40:11
Ich versuche zu verstehen welche 2 HEX Messages du von mir sehen willst, es gelingt mir mangels Kenntnissse aber nicht, auch wenn ich heute versucht habe mittels --enablehex ----enabledefine und ----loglevel=debug mich dem Thema zu nähern.

mach mal ein "ebusctl find -a -f Hc1HeatCurve" sowie "ebusctl find -a -h -V Hc1HeatCurve" und poste das jeweilige Ergebnis

TomLee · 05 Januar 2020, 11:46:48

Code Auswählen

pi@Ebus-Raspi:~ $ ebusctl find -a -f Hc1HeatCurve
r,700,Hc1HeatCurve,HeatCurve Heizkreis 1,,15,b524,020002000f00,,s,IGN:4,,,,,s,EXP,,,heating curve of Hc1
w,700,Hc1HeatCurve,HeatCurve Heizkreis 1,,15,b524,020102000f00,,m,EXP,,,heating curve of Hc1
r,700,Hc1HeatCurveAdaption,HeatCurveAdaption Heizkreis 1,,15,b524,020002001c00,,s,IGN:4,,,,,s,EXP,,,adaption applied to heating curve of Hc1

Code Auswählen

pi@Ebus-Raspi:~ $ ebusctl find -a -h -V Hc1HeatCurve                                                                                                                                                      700 Hc1HeatCurve = 3115b52406020002000f00 / 0803020f009a99593f [ZZ=15, lastup=2020-01-05 11:40:06, active read]
700 Hc1HeatCurve = no data stored [ZZ=15, active write]
700 Hc1HeatCurveAdaption = no data stored [ZZ=15, active read]

Reinhart · 05 Januar 2020, 19:13:03

Ich muss feststellen, das mein Format welches ich vom MQTT2 Server erhalte etwas von deinem abweicht.

mit dieser Abfrage:

Code Auswählen

set ebusMQTT publish ebusd/430/Hc1HeatCurve/get

erhalte ich diese Antwort (aber nur einmal):

Code Auswählen

2020.01.05 18:39:56 5: in:  PUBLISH: 08(0)(22)ebusd/430/Hc1HeatCurve{(10)     "curve": {"value": 1.00}}
2020.01.05 18:39:56 4:   ebusMQTT_10.0.0.9_54190 ebusd_3.3_2567 PUBLISH ebusd/430/Hc1HeatCurve:{
     "curve": {"value": 1.00}}
2020.01.05 18:39:56 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.3_2567\000ebusd/430/Hc1HeatCurve\000{\n     "curve": {"value": 1.00}}

und hier der Unterschied zu deine, ich habe den Namen außerhalb der Klammer schön aufgelöst:

Code Auswählen


deine  2019.12.31 13:38:30 5: in:  PUBLISH: 0@(0)(22)ebusd/700/Hc1HeatCurve{(10)     "0": {"name": "", "value": 0.65}}
deine  2019.12.31 13:38:34 5: in:  PUBLISH: 0?(0)(22)ebusd/700/Hc1HeatCurve{(10)     "0": {"name": "", "value": 0.6}}
meine 2020.01.05 18:39:56 5: in:  PUBLISH: 08(0)(22)ebusd/430/Hc1HeatCurve{(10)     "curve": {"value": 1.00}}

Verwendest du MQTT2 Server und MQTT2 Client eventuell gleichzeitig, die 2. Meldung kommt ja immerhin 4 Sekunden später?
Eigentlich kann der Unterschied der Ausgabeformatierung nur vom MQTT2_Server kommen, aber wie ich sehe hast du den auch auf "complex" eingestellt, sollten also gleich sein.

Ich habe diese Version von ebusd:

Code Auswählen

version: ebusd 3.3.v3.3-19-ga3f4999

LG

TomLee · 05 Januar 2020, 19:47:41

Hallo Reinhart,

so frag ich ab:

Code Auswählen

defmod at_ebus_updates at +*00:15:00 set MQTT2_Server publish ebusd/bai/HwcPostrunTime/get;;\
set MQTT2_Server publish ebusd/bai/StorageTempDesired/get;;\
set MQTT2_Server publish ebusd/bai/FanHours/get;;\
set MQTT2_Server publish ebusd/bai/HcHours/get;;\
set MQTT2_Server publish ebusd/bai/HwcHours/get;;\
set MQTT2_Server publish ebusd/bai/HwcStarts/get;;\
set MQTT2_Server publish ebusd/bai/HwcPostrunTime/get;;\
set MQTT2_Server publish ebusd/bai/RemainingBoilerblocktime/get;;\
set MQTT2_Server publish ebusd/bai/SDFlame/get;;\
set MQTT2_Server publish ebusd/bai/HcStarts/get;;\
set MQTT2_Server publish ebusd/bai/CounterStartattempts1/get;;\
set MQTT2_Server publish ebusd/bai/CounterStartattempts2/get;;\
set MQTT2_Server publish ebusd/bai/CounterStartAttempts3/get;;\
set MQTT2_Server publish ebusd/bai/CounterStartAttempts4/get;;\
set MQTT2_Server publish ebusd/700/PrEnergySumHc/get;;\
set MQTT2_Server publish ebusd/700/PrEnergySumHwc/get;;\
set MQTT2_Server publish ebusd/700/PrFuelSumHc/get;;\
set MQTT2_Server publish ebusd/700/HwcOpMode/get;;\
set MQTT2_Server publish ebusd/700/HwcSFMode/get;;\
set MQTT2_Server publish ebusd/700/CylinderChargeHyst/get;;\
set MQTT2_Server publish ebusd/700/Hc1FlowTemp/get;;\
set MQTT2_Server publish ebusd/700/Hc1Status/get;;\
set MQTT2_Server publish ebusd/700/Hc1PumpStatus/get;;\
set MQTT2_Server publish ebusd/700/CylinderChargeHyst/get;;\
set MQTT2_Server publish ebusd/700/z1DayTemp/get;;\
set MQTT2_Server publish ebusd/700/z1NightTemp/get;;\
set MQTT2_Server publish ebusd/700/HwcLockTime/get;;\
set MQTT2_Server publish ebusd/700/ccTimer.Saturday/get;;\
set MQTT2_Server publish ebusd/700/DisplayedOutsideTemp/get;;\
set MQTT2_Server publish ebusd/700/Hc1ExcessTemp/get;;\
set MQTT2_Server publish ebusd/700/PrFuelSumHcThisMonth/get;;\
set MQTT2_Server publish ebusd/700/PartloadHcKW/get;;\
set MQTT2_Server publish ebusd/700/Hc1HeatCurve/get;;\
set MQTT2_Server publish ebusd/700/HwcTempDesired/get;;\
set MQTT2_Server publish ebusd/700/Hc1MinFlowTempDesired/get;;\
set MQTT2_Server publish ebusd/700/PumpAdditionalTime/get;;\
set MQTT2_Server publish ebusd/700/MaxCylinderChargeTime/get;;\
set MQTT2_Server publish ebusd/700/CylinderChargeHyst/get;;
attr at_ebus_updates group Ebus
attr at_ebus_updates room Ebus
attr at_ebus_updates webCmd execNow

setstate at_ebus_updates Next: 19:42:36
setstate at_ebus_updates 2020-01-05 19:27:36 state Next: 19:42:36

Wie man sieht verwende ich MQTT2_SERVER und nein es gibt keinen MQTT2 Client auch nicht auf einem anderen System.

Mit 3.2 irgendwas (mein ich war ich vorher, die die halt aktuell war letzten Winter) hatte ich das ja auch nicht.
Du zeigst jetzt was mit 3.3 zurückkommt, für dich ist es doch kein Problem mal ein update auf meine jetzige Version zu machen, das würde mich jetzt interessieren ob dann der Name immer noch so aufgelöst wird wie du jetzt zeigst.
Ich hab doch nix an meiner Konfiguration in Fhem geändert, nur ein update vom ebusd gemacht.

Gruß

Thomas

Reinhart · 05 Januar 2020, 20:31:07

ich habe jetzt Version ebusd 3.4.v3.4-8-g177568c und es hat sich diesbezüglich nichts geändert.

Code Auswählen

2020.01.05 20:26:00 5: in:  PUBLISH: 08(0)(22)ebusd/430/Hc1HeatCurve{(10)     "curve": {"value": 1.00}}
2020.01.05 20:26:00 4:   ebusMQTT_10.0.0.9_56944 ebusd_3.4_5950 PUBLISH ebusd/430/Hc1HeatCurve:{
     "curve": {"value": 1.00}}
2020.01.05 20:26:00 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.4_5950\000ebusd/430/Hc1HeatCurve\000{\n     "curve": {"value": 1.00}}

Aber schau doch einmal, du hast doch hinter "PUBLSH: " 2 verschiedene Adressen, ich habe immer die "08" und du einmal die "0?" und "0@".

LG

TomLee · 05 Januar 2020, 20:33:48

Ja das ist mir natürlich auch gleich ins Auge gefallen, aber wo such ich jetzt den Grund dafür.

Gruß

Reinhart · 05 Januar 2020, 20:45:28

ich würde einmal die 700 abklemmen und schauen ob dann noch was kommt, dann bist du sicher das diese beiden Werte tatsächlich von der 700 kommen.

LG

TomLee · 05 Januar 2020, 21:48:59

Das kann ich mal machen, aber heute nicht mehr.

Woher soll die (zweite) Antwort aber dann kommen ? Es gibt keine weiteren Geräte auf dem Bus. Es werden ja auch keine anderen .csv wie oben geschrieben geladen. Das ist eine Zentralheizung die VRC ist in der Heizung verbaut.

In diesem Zusammenhang muss ich sagen das mir bis heute nicht klar ist ob und wenn wie man dieses DiA (links im Bild im Anhang, neben der VRC) abrufen kann und die Antwort mglw. auf einmal von diesem Gerät kommen kann , da steig ich bisher nicht durch aber auch nicht wirklich mit beschäftigt, bestimmte Werte würd ich da nämlich gerne auch abgreifen/steuern können.

Gruß

john30 · 06 Januar 2020, 11:14:33

Zitat von: TomLee am 05 Januar 2020, 21:48:59
Woher soll die (zweite) Antwort aber dann kommen ? Es gibt keine weiteren Geräte auf dem Bus. Es werden ja auch keine anderen .csv wie oben geschrieben geladen. Das ist eine Zentralheizung die VRC ist in der Heizung verbaut.

es können definitiv zwei Messages über den Bus laufen: Zum einen der Schreibbefehl mit der neuen Heizkurve und dann der Lesebefehl dazu.
Die Hex Logs sind noch unvollständig. Mache das gleiche bitte nochmal und zeitnah, nachdem Du via MQTT die Heizkurve geändert hast.

Reinhart · 06 Januar 2020, 11:15:57

die Werte im linken Display sind ja Teile aus den "status01" Meldungen.

Code Auswählen


r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
pi@raspberrypi:~ $ ebusctl r -f status01
46.0;37.0;10.812;36.0;44.0;on

Eigentlich kennt ja das Steuergerät diese Werte nur vom Master der sie ihm über den eBus übermittelt um eben dann eine Heizkurve bilden zu können und dann regelnd eingreifen kann.

Ich nehme an, das die 2. Antwort auch vom Steuergerät kommt, aber eben von einem anderen Register. Da der RAW Wert ja schon so formatiert ist, ist hier FHEM oder MQTT2_Server gar nicht im Spiel. Wieso das jetzt nur mit der neuen Version so wäre, ist mir aber nicht logisch.

Da ich über den Vorgänger des Steuergerätes (430) verfüge, kann ich auch deine Doppelmeldungen bei mir nicht nachvollziehen. Es wäre jetzt schön, wenn jemand eine 700er hat und auch MQTT2 einsetzt das nachprüfen könnte ob es hier auch zu den Doppelmeldungen kommt.

Leider wird MQTT2 noch zu wenig verwendet, obwohl das sogar parallel zu ECMD funktioniert und daher die ideale Testumgebung bietet.

LG