john30 / ebusd

daemon for communication with eBUS heating systems
GNU General Public License v3.0
560 stars 130 forks source link

Ebusd ignores QQ in message definition? #244

Closed klaasdc closed 5 years ago

klaasdc commented 5 years ago

I am writing a definition file for my Wolf heating system. Master F1h and 03h are broadcasting almost identical messages. For example:

03fe050308010000ff3e212d08 and f1fe050308010000ff3bff2d07

I'm not sure why they are basically duplicated, but according to the ebus docs I found, PB 0503 would represent operational data from the burner (which should be at master address 03h) So I write a line in the CSV to get the broadcast messages from 03h: r,burner0,opdata,Burner unit operational data broadcast block1,03,fe,0503,01,status,,UCH,,,State Number - In case of errr Bit7 is 1,signal,,UCH,,,Signal state of the burner control unit,settingdegree,,UCH,,,Setting degree between min and max boiler performance in pct,kt,,D1C,,Celsius,Boiler temperature KT [...]

But when I do a 'ebusctl grab result all', I notice that both messages originating from Master 03h and master F1h are both decoded into burner0 opdata. This leads to overwriting of a value. Most likely my definition line is wrong, but I can't figure out why my definition also decodes messages from F1h. What could be wrong?

john30 commented 5 years ago

you cannot actively read broadcast messages, as the term implies. those are broadcast from the corresponding unit and there is no means of reading them unless the unit offers the same data with a different ID as well (where ID also includes the PBSB). But you can make ebusd listen to and store the data of such broadcast messages by declaring it as "uw" for "update write" meaning passive reception only for ebusd while the message is composed of master data only. Then you should be able to query ebusd for the last received data using ebusctl.

klaasdc commented 5 years ago

Thanks for the reply! Setting the type to uw indeed solves my problem. Now I could create separate entries for the above opdata. But I do not understand the meaning of write very well. Does it only define that a message consist of master data (instead of master + slave part for read)?

I also have a question about the fields inside a message. One message can have multiple variables (e.g. as above outside temperature and exhaust temperature). But all fields are 'published' as a single string (values separated by a semicolon). Is there a way to have ebusd separate them based on the field names? Now I do this with a script that republishes the separate fields on my mqtt server, but maybe this is redundant work.

john30 commented 5 years ago

a write in ebus context is a pure data transfer from a master source to a slave or master destination, where a read usually is the oppsite (data transfer from destination to source) but may also transfer data to the destination. you can either make ebusd publish to MQTT on field level (but then it won't handle /set requests any more) or make ebusd publish in JSON format, which is even better IMO