The values in the templates come from ebusctl scan result:
08;Vaillant;BAI00;0104;7803;21;18;23;0010021961;0001;005167;N4
15;Vaillant;B7V00;0422;5503;21;18;36;0020197207;0082;013759;N6
So, 0010021961 and 0020197207 are those numbers you have to replace in your setup to the corresponding values of your equipment. In my case I can also use BAI00 and B7V00 as unique identifiers as well: basically any value which allows you to uniquely identify the HW can be used here.
No, for that I have an automation which sets up ebusd to poll for me, e.g. for BAI:
- service: mqtt.publish
data_template:
topic: ebusd/bai/FlowTemp/get
payload: '?1'
This piece will run once we have scan result from ebusd meaning that ebusd can now send/receive commands to/from BAI. By this automation I instruct ebusd to set polling priority to 1 for BAI’s FlowTemp. Sending this before ebusd has scanned BAI will do nothing as bai/FlowTemp is not yet known to ebusd. This can happen when HA starts before ebusd or if ebusd restarts - for that reason we have to maintain ebusd connection/signal status changes at run time.
Well, we can have number of states here to define our state machine:
- ebusd started before HA and has scanned the equipment
- ebusd and HA started, but ebusd has not yet scanned the HW
- ebusd has restarted, but HA not
- etc.
I have this trigger to start scanning:
- 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: '?'
but it is not immediately correct as per my understanding ebusd/global/signal just shows that it has acquired the signal on the bus and it doesn’t mean it has scanned the equipment. So, the best is to have yet another trigger to start generic scanning, but for that there is no means at ebusd MQTT, e.g. you cannot request ebusd/scan/get or something. So, this is a trade off I took, but I do realize it leads to race conditions and might not work all the time…
WRT polling intervals. In my experiments I see that ebusd does poll the values for me: those with priority 1 are placed in the corresponding message queue and are polled in round-robin fashion one parameter at --pollinginterval seconds, e.g. if you have a single FlowTemp with priority 1 then every --pollinterval seconds, if you have 2 parameters with priority 1 then every param will be polled every 2 * (–pollinterval) seconds and so on.
