An ebusd add-on

Over the past few days I’ve setup an ebusd add-on to run eBUSd daemon on my RaspberryPi with Home Assistant OS and an esera ebus usb interface plugged into it.

Here is a screenshot of it running:

All command line options of ebusd I’ve needed are made available as Add-on options, so this should be a “no-code” setup for users with the same use case I’ve come across. Thanks to the device option type, selecting the correct USB interface is made available via a simple dropdown.

It’s in an early state but I think mature enough to publish. I would very much appreciate pull requests or any other form of feedback.

get the eBUSd add-on on Github

To Install

prerequisite is obviously to connect a hardware interface to your computer running Home Assistant OS.

  1. In Supervisor go to the Add-on Store,
  2. In the overflow menu click “Repositories”
  3. Add https://github.com/LukasGrebe/ha-addons/
  4. Wait for the ebusd Add-on to show up (or click reload in the same overflow menu?)
  5. Click install - this will take a while because in this early state the add-on build from source on your device
  6. Configure Comandline Options in the Addon Settings
  7. Start the Add-on and check the output logs
1 Like

Hello, will this daemon work with an ebus device that communicates via wifi

Hi.
I have ordered ebus Adapter v3, yet unknown when this will arrive. But before connecting hardware, I am getting familiar with ebus protocol for my preferred connection to Vaillant.

The principal question is how to configure ebus Adapter with LAN port in Homeassistand via HACS and your add-on if I can not select a correct device through the dropdown? Apparently I am missing something here. I want to avoid using Raspberry Pi with ebus USB adapter or wifi adapter and want to hook up the LAN version of adapter directly to LAN and configure network conenction to my HA installation.

Any help or advice is very much appreciated.

Thanks,

hi, take a look at the ebusd Wiki’s hardware info: 6. Hardware · john30/ebusd Wiki · GitHub
I developed this add-on to work with my USB-ebus adapter plugged right into the Pi running HomeAssistant OS. Feel free to mess with the code and submit pull requests to get an IP interface working!

Hey @Raku ,

as far as I can tell WIFI ebus device already runs ebusd on the Wemos D1 Mini Firmware! So there’s no need to run a second copy of it with this add-on. You should be able to configure your device to send updates to an MQTT server and read them out from there via Homassitant as a sensor

Please share your progress with you Vaillant heater. I have one too and so far it’s quite frustrating. Reading values is not the problem although you have to poll certain values manually but somehow I cannot send any commands to my heater.

Hi
Any news with communicate by wemos D1 mini with HASSOS with Home Assistant ? Any manual how i can configure it ?

Ebusd is not running directly on the esp. In ebusd config you have to specify the IP of the esp connected to the heater. This is so far not possible with this addon.

And i must only installed Firmware on Wemos and then add to HA integration name ebusd and select IP whicha has this wemos from adapter ebus ?

Hello Lukas,

I would like to use you add-on.

It is possible to add following commands?

–address
–configpath
–accesslevel

Also I must import my own ebusd config.
Like:
–configpath=/etc/ebusd/de
It that possible?

Thanks for you help.

Greetings Tobias

Is any chance to rebuild this addon to comunicate also by WIFI/LAN with adapter ? Please…

There are already pull requests for accesslevel and config paths. I also found it extremely helpful to enable the http interface, as this seems to be by far the easiest way to get all available topics. To get going i forked the original repo and added most of the original ebusd options, but the current state is far from being ‘pull request ready’: My Fork

I don’t have much time for this atm and I have no idea how I can tie the http port to the exposed port parameter. Any help is appreciated, maybe we can make a decent pull request to enable most if not all ebusd options.

I cannot help with a ebusd lan/wifi adapter but maybe with polling: You can configure polling by publishing to <topic>/get ?<priority> as a raw value.

I permanently configure my ebusd to poll all the topics i need using a simple homeassistant automation like so:

- id: "ebusd_polling_configuration"
  alias: eBusd Polling konfigurieren
  description: ""
  trigger:
    - platform: time_pattern
      hours: "1"
      minutes: "0"
      seconds: "0"
  condition: []
  action:
        # BAI TOPICS
    - service: mqtt.publish
      data:
        topic: ebusd/bai/WaterPressure/get
        payload: ?9

I’d also recommend MQTT-Explorer for manual try and error as well as using the http interface to gather all possible topics/values by appending ?full&required

Running ebusd in MQTT-Verbose mode also helps.

Polling topics and data is not the issue. It works quite well and reliable. I had trouble writing data e.g. to set a desired room temperature. With default config this was not possible for my heating. So the conclusion would be to create a custom .csv and set the desired endpoints on the bus to writeable. But that seemed a bit too risky for me. My heating is currently asking for maintenance in the control display so I stopped fuzzing around with ebusd.

Ok, i can totally understand this. custom csvs for setting values is definetly a bit out of my comfort zone as well

I’m also interested in your fork but not yet have done any development on home assistant.
What I’ve seen is that the unifi addon is also exposing ports, maybe this config helps as a sample for exposing ports?
addon-unifi/config.yaml at main · hassio-addons/addon-unifi (github.com)

I think without modifying the run.sh script the easiest way to map the port ist to provide a default value for the httpport config entry like this

options:
  scanconfig: true
  foreground: true
  httpport: 4711
  
schema:
  device: "device(subsystem=tty)"
  port: "port?"
  latency: "int(0,10000)?"
  readonly: "bool?"
  foreground: "bool?"
  scanconfig: "bool?"
  configpath: "str?"
  pollinterval: "int(0,30)?"
  accesslevel: "str?"
  httpport: "port?"
  logareas: "list(main|network|bus|update|all)?"
  loglevel: "list(error|notice|info|debug)?"
  mqtthost: "str?"
  mqttport: "int?"
  mqttuser: "str?"
  mqttpass: "str?"
  mqttjson: "bool?"
  mqttlog: "bool?"
  mqttretain: "bool?"
  mqtttopic: "str?"
  mqttverbose: "bool?"
  
ports:
  4711/tcp: 4711

Hi, I have made a couple of pull requests and have some changes ready to submit to enable TCP and http access but I am not sure if the repo is being maintained any more. One of my pull requests has been outstanding for a month.

Thanks for the hint, it’s worth investigating.
As for the default: I’m not sure this is such a good idea to expose the http api by default. At the moment this is mainly a mqtt-based solution and for me http api mainly serves debugging purposes.
If we can’t figure out how to tie this port to the port exposed on the host, I’d rather provide a boolean ‘http api’ option with a fixed port - this should be fairly easy.

Please don’t expect any big updates from my point anytime soon. Given my current workload, I shouldn’t be doing this at all :wink:

So again: any help is very much appreciated.

EDIT: I couldn’t help to have a tiny peek into the unify addon and I don’t see any configurable ports there :(. In fact I’m wondering how one’s supposed to keep track of exposed ports and prevent collisions.

I agree, there hasn’t been much activity lately.
@afiwube: can you give us an update?

I am happy to fork the repo and take over as maintainer but don’t want to steal @afiwube thunder if he still wants to lead development

1 Like