Replies: 4 comments 2 replies
-
|
The procedure about what to do to get the controller specific What to do with that file after receiving it can be found within the subchapters of chap. 2.1 "Installation" for the corresponding microcontroller (Arduino Due / ESP32): |
Beta Was this translation helpful? Give feedback.
-
|
"Security reasons"? => "Safety stands for accident avoidance, and security for crime prevention." (Source: https://www.tuev-nord.de/explore/en/explains/whats-the-difference-between-safety-and-security/) ;) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, then safety is the better term. |
Beta Was this translation helpful? Give feedback.
-
|
Since people have asked about this in some of the pull requests: The parameter descriptions can be extracted in a number of languages, so translating parameters will no longer be an issue. Users will just have to state which language they want their BSB_LAN_custom_defs.h to be in. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Just to show you the amount of manual work involved in translating the dump into the actual BSB_LAN_custom_defs.h using a QAA75... |
Beta Was this translation helpful? Give feedback.
-
TLDR: We will no longer provide updated BSB_LAN_defs.h after version 2.0 for security reasons. Users will get tailor-made BSB_LAN_defs.h for their systems.
Some of you have probably wondered why there haven't been any significant updates in BSB_LAN_defs.h despite people sending in their "Check for new parameter" reports. In fact, these keep piling up on my ToDo list, and there are probably over a 1000 parameters waiting to be included.
Apart from the fact that I had quite a bumpy ride in life over the last 12 months, the reason for this delay is rather caused by the fact that we have managed to find a way to figure out what parameters each heating system "knows". That is the "complete dump" that is part of the "Check for new parameters" for quite some time now.
At first we thought that this is great - we would no longer have to ask users to check all different kind of parameters and their options and could simply add any parameter that is not currently in our BSB_LAN_defs.h. But after analyzing more and more of these reports, we stumbled upon two major problems:
The first one was that over the 20 years or so that the LPB/BSB bus exists, Siemens (the company manufacturing all the controllers in the heating systems BSB-LAN supports) had to introduce more and more categories and parameters that eventually overlapped with other, already existing categories or parameters. So one category or group of parameters on one system has the same number range as a different category or group of parameters has on another system. We have tried to accomodate this so far by moving these numbers away to "free" locations, but these became fewer and fewer. It also made translations more difficult because you would have to check whether parameter X on machine A really means the same on machine B or not. Also, we would have to change the whole category system which currently is a "one fits all" when in fact it's not. While all this would be possible to deal with, this would have meant a lot of work for us because we would have to do this check with every new heating system we come across.
The second and much more severe problem is that we figured out that there are a lot of parameters which have the same parameter number and the same name, but come with completely different sets of options. When you look at parameter 5950, you see that we realized this already years back but always hoped that this was just a strange exception. The fact is: it's not. There are dozens and dozens of parameters that differ from one heating system to another, be it in terms of their options, their conversion factor, their unit etc. We even realized that some options have the same numeric values, but with an opposite meaning (think: inverted contact function). And this is where we had to think hard, because in the current system, we would always assume a "default" meaning without knowing whether there is actually such a thing as a "default" meaning of a parameter. Take again parameter 5950 for example (there are many, many more): We think that the DEV_ALL line is the default that we use for any unspecified or new machine when in fact the list of exceptions that follows is so long that it's probably the other way around. This becomes worse when you compare different heating systems, such as gas heaters and heat pumps for example. We started out with gas and oil burners in the beginning, but again, there are so many more different systems now that it's hard to keep track.
So unless users really check if the parameters and options shown in BSB-LAN actually match what is shown on the heater, users might just take this as a given and use the parameter unknowingly in the wrong way. The danger here is that the heater will accept the "wrong" setting because the telegram that BSB-LAN sends is valid - just the meaning might be more or less completely off. And there are dozens of parameters, especially those with drop-down menus (a.k.a. ENUM parameters) which are f..cked up beyond repair.
So where do we go from here? We have contemplated various options but the only one that seems feasible is to move away from the "all parameters for all heating systems" approach. There was very little gain for the average user to begin with, but with the abovementioned risks, it is simply no responsible approach anymore.
The good news is that we now have more or less decoded the complete dump so we can generate a tailor-made BSB_LAN_defs.h from this dump for the heating system in question with all the correct parameter names, options, units etc.
The not so good news is that this process can only be semi-automated. It will require manual adjustments by us. And before anyone asks: No, we cannot make public the decoding algorhythm of the complete dump. Legal regulations in Germany do allow reverse engineering to some extent, but not to publish the decoding algorhythm.
So this is how we plan to do this in the near future:
We know that this is more work on all sides (more on ours than on the users'), but we believe that having a fully and accurately working BSB-LAN is in everyone's best interest. The old system was nice as a playground and especially I loved to explore new parameters, but a heating system is not a playground, therefore these changes are necessary.
We will roll out these changes over the next couple of weeks, hopefully before the heating season really kicks in, but bear with us if it'll take a bit longer. We want to make this step well prepared and without any major obstacles for the users.
More information will be provided here whenever there is any.
Beta Was this translation helpful? Give feedback.
All reactions