Läuft: Heizung mit eBus-Schnittstelle

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

Vorheriges Thema - Nächstes Thema

jkriegl

@ john30
Habe noch die "frühen" csv's und daher die quick.csv hinzugefügt.
u,quick,load,Quick - WW Speicherladung,,25,b505,06,onoff,s,UCH,0=off;1=on,,

w -c quick load on/off funktionieren.
Ich frage ab mit:
r -c hc IsInStorageFilling, r -c hc CleaningLady, r -c hc IsInParty
save/party habe ich nicht probiert.
Rpi 3, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

lewej

Zitat von: john30 am 02 April 2017, 12:10:10
das ist ja bizarr. aber okay. Ändere mal in hcmode die folgende Zeilen:


*r,,,,,,"B504",,,,,,,
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,


in das hier:


*r,,,,,,"B504",,,,,,,
*u,,,,,,"B510",,,,,,,
r;u,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,


Hallo John,

ich habe das jetzt so angepasst, die Fehler sind fast weg, ist noch eine Adresse die nicht erkannt wird:


[bus debug] switching from receive command ACK to receive response
2017-04-08 17:30:33.104 [bus debug] switching from receive response to receive response CRC
2017-04-08 17:30:33.109 [bus debug] switching from receive response CRC to send response ACK
2017-04-08 17:30:33.116 [bus debug] notify request: done
2017-04-08 17:30:33.116 [bus notice] poll mc CfgHeatSinkType: mixer
2017-04-08 17:30:33.116 [bus debug] switching from send response ACK to send SYN
2017-04-08 17:30:33.285 [update info] update MS cmd: 1025b505072b000100000000 / 00
2017-04-08 17:30:33.285 [update notice] unknown MS cmd: 1025b505072b000100000000 / 00
2017-04-08 17:30:33.562 [update info] update MS cmd: 1008b511020300 / 0a59026d04890600000000
2017-04-08 17:30:33.564 [update notice] update ehp Status QQ=10: 37.56;1.133;1.673;00 00 00 00
2017-04-08 17:30:33.725 [update info] update MS cmd: 1008b5110102 / 050000c800c8
2017-04-08 17:30:33.727 [update notice] update ehp Status02 QQ=10: disabled;0;100.0;0;100.0
2017-04-08 17:30:35.304 [update info] update MS cmd: 1008b50903290100 / 0501003c0200
2017-04-08 17:30:35.307 [update notice] update ehp StorageTempTop QQ=10: 35.75;ok
2017-04-08 17:30:35.480 [update info] update MS cmd: 1008b51009000100000000000002 / 00
2017-04-08 17:30:35.483 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:35.545 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-04-08 17:30:35.671 [mqtt debug] publish ebusd/global/uptime 352
2017-04-08 17:30:36.119 [update info] update MS cmd: 1008b509040ed10000 / 00
2017-04-08 17:30:36.121 [update notice] update ehp EnergyBalancingRelease QQ=10: off
2017-04-08 17:30:36.587 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-04-08 17:30:37.353 [update info] update MS cmd: 1023b5040101 / 091e0300000006000000
2017-04-08 17:30:37.355 [update notice] upda


tail -f /var/log/ebusd/ebusdvaillant.log|grep invalid
2017-04-08 17:28:04.352 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:14.648 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:24.642 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:34.728 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:44.595 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:54.675 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:04.885 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:14.827 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:24.842 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:34.954 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:46.434 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:55.049 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:05.123 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:15.334 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:25.241 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position


Gruß lewej

lewej

Zitat von: john30 am 08 April 2017, 10:52:43
Könnte mal bitte jemand mit einer SOLSY oder VR630 prüfen, ob die quick Kommandos dort auch greifen?
Also insbesondere auf Adresse 25 für HWC. Dazu einfach an die 25.*.hwc.csv noch "!include,quick.inc" als neue Zeile dranhängen, dann reload und am Ende schauen ob bspw. "ebusctl w -c hwc load on" die Speicherladung startet.
Auch interessant wäre, ob save/party ebenfalls auf Adresse 25 funktionieren würden.
VG John

Hi,

wenn es was bringt, könnte ich das mit einer auroMATIC 560 testen, da meckert sowieso das für die 23 und 25 keine Konfig vorhanden ist, soll ich das machen?

Gruß
lewej

Binnesmann

Hallo John,

oh man. Wie blöd ist das denn? Ich hab die Liste mit den Adressen vor mir liegen gehabt und hab das nicht gesehen. Werde dann morgen mal ausprobieren, bin gerade im Urlaub.

Vielen Dank und Gruß

Binnesmann.

VolkerGehrt

Guten Morgen alle zusammen,

ich habe ein Problem vielleicht kann mir einer helfen ?
Bei der Installation auf Raspberry PI3 bekomme ich diese Meldung.

sudo dpkg -i --force-overwrite ebusd-2.4_armhf.deb

dpkg-deb: Fehler: »ebusd-2.4_armhf.deb« ist kein Archiv im Debian-Format
dpkg: Fehler beim Bearbeiten des Archivs ebusd-2.4_armhf.deb (--install):
Unterprozess dpkg-deb --control gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
ebusd-2.4_armhf.deb

finde leider keine Lösung.

RaspiLED

Hi,
Was sagt den
file ebusd*
Und wie hast Du das deb geladen? Ich wette darauf, dass Du entweder eine html Datei mit einer Fehlermeldung geladen hast, statt dem deb-Paket, oder ein Windows/Unix Zeichensatz Problem vorliegt.
Let's see, shall we?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

MilanK

#2151
Hallo,

ich benutze Arch Linux auf RPi 2 und kürzlich hat gefunden, dass ich nicht mehr aktiv mit ebusctl datei lesen kann.

Die automatische Nachrichten sind noch korrekt:
2017-04-09 17:20:26.934 [bus debug] ERR: read timeout during receive command ACK, switching to skip                     
2017-04-09 17:20:30.635 [update info] update MS cmd: 1008b5110101 / 0928296011ffff0000ff                               
2017-04-09 17:20:30.636 [update notice] update MS StatusTHER: 20.0;20.5;17.375;-;-;0                                   
2017-04-09 17:20:32.290 [bus debug] ERR: read timeout during receive command ACK, switching to skip                     
2017-04-09 17:20:32.871 [update info] update MS cmd: 1008b5040100 / 0a00ffffffffffffff6011                             
2017-04-09 17:20:32.872 [update notice] update MS OutsideTemp: 17.375                                                   
2017-04-09 17:20:33.127 [update info] update MS cmd: 1008b5110102 / 050014965a78                                       
2017-04-09 17:20:33.127 [update notice] update MS PumpStatus: off                                                       
2017-04-09 17:20:34.723 [main debug] performing regular tasks


Doch, als ich versuche z.B. 'ebusctl read RoomTemp' (oder 'scan' und so):
2017-04-09 09:46:08.259 [main debug] >>> read RoomTemp                                                                 
2017-04-09 09:46:08.259 [bus info] send message: 3115b509030d3a00                                                       
2017-04-09 09:46:08.301 [bus debug] notify request: ERR: read timeout                                                   
2017-04-09 09:46:08.302 [bus error] send to 15: ERR: read timeout, retry                                               
2017-04-09 09:46:08.302 [bus debug] ERR: read timeout during ready, switching to skip                                   
2017-04-09 09:46:08.364 [bus debug] notify request: ERR: read timeout                                                   
2017-04-09 09:46:08.365 [bus error] send to 15: ERR: read timeout, retry                                               
2017-04-09 09:46:08.365 [bus debug] ERR: read timeout during ready, switching to skip                                   
2017-04-09 09:46:08.429 [bus debug] notify request: ERR: read timeout                                                   
2017-04-09 09:46:08.429 [bus error] send to 15: ERR: read timeout, retry                                               
2017-04-09 09:46:08.429 [bus debug] ERR: read timeout during ready, switching to skip                                   
2017-04-09 09:46:08.493 [bus debug] notify request: ERR: read timeout                                                   
2017-04-09 09:46:08.493 [bus error] send to 15: ERR: read timeout                                                       
2017-04-09 09:46:08.493 [bus error] send message part 0: ERR: read timeout                                             
2017-04-09 09:46:08.493 [main debug] <<< ERR: read timeout                                                             
2017-04-09 09:46:08.493 [bus debug] ERR: read timeout during ready, switching to skip                                   
2017-04-09 09:46:08.494 [main debug] >>>                                                                               
                                                                                                                       
... lot of empty lines removed ...                                                                                     
                                                                                                                       
2017-04-09 09:46:08.494 [main debug] <<< ERR: command not found                                                         
2017-04-09 09:46:08.494 [network debug] [00007] wait for result                                                         
2017-04-09 09:46:08.494 [network info] [00007] connection closed


Ich überprüfte die Leitung, keine Veränderung. Ich versuchte sowohl neuere als auch ältere Version des Ebusd. Als letzen Versuch installierte ich rasbian (jessie) - und voila, ebusd 2.4 läuft wieder.

Als ich in meine Ebuslogs sehe, die Probleme fing am 21/03/2017 21:24 an. Kürzlich früher, aktualisierte ich viele Programme - volles Log is beigelegt, doch ich meine, dass der 'beste' Kandidat das Kernel oder RPi firmware ist. (P.S. Downgrade in Arch is nicht so leicht...)

Hat jemand Idee, was schiefgehen konnte?

Reinhart

das mit dem Update ist wohl eher Zufall, denn empfangen kannst ja noch alles, nur senden geht nicht, slso dürfte der ebusd ja noch korrekt arbeiten.

Ich würd eher auf den eBus Konverter tippen. Was verwendest du denn für eine Schaltung?

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

MilanK

ebus Koppler von eservice-online.de (mit USB). Ich versuchte auch den Trimmer drehen, besser war das nicht.

Interessant ist, dass im Debian Jessie alles läuft ;-(

Vorläufig habe ich den Koppler an zweites RPi angeschlossen, zum Glück habe in ein Switch im Keller mit freiem Port.

Reinhart

aha, wenn der selbe Koppler unter Debian funktioniert (also auch senden kann), dann hast du wohl recht mit deiner Vermutung, dass es wohl mit einem Update zu tun hat.

Da ich Arch Linux nicht kenne, kann ich dir leider auch nicht weiter helfen. Vielleicht findest du ja im Changelog noch Hinweise was da so alles geändert wurde, speziell im Kernel. Es könnte ja dann irgendwas mit der seriellen Kommunikation zu tun haben.

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

john30

Zitat von: lewej am 08 April 2017, 17:34:33
ich habe das jetzt so angepasst, die Fehler sind fast weg, ist noch eine Adresse die nicht erkannt wird:
okay, dann schick mir doch bitte mal Dein scan result. Ich hab ja auch eine EHP und für Deine müssen die CSVs ein bisschen abgeändert werden.
author of ebusd

john30

Zitat von: lewej am 08 April 2017, 17:38:50
wenn es was bringt, könnte ich das mit einer auroMATIC 560 testen, da meckert sowieso das für die 23 und 25 keine Konfig vorhanden ist, soll ich das machen?
Gute Idee. Brauchst nicht machen, die hab ich selbst ja auch noch (an nem separaten eBUS).
author of ebusd

john30

#2157
Zitat von: MilanK am 09 April 2017, 20:52:23
ebus Koppler von eservice-online.de (mit USB). Ich versuchte auch den Trimmer drehen, besser war das nicht.

Interessant ist, dass im Debian Jessie alles läuft ;-(
da hat Reinhart Recht. Da wird mit dem Update sich das Verhalten der seriellen Schnittstelle geändert habe. Du könntest mal mit größeren Latenzwerten versuchen, das zu kompensieren (siehe wiki Stichwort latency).
Oder Du schaust, wie Du dem neuen Kernel beibringst, nicht so viel zu puffern und jedes einzelne Byte möglichst schnell von/an user level zu transportieren.
author of ebusd

MilanK

Zitat von: john30 am 10 April 2017, 08:25:15
Du könntest mal mit größeren Latenzwerten versuchen, das zu kompensieren (siehe wiki Stichwort latency).
Leider hat es nicht geholfen, der maximale funktionierende Wert war 100000 µs für beide Latenzen. Eigentlich, das RPi is nicht so viel überladen, 'top' zeigt CPU load zwischen 0.05 - 0.40.

Am Ende, downgrade des Kernels zu 4.4.41 hat es gelöst. Ich aktualisiere auch den Report am GitHub.

Prof. Dr. Peter Henning

Äh - setzt mich doch mal ins Bild, weil ich derzeit zu wenig Zeit habe, um alle Beiträge mitzulesen.

Hat da wirklich jemand versucht, über die serielle Schnittstelle zu gehen ?

Das war vor 2 Jahren mein erster Ansatz, ging vollkommen schief, weil diese serielle Schnittstelle im RPi nur per Emulation vorhanden ist und der dauernde Traffic auf dem EBUS diese Emulation total ausgebremst hat. Führte zu gewaltigen Verzögerungen bei der Weitergabe von Daten an den ebusd - Rekord waren 90 Minuten.

Bei dem USB-Zugang sollte das aber nicht auftreten.

LG

pah