eBusd Konfiguration für TEM PS5511 - Arbeitsthread

Begonnen von DS_Starter, 18 Juni 2022, 20:55:57

Vorheriges Thema - Nächstes Thema

DS_Starter

Hallo zusammen,

nachdem mein eBusd schon einige Zeit sehr gut mit meiner Vaillant Heizung zusammenarbeitet, habe ich versucht die ersten Schritte in Richtung Erweiterung für den bei mir vorhandenen Solarregler (Solarthermie) TEM PS551 zu gehen.

Ich schicke voraus, dass ich mir das eBusd Wiki (https://github.com/john30/ebusd/wiki) gelesen habe, aber sehr sehr viele Fragen bzw. Lücken im Verständnis vorhanden sind.

Der aktuelle Stand ist, dass ein

ebusctl scan full

den TEM erkennt. Ein "ebusctl i" zeigt die Info:


version: ebusd 21.1.v21.1-3-g62221bb
update check: version 22.3 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/08.bai.csv: newer version available, vaillant/15.700.csv: different version available, vaillant/52.vr_70.csv: different version available, vaillant/bai.0010007508.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: newer version available, vaillant/scan.csv: different version available, vaillant/service.inc: different version available
access: *
signal: acquired
symbol rate: 49
max symbol rate: 122
min arbitration micros: 1
max arbitration micros: 41
min symbol latency: 6
max symbol latency: 29
reconnects: 0
masters: 4
messages: 662
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010007508.inc" ([PROD='0010007508']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
address f7: master #20
address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878"
address ff: master #25, ebusd


Der erkannte TEM hat die Adresse fc.
Nun habe ich versucht mit


ebusctl grab result


weitere Informationen zu bekommen. Allerdings sehe ich nur Vaillant Messages (b5):


1008b5110100 / 08a8010e001f000000 = 19
10feb510020601 = 4
1008b5120204ff / 00 = 4
1008b513020508 / 00 = 4
1008b5100305ff03 / 00 = 4
1052b5030c0700ffffffffffffffffffff / 0101 = 1


Wie komme ich weiter bzw. welche Schritte fehlen um zu einer Dekodierung zu kommen ?

Ich habe mir schon die Befehlscodes aus dem Modul 70_TEMPS.pm (https://forum.fhem.de/index.php/topic,115377.0.htm) angeschaut, bin jedoch nicht wirklich schlauer geworden wie diese Codes in das Format des eBusd Control umgesetzt werden müssten.

Möglicherweise gibt es noch mehr Interessenten und eine funktionierende Konfigurations-CSV würde eBusd bereichern.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#1
Nun habe ich noch im Konfigurationsverzeichnis /etc/ebusd (ich verwende eine lokale Konfig) die Datei "../tem/fc.ps551.csv" angelegt.
Nach meinem bisherigen Kenntnisstand beginnt der Name mit der Adresse (fc), gefolgt von der ID in Kleinbuchstaben sowie optional weiteren Bestandteilen.

Da TEM so erkannt wird:


address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878"


sollte m.M. nach der Name passen.
Die Datei hat folgenden Inhalt:


# type(r[1-9]wu),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,PS551,PS551,,,,,,,,,,,
*r,PS551,,,,FC,0900,,,,,,,
r,,T_Kollektor_oben,,,,,03A0F502,temp,,,10,°C,


Allerdings wird sie nicht geladen, was mich sehr wundert.
Die erkannten Vaillant Devices werden geladen:


address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010007508.inc" ([PROD='0010007508']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0614;HW=6903", loaded "vaillant/15.700.csv"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0614;HW=6903", loaded "vaillant/ec.sol.sc.csv"
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#2
Heute habe ich zum ersten Mal die folgende Meldung im ebusd Log gefunden:


2022-06-19 02:23:49.826 [update info] received MS cmd: 10fc070400 / 0a10505335353131787878
2022-06-19 02:23:49.826 [update notice] received scan-read scan.fc  QQ=10: TEM;PS551;3178;7878
2022-06-19 03:09:04.878 [update info] received MS cmd: 10fc070400 / 0a10505335353131787878
2022-06-19 03:09:04.879 [update notice] received scan-read scan.fc  QQ=10: TEM;PS551;3178;7878
2022-06-19 03:24:27.117 [update info] received MS cmd: 10fc070400 / 0a10505335353131787878
2022-06-19 03:24:27.117 [bus notice] scan fc: ;TEM;PS551;3178;7878
2022-06-19 03:24:27.119 [update notice] store fc ident: done
2022-06-19 03:24:27.126 [update notice] received scan-read scan.fc  QQ=10: TEM;PS551;3178;7878
2022-06-19 03:24:27.452 [bus info] scan fc cmd: fffcb5090124
2022-06-19 03:24:27.963 [main error] error reading scan config file tem/fc.ps551.csv for ID "ps551", SW3178, HW7878: ERR: missing argument, tem/fc.ps551.csv:4: ERR: missing argument, field type in field 0
2022-06-19 03:24:27.963 [main error] scan config fc: ERR: read timeout


Es deutet auf einen Fehler in der Datei fc.ps551.csv hin.
Allerdings hatte ich die ergänzte Konfiguration geprüft mit:


root@ebusd:/etc/ebusd# ebusd --scanconfig --checkconfig
2022-06-18 16:25:43.862 [main notice] ebusd 21.1.v21.1-3-g62221bb performing configuration check...
2022-06-18 16:25:44.031 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2022-06-18 16:25:44.031 [main notice] ebusd stopped
root@ebusd:/etc/ebusd#


Hier wurden zunächst keine Fehler gemeldet, aber vielleicht habe ich die Verwendung dieses Aufrufs noch nicht richtig verstanden.
Falls jemand am gleichen Thema dran ist bzw. Erfahrungen hat, bitte hier gerne die Infos teilen.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Mittlerweile bin ich schon gut vorangekommen.
Wichtig war die CSV-Datei so zu erstellen, dass sie geladen werden konnte. D.h. die grundlegenden Fehler mussten zunächst bereinigt werden.
Die CSV-Datei habe ich noch in fc.ps551.HW7878.SW3178.csv um die Hardware- und Softwareversion mit zu verknüpfen.

Weiterhin konnte ich die in 70_TEMPS.pm verwendeten RAM-Adressen nicht 1:1 verwenden. Die gelieferten Werte waren inhaltlich nicht sinnvoll. Für meinen TEM PS 5511 S-1 brauchbare RAM-Adressen habe ich in diesem Beitrag (https://www.haustechnikdialog.de/Forum/t/133963/Solar-Regelung-TEM-PS-5511-SZ) gefunden.
Allerdings mussten auch hier LOW und HIGH Byte getauscht werden.

Zur Zeit können somit bereits etliche Daten aus dem TEM gelesen werden.
Der aktuelle Inhalt der CSV ist folgender:


# type (r[1-9];w;u),circuit,name,comment,QQ,ZZ,PBSB,ID,FIELD,part (m/s),type / templates,divider / values,unit,comment
#,PS551,PS551,,,,,,,,,,,
*r,PS551,,,,FC,0900,,,,,,,
r,,TKO,Temp Kollektor oben,,,,0AF502,T,,UIN,10,°C,
r,,TBU,Temp Boiler unten,,,,7AF402,T,,UIN,10,°C,
r,,TPU,Temp Puffer unten,,,,E2F402,T,,UIN,10,°C,
r,,TFK,Temp Zusatzkesselfühler,,,,BAF402,T,,UIN,10,°C,
r,,Q,Solarleistung aktuell,,,,22F502,SOL,,UIN,10,kW,
r,,QTOT,Solarertrag total,,,,24F502,SOL,,UIN,,kWh,passt nicht
r,,PS,Solarpumpe Drehzahl aktuell,,,,62F402,SPEED,,UIN,10,%,
r,,PFK,Zusatzkessel Pumpe Drehzahl aktuell,,,,64F402,SPEED,,UIN,10,%,
r,,PS2,Pumpe unbekannt,,,,3CF402,,,UIN,10,%,unbekannt
r,,MODE,SolarMode,,,,22F402,SOL,,UIN,0=off;1=manual;2=auto,,


Die Daten können auf Shell-Ebene mit dem ebusctl abgerufen werden, z.B.:


root@ebusd:/# ebusctl read -f PS
100.0

root@ebusd:/# ebusctl read -f Q
3.2

root@ebusd:/# ebusctl read -f TKO
70.3

root@ebusd:/# ebusctl read -f TBU
70.1

root@ebusd:/# ebusctl read -f TPU
47.4


Mein eBusd ist bereits per MQTT in FHEM eingebunden. Dadurch wurde automatisch über die MQTT-Bridge ein neues MQTT Device angelegt und die resultierenden Daten als Readings bereitgestellt:


   READINGS:
     2022-06-21 09:58:54   IODev           MQTT_Broker
     2022-06-21 13:43:10   MODE_SOL_value  auto
     2022-06-21 13:50:29   Q_SOL_value     3.2
     2022-06-21 14:39:28   TBU_T_value     70.1
     2022-06-21 13:25:39   TFK_T_value     0.0
     2022-06-21 14:39:24   TKO_T_value     70.3
     2022-06-21 14:39:33   TPU_T_value     47.4
     2022-06-21 09:58:54   subscriptions   ebusd/#
Attributes:
   readingList ebusd_21.1_1:ebusd/PS551/TKO:.* { json2nameValue($EVENT, 'TKO_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/TBU:.* { json2nameValue($EVENT, 'TBU_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/TPU:.* { json2nameValue($EVENT, 'TPU_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/PS:.* { json2nameValue($EVENT, 'PS_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/MODE:.* { json2nameValue($EVENT, 'MODE_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/PS2:.* { json2nameValue($EVENT, 'PS2_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/Q:.* { json2nameValue($EVENT, 'Q_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/P:.* { json2nameValue($EVENT, 'P_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/PTOT:.* { json2nameValue($EVENT, 'PTOT_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/TFK:.* { json2nameValue($EVENT, 'TFK_', $JSONMAP) }
ebusd_21.1_1:ebusd/PS551/PFK:.* { json2nameValue($EVENT, 'PFK_', $JSONMAP) }


Die Daten schickt der TEM aber nicht reglmäßig als Broadcast. Sie müssen aktiv abgerufen werden. Das wird später mit einem at Device erledigt.

Eine Frage an die eBusd Spezialisten bzw. john30 (sofern er hier mitliest).
Wie kann ich am effektivsten den RAM Bereich 0xF400 bis 0xF5FF durchscannen um Speicherinhalte mit relevanten Inhalten zu finden und zuzuordnen ?
Bisher hatte ich festgestellt, dass ich in der CSV-Datei für jede interessiernde RAM-Adresse einen Eintag erstellen musste damit ich sie mit dem Befehl


ebusctl read -f -h ZZPBSBNNDD


auslesen konnte. Ansonsten kam


ERR: element not found


LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Mit dem HEX - Befehl kann man den RAM auslesen ohne eine Definition in der CSV hinterlegen zu müssen, z.B.:

  ebusctl hex fc09000324F502

Damit kann ich nun mit Geduld und Spucke einzelne RAM Bereiche durchscannen und mit vllt. noch den einen oder anderen Wert zuordnen.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Kurzes Update zum Stand.
Ich konnte schon maßgebliche Werte extrahieren und zuordnen. Festgestellt habe ich dass die Verfügbarkeit und die Aktualisierung der Register von der eingestellten Hydraulikvariante und den aktivierten Optionen abhängig ist.
So wird zB. TKR (Solar Rücklauftemperatur) nur aktualisiert wenn man die Option VIG (Volumenimpulsgeber) aktiviert. Das macht das Ganze nicht einfacher.

Der momentane Stand der CSV - Datei für ebusd sieht so aus und passt schon sehr gut:


# type (r[1-9];w;u),circuit,name,comment,QQ,ZZ,PBSB,ID,FIELD,part (m/s),type / templates,divider / values,unit,comment
#,PS551,PS551,,,,,,,,,,,
*r,PS551,,,,FC,0900,,,,,,,
r,,Charging_Target_DeltaTemp_Collector_On,Überhöhung Kollektor zu Ladeziel Ein,,,,18F502,_,,UIN,10,K,
r,,Charging_Target_DeltaTemp_Collector_Off,Überhöhung Kollektor zu Ladeziel Aus,,,,1AF502,_,,UIN,10,K,
r,,Charging_Target,"Aufladung Speicher, Puffer oder Bad",,,,32F501,_,,UCH,1=Buffer;2=Puffer,,
r,,PS_Average_Speed,mittlere Leistung Solarpumpe,,,,1EF502,_,,UIN,10,%,
r,,Buffer_Setpoint_Temperature,Speicher Sollwert Temp.,,,,76F402,_,,UIN,,°C,
r,,Puffer_Setpoint_Temperature,Puffer Sollwert Temp.,,,,D8F402,_,,UIN,,°C,
r,,Operating_Mode,Betriebsmodus,,,,22F402,_,,UIN,0=off;1=manual;2=auto,,
r,,PS_Actual_Speed,Solarpumpe aktuelle Leistung,,,,62F402,_,,UIN,10,%,
r,,PFK_Actual_Speed,Zusatzkessel Pumpe aktuelle Leistung,,,,64F402,_,,UIN,10,%,
r,,TBU_Temperature,Temp Speicher unten,,,,7AF402,_,,UIN,10,°C,
r,,TFK_Temperature,Temp Zusatzkessel,,,,BAF402,_,,UIN,10,°C,
r,,TPU_Temperature,Temp Puffer unten,,,,E2F402,_,,UIN,10,°C,
r,,TKO_Temperature,Temp Kollektor oben,,,,0AF502,_,,UIN,10,°C,
r,,TKR_Temperature,Temp Kollektor Rücklauf,,,,50F502,_,,UIN,10,°C,
r,,Solar_Actual_Power,Solarleistung aktuell,,,,22F502,_,,UIN,10,kW,
r,,Solar_Total_Yield,Solarertrag total,,,,26F502,_,,UIN,,kWh,
r,,PS_Operating_Hours,Betriebsstunden Solarpumpe,,,,28F502,_,,UIN,,h,
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#6
Ich habe einen Stand erreicht der für meine Zwecke zunächst ausreicht.
Für die einfache Nachnutzung bzw. Weiterentwicklung habe ich die Datei fc.ps551.HW7878.SW3178.hv4.csv (hv4 = Hydraulik Variante 4) in meinem contrib im Verzeichnis ebusd/tem bereitgestellt.

Vielleicht gelingt es mir später noch weitere Parameter zu identifizieren, z.B. die eingestelle Hydraulikvariante. Dann wäre es sicherlich auch möglich entsprechende Varianten der CSV zu erstellen und bei Bedarf zu laden.
Vielleicht kann mich ein TEM Anwender dabei unterstützen.

Da ich MQTT aktivierte habe, wird ein Device automatisch angelegt sobald Werte abgerufen werden.
Zum Abruf verwende ich die folgende at-Definition:


define get.ebus.tem.short at +*00:00:27\
set MQTT_Broker publish ebusd/PS551/TKO_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TBU_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TPU_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TFK_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TKR_Temperature/get;;           \
\
set MQTT_Broker publish ebusd/PS551/PS_Actual_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/PS_Average_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/PFK_Actual_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/Solar_Actual_Power/get;;\
set MQTT_Broker publish ebusd/PS551/Solar_Total_Yield/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target/get;;\
\
set MQTT_Broker publish ebusd/PS551/Buffer_Setpoint_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/Puffer_Setpoint_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target_DeltaTemp_Collector_On/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target_DeltaTemp_Collector_Off/get;;\
set MQTT_Broker publish ebusd/PS551/Operating_Mode/get;;\
set MQTT_Broker publish ebusd/PS551/PS_Operating_Hours/get;;
attr get.ebus.tem.short alias Abruf eBus TEM PS 5511 (kurzes Intervall)
attr get.ebus.tem.short cmdIcon execNow:rc_BACK
attr get.ebus.tem.short disable 0
attr get.ebus.tem.short group eBus Heizung
attr get.ebus.tem.short icon clock
attr get.ebus.tem.short room Haustechnik->eBus
attr get.ebus.tem.short sortby 6
attr get.ebus.tem.short webCmd execNow


Die Bedeutung der Readings ist:


TKO_Temperature                          Temp Kollektor oben                            °C
TBU_Temperature                          Temp Speicher unten                            °C
TPU_Temperature                          Temp Puffer unten                              °C
TFK_Temperature                          Temp Zusatzkessel                              °C
TKR_Temperature                          Temp Kollektor Rücklauf                        °C
Solar_Actual_Power                       Solarleistung aktuell                          kW
Solar_Total_Yield                        Solarertrag total                              kWh
PS_Actual_Speed                          Solarpumpe Drehzahl aktuell                    %
PS_Average_Speed                         mittlere Leistung Solarpumpe                   %
PS_Operating_Hours                       Beteriebsstunden Solarpumpe                    h
PFK_Actual_Speed                         Zusatzkessel Pumpe Drehzahl aktuell            %
Operating_Mode                           Betriebsmodus                                  0=off;1=manual;2=auto
Buffer_Setpoint_Temperature              Speicher Solltemperatur                        °C
Puffer_Setpoint_Temperature              Puffer Solltemperatur                          °C
Charging_Target_DeltaTemp_Collector_On   Überhöhung Kollektor->Speicher für Pumpe an    K
Charging_Target_DeltaTemp_Collector_Off  Überhöhung Kollektor->Speicher für Pumpe aus   K


Der Abruf von TFK_Temperature und PFK_Actual_Speed ist in der Hydraulik Variante 4 nicht sinnvoll, wollte damit jedoch den kompletten aktuelle Arbeitsstand zur Verfügung stellen.

Man kann sicherlich noch einiges ergänzen und verbessern, insbesondere wenn jemand noch tiefer in der ebus(d) und TEM Materie steckt. Aber möglicherweise sind auch andere User an der PS 5511 Integration interessiert und die Vorarbeit hilft.
Später arbeite ich an der Stelle evtl. weiter und bin natürlich immer offen für Hinweise und Ergänzungen !

LG,
Heiko 
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

Hallo Heiko,
ich finds total genial was du hier machst!
Habe mir vor rund zwei Jahren auch den eBus Adapter mit dem Ziel meinen PS5511 einzubinden besorgt, aber bin auf die gleichen Probleme gestoßen wie du. Ebenso habe ich den Haustechnik-Thread gefunden, aber mangels Programmierkenntnis und letztlich auch Zeit habe ich das Ganze nicht zum Laufen gebracht und dann einschlafen lassen.
Jetzt kann ich es kaum erwarten den Aufbau wieder heraus zu kramen und mit deinen neuen Erkenntnissen nochmal versuchen, es zum Laufen zu bekommen.  :)
Danke schon mal für deine Arbeit und viele Grüße!
Matthias

DS_Starter

#8
Hallo Matthias,

na dann sind wir schon zwei Kämpfer mit PS 5511  :)

Ich habe noch etwas weiter gemacht und eine aktualisierte Datei ins contrib geladen.

Die aktuelle Readingbedeutung:


TKO_Temperature                          Temp Kollektor oben                            °C
TBU_Temperature                          Temp Speicher unten                            °C
TPU_Temperature                          Temp Puffer unten                              °C
TFK_Temperature                          Temp Zusatzkessel                              °C
TKR_Temperature                          Temp Kollektor Rücklauf                        °C
Solar_Actual_Power                       Solarleistung aktuell                          kW
Solar_Total_Yield                        Solarertrag total                              kWh
PS_Actual_Speed                          Solarpumpe Leistung aktuell                    %
PS_Average_Speed                         mittlere Leistung Solarpumpe                   %
PS_Operating_Hours                       Betriebsstunden Solarpumpe                     h
PFK_Actual_Speed                         Zusatzkessel Pumpe Drehzahl aktuell            %
Operating_Mode                           Betriebsmodus                                  off / manual / auto
Buffer_Setpoint_Temperature              Speicher Solltemperatur                        °C
Puffer_Setpoint_Temperature              Puffer Solltemperatur                          °C
Charging_Target                          aktuelles Ladeziel                             Buffer / Puffer
Charging_Target_DeltaTemp_Collector_On   Überhöhung Kollektor->Ladeziel für Pumpe an    K
Charging_Target_DeltaTemp_Collector_Off  Überhöhung Kollektor->Ladeziel für Pumpe aus   K
Possible_LoadingTarget                   mögliche Ladeziele je nach Hydraulikschema     true / false
RadiationSensor_Option                   Option Strahlungssensor gesetzt                true / false
VIG_Option                               Option Volumenimpulsgeber gesetzt              true / false



Noch etwas zu meiner Umgebung. Ich spreche den ebus V3 Adapter mit dem ebusd Daemon aus einem Docker Container meiner Synology an. Gestartet ist ebusd mit den Optionen:


ebusd -f --enablehex --enabledefine --scanconfig --configlang=de --configpath=/etc/ebusd --accesslevel=* -d enh:192.168.2.216:9999 --loglevel=info --latency=20 --address=ff --mqttport=1883 --mqttjson --mqtthost=192.168.2.46 --mqtttopic=ebusd/%circuit/%name",


Du siehst ich benutze eine lokales Konfigurationsverzeichnis "/etc/ebusd". Das ist im Docker gemapt auf ein Volume der Synology. Dadurch kann ich die Konfiguration sehr einfach ablegen.
Die von mir erstellte Datei legt man einfach ab in dem Verzeichnis "/etc/ebusd/tem".

Wird ebusd gestartet oder die Konfig mit "ebusctl reload" neu geladen, muß der TEM erkannt und die csv geladen werden.
Ein "ebusctl i" sollte dann zeigen (dauert u.U. einige Zeit):


address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878", loaded "tem/fc.ps551.HW7878.SW3178.hv4.csv"


Im FHEM passiert dann noch nichts. Erst wenn die Daten aktiv abgerufen werden kommen Readings (bei mir steht die MQTT Kommunikation bereits). Den Abruf mache ich mit einem einfachen at-Device:


defmod get.ebus.tem.short at +*00:00:27\
set MQTT_Broker publish ebusd/PS551/TKO_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TBU_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TPU_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TFK_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TKR_Temperature/get;;           \
\
set MQTT_Broker publish ebusd/PS551/PS_Actual_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/PS_Average_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/PFK_Actual_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/Solar_Actual_Power/get;;\
set MQTT_Broker publish ebusd/PS551/Solar_Total_Yield/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target/get;;\
\
set MQTT_Broker publish ebusd/PS551/Buffer_Setpoint_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/Puffer_Setpoint_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target_DeltaTemp_Collector_On/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target_DeltaTemp_Collector_Off/get;;\
set MQTT_Broker publish ebusd/PS551/Operating_Mode/get;;\
set MQTT_Broker publish ebusd/PS551/PS_Operating_Hours/get;;\
\
set MQTT_Broker publish ebusd/PS551/Possible_LoadingTarget/get;;\
set MQTT_Broker publish ebusd/PS551/VIG_Option/get;;\
set MQTT_Broker publish ebusd/PS551/RadiationSensor_Option/get;;
attr get.ebus.tem.short alias Abruf eBus TEM PS 5511 (kurzes Intervall)
attr get.ebus.tem.short cmdIcon execNow:rc_BACK
attr get.ebus.tem.short disable 0
attr get.ebus.tem.short group eBus Heizung
attr get.ebus.tem.short icon clock
attr get.ebus.tem.short room Haustechnik->eBus
attr get.ebus.tem.short sortby 6
attr get.ebus.tem.short webCmd execNow


Wenn du einen PS 5511 S-1 hast, sollte es schon passen. Wenn es eine anderere Variante ist muß man u.U. wieder auf die Suche nach den Speicheradressen gehen.
Aber wenn du es bei dir am Laufen hast, zeige ich dir auch gerne wie ich vorgehe um die Werte zu suchen. Es ist ja noch einiges zu erforschen ...

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

#9
Hallo Heiko,
danke für deine lange Antwort.
Zunächst schreib ich auch noch mal ein bisschen was über mich, da ich ja neu hier bin: Ich bin E-Techniker, komm aber mehr aus der Hardware- als aus der Software-Ecke.
Einen Raspberry im Keller habe ich schon ewig (seit dem Studium) und hab damit angefangen, Wasser- und Stromzähler "analog" mit einer Reflexlichtschranke und einem Arduino auszulesen, und an den Raspberry die Werte mit Impulsen zu übermitteln. Gespeichert wurden die Impulse via Python Skript in einer .csv Datei, welche dann ein Java-Skript visualisiert hat. ;D Lang ists her.

Dann begann aber das Berufsleben mit 40h-Woche und es kamen Kinder, was die Zeit für solche Spielereien arg dezimierte...
Was noch folgte waren die Integration von Gaszähler (Reed via Arduino), Umstellung auf einen digitalen Stromzähler (IR-Kopf), und ein Wärmemengenzähler (ebenfalls IR) sowie einige DS18B20 Sensoren an der Heizungsanlage.
Erfolglos blieben Versuche mit der Gastherme (die hätte eine OpenTherm Schnittstelle, ich hab aber keine Kommunikation hinbekommen) sowie eben mit dem Solarregler...
Softwaremäßig habe ich es auch noch ein wenig auf neueren Stand gebracht: Das Auslesen übernehmen immer noch diverse Python-Skripte, aber geschrieben wird das ganze in eine Influx Datenbank und visualisiert mit Grafana...
Mit FHEM gab es auch mal einen Anlauf, aber am Ende blieb ich bei meiner Lösung mangels Zeit und getreu dem Motto "never change a running system"  ;)

So viel zur Vorgeschichte. Nun zum Regler.
Ich habe gestern natürlich gleich noch ein wenig probieren müssen, und ich bin so weit gekommen, dass er mir antwortet. Also die Zeile
address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878",
habe ich empfangen. Als nächstes steht jetzt dann die Abfrage der Werte an. Ich werde also a) erstmal abrufen welche Hydraulikvariante ich habe b) deine config einspielen und c) dann versuchen abzufragen.
Ich muss zugeben mir sagt der "Docker Container" nichts und auch weiß ich nicht was eine Synology ist. Aber ich denke was bei dir die Synology ist, ist bei mir eben der Pi.
Und bei dir läuft die Abfrage übers Netzwerk/IP, und bei mir "direkt" über den ebus-Adapter bzw. dessen USB-Seriell Chip...
Mal schauen wann ich dazu komm, hoffentlich bald.  ;)

Eine Frage hätte ich noch: Du schreibst
ZitatWenn du einen PS 5511 S-1 hast, sollte es schon passen.
. Wie kann ich denn herausfinden, ob ich die Version S-1 oder eine andere hab?
Danke dir und viele Grüße!
Matthias

DS_Starter

Hallo Matthias,

Zitat
address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878",

Die csv muss aber auch geladen werden, also der rote Teil

   address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878", loaded "tem/fc.ps551.HW7878.SW3178.hv4.csv"

darf bei der Anzeige von "ebusctl i" nicht fehlen.

ZitatWie kann ich denn herausfinden, ob ich die Version S-1 oder eine andere hab?
Steht oben auf dem Typenschild.  ;)

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

Hallo Heiko,
heute habe ich mich wieder ein wenig damit beschäftigt und das configfile angepasst. Jetzt zeigt es mir auch die Zeile richtig an:
address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878", loaded "tem/fc.ps551.HW7878.SW3178.hv4.csv"
Allerdings kann ich immer noch keine Werte auslesen. Ich muss aber auch dazu sagen, dass bei mir "Hydraulikvariante 1" eingestellt ist, und auf dem Typenschild nur "PS 5511 S", ohne der -1 steht, vielleicht liegt es daran...
Aus der Log-Datei werde ich nicht wirklich schlau, ich hab sie mal angehängt.
Dort finde ich zwar schon eine Zeile 2022-07-01 16:01:04.274 [main notice] found messages: 18 (0 conditional on 0 conditions, 0 poll, 0 update), aber Abfrage wie ebusctl read -f TKO werden weiterhin mit ERR: element not foundquittiert...
Viele Grüße!
Matthias

DS_Starter

Das sieht doch schon gut aus.

Der Abruf erfolgt so:


ebusctl read -f TKO_Temperature


Du nimmst als Argument den String der in der CSV in der Spalte "name" hinterlegt ist.

Hydraulikvariante 1 kann ich bei mir simulieren wenn nötig.
Probiere erstmal aus ob es prinzipiell geht und ob die Werte sinnvoll sind die du bekommst.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

Ah, während ich schrieb hast du geantwortet.
Der Abruf
ebusctl read -f TKO_Temperature
gibt bei mir 0.0 zurück.

ABER jetzt zu meinem eigentlichen Post:
Es scheint aber nur noch eine ganz kleine Sache im Code zu sein. Denn wenn ich die Werte "händisch" Abfrage bekomme ich sie.
pi@strompi2gen:~ $ ebusctl hex FC0900033EF502
023c01
pi@strompi2gen:~ $ ebusctl hex FC090003A0F502
02c000

Die 31.6° für den Puffer bzw 19.2° für den Kollektor passen. Welch Freude!  :D

mr_86

Ah, ich habs selbst entdeckt!
Für mich sind schon die Adressen die in der 70_TEMPS hinterlegt sind die richtigen!  :D
Es läuft! Hurra und danke für deine/eure Arbeit nochmal!
Ich meld mich dann auch nochmal und geb Bescheid welche Werte mein Regler alle preisgibt.
Viele Grüße und schönen Abend!

DS_Starter

 :)

Ja die geänderten Speicheradressen können wir sehr wahrscheinlich auf die Version S statt S-1 zurückführen.
Vielleicht aber auch die Koppelart IP vs. USB, kann ich nicht sagen. Vllt. wissen es die Entwickler des ebus Adapters.

Du müsstest also die CSV anpassen und statt "0AF502" die "A0F502" eintragen.
Bei den anderen Adressen wird es vemutlich auch so sein. Teste es mal.
Aber das ist doch schonmal was.  8)

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

Ja, haut hin: Die hinterlegten Adressen für TKO, TBU, PS, Q und Q_total liefern jetzt die richtigen Werte und ich freue mich wie ein Schnitzel. Ich denke recht viel mehr wird bei meiner "Minimalkonfiguration" nicht zu holen sein, aber brauche ich eigentlich auch nicht. Die Werte die das Kästchen anzeigt wollte ich eben auch am Rechner haben und das haben wir geschafft.
Wenn ich mal Zeit habe werde ich trotzdem noch ein bisschen mit den Adressen spielen und schauen ob ich noch was Sinnvolles finde. Würde mich z.B. wundern wenn die Betriebsstunden nicht auch irgendwo rauszulesen sind und der Wert ist ja auch recht gut rückwärts zu erschließen...
Viele Grüße und schönes Wochenende!
Matthias

DS_Starter

#17
Betriebsstunden sind bei mir unter "PS_Operating_Hours" mit der Adresse "28F502" zu finden.

Dir auch ein schönes WE und noch viel Spaß beim suchen.  :)

PS: ... aktuellste CSV aus meinem contrib vorausgesetzt..
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

Hallo Heiko,

du hast ja geschrieben, dass das Haustechnik-Forum dein Ausgangspunkt für die bei dir korrekten Adressen war. Mittlerweile hast du aber viele mehr in deiner Konfiguration. Darf ich fragen, wie du auf die gestoßen bist? Das kann ja kaum alles Trial and Error sein, oder?

Und in dem Zusammenhang, auch ganz wichtig: Bevor ich munter Hex-Codes an meine Steuerung feuere, sind das eigentlich reine Abfragen oder kann das auch ein Schreibbefehl sein, also könnte ich mir damit was verstellen oder gar zerschießen?

Neben den erwähnten Gesamtbetriebsstunden fände ich noch einen eventuell vorliegenden Fehlercode interessant auszulesen. Denn meine alte Pumpe streikt manchmal bei hohen Temperaturen/hohem Druck mit dem Wiederanlaufen...

Viele Grüße
Matthias




DS_Starter

Hallo Matthias,

Zitat
Mittlerweile hast du aber viele mehr in deiner Konfiguration. Darf ich fragen, wie du auf die gestoßen bist? Das kann ja kaum alles Trial and Error sein, oder?

Momentan gehe ich davon aus, dass die interessanten Speicheradressen sich im Bereich 00F4 bis FFF5 befinden.
Möglicherweise sind es noch andere Stellen, mir aber momentan unbekannt.

Um jetzt einen bestimmten Zusammenhang zu finden, stelle ich am TEM zunächst einen markanten Wert ein um danach suchen zu können.
Nehmen wir als Beispiel einen hypothetischen Wert von 20,8.
Können die Parameter eine Nachkommastelle enthalten, wäre der zu suchende Wert 208 und nicht 20,8 (also mit 10 multipliziert).
Diesen Wert von 208 rechne ich in Hex um, ergibt  00d0 (Highbyte/Lowbyte).
Jetzt muß man High-Byte und Low-Byte tauschen, daraus ergibt sich als Suchmuster d000.

Auf Betriebssystemebene lese ich nun gleich mehrere Bytes aus um voran zu kommen und suche mit einem grep nach dem Muster:

ebusctl hex fc09000300F410 | grep d000
 
bringt zum Beispiel als

  0ed0007040f000847c0000e3eb000
 
Das erste Byte vorn (0e) zeigt nur die Anzahl der insg. gelieferten Bytes und wird ignoriert.
Aber die ersten Adressen gleich danach (00F4 , 2 Bytes) bringen das Suchmuster d000.
Jetzt schaue ich mir die genauer an und rufe ab:

ebusctl hex fc09000300F402

und es kommt

02d000

Nun ändere ich am TEM den verdächtigen Paramter und wiederhole den letzten Abruf um zu schauen ob die Änderung wie erwartet
mitläuft. Wenn es so ist, gehe ich stark davon aus einen Treffer gelandet zu haben. Ansonsten muß man weitersuchen.
Ich habe mir eine Liste erstellt die ich nach und nach fülle um Treffer und Versuche zu dokumentieren und so immer
einfacher voranzukommen. Immer dran denken dass High-Byte und Low-Byte vertauscht sind.

Manche Werte habe ich noch nicht entdeckt. Sie sind vielleicht an anderer Stelle oder entziehen sich meiner Vorgehensweise.
Vielleicht ist in diesen Fällen der Wert anders kodiert, what ever ...

Wenn ich einen neuen Wert dann gefunden habe, ist er nur noch in die CSV Datei nach dem Schema einzupflegen welches im eBusd Wiki beschrieben ist. Ich bin da auch noch nicht soooo firm, es gibt Optimierungsmöglichkeiten.

Schwierig ist es natürlich einen Wert mit 0 zu finden, zumal wenn man ihn nicht manuell ändern kann wie bei dem Fehlercode, welcher natürlich sehr interessant wäre. Aber wenn du öfters mal einen Fehlerwert hast, besteht ja durchaus die Chance.

Zitat
Und in dem Zusammenhang, auch ganz wichtig: Bevor ich munter Hex-Codes an meine Steuerung feuere, sind das eigentlich reine Abfragen oder kann das auch ein Schreibbefehl sein, also könnte ich mir damit was verstellen oder gar zerschießen?

Mit dem Befehl (fc)0900 werden RAM Adressen ausschließlich gelesen nicht geschrieben.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mr_86

Hut ab, dann isses ja wirklich trial and error.  :D Aber mit System, nochmal großen Respekt vor deiner Arbeit!
Und auch gut zu wissen, dass es read-only ist.

Da bei den bei mir funktionierenden fünf Abfragen zwei der drei Byte (..F502) immer gleich sind, beschränkt sich der Bereich den ich durchscannen werde erstmal auf 256 Adressen. Die Ergebnisse werde ich mir dann abspeichern und schauen, ob es im Fehlerfall dann den Wechsel von Dezimal 0 auf 1 (Es ist immer Fehler 1: Kein Wärmeanstieg im Puffer trotz Ansteuerung, da Pumpe nicht dreht) stattfindet.

Viele Grüße
Matthias

pc1246

Zitat von: DS_Starter am 29 Juni 2022, 19:22:27

Noch etwas zu meiner Umgebung. Ich spreche den ebus V3 Adapter mit dem ebusd Daemon aus einem Docker Container meiner Synology an. Gestartet ist ebusd mit den Optionen:


ebusd -f --enablehex --enabledefine --scanconfig --configlang=de --configpath=/etc/ebusd --accesslevel=* -d enh:192.168.2.216:9999 --loglevel=info --latency=20 --address=ff --mqttport=1883 --mqttjson --mqtthost=192.168.2.46 --mqtttopic=ebusd/%circuit/%name",


Du siehst ich benutze eine lokales Konfigurationsverzeichnis "/etc/ebusd". Das ist im Docker gemapt auf ein Volume der Synology. Dadurch kann ich die Konfiguration sehr einfach ablegen.
Die von mir erstellte Datei legt man einfach ab in dem Verzeichnis "/etc/ebusd/tem".


Moin Heiko
Ich weiss, dass meine Frage eigentlich nichts mit Deinem Thread hier zu tun hat!
Ich bin ueber google suche auf diesen Thread/post hier gestossen.
Mein Problem ist immer wieder wie ich eine Anleitung einen Docker-Container zu starten auf Synology umsetzen soll. Insbesondere der DSM-Wechsel ist auch nicht immer verstaendlich, da Synology da gerne mal etwas an andere Stellen schiebt, oder auch gar umbenennt.
Magst, kannst Du (mir) bitte kurz zeigen, wie man das auf der Synology einstellen muss, damit man den Container zum Laufen bekommt!?
Danke und Gruss
Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

DS_Starter

Nabend Christoph,

ist alles angekommen und klappt ?

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

pc1246

Moin Heiko
Nachdem ich noch Tage damit verbracht habe docker zu verstehen, bei mir ist Port 9000 leider belegt.
Laeuft es jetzt fast. Habe mir jetzt auch portainer als Container installiert, das macht es etwas einfacher!
Danke und Gruss
Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

DS_Starter

Moin,

ZitatHabe mir jetzt auch portainer als Container installiert...
Gut dass du das erwähnst... hatte ich auch noch vor und wieder verdrängt.  :o

Schönes WE,
LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

PCMichi

Guten Abend zusammen,

ich habe bei mir Zuhause auch eine PS 5511, allerdings in der Version: "PS5511S-3.2". Somit habe wir alle drei verschiedene Versionen der Steuerung oder?

Bei mir ist die Hydraulik Variante 1 aktiv.

Ich versuche auch schon lange, die Werte per eBus auszulesen. Nachdem ich diesen Eintrag durchgelesen habe, bekomme ich schon mal eBus Meldungen an meinem Raspi (habe auch den eBus Adapter V3.0).

Leider bekomme ich mit den bekannten RAM-Werte bei mir keine oder falsche Angaben (vermute ich), hier ein Beispiel vom TKO Wert:

Temperatur laut Display: 2 Grad

Ich habe folgende Varianten probiert:

TKO-Adresse von DS_Starter:
root@pi-test:/# ebusctl hex FC0900030AF502
020000


TKO-Adresse von der Datei 70_TEMPS.pm.txt

root@pi-test:/# ebusctl hex FC090003A0F502
020000


TKO-Adresse aus der Datei wrsol.pdf (https://ebus-wiki.org/lib/exe/fetch.php/ebus/wrsol.pdf / https://www.haustechnikdialog.de/Forum/t/133963/Solar-Regelung-TEM-PS-5511-SZ)
root@pi-test:/# ebusctl hex FC0900031CF502
02e33e
root@pi-test:/# ebusctl hex FC090003F51C02
029e7c



Leider verstehe ich die Anleitung von DS_Starter mit dem Finden der richtigen RAM-Werte nicht. Ich hänge bei der Aussage:
ZitatDas erste Byte vorn (0e) zeigt nur die Anzahl der insg. gelieferten Bytes und wird ignoriert.
Aber die ersten Adressen gleich danach (00F4 , 2 Bytes) bringen das Suchmuster d000.
Jetzt schaue ich mir die genauer an und rufe ab:

0e finde ich noch in dem Beispiel, aber die ersten Adressen 00F4 nicht mehr?

Wenn ich "ebusctl hex fc09000300F410" ausführe, dann bekomme ich diese Ausgabe:

root@pi-test:/# ebusctl hex fc09000300F410
0e00f700000000a98b000930fc6cfc

root@pi-test:/# ebusctl hex fc09000300F410
0e00f700000000a9eb010930fc6cfc

root@pi-test:/# ebusctl hex fc09000300F410
0e00f700000000a964000930fc6cfc


Kann man eventuell mal eine Ausgabe aller RAM-Werte machen und so den Wert suchen?

Vielleicht könnt ihr mir hier ein bisschen helfen.

Vielen Dank schon einmal und Grüße
Michael

mr_86

Hallo Michael,
zunächst sorry dass so lange keine Antwort kam, aber ich hab keine Mail-Benachrichtigungen aktiv und schau hier eher sporadisch rein. Da mir hier so nett geholfen wurde, werde ich es auch versuchen:

Zur Deutung der Werte: Es sieht wirklich so aus, als wären deine Adressen andere, denn die ausgespuckten Werte entsprechen keinen realistischen Temperaturwerten.
Da du die Erläuterung von Heiko/DS_Starter nicht verstanden hast, werde ich es nochmal mit meinen Worten anhand eines deiner Beispiele probieren:

root@pi-test:/# ebusctl hex FC0900031CF502
02e33e


Der Rückgabewert besteht aus drei Byte: 02, e3 und 3e.
02 ist wie Heiko schon beschrieben hat die Länge der Daten. Also zwei Byte.
Damit verbleiben für den eigentlichen Wert die beiden Byte e3 und 3e. Die Reihenfolge ist zu tauschen, also 3ee3.
In einen HEX-DEC Konverter reingeworfen ergibt sich ein Wert von 16099. Den Wert noch durch 10 teilen und du hättest deine Temperatur. Aber wie gesagt: 1609,9°C: Unrealistisch. ;-)

Nun das ganze noch Mal von hinten aufzäumen: Du sagst, du hast eine Temperatur von 2 Grad abgelesen und würdest die gerne in deinen Rückgabewerten suchen. Also los:
2 Grad auf dem Display entspricht dem Wertebereich 2,0 bis 2,9 Grad im Regler. Es kann also leider einer dieser zehn Werte sein, nicht nur einer. 2,0 bis 2,9 gibt 20 bis 29 im Dezimalen oder 14 bis 1D in Hex. Nun noch auf zwei Bytes erweitern und diese tauschen ergibt 1400 bis 1D00. Das heißt bei 2 Grad im Display suchst du nach einer der folgenden zehn Antworten:
021400
021500
021600
021700
021800
021900
021A00
021B00
021C00
021D00

So besser verständlich?

ZitatKann man eventuell mal eine Ausgabe aller RAM-Werte machen und so den Wert suchen?
Dazu habe ich mir ein Skript geschrieben. Es fragt die Adressen FC09000300F502 bis FC090003FFF502, ab. Ich habs mal angehängt, ebenso eine Datei mit den Antworten meines Reglers.

Die Spaltenüberschriften  in dieser Datei bedeuten:

DECIMAL: Dezimalwert der abgefragten Adresse
Bekannt?: Falls der Wert zugeordnet ist, steht hier sein Name
HEX: Der Hexadzimalwert der Adresse von 00 bis FF
response1: Die zwei Byte von Interesse
response rigth order: Die Bytes getauscht
decimal.1: Die Bytes in Dezimalwert umgerechnet
response: Nochmal die zwei Byte von Interesse(? weiß grad nimmer warum)
response2: Eine Antwort einer zweiten Abfrage an einem anderen Tag
response3: Eine Antwort einer dritten Abfrage an einem anderen Tag
response4: Eine Antwort einer vierten Abfrage an einem anderen Tag

Vielleicht hilfts, viele Grüße!
Matthias

any

#27
Hi zusammen :)

Ich habe einen PS5510 S-1 in der Software Version 1.00 vom 27.04.1999 (dieser war bereits vorhanden als ich eingezogen bin). Weiter Unterlagen dazu habe ich leider nicht.
Gestern habe ich einen ebus Adapter (Ethernet Variante von ebusd) angeschlossen, leider zeigt dieser aber kein Signal am E-Bus an und die grüne LED leuchtet durchgängig, ebusctl zeigt:


root@domoticz:~# ebusctl i
version: ebusd 23.1.23.1
update check: OK
device: 10.0.0.25:9999, enhanced, firmware 1.1[8419].2[847f]
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning


Muss der E-Bus noch irgendwie aktiviert werden? In den Einstellungen habe ich leider nichts gefunden. Angeschlossen ist der E-Bus Adapter an den Pins 1 und 2 am PS5511 (Klemmleiste X2).
Hat jemand eine Idee?


Danke und viele Grüße
Martin

DS_Starter

#28
Hallo Martin,

am TEM musst du nichts aktivieren.
Der eBusd muss beim scannen den TEM finden. Hast du die Polung (+-) beachtet ?

EDIT: Habe das Manual angehängt falls du es brauchst (weil du keine Unterlagen zum Gerät hast).

Grüße,
Heiko


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

any

Hallo Heiko,

vielen Dank für deine Antwort. Ich hatte heute morgen auch eine Rückmeldung von TEM erhalten, angeblich hat der PS5510 S1 (nicht PS5511) keinen E-Bus,
auch wenn die entsprechenden Klemmen sowie die Buchse an der Frontseite vorhanden sind. Ein vorhin gefundenes Handbuch (siehe Anhang) für den PS5510 S1 zeigt allerdings
ebenfalls, dass ein E-Bus vorhanden sein müsste *sigh* Ich bin mir aktuell unsicher, was jetzt richtig ist. Ich messe zwischen den PINs 1 und 2 auf dem Klemmfeld X2
jedoch auch keine Spannung und diese müsste - soweit ich das verstehe - ja eigentlich anliegen, der LOW-Pegel soll sich ja irgendwo bei 9V bewegen.

Danke und viele Grüße
Martin

iviurx

#30
Hallo zusammen!

Erstmal vielen Dank für Eure grandiose Vorarbeit!

Ich habe vergangene Woche meinen eBus3-Adapter für den RasPi in Betrieb genommen.
Ich hatte vorher noch nie was mit ebus oder überhaupt Heizungssteuerung am Hut. Ich dachte, das funktioniert einfach so ... jaja ... die Lacher hab ich mir verdient ;)

Ich habe hier eine TEM PS5511SZ
Leider passen bei mir die ausgelesenen Werte nicht mal ansatzweise. ... von jedweden Adressen, die ich gefunden habe ... von TEM PS5511-S1, über TEM PS5511-S3x bis WSOL (Weißhaupt). Nichts ergibt Sinn.

So habe ich mich nun heute erstmal hingesetzt und folgendes bash-script gestrickt:
nachträglicher Hinweis: aktualisierte und erweiterte Version im Post #39
#!/bin/bash

for (( hi=16#f4; hi<=16#f5; hi++ )) do
  for (( lo=16#00; lo<=16#ff; lo=lo+16 )) do
    printf '%02x%02x     ' $hi $lo
    ebuscommand0=$(printf 'ebusctl hex fc090003%02x%02x08' $lo $hi)
    ebuscommand8=$(printf 'ebusctl hex fc090003%02x%02x08' $(($lo+8)) $hi)
    octet0=$($ebuscommand0)
    octet8=$($ebuscommand8)
    printf ${octet0:2:2}' '${octet0:4:2}' '${octet0:6:2}' '${octet0:8:2}' '${octet0:10:2}' '${octet0:12:2}' '${octet0:14:2}' '${octet0:16:2}'     '
    printf ${octet8:2:2}' '${octet8:4:2}' '${octet8:6:2}' '${octet8:8:2}' '${octet8:10:2}' '${octet8:12:2}' '${octet8:14:2}' '${octet8:16:2}'\n'
  done
done

Ja, das geht noch schicker ;) ... Aber zumindest liefert es mir erstmal folgende Ausgabe:
f400     00 f7 00 00 00 00 3b 00     00 09 30 fc 6c fc 03 03
f410     06 06 00 00 ff 00 c0 00     e0 5f d0 00 42 62 00 00
f420     00 00 00 00 00 00 02 00     02 00 20 00 20 00 20 00
f430     20 00 ab 00 ff ff af 00     ff ff ab 01 ff ff ab 01
f440     ff ff 00 00 03 03 00 00     9d 10 20 01 67 16 22 00
f450     01 18 9a 10 20 01 67 16     22 00 01 18 9b 10 20 01
f460     67 16 22 00 01 18 9c 10     20 01 67 16 22 00 01 18
f470     9c 10 20 01 67 16 22 00     01 18 ff 00 01 00 20 00
f480     00 00 00 04 00 00 43 fe     39 8b f9 99 9c ac 41 fe
f490     c7 a9 f8 da 00 00 02 00     30 41 70 00 02 60 00 00
f4a0     bf 11 00 00 00 00 30 41     30 00 00 00 00 00 00 00
f4b0     e8 03 e8 03 26 81 10 00     01 00 02 00 00 0a 00 00
f4c0     00 00 03 00 ce d6 00 00     00 00 2d 00 01 00 56 04
f4d0     12 00 00 00 00 00 00 00     00 00 00 00 00 00 01 00
f4e0     00 8d 00 02 00 00 21 d7     31 d7 02 00 00 00 01 00
f4f0     00 00 00 00 00 00 00 00     00 00 00 00 00 00 00 01
f500     6c 68 69 0a 00 00 00 00     00 00 00 00 00 00 00 00
f510     00 00 00 00 00 00 00 00     00 00 09 00 ef 35 0f 01
f520     07 fe 01 00 ff fd 00 00     00 00 ff ff 32 32 00 00
f530     1a 1e b0 00 00 00 00 80     00 00 00 00 3c 00 14 14
f540     c8 00 00 00 c8 00 00 00     00 00 00 00 00 00 00 00
f550     00 00 00 00 00 00 00 00     00 00 00 00 00 00 00 00
f560     00 00 00 00 00 00 ff ff     00 00 00 00 00 00 00 00
f570     f0 00 00 00 00 80 00 00     00 00 1e 00 14 14 c8 00
f580     00 00 00 00 00 00 00 00     00 00 00 00 00 00 00 00
f590     00 00 00 00 c0 00 00 00     00 80 00 00 00 00 46 00
f5a0     2d 27 53 00 a8 fd a8 fd     c7 01 8b 01 00 00 49 01
f5b0     3e 01 00 00 00 00 00 00     00 00 00 00 00 00 00 00
f5c0     00 00 00 00 00 00 00 00     b0 04 00 00 64 00 b0 04
f5d0     53 00 86 01 bc 02 02 01     00 00 00 00 24 00 3c 00
f5e0     1e 00 00 00 00 00 00 00     00 00 a2 03 00 00 00 00
f5f0     4f 00 00 00 86 01 bc 02     02 01 00 00 00 00 22 00

... und bei Mehrfachdurchlauf kann ich sogar schnelle Änderungen in den Daten sehen. Das sind dann schon mal keine Einsteller und wahrscheinlich auch keine Temperaturwerte.

Als nächstes will ich die Daten mal über einen Zeitraum X sammeln und jeden Abfragelauf in eine Datei schreiben lassen. Da soll dann ein script drüber rennen und jeweils eine Maskendatei erzeugen: Variablen, Konstanten.
Danach kann ich mal anfangen an den Einstellern zu drehen. Wenn sich dann ein "Konstante" ändert, weiß ich, wo sie sitzt.

Zwei Fragen sind mir im Moment noch offen:
1. Lese ich mit F400 bis F5FF den richten Speicherbereich aus?
2. Woher wisst Ihr den Speicherbereich?
Solarladeregler: TEM PS5511SZ (Firmware V.2.20 Feb604 513807)
RasPi3 mit ebus3-Modul: Debian BullsEye mit ebusd aus Repository
Datenübertragung per MQTT an ioBroker auf einer Synology
# Ich habe KEIN fhem im Einsatz

DS_Starter

ZitatZwei Fragen sind mir im Moment noch offen:
Ich fange mal mit der zweiten an.

Zitat2. Woher wisst Ihr den Speicherbereich?
Ich habe im Internet recherchiert und im Hausdialog.de (Beitrag #3) einen Anhaltspunkt gefunden um damit zu starten.
An TEM hatte ich übrigens eine Anfrage nach eBus-Unterlagen gestellt, wurde aber abgeweisen mit der Begründung dass diese Unterlagen nicht veröffentlicht werden.

Zitat1. Lese ich mit F400 bis F5FF den richten Speicherbereich aus?
Das weiß ich nicht, möglicherweise sind es andere.

Ich hatte die RAM-Adressen in diesem Beitrag (https://www.haustechnikdialog.de/Forum/t/133963/Solar-Regelung-TEM-PS-5511-SZ) gefunden.
Allerdings musste ich die dort angegebenen LOW und HIGH Byte tauschen. Möglicherweise kannst du bei einem PS5511SZ die Adressen genau so benutzen wie in dem Beitrag beschrieben (also ohne Tausch LOW und HIGH Byte).


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

iviurx

#32
Hi DS_Starter,

Danke für den Rückmeldung. Den Thread kannte ich zwar schon, habe aber nochmals experimentiert: Leider ohne Erfolg.
Für TKO (Temperatur Kollektor Oben) erhalte ich entweder auf Adresse F50A nur "0.0" oder auf F5A0 völlig irre, sich ändernde Werte:
[bus info] send message: 31fc090003a0f502
[update info] sent MS cmd: 31fc090003a0f502 / 023021
[update notice] sent read PS551 TKO QQ=31: 849.6
[main info] read PS551 TKO: 849.6


Ich hatte schon vermutet, dass das eventuell die Widerstandswerte der Sensoren sein könnten, welche ich erst gemäß Tabelle im Handbuch umrechnen muss, aber das passt leider auch nicht.
Somit habe ich das erstmal beiseite geschoben.

Stattdessen habe ich heute versucht, mit meinem Script mal die Hydraulikvariante zu lokalisieren:

Bei mir läuft im Moment Hydraulikvariante 60, was hexadezimal 3C entspricht. Dabei wurden im Scanbereich F400 bis F7FF folgende Zeilen lokalisiert:

root@heizungpi:~# ./test.sh | grep 3c
f530     09 1a b0 00 00 00 00 80     00 00 00 00 3c 00 14 14
f5e0     32 00 00 00 b1 00 a6 ff     00 00 0e 03 3c 01 16 00
f6b0     00 00 00 00 01 ff 3c 00     3c 00 00 00 46 0b a4 73
root@heizungpi:~# ./test.sh | grep 3c
f530     1e 2f b0 00 00 00 00 80     00 00 00 00 3c 00 14 14
f5e0     32 00 00 00 ae 00 21 ff     00 00 0e 03 3c 01 16 00
f6b0     00 00 00 00 01 ff 3c 00     3c 00 02 00 46 0b a4 73


Ich habe nun mal auf Hydraulikvariante 61 umgestellt. Das entspricht hexadezimal der 3D.
Siehe da: Die Zeile f6b0 verschwindet bei Prüfung auf 3C und erscheint wieder bei Prüfung auf 3D:

root@heizungpi:~# ./test.sh | grep 3c
f530     06 11 b0 00 00 00 00 80     00 00 00 00 3c 00 14 14
f5e0     14 00 00 00 a5 00 a0 ff     00 00 0e 03 3c 01 16 00
f680     00 00 00 80 00 00 00 00     46 00 2f 21 0d 3c 00 00
root@heizungpi:~# ./test.sh | grep 3d
f6b0     00 00 00 00 01 ff 3d 00     3d 00 01 00 46 0b a4 73


Dann habe ich mal ganz verquer auf Hydraulikvariante 19 gestellt, welche ich im Sommer laufen lasse, damit mir die Wärme nicht über die offene Rücklaufanhebung in den Heizkreis gedrückt wird. Das entspricht dann hexadezimal der 13.
Voila: Der Test zeigt mir wieder die Zeile f6b0:

root@heizungpi:~# ./test.sh | grep 13
f6b0     00 00 00 00 01 ff 13 00     13 00 01 00 46 0b a4 73
f7c0     7f 13 ff 20 9b 00 f8 00     f7 14 bd 01 fd 6a 5f 00


Und nun stelle ich das ganze wieder zurück auf Hydraulikvariante 60 (hex 3C):
root@heizungpi:~# ./test.sh | grep 3c
f530     12 1d b0 00 00 00 00 b0     00 00 00 00 3c 00 14 14
f5e0     32 00 00 00 97 00 5f ff     00 00 0e 03 3c 01 16 00
f640     01 21 46 05 00 00 00 78     3c ff 03 00 00 00 00 ff
f660     00 00 3c 00 78 78 21 0f     22 00 00 00 00 00 84 03
f680     00 00 00 80 00 00 00 00     46 00 2f 21 0d 3c 00 00
f6b0     00 00 00 00 01 ff 3c 00     3c 00 02 00 46 0b a4 73


Und wieder taucht die Zeile f6b0 auf.

Warum sich allerdings immer die Werte an F6B6 und F6B8 ändern ist mir noch nicht ganz klar.
Ich vermute, dass das eine der Wert ist, welchen ich haben möchte (Einsteller) und das andere der übernommene Wert, mit welchem die Anlage dann auch arbeitet.

Folgende Addressen konnte ich somit bisher als Doppel-Bytes bei meiner PS5511SZ lokalisieren (bei eingestellter Hydraulikvariante 60):

F5A2 oder F5D0     Messwert TKO: Kollektor Temperatur IST (vermutlich eher Adresse F5A2)
F62C               Messwert ___: Kollektor Temperatur MAX
F5A8               Messwert TPO: Pufferspeicher oben IST
F5AA               Messwert TPU: Pufferspeicher unten IST
F5B0               Messwert TKR: Kessel Rücklauf IST
F5AE               Messwert TRH: Heizkreis Rücklauf IST

F5EC               Solarertrag addiert
F5EE               Betriebsstunden (vermutlich: aktiver Solarbetrieb)

F6B6 oder F6B8     Einsteller: Hydraulikvariante
F5DE oder F600     Einsteller: Überhöhung 2 EIN
F5E0 oder F602     Einsteller: Überhöhung 2 AUS

... und als Gimmick:
FEEE               aktueller Anzeigewert in Display Zeile 4 (Kommastellen, Einheit oder Vorzeichen noch nicht ermittelt)


Vielleicht kann mal jemand eine Gegenprüfung machen ;)

Ich versuche das mal als Tabelle abzubilden. Dann können wir hier vielleicht auch verschiedene Anlagen sammeln:

Solar-Laderegler TEM PS5511 Variante:   SZ
Firmware-Stand:                         V.2.20
                                        513807
RAM-Diagnose bei Hydraulikvariante:     60
- Messwerte ----------------- --------- ---------
Kollektor Temperatur IST      TKO       F5A2
Kollektor Temperatur MAX      TKOmax    F62C
Pufferspeicher oben IST       TPO       F5A8
Pufferspeicher unten IST      TPU       F5AA
Kessel Rücklauf IST           TKR       F5B0
Heizkreis Rücklauf IST        TRH       F5AE
- Einsteller ---------------- --------- ---------
Hydraulikvariante             HV        F6B6 o. F6B8
Überhöhung 2 EIN              UH2E      F5DE o. F600
Überhöhung 2 AUS              UH2A      F5E0 o. F602
- Informationen ------------- --------- ---------
Solarertrag addiert           SErtrSum  F5EC
Solar-Betriebsstunden         SBetrStd  F5EE
- Gimmick ------------------- --------- ---------
Displayzeile 4             ?? Display4  FEEE
Solarladeregler: TEM PS5511SZ (Firmware V.2.20 Feb604 513807)
RasPi3 mit ebus3-Modul: Debian BullsEye mit ebusd aus Repository
Datenübertragung per MQTT an ioBroker auf einer Synology
# Ich habe KEIN fhem im Einsatz

ElOmari

Hallo zusammen,

ich besitze den Controller PS5511 SZ (Einstellung auf HV 39) und habe vorgestern einen ebus(mit wifi bekommen.
Ich habe auch ebusd auf meinen Raspberry installiert und lauft.

Der Adapter hat folgende IP 192.168.178.68 bekommen. Laut der Beschreibung von DanielKucera, sollte man die folgenden Ports benutzen: 3333,3334,3335 und 5555."
the adapter listens on following TCP ports (latest SW):
3333 - raw - on this port you can both read and write to the eBus - ebusd config: -d esp-ebus.local:3333
3334 - listen only port - everything sent to this port will be discarded and not sent to bus
3335 - enhanced protocol - ebusd config: -d enh:esp-ebus.local:3335
5555 - status server - you can telnet to this port (or http://esp-ebus.local:5555) to see some basic status info

ich habe unter /etc/ebust/tem/fc.ps551.HW7878.SW3178.h39.csv erstellt(die gleiche Einstellung wie Heiko), nun sind sie falsch für meinen Controller.
daher wenn ich den Befehl "sudo ebusctl i" erhalte ich folgende Antwort "version: ebusd 23.1.23.1-8-g9c0af7b9
update check: revision 23.1 available
device: 192.168.178.68:3335, enhanced
signal: acquired
symbol rate: 6
max symbol rate: 26
min arbitration micros: 19
max arbitration micros: 22
min symbol latency: 7
max symbol latency: 11
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f7: master #20
address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878"


der kann sich nicht mit der Einstellung von CSV verbinden.

Zweite Bemerkung, die ich gemacht habe,  ist, dass ihr den Port 9999 verwendet, wenn ich es auch ändere unter /ect/default/ebusd:
EBUSD_OPTS="--scanconfig -d enh:192.168.178.68:9999"

bekomme ich diese Antwort, dass mein Port invalid ist:
@openhabian:~ $ sudo ebusctl i
version: ebusd 23.1.23.1-8-g9c0af7b9
device: 192.168.178.68:9999, enhanced, invalid
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

die Log-File zeigt das auch:

2023-04-06 10:54:15.183 [bus notice] device invalid
2023-04-06 10:54:20.227 [bus error] unable to open 192.168.178.68:9999: ERR: generic I/O error
2023-04-06 10:54:20.227 [bus notice] device invalid

Danach habe ich die Einstellung des Ports auf 3335 geändert und bekam unter LogFile folgendes:
2023-04-06 11:05:38.211 [main error] unable to load scan config fc: list files in tem ERR: element not found
das heist mein CSV ist falsch.

Hat jemand hier die richtige Einstellung von csv-datei?

Danke









ElOmari

#34
Hallo iviurx,

ich habe deinen Skript übernommen und ausgeführt.  leider bekomme ich keine Daten (ziemlich leer)

Woran könnte es liegen?

i@openhabian:~ $ ./ebusd/ebusd_script.sh
f400     R: R: f410     R: R: f420     R: R: f430     R: R: f440     R: R: f450     R: R: f460     R: R: f470     R: R: f480     R: R: f490     R: R: f4a0     R: R: f4b0     R: R: f4c0     R: R: f4d0     R: R: f4e0     R: R: f4f0     R: R: f500     R: R: f510     R: R: f520     R: R: f530     R: R: f540     R: R: f550     R: R: f560     R: R: f570     R: R: f580     R: R: f590     R: R: f5a0     R: R: f5b0     R: R: f5c0     R: R: f5d0     R: R: f5e0     R: R: f5f0     R: R:

hier die Ausgabe von ebusctl i
 sudo ebusctl i
version: ebusd 23.1.23.1-8-g9c0af7b9
update check: revision 23.1 available
device: 192.168.178.68:3333
signal: acquired
symbol rate: 11
max symbol rate: 26
min arbitration micros: 19
max arbitration micros: 19
min symbol latency: 6
max symbol latency: 10
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f7: master #20
address fc: slave #20, scanned "MF=TEM;ID=PS551;SW=3178;HW=7878"


 und die Ausgabe von " cat /var/log/ebusd.log"

2023-04-06 12:52:07.353 [main error] scan config fc: ERR: element not found
2023-04-06 12:54:09.418 [main notice] update check: revision 23.1 available
2023-04-06 13:55:24.304 [main notice] SIGTERM received
2023-04-06 13:55:28.639 [main notice] ebusd stopped
2023-04-06 13:55:28.727 [main notice] ebusd 23.1.23.1-8-g9c0af7b9 started with auto scan on device 192.168.178.68:3333
2023-04-06 13:55:29.128 [bus notice] bus started with own address 31/36
2023-04-06 13:55:29.237 [bus notice] signal acquired
2023-04-06 13:56:20.988 [bus notice] new master f7, master count 2
2023-04-06 13:56:27.434 [bus notice] scan fc: ;TEM;PS551;3178;7878
2023-04-06 13:56:27.434 [update notice] store fc ident: done
2023-04-06 13:56:27.434 [update notice] sent scan-read scan.fc  QQ=31: TEM;PS551;3178;7878
2023-04-06 13:56:27.434 [bus notice] scan fc: ;TEM;PS551;3178;7878
2023-04-06 13:56:27.486 [main error] unable to load scan config fc: list files in tem ERR: element not found
2023-04-06 13:56:27.486 [main error] scan config fc: ERR: element not found
2023-04-06 13:58:33.301 [main notice] update check: revision 23.1 available

ElOmari

#35
hallo zusammen,

ich habe es geschafft, zum Laufen zu bringen.
Nun muss ich die TEM-Daten anpassen, wie ich vorher erwähnt habe, mein HV ist 39.

@iviurx,

wie hast du Speicherparameter angepasst bzw. rausgefunden? welcher Sensor zur welchen Speicheradresse passt?

Danke

ElOmari

Hallo Heiko,

Kannst Du mir bitte eine Kopie deiner mqtt-integration.cfg schicken oder zeigen. Ich habe ein Problem bei der Einstellung bzw. Mit der Verbindung mit mqtt.

Danke im voraus

DS_Starter

Hallo ElOmari,

bei mir läuft der eBusd in einem Docker auf Synology.
Der Daemon wird mit dem Folgenden Kommando gestartet:

"cmd" : "-f --scanconfig --configlang\\=de --configpath\\=/etc/ebusd --accesslevel\\=* -d enh:192.168.2.216:9999 --loglevel\\=info --latency\\=20 --address\\=ff --mqttport\\=1883 --mqttjson --mqtthost\\=192.168.2.46 --mqtttopic\\=ebusd/%circuit/%name"
Du siehst hier die Aufrufparameter für MQTT.
Alles weitere passiert dann in FHEM.
Ein MQTT2 Server läuft als Broker (nicht nur für ebusd) und ein MQTT2_DEVICE agiert als Bridge. Diese Bridge legt ihrerseits weitere Devices an für Vaillant, TEM, usw.
Wenn du für diese Konfig in FHEM Unterstützung brauchst meldest dich einfach, oder fragst im MQTT Forum.

LG,
Heiko

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

ElOmari

Hi Heiko,

die gleiche Einstellung habe ich auch und so sieht es aus
 
ZitatEBUSD_OPTS="--enablehex --enabledefine --scanconfig --configlang=de --configpath=/etc/ebusd --accesslevel=* -d 192.168.178.68:3333 --loglevel=info --latency=20 --address=ff --mqttport=1883 --mqttjson --mqtthost=192.168.178.71 --mqtttopic=ebusd/%circuit/%name 
-l /var/log/ebusd.log --mqttint=/etc/ebusd/mqtt-integration.cfg"

ich arbeite unter OH3, die MQTT ist eingebunden, läuft und funktioniert. Es sind viele Devices an MQTT Broker gebunden.

OH3 bietet auch ebus als Package, nun möchte ich den ebusd einbauen und benutzen.

Die Anfrage an PS5511SZ funktioniert wunderbar.

ich habe folgende Einstellung bei deinem Post gesehen und mich gefragt, wo du sie eingetragen hast oder wird automatisch von fhem generiert?

Zitatdefine get.ebus.tem.short at +*00:00:27\
set MQTT_Broker publish ebusd/PS551/TKO_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TBU_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TPU_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TFK_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/TKR_Temperature/get;;           \
\
set MQTT_Broker publish ebusd/PS551/PS_Actual_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/PS_Average_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/PFK_Actual_Speed/get;;\
set MQTT_Broker publish ebusd/PS551/Solar_Actual_Power/get;;\
set MQTT_Broker publish ebusd/PS551/Solar_Total_Yield/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target/get;;\
\
set MQTT_Broker publish ebusd/PS551/Buffer_Setpoint_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/Puffer_Setpoint_Temperature/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target_DeltaTemp_Collector_On/get;;\
set MQTT_Broker publish ebusd/PS551/Charging_Target_DeltaTemp_Collector_Off/get;;\
set MQTT_Broker publish ebusd/PS551/Operating_Mode/get;;\
set MQTT_Broker publish ebusd/PS551/PS_Operating_Hours/get;;
attr get.ebus.tem.short alias Abruf eBus TEM PS 5511 (kurzes Intervall)
attr get.ebus.tem.short cmdIcon execNow:rc_BACK
attr get.ebus.tem.short disable 0
attr get.ebus.tem.short group eBus Heizung
attr get.ebus.tem.short icon clock
attr get.ebus.tem.short room Haustechnik->eBus
attr get.ebus.tem.short sortby 6
attr get.ebus.tem.short webCmd execNow


iviurx

#39
Hallo ElOmari,

Erstmal SORRY für meine verspätete Reaktion.
Ostern war etwas laaaang hier.  ;D

Habe ich richtig verstanden, dass Du es geschafft hast, mit meinem Code-Schnipsel Daten aus der PS5511SZ zu lesen?
Für mich sieht es weiter oben so aus, als hättest Du gar keine Verbindung bzw. es wurden keine Daten zurückgeliefert.
Wenn ich mich recht entsinne, dann sah das bei mir zwischenzeitlich auch so aus, weshalb ich mein Skript noch etwas
aufgebohrt habe. Das machte es flexibler und einfacher in der Abfrage  von Speicherbereichen. Nachdem ich auf MQTT
umgestellt hatte musste ich zudem noch den Server-Parameter mit einbauen, weil es bislang nur auf Basis von
localhost auf dem RasPi funktionierte (was vermutlich auch Dein Problem war).

Hier nochmal meine aktuelle Skript-Version Stand 16.04.2023:
VORSICHT! Das Skript hat keine Fehlerprüfung auf falsch übergebene Parameter

#!/bin/bash
ebusctlparameter="--server 192.168.201.121 --port 8890";
##########

start=$((0));
ende=$((0));
zaehler=$((0));
mem=0x00;
addr=0xfc;

for parameter in "$@"
do
  if [[ $parameter == "ram" ]]; then
    mem=0x00
  elif [[ $parameter == "eeprom" ]]; then
    mem=0x02
  elif [[ $parameter =~ ^[0-9A-Fa-f]{4} ]] ; then
    zaehler=$((zaehler+1))
    if [[ $start == $((0)) ]]; then
      start=$((16#$parameter))
    else
      ende=$((16#$parameter))
    fi
  elif [[ $parameter =~ ^[0-9A-Fa-f]{2} ]] ; then
    addr='0x'$parameter
  fi
done

if [[ $zaehler<2 ]]; then
  ende=$start;
fi
if [[ $start > $ende ]]; then
  tmp=$start
  start=$ende
  ende=$tmp
fi

start=$((start-(start%16)))
ende=$((ende+16-(ende%16)))

printf '%02x 09%02x 03 %02x%02x 08\n' $addr $mem $(($start%256)) $(($start/256))

for (( i=start; i<ende; i=i+16 )) do
  printf '%04x    ' $i
  ebuscommand0='ebusctl '$ebusctlparameter$(printf ' hex %02x09%02x03%02x%02x08' $addr $mem $(($i%256)) $(($i/256)) )
  ebuscommand8='ebusctl '$ebusctlparameter$(printf ' hex %02x09%02x03%02x%02x08' $addr $mem $((($i%256)+8)) $(($i/256)) )
  octet0=$($ebuscommand0)
  octet8=$($ebuscommand8)
  printf ${octet0:2:2}' '${octet0:4:2}' '${octet0:6:2}' '${octet0:8:2}' '${octet0:10:2}' '${octet0:12:2}' '${octet0:14:2}' '${octet0:16:2}'    '
  printf ${octet8:2:2}' '${octet8:4:2}' '${octet8:6:2}' '${octet8:8:2}' '${octet8:10:2}' '${octet8:12:2}' '${octet8:14:2}' '${octet8:16:2}'    '
  printf '\n'
done

printf '\n'

Trage am Anfang des Skripts unbedingt die Verbindungsparameter zu deinem ebusd ein!
Mögliche Parameter sind dann:
[Geräteadresse]
          Adresse das abzufragenden Gerätes auf dem ebus
          kann mit ebusctl i auf der Kommandozeile ermittelt werden
          Default: fc
[ram|eeprom]
          auszulesender Speichertyp
          Default: ram
[Startadresse]
          Startblock beim Auslesen des Speichers
          Wird immer auf den nächstkleineren 16-Byte-Block abgerundet
          Default: fc00
[Endadresse]
          Letzter Block beim Auslesen des Speichers
          Wird immer auf den nächstgrößeren 16-Byte-Block aufgerundet
          Default: [Startadresse+16Byte]

Mögliche Abfragen sehen dann wie folgt aus:
root@heizungpi:~# ./test.sh
fc 0900 03 0000 08
0000    8a 00 ff ff d8 73 d9 73    da 73 db 73 dc 73 b2 74

root@heizungpi:~# ./test.sh f400
fc 0900 03 00f4 08
f400    00 f7 00 00 00 00 3b a0    00 09 30 fc a0 fb 03 03

root@heizungpi:~# ./test.sh f402
fc 0900 03 00f4 08
f400    00 f7 00 00 00 00 3b b8    01 09 30 fc a0 fb 03 03

root@heizungpi:~# ./test.sh f402 f500
fc 0900 03 00f4 08
f400    00 f7 00 00 00 00 3b 6e    00 09 30 fc a0 fb 03 03
f410    06 06 00 00 ff 00 c0 00    e0 5f d0 00 42 62 b0 00
f420    00 5d 00 00 00 00 03 00    00 00 20 00 20 00 20 00
f430    20 00 ab 13 ff ff ab 13    ff ff ab 12 ff ff ab 12
f440    ff ff 01 00 03 03 00 00    9b 10 20 01 67 16 22 00
f450    01 18 9c 10 20 01 67 16    22 00 01 18 9d 10 20 01
f460    67 16 22 00 01 18 9d 10    20 01 67 16 22 00 01 18
f470    9a 10 20 01 67 16 22 00    01 18 ff 00 01 00 20 00
f480    00 00 00 02 00 00 48 fe    c7 80 ac 82 57 b9 47 fe
f490    07 b7 c7 c1 03 00 02 00    30 41 70 00 02 60 00 00
f4a0    bf 11 00 00 00 00 30 41    30 00 00 00 00 00 01 00
f4b0    c8 00 e8 03 26 81 10 00    01 03 02 00 00 0a 00 00
f4c0    00 00 03 00 37 b3 00 00    00 00 31 78 00 00 56 04
f4d0    12 00 00 00 00 00 00 00    00 00 00 00 00 00 01 00
f4e0    00 8d 00 02 00 00 8a b3    99 b3 02 00 00 00 03 00
f4f0    00 00 00 00 00 00 00 00    00 00 00 00 00 00 02 50
f500    6c 68 69 0a 00 00 00 00    00 00 00 00 00 00 00 00

root@heizungpi:~# ./test.sh f402 fa
fa 0900 03 00f4 08
f400    R: R:
########## auf dem ebus existiert bei mir kein Gerät unter der Adresse fa ##########

root@heizungpi:~# ./test.sh ram f400
fc 0900 03 00f4 08
f400    00 f7 00 00 00 00 3b 4f    00 09 30 fc a0 fb 03 03

root@heizungpi:~# ./test.sh eeprom f400
fc 0902 03 00f4 08
f400    00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00

Vielleicht mal noch was zu meiner Hardware-Aufstellung:
Ich habe ein ebusd-Modul direkt in einen Raspi3 eingebaut. Der steht im Keller direkt auf der TEM PS5511SZ und ist
per WLAN in meinem Netzwerk verfügbar. Mittlerweile habe ich den ebusd mit MQTT gestartet.
Auf meiner Synology läuft ein ioBroker in einem Docker-Container, der die Werte aller möglichen Systeme einsammelt
(Homematic, E-Auto, eBus) und alles aufhübscht.

Tatsächlich habe ich KEIN fhem im Einsatz und treibe mich nur wegen der Speicheradressen für die PS5511SZ hier rum ;)

Zitat von: ElOmari am 06 April 2023, 18:30:29wie hast du Speicherparameter angepasst bzw. rausgefunden? welcher Sensor zur welchen Speicheradresse passt?
Ich habe mich tatsächlich mit dem Laptop in den Keller gestellt und direkt an der PS5511SZ mit den Reglern gespielt.
Auf dem Laptop war ich per Putty mit meinem Raspi verbunden und konnte so mit meinem Skript diverse Felder ermitteln.
Essentiell musst Du Wissen, was du an der PS5511SZ einstellst, wie das dann HEXadezimal im Speicher aussehen wird.
Zusammen mit meinem Skript und dem besten Freund "grep" konnte ich dann Zeilen eingrenzen.
Dann an der Solaranlage den Wert verstellen (bevorzugt eins hoch oder runter) und wieder den selben Befehl ausführen.
In der Regel wird Dir dann eine Zeile weniger gelistet als vorher. Die ist dann höchstwahrscheinlich Dein Ziel.

Leider habe ich das bis heute auch aus Zeitgründen ausschließlich für die oben gezeigten Speicherfelder erreicht.
So ist es mir bis heute nicht gelungen, die Solarpumpe zu greifen.
Im Moment berechne ich mir den Wert für die Solarpumpe (AN oder AUS) aus den Formeln "TPO+UH2E" bzw. "TPO-UH2A"
und Vergleiche dies mit TKO ... funktioniert bislang ganz gut, ist aber alles andere als zufriedenstellend.

PS
Die PS5511Sz im Foto-Anhang ist nur zu Anschauungszwecken offen.
FINGER WEG von den Kabeln auf der rechten Seite! LEBENSGEFAHR
Solarladeregler: TEM PS5511SZ (Firmware V.2.20 Feb604 513807)
RasPi3 mit ebus3-Modul: Debian BullsEye mit ebusd aus Repository
Datenübertragung per MQTT an ioBroker auf einer Synology
# Ich habe KEIN fhem im Einsatz

ElOmari

hallo ivriux,

danke für deine Antwort.

ich habe es auch so gemacht, dass ich mir einen zweiten KONTROLLER(ps5511sz) gebraucht gekauft habe, damit ich damit spielen kann. es hat nicht viel gekostet und habe meinen eingebauten geschont. er hängt an einem OFEN. mein Ziel ist, den Ofen zu kontrollieren.

Bis jetzt habe ich alle Füller die PFK notiert, es fehlen noch die UHR und PPS.

Der ebusd läuft auch gut( allerdings unter openhabian). Ich habe ebusd mit matt installiert, leider kann ich bis jetzt nicht die topics sehen. Ich habe unter /etc/Default/ebusd die folgende Option eingestellt:
EBUSD_OPTS="--enablehex --enabledefine --httpport=8090 --scanconfig --pollinterval 10 --configlang=de --configpath=/etc/ebusd --accesslevel=* -d 192.168.178.68:3333 --loglevel=info --latency=20 --address=ff  --mqttport=1883 --mqttjson --mqtthost=192.168.178.71 --mqttuser=openhabian --mqttpass=xxxxx --mqtttopic=ebusd/%circuit/%name --mqttint=/etc/ebusd/mqtt-ebusd.cfg -l /var/log/ebusd.log"

Ich habe den vorhanden mqqt-hassio.cfg zu mqtt-ebusd.cfg umbenannt und haprefix vom Homeassistent zu ebusd geändert. Beide Änderungen haben nichts gebracht, ich dachte nach dem neuen reboot werden alle topics in dieser Form erkannt: ebusd/PS551/TFK_Temperature ...ect. leider steht nur mqtt:topic:Homeassistent:......

Mosquitto liefert diese Daten:

2023-04-22 23:41:50: New connection from 192.168.178.71:33772 on port 1883.
2023-04-22 23:41:51: New client connected from 192.168.178.71:33772 as ebusd_23.1_757 (p1, c1, k60, u'openhabian').

Ebusctl liefert auch Daten:

2023-04-22 23:49:10.215 [bus info] send/receive symbol latency 6 - 32 ms
2023-04-22 23:49:10.225 [update info] sent MS cmd: fffc09000322f402 / 020200
2023-04-22 23:49:10.225 [update notice] sent poll-read PS551 Operating_Mode QQ=ff: auto
2023-04-22 23:49:21.091 [bus info] poll cmd: fffc0900037af402
2023-04-22 23:49:21.487 [update info] sent MS cmd: fffc0900037af402 / 021101
2023-04-22 23:49:21.487 [update notice] sent poll-read PS551 TBO_Temperature QQ=ff: 27.3
2023-04-22 23:49:32.094 [bus info] poll cmd: fffc0900037ef402
2023-04-22 23:49:32.258 [update info] sent MS cmd: fffc0900037ef402 / 021301
2023-04-22 23:49:32.258 [update notice] sent poll-read PS551 TBU_Temperature QQ=ff: 27.5
2023-04-22 23:49:43.092 [bus info] poll cmd: fffc090003baf402
2023-04-22 23:49:43.295 [update info] sent MS cmd: fffc090003baf402 / 026b02
2023-04-22 23:49:43.295 [update notice] sent poll-read PS551 TFK_Temperature QQ=ff: 61.9
2023-04-22 23:49:54.054 [bus info] poll cmd: fffc0900030af502
2023-04-22 23:49:54.211 [update info] sent MS cmd: fffc0900030af502 / 020a01
2023-04-22 23:49:54.211 [update notice] sent poll-read PS551 TKO_Temperature QQ=ff: 26.6
2023-04-22 23:50:05.097 [bus info] poll cmd: fffc090003e4f402
2023-04-22 23:50:05.207 [update info] sent MS cmd: fffc090003e4f402 / 026c02
2023-04-22 23:50:05.208 [update notice] sent poll-read PS551 TPO_Temperature QQ=ff: 62.0
2023-04-22 23:50:16.112 [bus info] poll cmd: fffc090003e2f402
2023-04-22 23:50:16.500 [update info] sent MS cmd: fffc090003e2f402 / 026b02
2023-04-22 23:50:16.501 [update notice] sent poll-read PS551 TPU_Temperature QQ=ff: 61.9

Und openhab liefert

 cat /var/log/openhab/openhab.log | grep mqtt
2023-04-22 23:45:18.951 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'mqtt:broker:ebusd' takes more than 5000ms.
2023-04-22 23:45:24.181 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'mqtt:broker:MosquittoMttqBroker' takes more than 5000ms.
2023-04-22 23:45:25.050 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.178.71' with clientid 278a735b-b30e-4c53-8d9f-bf59d93c4d68
2023-04-22 23:45:25.028 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.178.71' with clientid ae9c8f18-6618-4305-a2de-21c75c63d246

Was mache ich falsch?
Wie kann ich die Liste der matt subscriber bzw Publisher ermitteln?

Gruss

iviurx

#41
Hallo ElOmari,

Sorry, da bin ich leider raus ...
OpenHABian kenn ich nur vom Namen her und vermute auf Grund der Namensgebung, dass da ein Debian als Unterbau läuft. Mehr kann ich dazu aber auch schon nicht mehr beitragen.
Solarladeregler: TEM PS5511SZ (Firmware V.2.20 Feb604 513807)
RasPi3 mit ebus3-Modul: Debian BullsEye mit ebusd aus Repository
Datenübertragung per MQTT an ioBroker auf einer Synology
# Ich habe KEIN fhem im Einsatz

mm

Hallo zusammen,

vielen Dank für diesen Forumsbeitrag!
Danke Heiko für die viele Vorarbeit.
Danke iviurx für dein bash script zum Scannen.

Ich habe bei der 20 Jahre alten Solarthermieanlage meiner Eltern einen eBus Adapter angebaut und durch etwas knobeln die folgende config für ebusd erstellt.
Durch den Unterschied von Hydraulikvariante 4 zu Hydraulikvariante 1 ändern sich leider alle Adressen. :(

Infos zur Anlage:
TEM PS5511 S-1
Hydraulikvariante 1
Kein Pufferspeicher verbaut.
Kein TFK Sensor vorhanden.
Kein Steuerungsventil, deshalb Possible_LoadingTarget uninteressant.
Kein VIG Sensor verbaut, deshalb habe ich mir nicht die Mühe gemacht diese Einstellung zu finden.
Kein Strahlungsfühler verbaut, ebenfalls nicht danach gesucht.


# type (r[1-9];w;u),circuit,name,comment,QQ,ZZ,PBSB,ID,FIELD,part (m/s),type / templates,divider / values,unit,comment,FIELD,part (m/s),type / templates,divider / values,unit,co
mment,FIELD,part (m/s),type / templates,divider / values,unit,comment,FIELD,part (m/s),type / templates,divider / values,unit,comment
#,PS551,PS551,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,PS551,,,,FC,0900,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Charging_Target_DeltaTemp_Collector_On,Überhöhung Kollektor zu Ladeziel Ein,,,,DEF502,_,,UIN,10,K,,,,,,,,,,,,,,,,,,,
r,,Charging_Target_DeltaTemp_Collector_Off,Überhöhung Kollektor zu Ladeziel Aus,,,,E0F502,_,,UIN,10,K,,,,,,,,,,,,,,,,,,,
r,,PS_Average_Speed,mittlere Leistung Solarpumpe,,,,E4F502,_,,UIN,10,%,,,,,,,,,,,,,,,,,,,
r,,Operating_Mode,Betriebsmodus,,,,96F402,_,,UIN,0=off;1=manual;2=auto,,,,,,,,,,,,,,,,,,,,
r,,PS_Actual_Speed,Solarpumpe aktuelle Leistung,,,,28F502,_,,UIN,10,%,,,,,,,,,,,,,,,,,,,
r,,TBU_Temperature,Temp Speicher unten,,,,40F502,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,
r,,TKO_Temperature,Temp Kollektor oben,,,,A2F502,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,
r,,Solar_Actual_Power,Solarleistung aktuell,,,,E8F502,_,,UIN,10,kW,,,,,,,,,,,,,,,,,,,
r,,Solar_Total_Yield,Solarertrag total,,,,ECF502,_,,UIN,,kWh,,,,,,,,,,,,,,,,,,,
r,,PS_Operating_Hours,Betriebsstunden Solarpumpe,,,,EEF502,_,,UIN,,h,,,,,,,,,,,,,,,,,,,

Vielleicht hilft ja jemandem mein Beitrag.

cu

Matthias

borkpaul

#43
Hallo zusammen,

vielen Dank an iviurx für dein bash script zum Scannen.
Ich habe eine ES6522 SZ (von Hark beigestellt) im Einsatz. Ich nutze die Hydraulikvariante 51. Mein Ziele ist es die beiden relevanten Messgrößen der Hydraulikvariante auszulesen und an OH weiterzugeben.
Ich hab den Adapter in der Version 5 im Einsatz.
Dank des Scripts konnte ich die Speicherbereiche 0F8E für TU1 und 0F53 für TFK identifizieren (hoffentlich..).
Leider ist es mir nicht gelungen, mit dem Lesen auch gleich eine entsprechenden MQTT-Meldung zu erzeugen. Keinerlei
Hinweise auf MQTT im ebusd-log.
Da ich aber bereits anderweitig Werte an MQTT sende, habe ich das dann auch wieder für mich so gelöst:

#!/bin/bash

x="ebusctl read -f TU1  | xargs  /var/local/ebusd/publish-ebusd-to-mqtt.sh TU1"
eval "$x"

x="ebusctl read -f TFK  | xargs  /var/local/ebusd/publish-ebusd-to-mqtt.sh TFK"
eval "$x"

VG Winfried
kein FHEM, UVR16x2, OH3, IoBroker, Daikin Altherma 3 R W mit P1P2-Adapter, ES6522 am Kamin mit WT und Pufferspeicher, Ceta104 an Gastherme, 9,8KW PV mit SNA Homemanager und Batterie, diverse Funksteckdosen (Fritz und Shelly)

tube

So, nach viel Einlesen klappt es auch bei mir mit Hydraulikvariante 1 nutze ich diese Konfig:
EBUSD_OPTS="--scanconfig -d ens:192.168.xx.xx:9999 --mqttclientid=ebusd --configpath=/etc/ebusd --mqtthost=192.168.xx.xx --mqttpass=xx --mqttport=1883 --mqttuser=xx --mqttint=/etc/ebusd.old/mqtt-hassio.cfg --mqttjson -p 8889 --httpport=8890"


# type (r[1-9];w;u),circuit,name,comment,QQ,ZZ,PBSB,ID,FIELD,part (m/s),type / templates,divider / values,unit,comment,FIELD,part (m/s),type / templates,divider / values,unit,comment,FIELD,part (m/s),type / templates,divider / values,unit,comment,FIELD,part (m/s),type / templates,divider / values,unit,comment
#,PS551,PS551,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,PS551,,,,FC,0900,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Operating_Mode,Betriebsmodus,,,,96F402,_,,UIN,0=off;1=manual;2=auto,,,,,,,,,,,,,,,,,,,,
r,,PS_Actual_Speed,Solarpumpe aktuelle Leistung,,,,28F502,_,,UIN,10,%,,,,,,,,,,,,,,,,,,,
r,,TBU_Temperature,Temp Speicher unten,,,,40F502,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,
r,,TKO_Temperature,Temp Kollektor oben IST,,,,A2F502,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,
r,,HK_RL,Heizkreis_Ruecklauf IST,,,,AEF502,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,
r,,TK_RL,Kessel_Ruecklauf IST,,,,B0F502,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,
r,,Charging_Target_DeltaTemp_Collector_On,Überhöhung Kollektor zu Ladeziel Ein,,,,DEF502,_,,UIN,10,K,,,,,,,,,,,,,,,,,,,
r,,Charging_Target_DeltaTemp_Collector_Off,Überhöhung Kollektor zu Ladeziel Aus,,,,E0F502,_,,UIN,10,K,,,,,,,,,,,,,,,,,,,
r,,PS_Average_Speed,mittlere Leistung Solarpumpe,,,,E4F502,_,,UIN,10,%,,,,,,,,,,,,,,,,,,,
r,,Solar_Actual_Power,Solarleistung aktuell,,,,E8F502,_,,UIN,10,kW,,,,,,,,,,,,,,,,,,,
r,,Solar_Total_Yield,Solarertrag total,,,,ECF502,_,,UIN,,kWh,,,,,,,,,,,,,,,,,,,
r,,PS_Operating_Hours,Betriebsstunden Solarpumpe,,,,EEF502,_,,UIN,,h,,,,,,,,,,,,,,,,,,,
r,,TKO_MAX,Temp Kollektor oben MAX,,,,2CF602,_,,UIN,10,°C,,,,,,,,,,,,,,,,,,,

Ich bekomme auch schön die wichtigsten Werte per MQTT alle paar Sekunden geliefert. Kann man diese Zeit besser einstellen? So 1x die Minute würde ja reichen...

Problem:
PS_Actual_Speed wird nicht von sich aus gemeldet, sondern erst wenn ich es z.B. per
mosquitto_pub -n -t ebusd/PS551/PS_Actual_Speed/get -u xx -P xxmanuell anfordere.

Ich verstehe nicht was hier der Unterschied zu den anderen Werten ist.