search

john30 / ebusd

daemon for communication with eBUS heating systems
GNU General Public License v3.0
560 stars 130 forks source link

How can i check if sending to eBus works? - Vaillant ecoCompact #274

Closed twischi closed 2 years ago

twischi commented 5 years ago

Dear All, today I again tried to get the ebusd running with my heating system.

My Vaillant Heating System is

I used a oscilloscope to adjust the potentiometer on eBUS Platine v1.6 and in addition followed the instructions

When I start ebusd

sudo ebusd --scanconfig --logfile=/var/log/ebusd.log --loglevel=debug -f

it looks fine in general 

2019-03-24 21:28:28.330 [main notice] ebusd 3.3.v3.3 started with auto scan
2019-03-24 21:28:28.330 [main info] loading configuration files from http://ebusd.eu/config/
2019-03-24 21:28:28.511 [main info] reading templates /
2019-03-24 21:28:28.537 [main info] read templates in /
2019-03-24 21:28:28.537 [main info] reading file memory.csv
2019-03-24 21:28:28.562 [main info] successfully read file memory.csv
2019-03-24 21:28:28.562 [main info] reading file broadcast.csv
2019-03-24 21:28:28.588 [main info] successfully read file broadcast.csv
2019-03-24 21:28:28.588 [main info] read config files
2019-03-24 21:28:28.603 [bus notice] bus started with own address 31/36
2019-03-24 21:28:28.603 [main info] registering data handlers
2019-03-24 21:28:28.603 [main info] registered data handlers
2019-03-24 21:28:28.606 [bus debug] ERR: SYN received during no signal, switching to ready
2019-03-24 21:28:28.606 [bus notice] signal acquired
2019-03-24 21:28:32.322 [bus notice] new master 10, master count 2
2019-03-24 21:28:32.358 [bus notice] new master 03, master count 3
2019-03-24 21:28:32.358 [update info] received MS cmd: 1008b510090000006effff01ff00 / 0101
2019-03-24 21:28:32.358 [update notice] received unknown MS cmd: 1008b510090000006effff01ff00 / 0101
2019-03-24 21:28:36.436 [update info] received MS cmd: 1008b5110101 / 09424280094e600000ff
2019-03-24 21:28:36.437 [update notice] received unknown MS cmd: 1008b5110101 / 09424280094e600000ff

but is looks like that no equipmentment can be identified automatically

In a second terminal-window i call

sudo ebusctl scan full

and get many timeouts

2019-03-24 21:35:58.201 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.201 [bus info] scan 04 cmd: 3104070400
2019-03-24 21:35:58.246 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.247 [bus info] scan 05 cmd: 3105070400
2019-03-24 21:35:58.292 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.292 [bus info] scan 06 cmd: 3106070400
2019-03-24 21:35:58.334 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.335 [bus info] scan 08 cmd: 3108070400
2019-03-24 21:35:58.378 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.379 [bus info] scan 09 cmd: 3109070400
2019-03-24 21:35:58.422 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.423 [bus info] scan 0a cmd: 310a070400
2019-03-24 21:35:58.469 [bus debug] notify request: ERR: read timeout
2019-03-24 21:35:58.469 [bus info] scan 0b cmd: 310b070400
2019-03-24 21:35:58.512 [bus debug] notify request: ERR: read timeout

In the "info" no identified equipmentment is shown: 

sudo ebusctl info
version: ebusd 3.3.v3.3
signal: acquired
symbol rate: 22
max symbol rate: 42
reconnects: 0
masters: 3
messages: 12
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

I asked my self may there a problem in "sending" commands to the eBUS with the adapter? How can I test if sending to the bus works?

Regards Thomas

john30 commented 5 years ago

simply activate the raw log, issue an arbitrary send command and check if at least the sent master address (e.g. ">31") is read back from the bus (i.e. "<31").

twischi commented 5 years ago

Dear John, thanks for you hint.

Done a lot without success :-(

First checked if only one instance is running ps aux|grep ebusd what is the case.

Than modified the ebusd start parameters:

ebusd --scanconfig=full -c /etc/ebusd/ebusd-configuration --enablehex --lograwdata --logareas=all --logfile=/var/log/ebusd.log --loglevel debug -f

At "scan full" I can see a lot ">31" message and no "<31":

2019-03-26 22:44:37.576 [main notice] ebusd 3.3.v3.3 started with full scan
2019-03-26 22:44:37.576 [main info] loading configuration files from /etc/ebusd/ebusd-configuration
2019-03-26 22:44:37.576 [main info] read config files
2019-03-26 22:44:37.590 [bus notice] bus started with own address 31/36
2019-03-26 22:44:37.590 [main info] registering data handlers
2019-03-26 22:44:37.590 [main info] registered data handlers
2019-03-26 22:44:37.637 [bus debug] ERR: SYN received during no signal, switching to ready
2019-03-26 22:44:37.637 [bus notice] signal acquired
2019-03-26 22:44:38.525 [bus notice] new master 10, master count 2
2019-03-26 22:44:38.594 [bus notice] new master 03, master count 3
2019-03-26 22:44:38.594 [update info] received MS cmd: 1008b5110101 / 093838a008464e0000ff
2019-03-26 22:44:38.594 [update notice] received unknown MS cmd: 1008b5110101 / 093838a008464e0000ff
2019-03-26 22:44:38.599 [bus notice] <1008b51101018900093838a008464e0000ff0c00
2019-03-26 22:44:40.535 [update info] received MS cmd: 1008b5100305ff01 / 00
2019-03-26 22:44:40.535 [update notice] received unknown MS cmd: 1008b5100305ff01 / 00
2019-03-26 22:44:40.540 [bus notice] <1008b5100305ff019800000000
2019-03-26 22:44:44.612 [update info] received MS cmd: 1008b510090000006effff05ff00 / 0101
2019-03-26 22:44:44.613 [update notice] received unknown MS cmd: 1008b510090000006effff05ff00 / 0101
2019-03-26 22:44:44.618 [bus notice] <1008b510090000006effff05ff00760001019a00
2019-03-26 22:44:47.591 [main debug] performing regular tasks
2019-03-26 22:44:47.592 [main notice] starting initial full scan
2019-03-26 22:44:47.592 [bus info] scan 02 cmd: 3102070400
2019-03-26 22:44:47.641 [bus debug] notify request: ERR: read timeout
2019-03-26 22:44:47.641 [bus info] scan 04 cmd: 3104070400
2019-03-26 22:44:47.673 [bus notice] >31
2019-03-26 22:44:47.688 [bus debug] notify request: ERR: read timeout
2019-03-26 22:44:47.688 [bus info] scan 05 cmd: 3105070400
2019-03-26 22:44:47.718 [bus notice] >31
2019-03-26 22:44:47.733 [bus debug] notify request: ERR: read timeout
2019-03-26 22:44:47.733 [bus info] scan 06 cmd: 3106070400
2019-03-26 22:44:47.761 [bus notice] >31
2019-03-26 22:44:47.776 [bus debug] notify request: ERR: read timeout
2019-03-26 22:44:47.776 [bus info] scan 08 cmd: 3108070400
2019-03-26 22:44:47.810 [bus notice] >31

In the second terminal windows i try to send "hex"- commands for example like this:

ebusctl write -h 08b5090101

but always get this info:

ebusctl write -h 08b5090101
usage: write [-s QQ] [-d ZZ] -c CIRCUIT NAME [VALUE[;VALUE]*]
  or:  write [-s QQ] [-d ZZ] -def DEFINITION [VALUE[;VALUE]*]
  or:  write [-s QQ] [-c CIRCUIT] -h ZZPBSBNN[DD]*
 Write value(s) or hex message.
  -s QQ        override source address QQ
  -d ZZ        override destination address ZZ
  -c CIRCUIT   CIRCUIT of the message to send
  NAME         NAME of the message to send
  VALUE        a single field VALUE
  -def         write with explicit message definition:
    DEFINITION message definition to use instead of known definition
  -h           send hex write message:
    ZZ         destination address
    PB SB      primary/secondary command byte
    NN         number of following data bytes
    DD         data byte(s) to send

I played around with this options --latency=0 --acquiretimeout=30000 --answer than point manually to config-file -c /etc/ebusd/ebusd-configuration, but nothing changes problem that I get not identified scan results.

Do you think "sending" commands works? Any idea what i can do, or what could be the problem?

Regards Thomas

john30 commented 5 years ago

it is described in detail here, so you should follow that one first. and scanning or reading without the poti being adjusted well won't work/help here. the whole problem with the poti was the reason for us initiating the new adapter.

twischi commented 5 years ago

Dear John this morning I done the Poti-adjustment again, like you suggested. Remark: Done this before. (And in addition a looks with my oscilloscope to the Rx-Signal)

I startet from the "most left" Poti-adjustment that works with stable "<aa" then go further to "the right (clockwise)" in small steps. Always checks step by step if now eBus participants answers. But no success. What is strange to me, is that i reached the most right-position of the Poti and still get messages. Could this be an indication that something is wrong with my hardware eBUS Platine v1.6? Regards Thomas

create1st commented 5 years ago

it is described in detail here, so you should follow that one first. and scanning or reading without the poti being adjusted well won't work/help here. the whole problem with the poti was the reason for us initiating the new adapter.

Hi @john30, Is there anywhere a PCB Schema for v2 or how can I get one? Thanks, Sebastian

john30 commented 5 years ago

if you never see a sent byte received again, this most probably indicates a damages send path on the adapter

john30 commented 5 years ago

@create1st for the time being you'd have to wait for the next mass order that will start sometime in autum this year

twischi commented 5 years ago

Dear All, yesterday I made a deep dive to how do the eBus Platine V1.6 works and now fully understand the electrical circuit. The Potentiometer for adjustments only impacts the "reading part", was a key learning. With my oscilloscope i could see that NO send command reaches the eBus. So what John mentioned is most properly truth. I now try to get a used V1.6 know as working in former times. I will give update here as soon as I can test it. Regards Thomas

kalledausb commented 5 years ago

Hi @create1st , since I have a working v2.2 I could send You my old v2 device. Just let me know how to contact You for details in case You're interested.

Cheers Kalle

create1st commented 5 years ago

Hi @create1st , since I have a working v2.2 I could send You my old v2 device. Just let me know how to contact You for details in case You're interested.

Cheers Kalle Hi @kalledausb catch me at sebastian.gil@gmail.com I’m from Poland BTW.

twischi commented 5 years ago

Today I received "the other" eBus Platine V1.6 and it immediately works like charm :-) This means the "sending-part" of my own V1.6-Platine has an defect.

What could be the indications, if "you" ever have a similar problem:

With the "working reference" I hopefully can find the defect.
Greets Thomas

samm-git commented 5 years ago

I have the same issue with mine :( Do you got it fixed?

twischi commented 5 years ago

Dear Samm-git, in my case it simply was a hardware problem. I replaced the e-bus platine and it worked fine. Regards Thomas

samm-git commented 5 years ago

@twischi JFYI and for other members. I was able to fix mine! Describing for history, may be someone else will need that:

  1. I connected device to bus and usb and initiated endless write to the port.
  2. With a tester i found that output voltage on U4 is lower then 5v, but is 3v. Good news is that when i was stopping output to port it became 0, so output chain is alive!
  3. I also found that there is a signal on t1 input and z1 output , but voltage level is lower then ebus specification sets. TBH, am not sure about the reason but i just reduced R6 capacity to 18K and, magic, it starts to work! To make it more stable i added --latency 5000 --acquiretimeout=15000 - so far it works good, but in rare cases i am getting ACK error. Anyway, works good enough for me :)

P.S. I been able to get rid of high latency settings using UART low latency flag.

john30 commented 2 years ago

closed due to inactivity