eBusd Konfiguration für TEM PS5511 - Arbeitsthread

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

Vorheriges Thema - Nächstes Thema

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.