[BUG]? There's still "unknown parameters" with custom_defs

[DE-cr]

BSB-LAN Version 3.0.1-20221101130752

Architecture ESP32 NodeMCU

Bus system BSB

Describe the bug When configured (/C) to show unknown parameters, my system DOES display some, even with a personalized BSB_LAN_custom_defs.h:

• 20500[01].[0-3]
• 15000.0 .. 15091.0 (with gaps in between)
• 1002[34].0 (Sections /K25, /K26 are empty on my system; the could be omitted in /K.)

[fredlcore]

No, there are no more unknown parameters. 15000 are PPS parameters which cannot be used on BSB/LPB devices, 20000 and upwards are sensors and I have no idea what 1002[34].0 is supposed to mean, but if you mean 10002 and up, these are the parameters for setting the room temperature (as it is for years).

[DE-cr]

Sorry, I saw regular expressions used in the source code (or was it even in the manual?) so I thought you're familiar with them.

[fredlcore]

Yes, I'm familiar with them, but without context, the brackets could mean anything, especially if the first occurrence is definitively is not a meaningful regular expression in this context (20500[01] would mean the numbers 205000 and 205001 - both of which do not exist in BSB-LAN), then you don't use a regex in the second line where it would be perfectly possible to do so, too, and only in the last line you use one that actually makes sense. Maybe next time just do it in a way where none of us gets confused ;)...

[fredlcore]

As for parameters 10023 and 10024, that is interesting because your dump file reports these command IDs (but without a parameter number, which is why they are listed at 10000+). What you could try to do is change these lines

{0x053D058C,  VT_TEMP,            10023, S10023_0, 0,                  NULL,         DEFAULT_FLAG, 95, 239}, // Raumtemperatur Minimum
{0x053D058B,  VT_TEMP,            10024, S10024_0, 0,                  NULL,         DEFAULT_FLAG, 95, 239}, // Raumtemperatur Maximum

into

{0x0500058C,  VT_TEMP,            10023, S10023_0, 0,                  NULL,         DEFAULT_FLAG, 95, 239}, // Raumtemperatur Minimum
{0x0500058B,  VT_TEMP,            10024, S10024_0, 0,                  NULL,         DEFAULT_FLAG, 95, 239}, // Raumtemperatur Maximum

and see if that makes a difference. Furthermore, it could mean that these parameters cannot be read, but only set. However, I'm not sure about the effects of doing so, so this would be entirely your own responsibility. If setting the parameter results in an error, you could try to send the value as an INF using /I instead of /S. For INF telegrams, you won't get a success or failure response from the heater, though, so you would have to know the effects of that parameter to check if that's actually working.

[1coderookie]

Btw: Enabling "display unknown parameters" only affects the output of "error 7 - parameter not supported" types. Your 'parameter not supported' at the sensors for example is different though, cuz they would be supported if connected and activated, so they are not error7-types (correct @fredlcore ?).

[fredlcore]

Correct, the only thing is that I think at some point we dropped the "error 7" part of that message (don't know when, don't know why), so at first glance they look the same, although they're different in the way you described it. That configuration option will, however, be removed anyway because with the BSB_LAN_custom_defs.h there is no need to filter them out anymore because either they don't exist anymore or you want to know them (like with 10023 and 10024) so you can still try other ways of accessing them as mentioneed above.

[1coderookie]

..hmm, I'd vote for keeping that function tho cuz users who'll use the 'old & complete' custom_defs.h from v2.2 would still benefit from it!

[fredlcore]

Yes, they might benefit from it, but the benefit in my opinion does not outweigh the confusion that may arise for users using the new custom defs - as this example here show ;). Also, since there was never a benefit in terms of time, only in terms of "looks", and using the "complete" defs from 2.2 is deprecated, I would rather move to a "clean" solution.

[1coderookie]

Yeah, you're right..

(Personal note: I personally love(d) this feature tho when I did complete queries and didn't had to dig through tons of error7.. ;) )

[fredlcore]

Yes, I think that was one of the main reasons for us to add this feature ;). But since we won't get this kind of queries anymore, there is also no longer a benefit for us ;)...