[WIP] Add MQTT logging

[jbaudoux]

Forward messages to MQTT broker

Relates to #442

In your BSB_LAN_config.h, set

• byte LoggingMode = 4; // CF_LOGMODE_MQTT
• int logTelegram = LOGTELEGRAM_ON

[jbaudoux]

What's the purpose of dest_addr in log_parameters ?
In MQTT, this adds a ! and the address in the topic but that does not correspond to any MQTT usage

[fredlcore]

Is there really no way that you can work on your contributions in your fork and only submit a PR when it's ready for review? Then these "draft PRs" wouldn't clutter my project's PR list which is basically my main ToDo list for this project.

And again: I don't entertain any questions before there is an explanation on what is planned to do and how it is planned to do it. Other than that, the questions you ask show that you haven't even made it to chapter 5 in the manual.

[jbaudoux]

First trial shows promising results. I tested with logTelegram = LOGTELEGRAM_ON
Now the MQTT broker is aware of any static config change. Whatever the thermostat I use, the SET command is forwarded with the new value. The state updates that are published on the bus are also forwarded to the MQTT broker (e;g. 10025, 10027, 10028).
I only need to list in log_parameters the moving temperature values that are not automatically notified on the bus like the outside temperature (8700) and room temperature (8740)

[fredlcore]

No one - including me - knows what parameters you are referring to when you talk abount parameter numbers >= 10020...

[fredlcore]

Even though it's still in draft, please take note of the following:

• Have a look at the function parsingStringToParameter.
• We specifically introduced the parameter struct for easier handling of parameters as well as destinations. Do not introduce your own kind of handling of that by removing code that explicitly uses this struct, unless you have a good reason to do so.

Again, please explain what you plan to do before wasting your own time on a PR that I may not accept in the end.
I appreciate if someone takes the time to refactor this part of the code which has grown organically too entangled, but if we do such a major move, it should be done solidly:

• query() should be removed from mqtt_sendtoBroker(). If the former is executed before the latter, we will have decodedTelegram populated with all relevant information, so it can be published right away.
• query() should no longer be called with the line number but a parameter struct. Having also the destination device ID in the function would enable us to move a lot of the temporary switching of destination devices to the query() function, as well as (optionally) call mqtt_sendtoBroker() which requires a parameter struct to be passed to it.
• printTelegram also uses decodedTelegram, so mqtt_sendtoBroker() could easily be called from there as well. There is also quite a significant amount of overlap between LogTelegram() and printTelegram(), and it might be worthwhile to bring together all log functionalities (debug output, SD card, MQTT, UDP) together in one function (or one with several sub functions).

[fredlcore]

How do you know that the destination address is always the default destination address (that's what -1 stands for in param.dest_addr)?

[fredlcore]

What about TYPE_QINF, TYPE_ACK, TYPE_NACK etc., do you want to log them as well? Do you know the state of decodedTelegram in these cases?

[fredlcore]

This has become obsolete now, I think. Thanks for the ideas anyway.