I have been trying to get my Ebus installation using the new Ebus-binding to work for some hours now, to no avail.
I am using a commercial Ebus <-> Ethernet converter, trying to communicate with a Wolf CGS-20/160 and a command module BM.
Due to current limitations I can only connect either the converter or the command module.
A strange thing is: I only receive values after having the BM connected for a short period of time. After replacing it, I receive values for ~3 minutes, then the bus is silent again. The converter is set up properly; using RealTerm I can see loads of AA values during these 3 minutes.
During the first of these phases, the binding with one properly set up bridge-thing responded with log entries like
[nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 28 [ERROR: INVALID_SOURCE_ADDRESS[...] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN [...]Update state from SYN to UNKNOWN [...]Auto-SYN byte received
The source adresses vary: 0A, 22, 28, 2A, 80, 88, 8A, A2, A8, the data is all zeros.
All subsequent tries (restarting the converter, openhab and the server, reinstalling the binding, removing and re-adding the things) didn’t result in any of these entries (with logging still set to trace).
So my questions are:
Why is my ebus silent, and only speaks to me for a short period after plugging in the BM?
How can there be so many source adresses when there are just two clients in the whole network (CGS-20 and the converter)?
Speaking of adresses: how should I set up the slave adresses for future things like “eBUS Standard”?
Why did the binding only react to the first ebus events?
Apparently the Ebus is only working when the BM is attached. After changing my infrastructure to be able to connect both, the BM and the converter, everything is working as expected. The inbox immediately filled with discovered things.
I don’t understand why the BM is needed, though, but I accept it!
A bit late but, you mean the direct connected BM and not a remote connected BM as Room Controller ? Most of the bus traffic is triggered by the BM. I’m not sure if the auto syn generator is also provided by the BM.
I have only one BM, which is used as a Room Controller.
For now, the binding and the converter isn’t of much use for me, as I can’t read / set properties that are of my interest (room temperature, outside temperature, warmwater preparation, heating curve, heating switch,…).
Since tado is able of setting/reading all of these, I’m actually thinking of buying one and sniffing all the traffic for one month (which happens to be the trial period of said device), trying to figure everything out by myself.
Most likely however I will stick to tado and sell my ebus converter, even though I don’t like the cloud aspect of it at all.
But it works (and it is more beautiful than my green converter with bulky housing)!
I really don’t understand, why heating manufacturers don’t publish their bus specifications. It’s not likely that anyone would copy their proprietary telegram style anyhow.
I would happily buy from manufacturers with documented bus systems, even if their products would be more expensive than comparable ones.
Sorry for refreshing this discussion but I also do have Wolf with BM and having it connected to OpenHab is very appealing. @_tom what do you mean by “After changing my infrastructure to be able to connect both, the BM and the converter, everything is working as expected”. Have you connected both on different channels? Or what have you exactly done?
I just meant that I kept the BM in the ebus network. This is necessary, as the whole thing won’t work without it.
Happy to see another Wolf owner!
To be honest: my main reason for starting this whole smart home stuff was being able to control my heating. To this date this is still the only thing that doesn’t work at all, though.
