Support for Weishaupt WRSOL2.1

[nokia001]

Hi is there a config for WRSOL2.1?

thx

[john30]

No, there is no specific config for that device yet. However, some of the files in the ebusd-2.x.x/de/wolf folder might work since some of the messages are based on eBUS specification only.

One more thing: another user has provided details for a Weishaupt WTC unit, which might also help decoding a WRSOL...

[bidouilleur31]

could this be of some help to decode the wrsol ? http://ebus-wiki.org/lib/exe/fetch.php/ebus/wrsol.pdf I have one of these wrsol devices and am also looking into the ebus of it to retrieve the data real time. No write but read only in my case (maybe on day to write but would already be very happy to read)

[john30]

we can give it a try and read one of the values mentioned in there. which one are you interested in most? try ebusctl r -d f7 -i 62596,2 ram to get the upper storage temperature in hex (still has to be decoded and reformatted)

[bidouilleur31]

Before that I need to get me an adapter etc and build what is needed to read. But since I found this document and already nokia001 was looking for it ... maybe he has already a system connected. In my case it'll be soon, need to get bits and pieces first. Will be back once I have the hardware. Thanks for the reply in the meantime.

[john30]

you're welcome

[bidouilleur31]

Hello John, got the ebus converter hooked up to the wrsol, linked to a raspberry, think I installed ebusd but from here I'm in the dark as I can't find much how this thing works. Your above mentioned command gives : ERR: invalid address But I guess there must be a few steps I didn't do but sorry to say ... your installation intructions are a bit .... for experts and I'm novice. I found more details on this page : http://www.fhemwiki.de/wiki/EBUS but German isn't my best language ... trial and error one command i issued might already help you undrstand where I'm stuck ... I hope

pi@wrsolpi:/ $ ebusctl info
version: ebusd 2.2.8e247be
signal: acquired
symbol rate: 33
masters: 1
messages: 0
address 31: master #8, ebusd
address 36: slave #8

Also I don't think this is the best place to exchange since my problem for now is understanding how your daemon works (and basically how a daemon works in general) Is there a more appropriate channel so not to pollute your github ? thanks

[john30]

Okay, first of all you need to get your coupler working correctly. It has a potentiometer that needs to be adjusted very carefully to your signal. The way I do it (and I think the FHEM wiki uses this description as an alternative to another one) is to first turn the poti fully counter clock wise. Then start ebusd in foreground with raw logging enabled in order to see the bytes travelling on the eBUS. After that, I turn the poti so far clock wise, that the raw logging more or less stops. From there the poti has to be turned back again very very little until "<aa" or other bytes arrive constantly. See also my comment in the FHEM forum.

The command I gave you was a little bit wrong. Once your poti is adjust, try this one: ebusctl r -d fc -i 62596,2 ram

[bidouilleur31]

Hello H_John, thanks for the feedback Did as mentioned on German forum and was able to fine tune though the values coming back do change a bit when I give a little more or less once the signal is acquired. It begins with <00 and further up it give

<00 2016-11-02 20:22:53.120 [bus notice] <aa 2016-11-02 20:22:53.124 [bus notice] <10 2016-11-02 20:22:53.128 [bus notice] <00

and with a bit more it goes to

<aa 2016-11-02 20:23:03.681 [bus notice] <10 2016-11-02 20:23:03.685 [bus notice] <fc 2016-11-02 20:23:03.737 [bus notice] <aa

not to sure where I have to calibrate but anyway

then I tried to give your above mentioned command and at first I had a problem but see below

pi@wrsolpi:~ $ ebusctl r -d fc -i 62596,2 ram error connecting to localhost:8888 pi@wrsolpi:~ $ sudo ebusd --port=8888 pi@wrsolpi:~ $ ebusctl r -d fc -i 62596,2 ram ERR: invalid numeric argument pi@wrsolpi:~ $ ebusctl r -d fc -i 62596,2 ram ERR: invalid numeric argument pi@wrsolpi:~ $ sudo ebusctl r -d fc -i 62596,2 ram ERR: invalid numeric argument

getting closer but not yet there

Would the german forum have a problem if I join there but start and english topic ? Instead polluting this nice GitHub account ?

[john30]

Again my fault, the correct command is this: ebusctl r -d fc -i 62596;2 ram

For fine-tuning you should check for CRC errors in the debug level logging. You can switch off the raw output for that one.

Sure, go ahead and start an english topic if you want. But we can continue here as well.

[bidouilleur31]

this is the result

-bash: 2: command not found

trying to understand what I do, trying to read the forum topic to learn some more.. hoping to advance alone but have to say I fail ..

ps : the more I try the more it goes square now I'm unable to get to link to the ttyUSB0

[bus error] unable to open /dev/ttyUSB0: ERR: generic device error

reboot, sudo not sudo ..not one single command is making it to the usb port anymore .. ok I know linux level problem I guess but still ..

[john30]

well in this case you need to fix that first. and where did the "-bash: 2: command not found" result from? what did you enter?

[bidouilleur31]

The reply is what comes back from your latest command.

Will spend some more time this weekend to get this bus working. Not sure why it is acting like this. Different logs don't show any error so bit harder to trace down the origin of the error.

[john30]

well you were able to run that command before, so something is wrong on your OS. As said, you need to fix that first and especially the USB issue. It does not make much sense to dig around when the basics are not working correctly.

[bidouilleur31]

not sure where it goes wrong Started all up again, was again able to get to the part where you adjust the potentiometer though I still can't understand (told you my german is limited) if I had to adjust so to only have aa or when I get something else .. though according where I set it the return is slightly diffferent but a continuous flow once set ... always the same set coming up

I did again your command from earlier and this is the result (included service status)

root@wrsolpi:/etc/ebusd# service ebusd status ● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems. Loaded: loaded (/etc/init.d/ebusd) Active: active (exited) since Sat 2016-11-05 15:38:45 CET; 1min 32s ago Process: 1229 ExecStop=/etc/init.d/ebusd stop (code=exited, status=0/SUCCESS) Process: 1277 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS) Nov 05 15:38:45 wrsolpi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems.. root@wrsolpi:/etc/ebusd# ebusctl r -d fc -i 62596;2 ram usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v|-V] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]] or: read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx Read value(s) or hex message. -f force reading from the bus (same as '-m 0') -m SECONDS only return cached value if age is less than SECONDS [300] -c CIRCUIT limit to messages of CIRCUIT -d ZZ override destination address ZZ -p PRIO set the message poll priority (1-9) -v increase verbosity (include names/units/comments) -V be very verbose (include names, units, and comments) -n use numeric value of value=name pairs -i VALUE read additional message parameters from VALUE NAME NAME of the message to send FIELD only retrieve the field named FIELD N only retrieve the N'th field named FIELD (0-based) -h send hex read message (or answer from cache): ZZ destination address PB SB primary/secondary command byte NN number of following data bytes Dx data byte(s) to send bash: 2: command not found

[john30]

due to execution in a shell you'll have to escape the semicolon or put the argument behind "-i" in quotes, i.e.: ebusctl r -d fc -i '62596;2' ram

[bidouilleur31]

root@wrsolpi:/etc/ebusd# ebusctl r -d fc -i '62596;2' ram ERR: arbitration lost

once I had invalid argument when playing with the potentiometer ....

[bidouilleur31]

going to stop bothering you. This is not working whatever I try, getting error after error then the device becomes generic etc ... this is high geek level way above my options and all the things I can find online are german only ... this is going to take way to long for you I'm afraid, just to get the ebus converter talk to a simple usb port. Just hope the hex thing I found will serve someone knowing that the wrsol is basically a TEM device. Sorry again for the trouble.

[tikismoke]

@bidouilleur31 n'abandonne pas y a forcément moyen d'y arrivé ;) passe sur gitter pour discuter en français si ça peut aider.

[bidouilleur31]

@tikismoke bonjour à toi. Ce n'est pas vraiment abandonner mais disons que mon niveau est trop bas pour l'instant et je souhaite respecter John en ne pas abusant son temps. J'ai trouvé Gitter mais je t'avoue ne pas avoir utilisé avant, encore un truc à explorer. Je t'ai trouvé mais de là ... ;-)

[bidouilleur31]

thanks to @tikismoke I understand way better why it failed, thanks to him. Since, I've been trying to get the bus stabilised to show only <aa and nothing else. Very tricky and unstable to say. Hardly go to the computer and I get <aa <00 again. Not sure why it is so unstable ... And when I finally can get a +/- stable situation launching for example ebusctl scan full -> ends empty and when I go back to see raw it just went back to <aa <00 .... when playing with the setting I can get more hex values like <10 and then depending going to <ff ... mostly last on the series of 3 changes slowly with change of potentiometer ... The most stable <aa is near the end (max) before loosing signal again. WhenI launch a scan or your command I get invalid argument

[bidouilleur31]

ok an hour fooling extra. On the wrsol2 I remembered there is an extra menu with PW. As a good boy I unlocked it and found an ebus menu with ebus adresse : from 2 to 16 2 gives a very fast signal (led blinks rapidly and in raw mode you see the lines flash by) 16 is the other extreme (led blinks like once a sec and the lines in raw are going the same speed) Also rereading the document I added earlier it tells the wrsol waits for some sync signal

But whatever ebus adresse I take, the scan stays empty even if now I can stabilise <aa

[bidouilleur31]

Played some more with the wrsol today. Tried bus 2 to 16 and except being slower (led blinks way slower the higher the number ..) didn't see anything It is still very difficult to get a stable <aa when on ebus 2. Even if I finally get it, after a few commands it goes away again to more alternative returns. achat I did (thanks again for the help @tikismoke ) terminal one with following command : ebusd -f -d /dev/ttyUSB0 --loglevel=info terminal two to launch several commands line ebusctl raw scans etc and see on terminal one the result

ex your command when I have a stable <aa (never lasts very long)

2016-11-07 15:34:06.769 [network info] [00003] client connection opened 127.0.0.1 2016-11-07 15:34:06.769 [bus info] send message: 31fc09000384f402 2016-11-07 15:34:06.807 [bus error] send to fc: ERR: invalid argument, retry 2016-11-07 15:34:06.897 [bus error] send to fc: ERR: invalid argument, retry 2016-11-07 15:34:06.979 [bus error] send to fc: ERR: invalid argument, retry 2016-11-07 15:34:07.077 [bus error] send to fc: ERR: invalid argument 2016-11-07 15:34:07.077 [main error] send message part 0: ERR: invalid argument 2016-11-07 15:34:07.079 [network info] [00003] connection closed

a ebusctl scan full

2016-11-07 15:34:46.708 [network info] [00004] client connection opened 127.0.0.1 2016-11-07 15:34:46.708 [bus info] scan 02 cmd: 3102070400 2016-11-07 15:34:46.709 [network info] [00004] connection closed 2016-11-07 15:34:46.747 [bus error] scan 02 failed (227 slaves left): ERR: invalid argument 2016-11-07 15:34:46.747 [bus info] scan 04 cmd: 3104070400 2016-11-07 15:34:46.818 [bus error] scan 04 failed (226 slaves left): ERR: invalid argument 2016-11-07 15:34:46.818 [bus info] scan 05 cmd: 3105070400 2016-11-07 15:34:46.888 [bus error] scan 05 failed (225 slaves left): ERR: invalid argument 2016-11-07 15:34:46.888 [bus info] scan 06 cmd: 3106070400

and so on till slave 1 and the scan result is empty

on the box I do see the led blink more intense when the commands pass. Makes me think we're on the wrong bus or on the wrong speed ... in any case the connection is very unstable and the wrsol does not reply with something sensible. Not sure this can help but the data can be written to a sd card and it is done once every 30 secs (quite a long string) Not sure what is the next step? Ask help on the german forum ?

[bidouilleur31]

after upgrading to latest ebusd still nothing

root@wrsolpi:/home/pi# ebusctl info version: ebusd 2.3.5bcc475 signal: acquired symbol rate: 20 masters: 1 messages: 10 conditional: 0 poll: 0 update: 7 address 31: master #8, ebusd address 36: slave #8 root@wrsolpi:/home/pi# ebusctl r -d fc -i '62596;2' ram ERR: element not found

[tikismoke]

the weird things is that nothing else except ebusd (31 and 36) appear on the bus

[john30]

first of all the adjustment of the interface needs to be fixed, after that we can check for messages and participants on the bus. So please start ebusd without changing any further, enable the raw logging (via "ebusctl raw"), let ebusd continue to run for 30 seconds or so, and then send me the log file.

[bidouilleur31]

ok here is the beginning of the dump, not going to post the full length as once the <aa start ... they just go on and on ... not a single other string for over a full minute

command used to create the dump : ebusd -d /dev/ttyUSB0 --lograwdata --logfile=/tmp/ebusd_raw.bin

2016-11-0821:01:32.886 [bus notice] <00 2016-11-08 21:01:32.887 [bus notice] <00 2016-11-08 21:01:32.888 [bus notice] <00 2016-11-08 21:01:32.889 [bus notice] <00 2016-11-08 21:01:32.890 [bus notice] <00 2016-11-08 21:01:32.891 [bus notice] <00 2016-11-08 21:01:32.892 [bus notice] <aa 2016-11-08 21:01:32.905 [main error] error reading config files: ERR: duplicate entry, /etc/ebusd/vaillant/15.350.csv:8 2016-11-08 21:01:32.905 [main notice] found messages: 210 (4 conditional on 4 conditions, 0 poll, 4 update) 2016-11-08 21:01:32.920 [bus notice] <aa 2016-11-08 21:01:32.970 [bus notice] <aa 2016-11-08 21:01:33.020 [bus notice] <aa 2016-11-08 21:01:33.071 [bus notice] <aa .....

just imagine the same line with just another timestamp for 60 seconds till I stop it ... the log doesn't show more then the beginning you have and the last timestamp<aa when I kill ebusd pid. Seems to be no communication on this line

[john30]

well then obviously nothing is sent by the circuits on this bus, so it's difficult to adjust the poti accordingly. you could try and do a full scan to see if some circuit responds at least. Please send me the full log with raw logging enabled of this one per email, I dont want to flush this issue that much: ebusd@ebusd.eu

[bidouilleur31]

As said the wrsol has like adresses 2 to 16 with different speeds. Will try to dump all 14 and see/send the dumps

I wonder if there isn't another hidden menu to activate the bus or it needs an incoming ping to send back the info.

[bidouilleur31]

Hello John, yesterday a friend coder was here and we tried to communicate with the wrsol via javascript. Basically it didn't work to nicely as we never received the expected reply. He won't be available for another 3 weeks (he's for a trip to China) but here are a few things that maybe might help a little more

I tried all the adresses that are mentioned in the hidden wrsol menu and the only difference we could see is speed. The higher the number the lower the 'busspeed'. Only real advantage is that when we go to 5 instead 2 we can stabilize the return <aa (ack) So we played from there on. We also used Tony's experiencethough the thread doens't give a solution. Coupled with this document mentioned earlier in this thread.

We tried sending several messages to try to get an identification from the wrsol and we failed. It never ever gave the expected result. Or the docment from Weishaupt isn't correct anymore (could be) or the ebus crc isn't implemented as we found. SO we are stuck for now

here is the command we send and then the return (though the crc isn't correct on this one accoding us)

root@wrsolpi:/home/pi/ebus# java -jar EbusTest.jar Send : 77 fc 07 04 01 00 bf aa 77 fc 07 84 ff 00 aa 00

we tried several commands and basically what we saw (Tony says the same) is that we get the string send back ... sometimes with a little change but nothing that makes sense. Even if the crc is set voluntary wrong we don't get the error back .. just like an echo from send string ..

Only thing we could conclude, the ebus reacts but not as expected ...

[john30]

wow, you're going hard the way :-) why do you write your own tool for communicating with the bus instead of using ebusd? Anyway, if none of the slaves reacts on a query, then there might just not be anything on the bus, right? on the other hand, you had some symbols other than 0xaa sent around as stated in your comment https://github.com/john30/ebusd-configuration/issues/9#issuecomment-257976725, so i sstill think you should get back to that state and adjust the poti until you receive those messages that are obviously being sent on the bus.

[bidouilleur31]

Reason to avoid your ebusd was to be able to be sure what we send and what we receive. There isn't much more to to with the potentiometer. With adresse 8 (constant <aa with raw command) when issuing your string I again get this reply

2016-11-13 11:38:06.784 [network info] [00002] client connection opened 127.0.0.1 2016-11-13 11:38:06.785 [network info] [00002] connection closed 2016-11-13 11:39:13.098 [network info] [00003] client connection opened 127.0.0.1 2016-11-13 11:39:13.098 [bus info] send message: 31fc09000384f402 2016-11-13 11:39:13.418 [bus error] send to fc: ERR: invalid argument, retry 2016-11-13 11:39:13.978 [bus error] send to fc: ERR: invalid argument, retry 2016-11-13 11:39:14.549 [bus error] send to fc: ERR: invalid argument, retry 2016-11-13 11:39:15.119 [bus error] send to fc: ERR: invalid argument 2016-11-13 11:39:15.119 [bus error] send message part 0: ERR: invalid argument 2016-11-13 11:39:15.120 [network info] [00003] connection closed

[john30]

well thats exactly what the raw mode is for...

[bidouilleur31]

I know, you explained it well, so I have now the constant <aa but whatever you send, the reply gives error or just bouncing back the send string ... depending what tool you use. (btw friend coder made his script in less then 5 minutes btw so that was not an issue, think you can qualify him as geek ;-) )

[john30]

I only wonder why you don't get the values as in the mentioned comment any more. something must have changed, so you should try to get back to that state.

[bidouilleur31]

upgraded to 2.3 ... maybe I did it incomplete or bad ? Maybe I should re install ebusd from scratch ? What are the commands to delete everything (for sure and not forgetting bits and pieces ..)

[bidouilleur31]

weird; was letting the raw spit out and after several time i get this

2016-11-13 13:09:01.044 [bus notice] <aa 2016-11-13 13:09:01.574 [bus notice] <aa 2016-11-13 13:09:02.103 [bus notice] <aa 2016-11-13 13:09:02.634 [bus notice] <aa 2016-11-13 13:09:02.638 [bus notice] <31 2016-11-13 13:09:02.642 [bus notice] <fe 2016-11-13 13:09:03.173 [bus notice] <aa 2016-11-13 13:09:03.177 [bus notice] <fe 2016-11-13 13:09:03.182 [bus notice] <01 2016-11-13 13:09:03.186 [bus notice] <0b 2016-11-13 13:09:03.723 [bus notice] <aa 2016-11-13 13:09:03.727 [bus notice] <45 2016-11-13 13:09:03.732 [bus notice] <53 2016-11-13 13:09:04.264 [bus notice] <aa 2016-11-13 13:09:04.268 [bus notice] <36 2016-11-13 13:09:04.272 [bus notice] <35 2016-11-13 13:09:04.277 [bus notice] <a0 2016-11-13 13:09:04.813 [bus notice] <aa 2016-11-13 13:09:04.817 [bus notice] <20 2016-11-13 13:09:04.822 [bus notice] <45 2016-11-13 13:09:05.353 [bus notice] <aa 2016-11-13 13:09:05.357 [bus notice] <20 2016-11-13 13:09:05.361 [bus notice] <4f 2016-11-13 13:09:05.892 [bus notice] <aa 2016-11-13 13:09:05.898 [bus notice] <4b 2016-11-13 13:09:05.902 [bus notice] <ff 2016-11-13 13:09:05.906 [bus notice] <0b 2016-11-13 13:09:05.911 [bus notice] <aa 2016-11-13 13:09:06.442 [bus notice] <aa 2016-11-13 13:09:06.973 [bus notice] <aa

seems the bus is sending out something but with large interval, going to see when next pops up and determine timelapse

[bidouilleur31]

here you go exact same string after 5 minutes

2016-11-13 13:14:02.652 [bus notice] <31 2016-11-13 13:14:02.656 [bus notice] <fe 2016-11-13 13:14:03.189 [bus notice] <aa 2016-11-13 13:14:03.193 [bus notice] <fe 2016-11-13 13:14:03.197 [bus notice] <01 2016-11-13 13:14:03.201 [bus notice] <0b 2016-11-13 13:14:03.738 [bus notice] <aa 2016-11-13 13:14:03.742 [bus notice] <45 2016-11-13 13:14:03.746 [bus notice] <53 2016-11-13 13:14:04.278 [bus notice] <aa 2016-11-13 13:14:04.282 [bus notice] <36 2016-11-13 13:14:04.287 [bus notice] <35 2016-11-13 13:14:04.291 [bus notice] <a0 2016-11-13 13:14:04.828 [bus notice] <aa 2016-11-13 13:14:04.832 [bus notice] <20 2016-11-13 13:14:04.836 [bus notice] <45 2016-11-13 13:14:05.367 [bus notice] <aa 2016-11-13 13:14:05.373 [bus notice] <20 2016-11-13 13:14:05.376 [bus notice] <4f 2016-11-13 13:14:05.907 [bus notice] <aa 2016-11-13 13:14:05.911 [bus notice] <4b 2016-11-13 13:14:05.916 [bus notice] <ff 2016-11-13 13:14:05.920 [bus notice] <0b 2016-11-13 13:14:05.924 [bus notice] <aa

[john30]

finally a useful comment. what interface do you have exactly? it seems to be a network connected one, because of the time gaps of 550ms in the reception. try using "--latency=200000" for a start, but even that might not be enough. did you set up the device correctly?

[bidouilleur31]

this is the command I use to launch ebusd manually

ebusd -f -d /dev/ttyUSB0 --loglevel=info --enablehex

will add the latency

and what do you mean by setting up the device correctly? remember I use a slower adresse from the wrsol, if I use adresse 2 at full speed it is impossible to stabelise to <aa

got again the same string coming in exactly 4 mins after start of modified command, expecting it at 13:28 wrong : arrived after 5 mins 13:29 ...

[john30]

then you have a serial converter that is really bad. or do you use the RPi integrated serial port? That's not usable at all.

[bidouilleur31]

I us a pi3 that has 4 integrated usb ports .. and the dongle is seen

root@wrsolpi:/home/pi# lsusb Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[bidouilleur31]

the decoded string gives something useful 1ES65 E is partly the name of the wrsol but TEM code wrsol = ES 651X from TEM

[tikismoke]

with samme device on a pib+ and my TEM1111 i use this options: EBUSD_OPTS="-d /dev/ttyUSB0 --loglevel=info --latency=10000 --enablehex --receivetimeout 10000"

[bidouilleur31]

with command from tikismoke the same string is still passing by every 5 minutes with a few <aa <fe ... just changed it to superior address with a little higher speed, see what happens next

[bidouilleur31]

here is the string again with the higher speed, almost identical, just beginning and end change

2016-11-13 14:44:01.091 [bus notice] <aa 2016-11-13 14:44:01.095 [bus notice] <11 2016-11-13 14:44:01.100 [bus notice] <fe 2016-11-13 14:44:01.552 [bus notice] <aa 2016-11-13 14:44:01.556 [bus notice] <fe 2016-11-13 14:44:01.560 [bus notice] <01 2016-11-13 14:44:01.565 [bus notice] <0b 2016-11-13 14:44:02.021 [bus notice] <aa 2016-11-13 14:44:02.026 [bus notice] <45 2016-11-13 14:44:02.030 [bus notice] <53 2016-11-13 14:44:02.034 [bus notice] <36 2016-11-13 14:44:02.491 [bus notice] <aa 2016-11-13 14:44:02.495 [bus notice] <35 2016-11-13 14:44:02.499 [bus notice] <20 2016-11-13 14:44:02.504 [bus notice] <fc 2016-11-13 14:44:02.961 [bus notice] <aa 2016-11-13 14:44:02.966 [bus notice] <45 2016-11-13 14:44:02.970 [bus notice] <20 2016-11-13 14:44:03.420 [bus notice] <aa 2016-11-13 14:44:03.425 [bus notice] <4f 2016-11-13 14:44:03.429 [bus notice] <4b 2016-11-13 14:44:03.433 [bus notice] <ff 2016-11-13 14:44:03.891 [bus notice] <aa 2016-11-13 14:44:03.895 [bus notice] <a0 2016-11-13 14:44:03.899 [bus notice] <aa

[john30]

as you can see in the timestamps, there is a pause of 550ms between some blocks of data. this is the problem that needs to get solved and it is related to the driver for the serial device. You could check if the module used for that driver allows starting it with some parameters. the parameter to look for is related to buffering and timing.