Ebus integration?

Right that is also my understanding now, that ebusd is not sending updates via MQTT.
That’s why at the moment I created a small bash script and croned that one to run every min to update the mqtt entries.

the --pollinterval i set to 5 seconds, but still only some topics are sent, not the one i need.
Maybe you are right I have to check the CSVs, there might be a definition which topics are been sent and updated in that pollinterval.
I never checked so far the csvs…

Another test is to try ebusctl read and use its

-p PRIO      set the message poll priority (1-9)

parameter, e.g. run this manually for those parameters you want to be updated by ebusd instead of your script (e.g. Hc1DayTemp) and probably set

-m SECONDS   only return cached value if age is less than SECONDS [300]

to 1 second?
I hope this will force ebusd to actively poll Hc1DayTemp with poll interval of 1 sec and report the value over MQTT on its change

you mean something like this ?

pi@rp4:~ $ ebusctl r -p 1 -m 5  Hc1DayTemp
23.0

it is just forcing a read once, but not doing it after that every 5 seconds or so…

by the way any idea how to configure properly
the modes ?

I get them blank …only auto can be selected.
if I select one of the blank value then I get this error:

can you check the logs? e.g.
tail -f /var/log/ebusd.log
to see if ebusd does poll it? It can be that it does, but doesn’t update the relevant MQTT topic (for example, if Hc1DayTemp doesn’t change)

Not yet, sorry. I am still at the very beginning of my journey with HA :wink:

you are so right, it is polling the data but not updating the MQTT topic:

pi@rp4:~ $ tail -f /var/log/ebusd.log | grep Hc1DayTemp
2019-10-24 22:39:06.117 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:12.110 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:18.121 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:24.091 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:30.111 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:36.098 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:42.111 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:48.094 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:39:54.102 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0

Hmm any way to update the mqtt topic too ?
Or should we switch to TCP for mqtt ? :smiley:

I mean with the script works quite well… I know it is a workaround, but I don’t mind…

btw some topic do get updated automatically like Status01,02…

2019-10-24 22:44:06.111 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:44:06.854 [update notice] received read bai Status01 QQ=10: 44.0;37.0;-;-;34.0;overrun
2019-10-24 22:44:08.849 [update notice] received read bai Status02 QQ=10: auto;60;45.0;70;50.0
2019-10-24 22:44:10.909 [update notice] received update-write bai SetMode QQ=10: auto;0.0;-;-;1;0;1;0;0;0
2019-10-24 22:44:12.088 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:44:16.915 [update notice] received read bai Status01 QQ=10: 49.0;41.0;-;-;35.0;overrun
2019-10-24 22:44:18.094 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:44:18.929 [update notice] received read bai DateTime QQ=10: nosignal;03:35:39;-.-.-;-
2019-10-24 22:44:20.944 [update notice] received update-write bai SetMode QQ=10: auto;0.0;-;-;1;0;1;0;0;0
2019-10-24 22:44:24.122 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:44:26.953 [update notice] received read bai Status01 QQ=10: 53.0;44.0;-;-;36.0;overrun
2019-10-24 22:44:30.125 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:44:30.960 [update notice] received update-write bai SetMode QQ=10: auto;0.0;-;-;1;0;1;0;0;0
2019-10-24 22:44:36.126 [update notice] sent poll-read 350 Hc1DayTemp QQ=31: 23.0
2019-10-24 22:44:37.006 [update notice] received read bai Status01 QQ=10: 56.0;47.0;-;-;37.0;overrun
2019-10-24 22:44:38.984 [update notice] received update-read broadcast vdatetime QQ=10: 22:44:58;24.10.2019
2019-10-24 22:44:39.244 [update notice] received unknown MS cmd: 1008b512020000 / 00

Then it just works as designed: MQTT is only updated if there is a change. You constantly have 23.0, so no change - no update. And why would you need extra traffic if it brings zero new information? :wink:
I do believe if you setup something like current temperature to be polled with -p switch then on temperature change you’ll see MQTT topic updated.

These are on the bus because your 350 talks to bai, so you are seeing the consequence of that captured by ebusd.

I used the -p switch as showed above in my previous post, but I don’t get any updates if the temp changed on the wall thermostat…

btw did you saw this switch ?
/list : publishes all messages known so far (according to access level, see above).

I don’t know how to use that one, if that one can help in some way …

well, then I would suggest the following exercise:

  1. Run tail -f /var/log/ebusd.log | grep Hc1DayTemp in one of the terminals/consoles
  2. Subscribe with mosquitto_sub to ebusd/350/Hc1DayTemp in the other, so we can see both logs
  3. Change the temperature using the wall thermostat

If there is NO message published and we see that Hc1DayTemp has changed and captured by ebusd then we have a bug in ebusd and this use-case and the issue should be reported to john30

BTW, I would strongly recommend setting the following:
availability_topic
payload_available
payload_not_available

If I read the code correctly then publishing something like

ebusd/350/Hc1NightTemp/get?1

will enable polling of Hc1NightTemp with priority 1… Need to test and confirm

UPD. The poll and MQTT IS documented here:

For /get and /set suffixes, the optional message payload can be used to transfer additional input data, e.g. the values to be set for a write message or the needed input for a read message, separated by semicolon.

In addition to that, appending a question mark and a poll priority digit allows adjusting the poll priority for read messages. For example, using mosquitto_pub -m '?3' -t 'ebusd/uih/YieldSum/get' would set the uih/YieldSum message to be polled with priority 3 and is equivalent to issuing ebusctl -c uih -p 3 YieldSum .

you mean to have this in HA YAML config ?

at the moment I do have it like this:

climate vaillantThermostat:
  - platform: mqtt
    name: "Hc1DayTemp"
    temperature_state_topic: "ebusd/350/Hc1DayTemp"
    temperature_command_topic: "ebusd/350/Hc1DayTemp/set"
  - platform: mqtt
    name: "Hc1NightTemp"
    temperature_state_topic: "ebusd/350/Hc1NightTemp"
    temperature_command_topic: "ebusd/350/Hc1NightTemp/set"
  - platform: mqtt
    name: "Thermostat Mode"
    mode_state_topic: "ebusd/350/Hc1OPMode"
    mode_command_topic: "ebusd/350/Hc1OPMode/set"
    modes:
      - auto
      - summer
      - night
      - on
      - off
    current_temperature_topic: "ebusd/350/DisplayedRoomTemp"
    temperature_state_topic: "ebusd/350/Hc1DayTemp"
    temperature_command_topic: "ebusd/350/Hc1DayTemp/set"
    retain: true
    initial: 23
    min_temp: 10
    max_temp: 30

With this:
$ docker exec -i mosquitto mosquitto_pub -n -t ebusd/350/Hc1NightTemp/get?1

I only get this back via MQTT:

ebusd/350/Hc1NightTemp/get?1 (null)
ebusd/350/Hc1NightTemp/get?1 (null)

So no response actually :frowning:

No, this needs to be done once for every parameter you want to be polled at the very startup, right after there is a connection with ebusd.
In the YAML I would recommend adding availability_topic, payload_available, payload_not_available, so when connection to ebusd dies you don’t have uncontrolled stalled data

Modify the below example from the ebusd’ documentation:

yes, that gives me the result once per mqtt:
$ mosquitto_pub -m '?3' -t 'ebusd/350/Hc1NightTemp/get'

I get in mqtt:

ebusd/350/Hc1NightTemp/get ?3
ebusd/350/Hc1NightTemp 21.0

like that with /get?1:
mosquitto_pub -m '?3' -t 'ebusd/350/Hc1NightTemp/get?1'

I get nothing back…

So I’m afraid the only option is to run my dummy script:

 cat ebusdMqttRefresh.sh
#!/bin/bash
mosquitto_pub -n -t ebusd/350/Hc1OPMode/get
mosquitto_pub -n -t ebusd/350/Hc1DayTemp/get
mosquitto_pub -n -t ebusd/350/Hc1NightTemp/get
mosquitto_pub -n -t ebusd/350/DisplayedRoomTemp/get
mosquitto_pub -n -t ebusd/350/BMUB51101BoilerFlowTemp/get

mosquitto_pub -n -t ebusd/bai/Flame/get
1 Like

This should enable polling with priority 3, so you should see ebusd queries this parameters once in 3 * polling_interval seconds - please confirm you see this happening in ebusd logs

This is not correct, I didn’t read the documentation carefully, sorry. But this will set polling priority t 1*pollin_interval:
mosquitto_pub -m '?1' -t 'ebusd/350/Hc1NightTemp/get'
and you should see this happening in ebusd logs

I still believe we can avoid that

Was there ever a new batch of the boards made? I can’t quite work out the german on the forum, but I’d really like to get hold of one :slight_smile:

Here how I set up the polling:

################################################################################
# Setup ebusd messages to poll
################################################################################
- alias: 'ebusd setup VRC700f/4 polling priorities'
  trigger:
    platform: state
    entity_id: binary_sensor.ebusd_vrc700f_4_connected
    to: 'on'
  action:
    # Set priority to 1 polling interval: ebusd will add all the below
    # into its message queue and will query one of the parameters per
    # polling interval
    - service: mqtt.publish
      data_template:
        topic: ebusd/b7v/z1RoomTemp/get
        payload: '?1'
    # set priority to 2 polling intervals
    - service: mqtt.publish
      data_template:
        topic: ebusd/b7v/z1DayTemp/get
        payload: '?2'

Please pay attention on the trigger: this automation runs when my VRC700 has been scanned. To force scanning (as ebusd may have already scanned the devices before HA start):

- alias: 'ebusd force ebusd scanning'
  trigger:
    - platform: mqtt
      topic: "ebusd/global/signal"
      payload: 'true'
  action:
    - service: mqtt.publish
      data_template:
        topic: ebusd/scan.08/id/get
        payload: '?'
    - service: mqtt.publish
      data_template:
        topic: ebusd/scan.15/id/get
        payload: '?'

and

- platform: mqtt
  name: "ebusd BAI connected"
  device_class: connectivity
  state_topic: "ebusd/scan.08/id"
  availability_topic: "ebusd/global/signal"
  payload_available: "true"
  payload_not_available: "false"
  qos: 2
  value_template: >
    {% if "0010021961" in value %}
      ON
    {% else %}
      OFF
    {% endif %}

- platform: mqtt
  name: "ebusd VRC700f/4 connected"
  device_class: connectivity
  state_topic: "ebusd/scan.15/id"
  availability_topic: "ebusd/global/signal"
  payload_available: "true"
  payload_not_available: "false"
  qos: 2
  value_template: >
    {% if "0020197207" in value %}
      ON
    {% else %}
      OFF
    {% endif %}

I don’t like the hardcodes inside, but don’t know how those can be avoided, e.g. read from configuration or so

1 Like

First of all, I’m really sorry for the delayed answer, I was quite busy at home with other stuff …

Interesting approach, but for some of the config I do need some clarifications:
How did you came up with these values templates:

This is for the boiler (bai), right ?
Are those values valid for my boiler or I need to figure that out in some way ?

This is for the wall thermostat I guess.
But again are the values valid for me too or how should I get them ?

Just for my understanding: you are pulling the values via MQTT via an automation in HA, right?
How oft will this happen and in which conditions ? e.g. HA restart, value change in ebusd?