Läuft: Heizung mit eBus-Schnittstelle

Begonnen von Prof. Dr. Peter Henning, 29 November 2014, 13:36:59

Vorheriges Thema - Nächstes Thema

john30

Zitat von: PavelCoast am 30 Dezember 2018, 12:19:00
Wie kann ich den Fehler bei heatpump cycles beheben?
ebusctl find -d
heatpump cycles = 80;1;1d;00;1;1320 (ERR: invalid position for 01150621047d860002 / 0a50811d00010028050000)

der Wert "0000" passt nicht zum Datentyp HCD des Feldes "cycles". Das müssten eigentlich 4 Bytes sein, aber die Antwort enthält nur 2. Also ist die Definition zumindest für Dein Device nicht korrekt.
Jetzt könnte man mutmaßen, dass es bei Deinem einfach eine verkürzte Version ist und cycles in den _templates von HCD auf HCD:2 umdefinieren. Ob das dann für andere Devices noch passt, ist fraglich.
author of ebusd

Peter0961

Zitat von: Reinhart am 30 Dezember 2018, 06:09:29
doch, das ist immer noch so!
John hat das alles im Git so hinterlegt. Wenn du selber compiliert hast, dann siehst du unter "/home/pi/ebusd/contrib/etc/logrotate.d" die Datei, welche mit "make install" (make_debian.sh)  ja auch installiert wird.

cp contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/

Du kannst sie aber auch selber dort anlegen.

/var/log/ebusd*.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
postrotate
/usr/bin/killall -HUP ebusd
    endscript
}


LG

Super, danke für deine Hilfe!
Allerdings musste ich deine copy-Zeile noch wie folgt ergänzen, sonst ging es nicht.
Deine Befehlszeile brachtebei mir immer einen Fehler.
cp ebusd/contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/
Hinter cp musste ich "ebusd" vor contrib noch einfügen.
Dann hat er das kopieren durchgeführt.

Gruß Peter


Reinhart

ja ist klar, weil bei "make install" man ja im Verzeichnis /home/pi/ebusd" steht!
Hauptsache es klappt jetzt!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

rellla

Hallo Rene,
ich gehe davon aus, dass bei dir ein TEM-Controller verbaut ist? Dann kannst du mal versuchen, in der templates.csv die command definition gegen https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/tem/_templates.csv#L11 auszutauschen.
Bei mir (Bartl/TEM) wird dann der TEM-Code des jeweiligen Parameters ausgegeben, wie er im Display bzw. in der Anleitung aufgeführt ist. Vorausgesetzt natürlich bei dir (Ochsner) gibts das auch. Das würde dir die Zuordnung erleichtern.
Ansonsten solltest du das hier nochmal durchstöbern: https://github.com/john30/ebusd-configuration/issues/4

Gruß
Andreas

Peter0961

#2884
Zitat von: Peter0961 am 30 Dezember 2018, 15:53:53
Super, danke für deine Hilfe!
Allerdings musste ich deine copy-Zeile noch wie folgt ergänzen, sonst ging es nicht.
Deine Befehlszeile brachtebei mir immer einen Fehler.
cp ebusd/contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/
Hinter cp musste ich "ebusd" vor contrib noch einfügen.
Dann hat er das kopieren durchgeführt.

Gruß Peter

Hallo,
ich habe heute einmal wieder nach den Log-Dateien geschaut,
da ich ja letzte Woche die ebusd nach /etc/logrotate.d kopiert habe.
Da scheint aber irgendetwas nicht zu funktionieren.
Es gibt nur die aktuelle ebusd.log im Ordner /var/log.
Es wurden keine Backups angelegt in den letzten Tagen.
Kopiert habe ich die ebusd mit folgendem Befehl:
cp ebusd/contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/
Das hat auch geklappt, die Datei ist jetzt im Ordner /var/log und sieht aus wie folgt:
/var/log/ebusd*.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
postrotate
/usr/bin/killall -HUP ebusd
    endscript
}


Wenn ich das script versuche mit admin-Berechtigung manuell auzuführen,
bekomme ich folgende Fehlermeldung:
2019-01-05 00:43:25.601 [main error] invalid configpath without scanconfig
Ich weiß aber nicht woran es liegt!


Reinhart

ah, nicht versuchen den ebusd aufrufen!
Du kannst Logrotate so testen.
sudo logrotate /etc/logrotate.d -v

und checke einmal die Rechte von der Logrotate config "ebusd", die sollte 644 sein!

sudo chmod 644 /etc/logrotate.d/ebusd


rotating pattern: /var/log/ebusd*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/ebusd.log
  Now: 2019-01-05 21:18
  Last rotated at 2018-12-03 06:25
  log needs rotating
rotating log /var/log/ebusd.log, log->rotateCount is 7
dateext suffix '-20190105'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/ebusd.log.7.gz to /var/log/ebusd.log.8.gz (rotatecount 7, logs                            tart 1, i 7),
renaming /var/log/ebusd.log.6.gz to /var/log/ebusd.log.7.gz (rotatecount 7, logs                            tart 1, i 6),
renaming /var/log/ebusd.log.5.gz to /var/log/ebusd.log.6.gz (rotatecount 7, logs                            tart 1, i 5),
renaming /var/log/ebusd.log.4.gz to /var/log/ebusd.log.5.gz (rotatecount 7, logs                            tart 1, i 4),
renaming /var/log/ebusd.log.3.gz to /var/log/ebusd.log.4.gz (rotatecount 7, logs                            tart 1, i 3),
renaming /var/log/ebusd.log.2.gz to /var/log/ebusd.log.3.gz (rotatecount 7, logs                            tart 1, i 2),
renaming /var/log/ebusd.log.1.gz to /var/log/ebusd.log.2.gz (rotatecount 7, logs                            tart 1, i 1),
renaming /var/log/ebusd.log.0.gz to /var/log/ebusd.log.1.gz (rotatecount 7, logs                            tart 1, i 0),
old log /var/log/ebusd.log.0.gz does not exist
copying /var/log/ebusd.log to /var/log/ebusd.log.1
truncating /var/log/ebusd.log
running postrotate script
compressing log with: /bin/gzip

so in etwa sollte das Ergebnis aussehen!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Peter0961

Zitat von: Reinhart am 05 Januar 2019, 21:25:26
ah, nicht versuchen den ebusd aufrufen!
Du kannst Logrotate so testen.
sudo logrotate /etc/logrotate.d -v

und checke einmal die Rechte von der Logrotate config "ebusd", die sollte 644 sein!

sudo chmod 644 /etc/logrotate.d/ebusd


rotating pattern: /var/log/ebusd*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/ebusd.log
  Now: 2019-01-05 21:18
  Last rotated at 2018-12-03 06:25
  log needs rotating
rotating log /var/log/ebusd.log, log->rotateCount is 7
dateext suffix '-20190105'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/ebusd.log.7.gz to /var/log/ebusd.log.8.gz (rotatecount 7, logs                            tart 1, i 7),
renaming /var/log/ebusd.log.6.gz to /var/log/ebusd.log.7.gz (rotatecount 7, logs                            tart 1, i 6),
renaming /var/log/ebusd.log.5.gz to /var/log/ebusd.log.6.gz (rotatecount 7, logs                            tart 1, i 5),
renaming /var/log/ebusd.log.4.gz to /var/log/ebusd.log.5.gz (rotatecount 7, logs                            tart 1, i 4),
renaming /var/log/ebusd.log.3.gz to /var/log/ebusd.log.4.gz (rotatecount 7, logs                            tart 1, i 3),
renaming /var/log/ebusd.log.2.gz to /var/log/ebusd.log.3.gz (rotatecount 7, logs                            tart 1, i 2),
renaming /var/log/ebusd.log.1.gz to /var/log/ebusd.log.2.gz (rotatecount 7, logs                            tart 1, i 1),
renaming /var/log/ebusd.log.0.gz to /var/log/ebusd.log.1.gz (rotatecount 7, logs                            tart 1, i 0),
old log /var/log/ebusd.log.0.gz does not exist
copying /var/log/ebusd.log to /var/log/ebusd.log.1
truncating /var/log/ebusd.log
running postrotate script
compressing log with: /bin/gzip

so in etwa sollte das Ergebnis aussehen!

LG

Hallo Reinhart,

danke für deine super Hilfe!
Das mit den Rechten scheint es gewesen zu sein.
Nach ausführen von:
sudo logrotate /etc/logrotate.d -v
zeigt er mir jetzt bei ebusd keinen Fehler mehr an.
Aber wie kann das sein.
Ich habe mich vorab sehr viel im Forum eingelesen und auch ins Wiki von John geschaut,
aber über ein Problem mit den Rechten und das da was geändert werden muss, habe ich nichts gelesen.
Auch das man den ebusd erst in das Verzeichnis logrotate.d kopieren muss, damit das funktioniert war mir neu.
Ich habe mich eigentlich genau an die Anleitungen gehalten,
stoße aber immer wieder auf solche kleinen Hürden, wo es dann stockt.

Gruß Peter

Reinhart

normalerweise braucht man das auch nicht durchführen, weil das in den Installationspaketen ja alles enthalten ist, egal ob du selber compilierst oder das Installationsfile aus dem Git holst. Eventuell wurde was nicht mit sudo ausgeführt, dann könnte sowas schon passieren.

Hauptsache es funktioniert jetzt.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

iglo36

#2888
Hallo Zusammen,
gestern ist mein ebus adapter angekommen (@John30: Vielen Dank). Ich habe ihn angeschlossen und ebusd hat direkt Daten geliefert.  8)

Leider können nicht alle Vaillant Geräte ausgelesen werden:

Ich bekomme folgende Fehlermeldung:
2019-01-09 21:11:49.474 [update error] unable to parse scan-read scan.76 id from 3176b5090124 / 00: ERR: invalid position
2019-01-09 21:11:49.585 [update error] unable to parse scan-read scan.76 id from 3176b5090125 / 00: ERR: invalid position
2019-01-09 21:11:49.697 [update error] unable to parse scan-read scan.76 id from 3176b5090126 / 00: ERR: invalid position
2019-01-09 21:11:49.812 [update error] unable to parse scan-read scan.76 id from 3176b5090127 / 00: ERR: invalid position
2019-01-09 21:11:49.812 [main error] scan config 76: ERR: invalid position


Ein paar Infos:

root@d1609b55823a:/tmp# ebusctl info
version: ebusd 3.3.v3.3
signal: acquired
symbol rate: 23
max symbol rate: 121
min arbitration micros: 626
max arbitration micros: 938
min symbol latency: 4
max symbol latency: 5
reconnects: 0
masters: 4
messages: 465
conditional: 0
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0211;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0211;HW=0403"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"




Ich habe schon folgende Sachen ausprobiert:
Script https://raw.githubusercontent.com/john30/ebusd/master/contrib/scripts/readall.sh ausgeführt. Die ganzen Werte für die Vaillant 700 werden ausgelesen und enige Werte von der hmu. Bei ein paar der Werten von der HMU bekomme ich wieder den Fehlermeldung:

...
hmu SetMode = auto;0.0;-;-;1;1;1;0;0;0
hmu State = 0;384;24;ready
hmu Status = ERR: invalid position in decode
hmu Status01 = 22.0;21.0;1.312;-;36.5;off
hmu Status02 = auto;40;65.5;40;65.5
hmu Status16 = ERR: invalid position in decode
hmu YieldThisYear1 = ERR: invalid position in decode
hmu YieldThisYear10 = ERR: invalid position in decode
hmu YieldThisYear11 = ERR: invalid position in decode
hmu YieldThisYear12 = ERR: invalid position in decode
hmu YieldThisYear2 =
hmu YieldThisYear3 = ERR: invalid position in decode
...


Der ebusd läuft mit folgenden Parametern "ebusd --scanconfig=full -d /dev/ttyUSB0 --latency=100000 --receivetimeout=100000 --enablehex"

Kann sich jemand vielleicht erklären, warum ich diese Fehlermeldungen bekomme?


ps. Ich habe die Vaillant Wärmepumpe Flexotherm Compact  VWF 58/4
fhem und hmusb via docker

john30

Zitat von: iglo36 am 09 Januar 2019, 22:29:12
Leider können nicht alle Vaillant Geräte ausgelesen werden:
stimmt nicht ganz, lediglich die 76 antwortet nicht wie erwartet auf den Vaillant spezifischen Produkt-Scan. Dennoch erscheint die HW/SW ID im info Ergebnis. Also das ist ok.

Zitat von: iglo36 am 09 Januar 2019, 22:29:12
Bei ein paar der Werten von der HMU bekomme ich wieder den Fehlermeldung:

...
hmu Status = ERR: invalid position in decode
...

das beudeutet im Endeffekt, dass für deine HMU ein paar Nachrichtendefinitionen nicht ganz stimmen, vermutlich weil diese eine neuere HW oder SW hat.
D.h. man müsste jetzt für diese Variante eine angepasste Version der 08.hmu.csv zusammenstricken. Mit heißer Nadel versteht sicht :)
author of ebusd

iglo36

Zitat von: john30 am 10 Januar 2019, 08:24:34
D.h. man müsste jetzt für diese Variante eine angepasste Version der 08.hmu.csv zusammenstricken. Mit heißer Nadel versteht sicht :)

O.k. wie kann ich das machen?
Ich hätte auch so ein Internetmodul VR 920. Dieses läuft auch über den ebus und schickt die ganzen Daten zu Vaillant. (Aus dem Grunde hatte ich es nur kurz in Betrieb). Vielleicht könnte damit die ganze Komunikation aufgezeichnet werden.
fhem und hmusb via docker

Sven77

Das hört sich doch gut an!
Genau so habe ich damals die meisten Sachen der VRC700 "entdeckt": mit der App bei angeschlossenem VR900 alles mögliche abgefragt und geändert, dabei hat Ebusd dann alle möglichen "unknown MS" im Log gemeldet. Mit viel Handarbeit findet man dann im günstigsten Fall, welche Meldung was beinhaltet.

Aber in meinem Fall spricht die VR900 fast ausschließlich mit der VRC700, den Brenner selbst (08) fragt sie soweit ich mich erinnere nur nach dem Fehlerzustand ab.
Unabhängig davon müsste ja aber deine Steuerung mit der HMU kommunizieren.

Darüberhinaus gibt es natürlich Werte, die weder die Steuerung noch das Internetmodul interessieren, hier hilft dann nur schnüffeln mit dem Script von John. Dieses ist so natürlich nur für b509/0d-Abfragen ausgelegt, evtl. nutzt Vaillant hier (wie bei der VRC700) auch andere Nachrichten, dann musst du das im Script anpassen.
VG, Sven

Sunnyvale

Hallo Zusammen,
als begeisterter Leser dieses Forums, komme ich leider nicht mehr weiter und muss auch mal eine Frage stellen:

Ich versuche meine Vaillant Heizung mit calormatic 430 auszulesen, habe die 1.6 Platine, einen FTDI32 Adapter sowie eine Raspberry wo meine ebusd SW drauf läuft, ich bekomme leider im var/log/ebusd Log nur die Meldungen


2019-01-18 16:36:06.597 [update notice] received unknown MS cmd: 1008b5110101 /                                         095e545000ff660000ff
2019-01-18 16:36:08.599 [update notice] received unknown BC cmd: 10feb5160301500                                        0
2019-01-18 16:36:12.690 [update notice] received unknown MS cmd: 1008b5100900006                                        378ffff00ff00 / 0101
2019-01-18 16:36:16.746 [update notice] received unknown MS cmd: 1008b5110101 /                                         09584e5000ff660000ff
2019-01-18 16:36:18.688 [update notice] received unknown MS cmd: 1008b5110102 /                                         05033c96506e
2019-01-18 16:36:22.739 [update notice] received unknown MS cmd: 1008b5100900006                                        378ffff00ff00 / 0101
2019-01-18 16:36:26.788 [update notice] received unknown MS cmd: 1008b5110101 /                                         09524a5000ff660000ff
2019-01-18 16:36:28.845 [update notice] received unknown MS cmd: 1008b5040100 /                                         0a03303616180105195000
2019-01-18 16:36:29.072 [update notice] received unknown BC cmd: 10feb505020400
2019-01-18 16:36:32.887 [update notice] received unknown MS cmd: 1008b5100900006                                        378ffff00ff00 / 0101
2019-01-18 16:36:36.927 [update notice] received unknown MS cmd: 1008b5110101 /                                         094e465000ff660000ff


*****************************************************************************
mit ebusctl info

root@raspberrypi:/var/log# ebusctl info
version: ebusd 3.3.v3.3-4-g212b22d
update check: OK, broadcast.csv: different version available
signal: acquired
symbol rate: 41
max symbol rate: 60
reconnects: 0
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
***************************************************************************************
Ergebnis :ebusctl scan result
done (mehr steht da leider nicht))
*****************************************************************************************
mir fehlt da irgendwie die Vaillant Auflösung, hier im Forum sehen die Ergebnisse immer anders aus, ich denke ich habe irgendwie ein Problem mit den csv's, die habe ich aber ordnungsgemäß runtergladen und verteilt.
also auch erst auf raspi entpackt usw.

Bin total ratlos

Vielen dank im vorraus 

Reinhart

Bitte in Zukunft solche Logs in einem Code Tag ( # Symbol ) einfügen dann sieht man es besser!

Bei dir werden absolut keine CSV geladen und die Calormatic 430 auf Adresse 15 fehlt komplett. Der Rest sieht ja schon gut aus.
Poste doch einmal deine config ( etc/default/ebusd )

Ich habe dieselbe Umgebung wie du und da sieht es so aus.

pi@raspberrypi:~ $ ebusctl i
version: ebusd 3.3.v3.3-5-g2f6b2bb
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.430.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 145
min arbitration micros: 31
max arbitration micros: 5390
min symbol latency: 1
max symbol latency: 15
reconnects: 0
masters: 4
messages: 450
conditional: 16
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd


Ich bin mir nicht ganz sicher ob das Poti schon optimal ist, eventuell ganz ganz leicht oder rechts probieren da ja der Rest schon kommt. Die V 1.6 hatte ja noch ein paar Probleme bei der Abstimmung.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Sunnyvale

Hallo Reinhart,
danke für die schnelle Hilfe :)
hier das file, das mit dem Poti probier ich gleich mal aus

root@raspberrypi:/etc/default# more ebusd
# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"

# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/l
og/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/l
og/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/l
og/ebusd3.log"

# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.