Open kenny00111 opened 1 month ago
Hi, it probably either the default value sent if the external probe is missing or the decoding is wrong for your model. Try searching the raw message that gets intercepted.
You should use ebusctl command to dump the message
thanks, but exactly how can I do that?
It depends on how you installed ebusd. Take a look at ebusd documentation but if you have a standard install the command should be
ebusctl grab result all | grep PBSB
In a docker env.
docker exec -ti EBUDS_CONTAINERNAME ebusctl grab result all | grep PBSB
Where PBSB is the command code of the parameter you're diagnosing.
I got this reply: 313c2000027647 / 0301ff7f = 18: boiler ext_temp
I guess 0301ff7f need to be decoded?
I also see a bunch of unknown fe2000 commands:
2024-06-10 18:29:34.455 [update info] received BC cmd: 37fe2000026d26 2024-06-10 18:29:34.455 [update notice] received unknown BC cmd: 37fe2000026d26 2024-06-10 18:29:34.951 [update info] received BC cmd: 37fe2000027647 2024-06-10 18:29:34.951 [update notice] received read broadcast accept_telegrams_external_temp: 2024-06-10 18:29:35.412 [update info] received BC cmd: 37fe2000026047 2024-06-10 18:29:35.412 [update notice] received unknown BC cmd: 37fe2000026047
It seems that the message is indeed decoded:
0301ff7f
means
03 = 3 hex byte reply
01 = 1 parameter in the reply
ff7f = 7fff = 32767 in decimal
I think that the missing probe means that the system fall back to a default (?) or invalid value.
You log extract means that the boiler (37 is usually the master address of the boiler in Ariston Group bridgenet) Is asking (that's my interpretation of 2000 PBSB) to everyone (fe=broadcast) if they have/can provide an up to date value for the 6d26 and 6047 parameters. In one instance ebusd correctly interpreted the ext temp message in the way that the decoding of the message was successful, ebusd doesn't know that the translation of the 7647 parameter is meaningless/wrong/default.
Thanks for the great answers I start to understand. It strange that the system knows about the disconnected sensor so my opinion it should default to some value like unknown.
Thanks for the great answers I start to understand. It strange that the system knows about the disconnected sensor so my opinion it should default to some value like unknown.
That field is a numeric one. That exclude strings like NULL, VOID etc, you cannot obviously choose 0 as it is a "valid" external temp, my guess is they choose that high number as default and all the Ariston devices recognize this.
BTW have you thought of buying an external probe? It's reasonably cheap (around 20€ here in Italy) and all it needs is a 2 wire cable (the old telephone twisted pair is good enough) from the boiler to function. Having the ext probe you can enable SRA thermoregulation.
If you look in the hardware reverse engineering of this repo you can find also a diy solution (NTC 10k@20°C)
So it could be possible to emulate the resistance with the esp based on an existing sensor value?
So it could be possible to emulate the resistance with the esp based on an existing sensor value?
I don't think so, but you can try, in case of problem disable your "automation" and simply reboot your boiler. You should continuously update the 7647 parameter with your own value writing it on the bus. Don't know if the boiler likes it :)
If it was me I 'd go with a physical probe, "original" or custom made but independent from HA , esp, wifi etc.... it's my home in the winter we're speaking of ..
My idea is rather to use a digital potentiometer to emulate the sensor (not sure yet if it is feasible or not). It would be too much wiring otherwise.
Hi, I used your config to my Chaffoteux mira C green boiler, and everything is working fine except the external temp ( as far as I know i don't have an external sensor).
![image](https://github.com/ysard/ebusd_configuration_chaffoteaux_bridgenet/assets/64666922/4edf2a53-cf29-477f-a192-7d937206c55f)
do you know what could be the problem? i am very new to ebusd
thanks