Ariston Group integration via eBusd

This is what I get running ebusctl info from inside the ebusd container:

root@05b0aa437146:/# ebusctl info
version: ebusd 23.3.23.3
update check: version 24.1 available, device firmware 1[4a1b] available
device: ebus-aerotermia.local:9999, TCP, enhanced, firmware 1.1[4a08].1[4a08]
signal: acquired
symbol rate: 33
max symbol rate: 168
min arbitration micros: 0
max arbitration micros: 3
min symbol latency: 4
max symbol latency: 15
scan: finished
reconnects: 0
masters: 9
messages: 301
conditional: 0
poll: 0
update: 54
address 00: master #1
address 01: master #6
address 03: master #11
address 06: slave #6, scanning
address 11: master #7
address 13: master #12
address 16: slave #7, scanning
address 18: slave #12, scanning
address 1e: slave, scanning
address 31: master #8, ebusd, conflict
address 36: slave #8, ebusd, conflict, scanning
address 70: master #4
address 75: slave #4, scanning
address 7f: master #24
address 84: slave #24, scanning
address f0: master #5
address f5: slave #5, scanning

change CSV configuration to explicitly request the reading

I guess the question is… how do I know the name of the parameters that my HAVC exposes? Is there a way of just seeing all the traffic and then add stuff to the CSV as I need it?

Thank you for your help :man_bowing:

I think the first issue to be solved is this. Why are you having a conflict in ebus addressing? Are you running multiple instances of ebusd on the same bus? If so you should give each one a different master address.

I had two instances of ebusd running (the one you see, for the Nimbus Pocket heatpump, and another one still not connected to anything, for the Nuos Plus Wifi boiler), but I just stopped the instance for the boiler and still getting those conflicts.

Could that be the Sensys HD or any of the Ariston “Cube” thermostats? :flushed:

If you have 2 ebusd instances connected to the same adapter or with different adapters connected to the same bus then the devices on the bus “feels” the address duplication.
If you want 2 instances of ebusd running please be sure that you alter the def. address of one of them (–address command line params)

I have two adapters, two instances of ebusd both running on the same Raspberry Pi.

I’ve disconnected one of the adapters, stopped one of the ebusd instances, restarted the other one, and still see that conflict. I will look into the --address param and see if I can get rid of that :thinking: Thank you! :bowing_man:

there are entities that become “unknown” example “sensor.ebusd_energymgr_ebusd_energymgr_hybrid_mode”
until yesterday it was hp only now it is unknown


AFAIK an Entity became unknown (from a known state) in HA, with ebusd if:

  • the ebusd addon is restarted
  • since the restart the entity is not updated/read on the bus

can you post here the message dump? ( ebusctl grab result all > message_dump.txt )


doesent work in homeassistant

must be run inside the container/addon

this is file log

I use a select mqtt that you suggested me the code but the sensor view “2”

Now I edit it in www.ariston-net.remotethermo.com to “auto” and return correctly


Sorry ilgio, not what I asked. The file you sent is the ebus log, it contains trace of every packet sent, if the same pachet travels 100 times in the log you hav 100 entries.

The file I asked contains trace of all the messages that traveled on the bus since ebsd start (I think) and the count of times these appeared.

I know it’s a little frustrating, HA tend to hide some complexity behind addon etc, but whith this integration you need to debug at very low level.

In my case it works correctly, with the MQTT select,from Auto, I switched to “HP Only”

image

the entity does indeed shows “2”

but if you ask to the Energymanager what it stored it answer with “hp_only”:

~$ ebusctl read -m 0 -c energymgr hybrid_mode
hp_only

so the system received the message and processed it.

I don’t know how to do low level debugging on HA

my explorer mqtt:
Screenshot 2024-10-30 alle 19.23.36

there is something wrong.
I tried to update from web ariston and the first two times ebusd also updated, then it stops updating anymore


Screenshot 2024-10-30 alle 19.23.36

It’s normal. When you update a parameter from the web/app the HVAC system may get the update immediately, for this to be reflected in HA (via ebusd) you need to wait that some device on the bus transmit that parameter to some other device and, thus, ebusd is able to grab it from the bus and send it to HA.

For some parameters (eg i/o configuration and some boiler settings) that are almost never trasmitted on the bus, and so ebusd is unable to “read” the updated from messages traveling on the bus in my case I had to schedule some explicit reading.

If you have a fairly good latency you can tru to modify these parameters lines to force ebusd to read them adding a prioriy reading setting in the CSV.

From:
r,energymgr,hybrid_status,....
To
r4,energymgr,hybrid_status,....

I know that now you’re tempted to forcibly read every parameter in the file. Don’t do it, you’ll get a bus too much trafficked, endangering the normal functioning of the system and, btw, some line are not “good” to be explicitly read, why this is too complicated to be inserted in an english post…

I found the log when I change the select hybrid mode:

set to boiler

set to auto

set from web ariston

since i changed this.

r4,energymgr,hybrid_mode,Hybrid Mode,,18,2000,c628,,s,IGN:1,,,,,,BCD,0=auto;1=boiler_only;2=hp_only

now when i change the select , it sets 2 and after a few seconds it updates correctly to hp_only … wowww

Hi, I set up the device with the linked csv (thanks a lot!) and apart from some errors with things that I don’t use, it works quite well!
The only thing I’d like to fix is the internal temperature (and possibly the humidity), I have a Sensys HD thermostat and I tried with an ebusctl grab result decode and a grep with the actual temperature but it’s not so clear how can I translate it into a new row for the csv.
Could anyone help me?

Edit:
Found the guide on the eBUSd repository, linking it for everyone c:

HI, are you sure in your system the parameter 7118 (room temp) is missing?
can you try to search for it?

ebusctl grab result all | grep 7118

There are other ways to find the info. If the room temp and humidity are sent regularly as a broadcast you can try to dump the messages received (ebusctl grab result all > dumpfile.txt) and sort the file alphabetically. Then scroll down to it and search for messages that are almost identical but varied between them for 2/3 hex bytes. This usually means that the message structure is the same but some parameter is changing over time.
You may influence a room temp change heating the Sensys, touching the sensor zone with your hand or brutally with an hair drier.

If you look into the ebusctl grab result decode output grep the SIN rows, it’s the usual datatype for temp values. If you find a SIN value that seems interesting go looking for that message and see if it’s frequent etc…

Reverse engineering basics :slight_smile:

Yes that’s a start but keep in mind that Aristo Group BusBridgenet is not really compliant with ebus specifictions.

Message structure is different than the standard ebus :

Master/slave “query”:

 QQZZPBSBNNP1P1P2P2 / NNCC111122 = count

In Bridgenet, QQ is the source address, ZZ is the destination address, PBSB is the primary and secondary command byte, and these are peculiar, the most common is PBSB=2000 that is read one or more parameter (if broadcasted - ZZ=fe -it means “please anyone that has the info on this please reply with another message”)

NN is the number of hex bites following, P1P1 is the 2 hex bytes of Parameter1, P2P2 the 2 for Paramter2
The reply from the slave is: NN number of hex bytes in the reply, CC is the number of parameters in the reply (2^parnum-1: 1=1 par, 3=2 par, 7=3 par, f=4 par).
1111 is a 2 hex byte reply for P1, 22 is a single hex byte reply for P2. Obviously the length of the parameter reply (1,2 or 3 hex bytes is dependent of the datatype)

master/master messages are more tricky:

13 1e 2020 03 d5f0 00 / 00

this is the energymgr (13 master address) issuing the HP (1e master address) a command (2020 PBSB I interpret it as a writing a parameter change) the command is 03 hex bytes long and it has a single parameter written, that is d5f0 and the value that is 00 (0), probably a onoff switch (0/1) the part after the / is the ACK (00 = ok)

Also keep in mind that Bridgenet does not (AFAICT) respect the ebus standard on master address and their roles.

00 used by ?? to control the bus
03 used by ?? to control the bus
13 Energy Manager
18 slave Energy Manager
1e slave Heatpump
23 slave ???
37 master Boiler
3c slave Boiler
70 master z1 SENSYS
75 slave z1 SENSYS
7f master WIFI GW
84 slave WIFI GW
fe BROADCAST

Thanks for the detailed explanation!
Just a question, for non integers values: in my thermostat the temperature is a floating point with a decimal digit, how will it be converted into an hex? The hex of the integer part followed by the hex of the decimal one?