Read timeouts while reading (not sending)

[codeaholics]

Hello. I'm building this eBus converter and trying to connect it to ebusd: https://wiki.fhem.de/wiki/EBUS

I've trimmed it as best I can with my bench equipment, and measured the voltages, etc. and everything is looking pretty good, except I keep getting read timeouts just while listening to the bus - not trying to send. I've read #79 about latency, and I don't think that's the issue.

I've connected the board directly to the GPIO/UART of a RPi 3. (I've tested that the board works OK with 3.3v on the low-voltage side, and it seems to be just fine). I'm running Debian Jessie (I guess Raspbian) with this kernel: Linux ebus 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux. This kernel is known to have the latency issue, I believe.

I've built the daemon myself from git rev 7a569e2 which includes the source code fix for setting the low-latency flag on the serial port.

Here is a snippet of my output with --logareas=bus --loglevel=debug --lograwdata:

2017-06-07 21:29:29.196 [bus notice] <7f08b503020001ea00
2017-06-07 21:29:29.462 [bus notice] <7f08b510091e004affff0000ff00be00
2017-06-07 21:29:30.995 [bus notice] <7f150704f8b47f08b51101c0fe00
2017-06-07 21:29:31.263 [bus notice] <7f08b51101019e00
2017-06-07 21:29:31.518 [bus notice] <7f08b51101029d00
2017-06-07 21:29:31.761 [bus notice] <7f08b509030d4bc0fe00
2017-06-07 21:29:32.039 [bus notice] <7f08b5030200e1fd00
2017-06-07 21:29:32.309 [bus notice] <7f08b5100900fe4affff007cff00bc00
2017-06-07 21:29:33.393 [bus notice] <7f08b51101009f00
2017-06-07 21:29:33.662 [bus notice] <7f08b51101019e00
2017-06-07 21:29:33.917 [bus notice] <7f08b51101239d00
2017-06-07 21:29:34.160 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:34.437 [bus notice] <7f08b50302ff01ea00
2017-06-07 21:29:34.708 [bus notice] <7f08b51009c04affff0000ff00bc00
2017-06-07 21:29:35.796 [bus notice] <7f08b51101009f00
2017-06-07 21:29:36.064 [bus notice] <7f08b51101f99e00
2017-06-07 21:29:36.319 [bus notice] <7f08b51101029d00
2017-06-07 21:29:36.606 [bus notice] <7f08b509030d4b00fb00
2017-06-07 21:29:36.880 [bus notice] <7f08b503020001ee00
2017-06-07 21:29:37.146 [bus notice] <7f08b5900900904affff0000ff40bc00
2017-06-07 21:29:38.278 [bus notice] <7f08b51101f8fe00
2017-06-07 21:29:38.547 [bus notice] <7f08b51101019e00
2017-06-07 21:29:40.053 [bus notice] <7f08b51101029d00
2017-06-07 21:29:40.297 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:40.573 [bus notice] <7f08b503028081ee00
2017-06-07 21:29:40.840 [bus notice] <7f08b5100900004affff0000ff00bc00
2017-06-07 21:29:41.933 [bus notice] <7f08b51101ff9f00
2017-06-07 21:29:42.201 [bus notice] <7f08b51101019e00
2017-06-07 21:29:42.456 [bus notice] <7f08b51101f29d00
2017-06-07 21:29:42.699 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:42.977 [bus notice] <7f08b50302fc01ea00
2017-06-07 21:29:43.247 [bus notice] <7f08b51009f09ceaff0000ff00bc00
2017-06-07 21:29:44.819 [bus notice] <7f15070400b47f08b51101009f00
2017-06-07 21:29:45.087 [bus notice] <7f08b511d1019e00
2017-06-07 21:29:45.342 [bus notice] <7f08b51101029d00
2017-06-07 21:29:45.585 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:45.863 [bus notice] <7f08b503020001ea00
2017-06-07 21:29:46.133 [bus notice] <7f08b510090060faffff0000ff00bc00
2017-06-07 21:29:47.217 [bus notice] <7f08b51101c0fe00
2017-06-07 21:29:47.486 [bus notice] <7f08b511c1019e00
2017-06-07 21:29:47.745 [bus notice] <7f08b51101029d00
2017-06-07 21:29:47.988 [bus notice] <7f08b509030d4bf8f300
2017-06-07 21:29:48.265 [bus notice] <7f08b5030200fdea00
2017-06-07 21:29:48.532 [bus notice] <7f08b5100900a0ebff00e000bc00
2017-06-07 21:29:50.009 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-07 21:29:50.009 [bus error] signal lost
2017-06-07 21:29:50.980 [bus notice] signal acquired
2017-06-07 21:29:51.043 [bus notice] <7f08b51101009f00
2017-06-07 21:29:51.312 [bus notice] <7f08b51101019e00
2017-06-07 21:29:51.567 [bus notice] <7f08b511e1029d00
2017-06-07 21:29:51.810 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:52.087 [bus notice] <7f08b503020001ea00
2017-06-07 21:29:52.358 [bus notice] <7f08b51009fc204affff0000ff00bc00
2017-06-07 21:29:53.447 [bus notice] <7f08b51101009f00
2017-06-07 21:29:53.715 [bus notice] <7f08b5110156fe00
2017-06-07 21:29:53.970 [bus notice] <7f08b51101029d00
2017-06-07 21:29:54.212 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:54.490 [bus notice] <7f08b503020001ea00
2017-06-07 21:29:54.760 [bus notice] <7f08b5100900204affff0000ff00bc00
2017-06-07 21:29:56.509 [bus notice] <7f15070400b47f08b5110180fe00
2017-06-07 21:29:56.777 [bus notice] <7f08b51101019e00
2017-06-07 21:29:57.076 [bus notice] <7f08b51101fa9d00
2017-06-07 21:29:57.319 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:29:57.596 [bus notice] <7f08b50302f840fd00
2017-06-07 21:29:57.867 [bus notice] <7f08b5100900fea5ff007cff00bc00
2017-06-07 21:29:58.956 [bus notice] <7f08b51101009f00
2017-06-07 21:29:59.223 [bus notice] <7f08b5110101fe00
2017-06-07 21:29:59.479 [bus notice] <7f08b51101029d00
2017-06-07 21:29:59.721 [bus notice] <7f08b509038d4b00f300
2017-06-07 21:30:01.045 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-07 21:30:01.045 [bus error] signal lost
2017-06-07 21:30:01.165 [bus notice] signal acquired
2017-06-07 21:30:01.246 [bus notice] <7f08b5030200f1eb00
2017-06-07 21:30:01.517 [bus notice] <7f08b5100900007effff000000bc00
2017-06-07 21:30:02.601 [bus notice] <7f08b51101fe9f00
2017-06-07 21:30:02.913 [bus notice] <7f08b51101019e00
2017-06-07 21:30:03.169 [bus notice] <7f08b51101e2e700
2017-06-07 21:30:03.412 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:30:03.733 [bus notice] <7f08b503821f01ea00
2017-06-07 21:30:04.043 [bus notice] <7f08b5104900004affff0000ff00be00
2017-06-07 21:30:05.132 [bus notice] <7f08b51101409f00
2017-06-07 21:30:05.400 [bus notice] <7f08b51101f99e00
2017-06-07 21:30:05.655 [bus notice] <7f08b51101029d00
2017-06-07 21:30:05.898 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:30:06.172 [bus notice] <7f08b503020081ea00
2017-06-07 21:30:06.442 [bus notice] <7f08b51009fc004affff0000ff00bc00
2017-06-07 21:30:07.527 [bus notice] <7f08b51101009f00
2017-06-07 21:30:07.795 [bus notice] <7f08b51101e1fe00
2017-06-07 21:30:08.050 [bus notice] <7f08b51101029d00
2017-06-07 21:30:08.293 [bus notice] <7f08b509c30d4b00f300
2017-06-07 21:30:08.571 [bus notice] <7f08b503e20001ea00
2017-06-07 21:30:08.885 [bus notice] <7f08b5100980004affff0000ff00bc00
2017-06-07 21:30:10.461 [bus notice] <7f150704f0fb7f08b51101009f00
2017-06-07 21:30:10.729 [bus notice] <7f08b51101019e00
2017-06-07 21:30:12.002 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-07 21:30:12.002 [bus error] signal lost
2017-06-07 21:30:12.182 [bus notice] signal acquired
2017-06-07 21:30:12.236 [bus notice] <7f08b51101029d00
2017-06-07 21:30:12.479 [bus notice] <7f08b509030d4bf0f300
2017-06-07 21:30:12.756 [bus notice] <7f08b5030200fdea00
2017-06-07 21:30:13.027 [bus notice] <7f08b5100900c0eaff00f8ff00bc00
2017-06-07 21:30:14.117 [bus notice] <7f08b51101009f00
2017-06-07 21:30:14.384 [bus notice] <7f08b51101019e00
2017-06-07 21:30:14.639 [bus notice] <7f08b51101629d00
2017-06-07 21:30:14.882 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:30:15.160 [bus notice] <7f08b50302fd01ea00
2017-06-07 21:30:15.426 [bus notice] <7f08b51009004affff0000ff00bc00
2017-06-07 21:30:16.514 [bus notice] <7f08b51101009f00
2017-06-07 21:30:16.782 [bus notice] <7f08b51101019e00
2017-06-07 21:30:17.038 [bus notice] <7f08b511e1029d00
2017-06-07 21:30:17.281 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:30:17.558 [bus notice] <7f08b50302bf01ea00
2017-06-07 21:30:17.825 [bus notice] <7f08b51009f092eaff0000ff00bc00
2017-06-07 21:30:18.914 [bus notice] <7f08b51101209f00
2017-06-07 21:30:19.181 [bus notice] <7f08b5110101fe00
2017-06-07 21:30:19.437 [bus notice] <7f08b51101029d00
2017-06-07 21:30:19.680 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:30:19.957 [bus notice] <7f08b503c20c01ea00
2017-06-07 21:30:20.228 [bus notice] <7f08b510c90a004affff0080ff00be00
2017-06-07 21:30:22.010 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-07 21:30:22.010 [bus error] signal lost
2017-06-07 21:30:22.679 [bus notice] signal acquired
2017-06-07 21:30:22.744 [bus notice] <7f08b511811a9f00
2017-06-07 21:30:23.012 [bus notice] <7f08b51101019e00
2017-06-07 21:30:23.267 [bus notice] <7f08b51101c2e700
2017-06-07 21:30:23.510 [bus notice] <7f08b509030d4b00f300
2017-06-07 21:30:23.831 [bus notice] <7f08b50302fe01ea00
2017-06-07 21:30:24.102 [bus notice] <7f08b51009f8014affff0000ff00bc00

[john30]

your issue is different and might be related to using the GPIO. Please check this wiki entry:
eBus-with-Raspberry-Pi-Serial

[codeaholics]

I've already seen that page. It doesn't have much useful info on it, unfortunately. Interestingly, I'm using the same boiler as the original author (an EcoFit Pure).

It's not clear to me what could be causing this. I believe the latency issue is just on sending, but even if it's on reading that will surely just make the whole signal delayed - it won't affect the timing of individual bits and bytes.

[codeaholics]

@russss as the original author of that wiki page, can you add any further info here? (Also, do you have a CSV file for an EcoFit Pure and/or a VR33?)

[john30]

try adding the --latency parameter as described on that page.
and post a snippet of the ebusd log file after ebusd was started with --lograwdata=bytes, where the snippet covers some lines before and after the signal lost message.

[codeaholics]

Here's one without the --latency

2017-06-08 18:50:46.231 [bus notice] <aa
2017-06-08 18:50:46.424 [bus notice] <7f
2017-06-08 18:50:46.424 [bus notice] <08
2017-06-08 18:50:46.424 [bus notice] <b5
2017-06-08 18:50:46.425 [bus notice] <10
2017-06-08 18:50:46.425 [bus notice] <09
2017-06-08 18:50:46.425 [bus notice] <00
2017-06-08 18:50:46.425 [bus notice] <00
2017-06-08 18:50:46.425 [bus notice] <14
2017-06-08 18:50:46.467 [bus notice] <ff
2017-06-08 18:50:46.467 [bus notice] <ff
2017-06-08 18:50:46.468 [bus notice] <00
2017-06-08 18:50:46.468 [bus notice] <01
2017-06-08 18:50:46.468 [bus notice] <ff
2017-06-08 18:50:46.468 [bus notice] <00
2017-06-08 18:50:46.468 [bus notice] <d0
2017-06-08 18:50:46.497 [bus notice] <00
2017-06-08 18:50:46.497 [bus notice] <aa
2017-06-08 18:50:46.695 [bus notice] <7f
2017-06-08 18:50:46.695 [bus notice] <15
2017-06-08 18:50:46.695 [bus notice] <07
2017-06-08 18:50:46.695 [bus notice] <04
2017-06-08 18:50:46.696 [bus notice] <00
2017-06-08 18:50:46.696 [bus notice] <b4
2017-06-08 18:50:48.019 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-08 18:50:48.019 [bus error] signal lost
2017-06-08 18:50:48.048 [bus notice] <7f
2017-06-08 18:50:48.048 [bus notice] signal acquired
2017-06-08 18:50:48.048 [bus notice] <08
2017-06-08 18:50:48.048 [bus notice] <b5
2017-06-08 18:50:48.048 [bus notice] <11
2017-06-08 18:50:48.049 [bus notice] <01
2017-06-08 18:50:48.049 [bus notice] <80
2017-06-08 18:50:48.049 [bus notice] <9f
2017-06-08 18:50:48.114 [bus notice] <00
2017-06-08 18:50:48.114 [bus notice] <aa

[codeaholics]

Here's one with --latency. It's fair to say it seems to survive longer with this parameter, but it could be my imagination. I thought this was only useful on the sending side?

2017-06-08 18:52:15.112 [bus notice] <aa
2017-06-08 18:52:15.314 [bus notice] <7f
2017-06-08 18:52:15.314 [bus notice] <08
2017-06-08 18:52:15.314 [bus notice] <b5
2017-06-08 18:52:15.314 [bus notice] <11
2017-06-08 18:52:15.314 [bus notice] <01
2017-06-08 18:52:15.314 [bus notice] <01
2017-06-08 18:52:15.314 [bus notice] <9e
2017-06-08 18:52:15.381 [bus notice] <00
2017-06-08 18:52:15.381 [bus notice] <aa
2017-06-08 18:52:15.585 [bus notice] <7f
2017-06-08 18:52:15.585 [bus notice] <08
2017-06-08 18:52:15.585 [bus notice] <b5
2017-06-08 18:52:15.585 [bus notice] <11
2017-06-08 18:52:15.585 [bus notice] <01
2017-06-08 18:52:15.585 [bus notice] <02
2017-06-08 18:52:15.586 [bus notice] <9d
2017-06-08 18:52:15.636 [bus notice] <00
2017-06-08 18:52:15.637 [bus notice] <aa
2017-06-08 18:52:17.055 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-08 18:52:17.055 [bus error] signal lost
2017-06-08 18:52:17.085 [bus notice] <7f
2017-06-08 18:52:17.085 [bus notice] signal acquired
2017-06-08 18:52:17.085 [bus notice] <08
2017-06-08 18:52:17.085 [bus notice] <b5
2017-06-08 18:52:17.085 [bus notice] <09
2017-06-08 18:52:17.085 [bus notice] <03
2017-06-08 18:52:17.085 [bus notice] <0d
2017-06-08 18:52:17.085 [bus notice] <4b
2017-06-08 18:52:17.085 [bus notice] <00
2017-06-08 18:52:17.102 [bus notice] <f3
2017-06-08 18:52:17.135 [bus notice] <00
2017-06-08 18:52:17.135 [bus notice] <aa

[john30]

2017-06-08 18:52:15.637 [bus notice] <aa
2017-06-08 18:52:17.055 [bus debug] ERR: read timeout during skip, switching to no signal
2017-06-08 18:52:17.055 [bus error] signal lost
2017-06-08 18:52:17.085 [bus notice] <7f

as you can see in the snippet:
the time between the last SYN and the next symbol is almost 1.5 seconds. That's just way too much and way beyond the specification.
You need to get that down to below 250 millis. Otherwise the communication will always yield in signal loss.
So you can either live with the signal loss messages or buy a decend USB to RS232 coupler :)

[codeaholics]

I'm stuggling to understand how the RPi GPIO/UART can be this bad? If it was this fundamentally broken, surely people would be up in arms about it and it would have been fixed? I'm using it successfully on another project at 115,200 baud with no noticeable issues.

Is it possible my error is down to trimming?

[codeaholics]

This looks relevant, but doesn't provide any kind of solution: https://www.raspberrypi.org/forums/viewtopic.php?t=170945&p=1095466

I wonder how @russss is getting his to work with no issues! Also, the fact that it seems to be kernel based but this article suggests it's a hardware thing. Perhaps the kernel can re-configure the hardware but doesn't expose that to anything in user-land.

[codeaholics]

Also... I've built from source which means I have the "low latency" fix. This is confirmed to fix sending issues, so I suppose it's possible it only fixes sending issues and not receiving issues.

[john30]

I can't give you answers to those questions as I'm not using the GPIO based serial port and it is clearly not recommended to be used for eBUS communication. As said, go get yourself a decent converter for about 5 EUR and you're fine.

[codeaholics]

That's fair enough. I've got one on order so I'll see how it goes when it arrives. I was trying to avoid having yet another PCB and more wires in the box.

Out of interest, what's the benefit of enforcing such rigorous timing constraints on the receiving side? I understand what the spec says, and the sending side should totally respect that, but what's gained by making the receiving side so strict?

[russss]

This is curious and unfortunately I have no answers for it.

My experience (using the Pi Zero W, which I understand should be broadly identical hardware-wise to the Pi3) has shown that the latency is a fairly constant 15-18ms when transmitting, so the variance of 1.5 seconds is odd.

I confirmed this with a logic analyzer - if you can get hold of one it would be interesting to see a dump of the bus which would show whether the delay occurs on sending or receiving (the periodic SYN bytes make this quite easy to determine).

Regarding the CSV file, the ecoFIT Pure gets detected as one of the existing supported boilers (I think it was 08.bai.HW7401.csv) and the majority of channels in that file work as expected.

My long-term goal is to spin some new PCBs which include a small microcontroller which can (optionally) handle the bus access in firmware to completely remove the effect of userspace (and stupid UARTs) on bus timings.

[codeaholics]

Thanks for the feedback @russss. I'm doing no sending at all at the moment, so this is pure receive-side spikes.

[codeaholics]

(And thanks for the info on the boiler.)

[codeaholics]

I'd be interested in helping with that. Would be nice not to need the trim pot too. Perhaps using a voltage divider and an analogue input? Or using that to sense the high and low voltages and self-trim or something like that.

[russss]

The trim pot really shouldn't be necessary as the voltage levels are clearly defined by the spec. It just makes it fiddlier than it needs to be. The board I'm testing with uses an op-amp comparator with fixed trim resistors, and that seems to work fine.

[john30]

@codeaholics the idea is to be spec conformant. feel free to increase the values as you need :-)

there was already a PCB suggestion for having no poti any more in the fhem forum back some time ago

[codeaholics]

@john30 Unfortunately, I'm still getting timeouts even with an RS232 to USB converter. I'm going to try process priorities now to see if this is a kernel pause thing.

[john30]

Is the converter FTDI based or something different?

[codeaholics]

FT232RL. I'm getting one error approximately every 10-15 seconds. Otherwise, everything seems to be working well.

I can now send without any problems too (I had a failed component on the board), so I suspect this is something to do with kernel scheduling. However, playing with priorities didn't improve things.

[john30]

is it still the signal loss issue or something else?

[codeaholics]

Just read timeouts. So it does look like the USB/RS232 adapter has improved things and removed at least one source of trouble.

2017-06-14 08:29:27.318 [bus notice] <aa
2017-06-14 08:29:27.322 [bus notice] <7f
2017-06-14 08:29:27.326 [bus notice] <15
2017-06-14 08:29:27.331 [bus notice] <07
2017-06-14 08:29:27.335 [bus notice] <04
2017-06-14 08:29:27.339 [bus notice] <00
2017-06-14 08:29:27.343 [bus notice] <b4
2017-06-14 08:29:27.369 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-06-14 08:29:27.848 [bus notice] <aa

Interestingly, it always seems to be the same message that causes the problem:

2017-06-14 08:32:07.136 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-06-14 08:32:07.615 [bus notice] <7f15070400b4
...
2017-06-14 08:32:21.002 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-06-14 08:32:21.481 [bus notice] <7f15070400b4
...
2017-06-14 08:32:35.004 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-06-14 08:32:35.482 [bus notice] <7f15070400b4
...
2017-06-14 08:32:47.057 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-06-14 08:32:47.533 [bus notice] <7f15070400b4

Device 0x7F is a Vaillant VR33 OpenTherm to eBus adapter:

version: ebusd 3.0pre.7a569e2
signal: acquired
symbol rate: 57
max symbol rate: 139
reconnects: 0
masters: 3
messages: 197
conditional: 2
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0610;HW=1303", loaded "vaillant/bai.0010015600.inc" ([PROD='0010020398']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 7f: master #24
address 84: slave #24, scanned "MF=Vaillant;ID=OTS00;SW=0205;HW=9101"

If my understanding of the message format is right, the VR33 is attempting to send a message to device 0x15, but that device isn't present. Is that right?

[john30]

well then there is no slave that is willing to answer the query. as the message is at debug level, this isn't really an error, it's just normal behaviour when a master sends a message to a slave that either does not exist or is not willing to answer that message.
so everything seems fine from my point of view

[codeaholics]

I agree. I have to wonder what device 0x15 is and why the VR33 is trying to talk to it when it's not present! But it's not doing any harm. Thank you for your help.

[john30]

0x15 is usually the main user interface and/or controller that is expected to be present

[ITachiLab]

I recently created a pull request (raspberrypi/linux#5794) to Raspberry Linux Kernel with a fix that solves problems originating from the response latencies. The PL011 UART chip indeed has FIFO queues which introduce latencies the eBUS obviously doesn't like, but thankfully it also allows to control whether these queues should be enabled or not (it's a matter of a single bit in one of the configuration registers). The current implementation of the driver always assumes that FIFOs should be enabled whenever they are present, at the same time not allowing to turn this feature off when it isn't appropriate.

@russss

My experience (using the Pi Zero W, which I understand should be broadly identical hardware-wise to the Pi3) has shown that the latency is a fairly constant 15-18ms when transmitting, so the variance of 1.5 seconds is odd.

I confirmed this with a logic analyzer - if you can get hold of one it would be interesting to see a dump of the bus which would show whether the delay occurs on sending or receiving (the periodic SYN bytes make this quite easy to determine).

From my observations it seemed that the problem was with RX queues. When I was sending data through UART, the output from a logic analyzer shown that data frames were flowing out of TX pin one after another with no delays in-between. But when I did "write and read and write", then I got a big (~13 ms) delay before the second write made its way on the wires. When I disabled FIFOs, the delay dropped to 30 microseconds, so it falls into eBUS's expectations just fine.

I'm now successfully running ebusd on Raspberry Pi Zero W for almost a whole week, and it works perfectly (I already tied it with my home automation). Between eBUS and Raspberry I have a custom made hat which I based on official schematics from the eBUS specification, just level convertions.

[russss]

I'm now successfully running ebusd on Raspberry Pi Zero W for almost a whole week, and it works perfectly (I already tied it with my home automation). Between eBUS and Raspberry I have a custom made hat which I based on official schematics from the eBUS specification, just level convertions.

Ah, that's good news! I'll see if I have time to spin a new design for the Pi Zero hat. I unplugged mine quite a few years ago when I switched to the vSMART thermostat and I hadn't got round to trying it again...