-
-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recurring "YieldThisYear failed", "wrong symbol received" and "SYN received" #891
Comments
check with "raw" what symbols are received from ui as answer to the query. if that does not produce enough output, use "raw bytes" instead |
oh and do you have a strong enough wifi? |
I've enabled raw logging and called ebusctl r -c ui YieldThisYear. 2023-05-13 08:53:12.245 [bus info] send message: 3115b509030d4400
The adapter shows 52% (-74dBm). My unifi controller shows -69dBm I've seen the adpater didn't use the nearest AP. I've now kicked him to the nearest AP and fixed the configuration. |
please check for a potential address conflict by issuing "ebusctl info". if there is no conflict detected, please run that particular read with raw logging bytes enabled and post it here (but don't do that too long, as it yields in massive logging). |
Sorry, I was a litte too busy in the last weeks. :-( Here is the output of ebusctl info: localhost: info Next I will do some raw logging... |
Actually YieldThisYear works everytime, i try to read it via ebusctl, but I found some other recurring errors in the log: 2023-06-01 14:23:39.019 [bus info] poll cmd: 3150b509030d0100 another error: 2023-06-01 14:26:38.875 [bus info] scan 05 cmd: 3105070400 |
I've set the pollintervall to 1, restarted the ebusd again and the errors are back again: 2023-06-01 15:24:33.116 [bus info] poll cmd: 31ecb509030d0900 |
raw logging in bytes is needed to check the timing |
I think I have the same issue. With my old custom ebus adapter it worked ok, but I just received and tested the new v5 adapter and I am seeing lots of intermittent "wrong symbol received" and "SYN received". WiFi signal 88%.
I have attached raw bytes dump while reading flame
|
thanks for the log. at several times like 21:16:13.230 there is a successful read of flame (0500), so that does not fit to the findings. on the other side, there are some weird examples in the log as well like at 21:16:09.688 where the receive is interrupted by a SYN symbol after 16ms. now it would be good to know if easi> reports WIFI issues at such occasions. also your max symbol latency of around 60 suggests there is either a lot of traffic on your WIFI or many lost(broken packets. maybe check with your router? |
Yes sometimes the read is successful other times it fails. I have ruled out WiFi issues by switching to usb mode and connecting it to a raspberry pi running ebusd.
|
please provide the corresponding raw log |
Unfortunately I can't get it to make a connection anymore. It can't find any other devices on the bus anymore so just getting an empty raw log. All I get is lots of these messages.
|
what do you mean by "empty raw log"? if that would be really empty, then your bus is dead, so that's probably not the case |
Worked out why was getting an empty log file, it was a permissions problem, log file owned by root and running ebusd as non-root user! This is the command I used.
Also tried with this command but the raw data file only contained <aa lines.
I swapped the hardware back to my old one and it works fine, so the bus is working fine. |
the raw log does not contain any send, so again not useful at all. I need at least to have it cover one of the issued active reads. furthermore it is easier to read everything if the raw log is embedded in the normal log (i.e. leave out "--lograwdatafile ...") why are you using an older ebusd version? |
Looks like I haven't upgraded ebusd for a while, will update and try again. Problem is I can't do any commands like |
I have upgraded to the latest version and seeing the same issue. |
again, I need some raw logging in order to check in detail. this is also true for the scanning process after starting ebusd. futhermore it would good to know if errors are reported in the easi> log page in the same time period |
I have tried to get some raw logging. I have checked the easi> log page and there are no errors whilst running ebusd, however there are some on startup but I don't think they are relevant to this issue as I am connecting via USB cable.
|
I can also do a capture of the bus using a logic analyser if that helps. |
you didn't specify "--scanconfig" as argument to ebusd, so it will pick up all messages from the config folder, which is definitely wrong. consequently it would try to poll those messages for which not even a device exists, so you better fix that first. furthermore, from the logs it seems that your device can't write anything to the bus. do you have special cabling of some sort? would be interesting to find out the voltage levels on the bus if you have the possibility |
I have added --scanconfig and it worked for a bit and then stopped. Haven't been able to get it to work again since, so I assume it must be on the edge. I have included the log file from the time it did work. I have no special cabling, just two wires connected directly to the boiler. Measuring the voltage one wire of ebus is tied to the boiler ground, and the other is at 22v from this ground. There is not continuity between the boiler ground the the ebusd adapter ground but I understand this is ok. |
can you try to grab the levels when writing with the adapter? or does your rigol have decoding capability? then you could make it trigger on 0xaa or on the master source address of ebusd. one thing that just comes to my mind: in case of a simple broken diode, you could check if inverting the two wires to the bus makes a difference |
I think the last photo is from when the adapter was writing. Unfortunately that is the best I can do with my rigol as it is quite basic. Is there anywhere on the adapter board I can hook into the ebus signal as I have another scope/logic analyser but it only supports up to 10v. I tried switching the cables but it hasn't made a difference. |
I've checked your screenshot and if your rigol is correct, then the signal timing of your heating is probably damaged as the baudrate is at 2460 Bd instead of 2400 for the SYN symbol. this is more than the allowed tolerance of +/- 1,2% and most probably the root cause of the issues. |
this issue is continued in the appropriate repo: |
Description
Yesterday I've received my ebus-adapter (v5) from John and connected it to my Vaillant heating (ecoTEC exclusiv VC DE 146/4-7, allSTOR VPS800/2, auroMATIC VRS620/3, VPM 20S and VPM 20/25 W). The signal is detected and the ebusd found some devices at scanning the bus.
I use MQTT with retention to send the values to my smarthome server. Some status messages were found directly and if I switch something on the auroMATIC, the values were mostly read/found of ebusd. But I get many errors on the bus like
2023-05-12 09:34:15.390 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
Sometimes YieldThisYear could be polled successfully (after some hours) but mostly I get errors.
Topology:
ecoTEC, and VPM 20S are connected directly to auroMATIC and the eBus-adapter is connected to VPM 20S - all with 1,5mm² cables.
The adapter (Firmware Build 20230501) uses wifi to connect to my LAN and the ebusd V23.1.23.1 is installed on a Proxmox LXC, 2CPUs (Intel i5 6400), 256MB RAM, SSD storage) with Debian 11.
Actual behavior
errors
Expected behavior
no errors ;-)
ebusd version
23.1
ebusd arguments
EBUSD_OPTS="--device=ens:mydeviceFQDN:9999 --latency=10 --logfile=/var/log/ebusd.log --log=all:error --log=network:info --log=other:info --mqttjson --mqttretain --mqttchanges --mqttverbose --mqtthost=myhostFQDN --mqttport=1833 --mqttuser=myuser --mqttpass=mypass --mqttclientid=ebusd --scanconfig=full --configpath=/etc/ebusd/configs/ --httpport=8889 --htmlpath=/var/ebusd/html"
Operating system
Debian 11 (Bullseye) / Ubuntu 20-21 / Raspbian 11 / Raspberry Pi OS 11 (including lite)
CPU architecture
x64
Dockerized
None
Hardware interface
other
Related integration
HTTP, MQTT generic
Logs
2023-05-12 09:34:15.040 [bus info] poll cmd: 3115b509030d4400
2023-05-12 09:34:15.280 [bus info] poll cmd: 3115b509030d4408
2023-05-12 09:34:15.390 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
2023-05-12 09:34:21.031 [bus info] poll cmd: 3115b509030d4400
2023-05-12 09:34:21.120 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
2023-05-12 09:34:22.178 [bus info] scan 23 cmd: 3123b5090124
2023-05-12 09:34:22.300 [main error] scan config 23: ERR: wrong symbol received
2023-05-12 09:34:24.301 [bus info] scan fc cmd: 31fcb5090124
2023-05-12 09:34:24.440 [main error] scan config fc: ERR: SYN received
2023-05-12 09:34:27.010 [bus info] poll cmd: 3115b509030d4400
2023-05-12 09:34:27.130 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
2023-05-12 09:34:32.448 [bus info] scan 23 cmd: 3123b5090124
2023-05-12 09:34:32.580 [main error] scan config 23: ERR: wrong symbol received
2023-05-12 09:34:33.025 [bus info] poll cmd: 3115b509030d4400
2023-05-12 09:34:33.366 [bus info] poll cmd: 3115b509030d4408
2023-05-12 09:34:33.468 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
2023-05-12 09:34:34.581 [bus info] scan fc cmd: 31fcb5090124
2023-05-12 09:34:34.690 [main error] scan config fc: ERR: wrong symbol received
The text was updated successfully, but these errors were encountered: