Wow, thank you very much, you have opened up a world for me with this example :D.
Can I ask you one more thing about the read command, when I try to read a value, for example:
docker exec -en c19abbbdd932 ebusctl read -m 0 energymgr z1_night_temp
I get this result:
31182000026371 / 0100 = 3: energymgr z1_night_temp
in this case the result does not make sense, is the problem that the read command is not correct or can there be answers that have no value like this one?
Thanks
I know I’m asking a lot of you, but I’m entusist to be able to do it myself.
I tried to decode this string using that csv attached but the result is negative, can you help me to decode this one?
THANKS
#70 1e 2001 02 7710 / 06a4000080ff7f = 3
#r,heatpump,heatpump_EWT_temp,Heatpump Water Return Temp,,18,2000,7710,,s,IGN:1,,,,,,SIN,10,°C
#r,energymgr,heatpump_EWT_temp,Heatpump Water Return Temp,,1e,2001,7710,,s,IGN:1,,,,,,SIN,10,°C
#r,heatpump,water_flow_info,Heatpump Water Flow Data,13,1e,2000,7610771079106e13,,s,IGN:1,,,,LWT_temp,s,SIN,10,°C,,EWT_temp,s,SIN,10,°C,,evaporator_temp,s,SIN,10,°C,,flow_meter,s,UIN,10,L
#g,heatpump,coolat_data,Heatpump Coolant Data,70,1e,2001,7710,,s,IGN:2,,,,EWT_temp,s,SIN,10,C
r,heatpump,heatpump_EWT_temp,Heatpump EWT Temp,,1e,2001,7710,,s,IGN:1,,,,,,SIN,10,°C
I found the solution, i used this row:
r,heatpump,heatpump_EWT_temp,Heatpump EWT Temp,1e,2001,7710,SIN,10,°C,
because the first byte 06 is automatically excluded.
Thanks,
Matteo
Yeah the first byte is handled directly by ebusd as it is part of the standard protocol .
Ariston ebus implementation adds second byte to be ignored only on master/slave query commands, that has to be discarded with a IGN:1 field setting.
In your firmware (and many others recent versions of the devices it seems) the energy manager doesn’t reply back with a reply but with (what I interpret as) an error code /0100.
Having been asked I try to answer to Matteo’s question and otherd who would like to try decoding these are the most commonly transmitted message types, treat these as templates and with these you should be able to “read” most of the messages.
1) MASTER/SLAVE
It’s the message type used mainly by a device to request a parameter/reading from another eg.
311e200002d22c / 020119
This is read as:
31 - MASTER Address (in this case ebusd that has 31 as master and 36 as slave addresses)
1e - HP slave address
2000 - PBSB (primary and secondary bytes) in Ariston dialect of ebus is (what I interpret as) the command to be executed, 2000 stands for queryparameter
02 - LEN of the message (ebusd is able to generate this in case of writing messages, reading a parameter via ebusctl read cause the writing of a query message on the bus like the one we’re dissecting) in Ariston jargon 2 hex bytes are a single parameter
d22c - parameter code/id, in this case the HP minimum pump modulation
/ divider that separate the request from the reply, from here on the communication is from the slave to the master
02 - REPLY length, 02 hex bytes, ebusd use this to check that all bytes have been received then discard it, doesn’t need to be parsed
01 - Ariston dialect addition: represents the number of parameter that are replied back, it’s generated with the formula 0x(2^n-1) where n is the number of parameters here a single one (2^1-1=1)
19 - value in hex of d22c parameter (0x19= 25 dec) my HP pump is set to go down to minimum 25% of the modulation
Master/Slave commands usually request more parameter with a single query: eg:
7f1e200004704f7217 / 05036300bf00
7f - Sensys master address
1e - HP slave
2000 - query
04 - 04 hex bytes, 2 parameters
704f - 1st par. (heatpump_exp_valve)
7217 - 2nd par. (heatpump_suction_temp)
/
05 - number of hex bytes of the reply
03 - number of parameters sent back, here n is 2: (2^2-1=3)
6300 - ebus is Little Endian so the reply must be read swapping hex bytes, 0063= 99 (99pct??)
bf00 - 00bf = 191 = 19.1°C (Ariston Ebus transmits temps almost always as integer multiplied by 10)
2) MASTER/MASTER messages (used also for broadcast messages)
These are messages that a master sent to another one and usually the only replied back value is an ack (/00)
13fe2020106a7146006a723c006a7396006a749600
13 - sender
fe - receiver (fe stand for every device on the bus)
2020 - PBSB this I read as “the following parameter have these values act on them accordingly”
10 - LEN
6a71 - 1st par CODE
4600 - 1st par VALUE
6a72 - 2nd par CODE
3c00 - 2nd par VALUE
6a73 - 3rd par CODE
9600 - 3rd par VALUE
6a74 - 4th par CODE
9600 - 4th par VALUE
remember that par CODES are always 2 hex bytes long, values have different lentgh based on various data types (1,2 3 even 4 bytes long)
The /00 ack is not sent back on replying to broadcast messages
This other message
131e20200dc33efbc44664cd46006a475b01 / 00
should be parsed as:
13 1e 2020 0d c33e fb c446 64 cd46 00 6a47 5b01 / 00
Here you have 3 PAR with a single hex byte VALUE length and a single parameter with a 2 byte length.
1e here reply back a /00 ack.
An exception to this case is when a device broadcast a query command like this one:
37fe2000020120
here the boiler (master 0x37) is asking to every device (fe) to reply back (2000 PBSB) the value of 0120 parameter; there is no direct reply but (I interpret, from my findings) independently, the devices that have the value and are “authoritative” for that parameter reply back the value with another, asyncronous, broadcast message.
There are other message types but these are used mainly for specific function (cast date, programs, errors, serials, but these can be left for other nights 
Many thanks to all of you and to @wrongisthenwright in particular. I have interfaced our Ariston Nuos Split WiFi (heatpump water heater) with an eBUS Adapter Shield C6. With the help of this post and the referenced github sites I managed to decode most broadcasts. My csv file is:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment,field2,part (m/s),datatypes/templates,divider/values,unit,comment,field3,part (m/s),datatypes/templates,divider/values,unit,comment,field4,part (m/s),datatypes/templates,divider/values,unit,comment,field5,part (m/s),datatypes/templates,divider/values,unit,comment
b,broadcast,slave_address,SlaveAddress,,fe,203b,,address,,HEX:1
b,broadcast,date_time,DateTime,,fe,2070,,time,,VTM,,,,date,,HDA
b,broadcast,current_target_temperature,Current Target Temperature,,fe,2010,6147,target,,S3N,10,°C,,code,,HEX:2,,,,normal_reduced,,BCD,0=off;1=reduced;2=normal,,,
b,broadcast,reduced_temperature,Reduced Temperature,,fe,200f,6226,reduced,,S3N,10,°C,,code,,HEX:2,,,,timed_fixed,,BCD,0=off;1=timed;2=always_on,,,
b,broadcast,normal_temperature,Normal Temperature,,fe,200e,6126,new_target,,SIN,10,°C,,code,,HEX:2,,,,max_temperature,,SIN,10,°C,,
b,broadcast,nuos_info1,Nuos Info 1,,fe,2020,0220,dhw_status,s,BCD,,,,el_code,s,HEX:2,,,,electrical_element,s,BCD,,,,al_code,s,HEX:2,,,,anti_legionella,s,BCD,,,,mode_code,s,HEX:2,,,,comfort_mode,s,BCD,0=off;1=timed;2=always_on,
b,broadcast,nuos_info2,Nuos Info 2,,fe,2020,ca2a,data,s,HEX:1,,,,comfort_temp,s,HEX:2,,,,dhw_comfort_temp,m,SIN,10,°C,,economy_temp,m,HEX:2,,,,dhw_economy_temp,m,SIN,10,°C
b,broadcast,heating_mode,Heating Mode,,fe,2010,d69a,status,,SIN,1,,,heating_code,,HEX:2,,,,heating_mode,,BCD,0=off;1=heatpump;2=element;3=both,,,
b,broadcast,c_2010_da46,2010 da46,,fe,2010,da46,c_da46,,SIN,1,,,code,,HEX:2,,,,c_d3f2,,SIN,1,,,
b,broadcast,c_2038_00,2038 00,,fe,2038,00,c_2038_00,,HEX:1,,,,data,,HEX:3,,,,
b,broadcast,c_2038_01,2038 01,,fe,2038,01,c_2038_01,,HEX:1,,,,data,,HEX:3,,,,
b,broadcast,c_2038_02,2038 02,,fe,2038,02,c_2038_02,,HEX:1,,,,data,,HEX:3,,,,
b,broadcast,c_2020_7d26,2020 7d26,,fe,2020,7d26,c_7d26,,SIN,10,°C,,code1,,HEX:2,,,,c_712b,,HEX:2,,,,code2,,HEX:2,,,,c_7e2b,,SIN,10,,,
b,broadcast,ign2050,ign2050,,fe,2050,,data,,IGN:11
b,broadcast,ign2051,ign2051,,fe,2051,,data,,IGN:14
b,broadcast,ign2071,ign2071,,fe,2071,,data,,IGN:7
b,broadcast,reply,Reply,,fe,200f,,reply,,HEX:*
w,broadcast,command,Command,,fe,2020,,command,,HEX:*
w,broadcast,query,Query,,fe,2000,,query,,HEX:*
Reading parameters only seems to succeed by issuing a broadcast request, e.g. hex fe 2000 02 c028 to read the program/manual mode. Up to 4 parameters can be requested in one request. The reply comes as a broadcast message with PBSB 200f. Setting a parameter also works with a broadcast message but with PBSB 2020.
Adressing the master or the slave (77, 7c) directly does not seem to work.
Not sure how I did it, ChatGPT helped me a lot with it, but I managed to decode the Leaving Water Temp and Return Water Temp on my Ariston Nimbus Pocket heatpump!
The original csv had those two lines:
r,heatpump,heatpump_LWT_temp,Heatpump Waterflow T emp,,18,2000,7610,,s,IGN:1,,,,,,SIN,10,°C
r,heatpump,heatpump_EWT_temp,Heatpump Water Return Temp,,18,2000,7710,,s,IGN:1,,,,,,SIN,10,°C
But they wouldn’t work for me. I changed just the 18,2000 part to 1e,2000 and it works!
Now, since most lines on the CSV don’t work for me, I wondered if by changing them from 18 to 1e will fix them! So I tried a few more lines and, even though the correct value for me wasn’t always the 1e, it seems that by just changing that part the messages are being decoded correctly!
Another example is the heatpump_mode, which I changed from 18,2000,ca46 to 70,2000,ca46 and it reads it correctly! 
After a lot of trying and with a lot of help from wrongisthenwright my strong feeling is that Ariston only puts changing values on the ebus. So sensor info is always there because they change all the time. User settings need to be changed before they are published. Today, for example, I changed the room influence per zone and BOOM, they are there in HA. So, before changing the original CSV to much, I would change some setting and see or they pop-up.