Please clarify: /T, /A, /B, /DG, /JR and K49

[1coderookie]

@dukess : Sorry that I have to ask about the following, but I need to adjust the manual and it isn't really clear to me yet..

A) You deleted the functions of /T, /A and /B - is that correct? If so: 1) In the config.h there is this comment: You can enable I_DO_NOT_WANT_URL_CONFIG for saving space (~1.2Kb). This will disable configuration through URL commands (/A, /L, /P) -> is that comment just not adjusted yet or why is there named the /A command if /A is deleted? Or does it mean the command /A=\<x>,\<y>? 2) What about the other commands like /A=\<x>,\<y>, /A=0 and /B0 - are they obsolete too or do they still work somehow?

B) I probably missed the explanation of that function: Enable I_WILL_USE_EXTERNAL_INTERFACE for saving space (~6,8Kb). /DG command will be disabled - what is meant with 'external interface'?

C) I found this comment about /JR: 'reset program value to default through JSON' somewhere (I think it was within the note of that PR). Does that mean that the default value (if there is one) of that specific parameter within the controller will be queried (somehow ;) ) by BSB-LAN and then the value will be set back to that default setting? Did I understand that right?

D) Just a thought: you added K49 for the summarized output for the sensors etc - maybe it would be better if you would give that category already a higher number, just in case that there will be some other/new categories coming from the controller in the future..?

[fredlcore]

I think only /T and /B have been removed, as /A is still necessary for configuration via URL?

[dukess]

In the config.h there is this comment: You can enable I_DO_NOT_WANT_URL_CONFIG for saving space (~1.2Kb). This will disable configuration through URL commands (/A, /L, /P) -> is that comment just not adjusted yet or why is there named the /A command if /A is deleted? Or does it mean the command /A=,? What about the other commands like /A=,, /A=0 and /B0 - are they obsolete too or do they still work somehow?

/A command still partially work: user can set or clear list of programs, but not show list of current values.

B) I probably missed the explanation of that function: Enable I_WILL_USE_EXTERNAL_INTERFACE for saving space (~6,8Kb). /DG command will be disabled - what is meant with 'external interface'?

Interface which will be loaded from SD card. Ex. my project included /DG function too.

C) I found this comment about /JR: 'reset program value to default through JSON' somewhere (I think it was within the note of that PR). Does that mean that the default value (if there is one) of that specific parameter within the controller will be queried (somehow ;) ) by BSB-LAN and then the value will be set back to that default setting? Did I understand that right?

No. here is two step:

1. /JR (and /R) will return default value of program.
2. And if we substitute this value to set (/JS, /S) command then program will return to their default value.

D) Just a thought: you added K49 for the summarized output for the sensors etc - maybe it would be better if you would give that category already a higher number, just in case that there will be some other/new categories coming from the controller in the future..?

In this case we need add some empty categories. Users will not understand us. :)

[fredlcore]

Yes, while I understand your point, @1coderookie, this will happen to other categories as well if new categories are found (which will happen soon). So we shouldn't treat K49 differently then, I guess...

[1coderookie]

In the config.h there is this comment: You can enable I_DO_NOT_WANT_URL_CONFIG for saving space (~1.2Kb). This will disable configuration through URL commands (/A, /L, /P) -> is that comment just not adjusted yet or why is there named the /A command if /A is deleted? Or does it mean the command /A=,? What about the other commands like /A=,, /A=0 and /B0 - are they obsolete too or do they still work somehow?

/A command still partially work: user can set or clear list of programs, but not show list of current values.

So I have to delete the commands /T, /B and /A from the manual, but the other two /A-commands still have to be in the description, got it. So the comment within the config.h about the /A-command should be adjusted also maybe, just to make it clear for the users..?

What about /B0?

No. here is two step:

1. /JR (and /R) will return default value of program.
2. And if we substitute this value to set (/JS, /S) command then program will return to their default value.

Ah ok, so /JR will not automatically reset&set the default value. Got it, thanks

[1coderookie]

Yes, while I understand your point, @1coderookie, this will happen to other categories as well if new categories are found (which will happen soon). So we shouldn't treat K49 differently then, I guess...

Sure, that will affect all or many other categories. I just thought that K49 is kinda independent from the controller-categories, so if we already give it a higher number, users wouldn't have to also adjust settings for that one if new categories appear.. Just a thought and suggestion, no problem if it doesn't really make sense or so.. ;)

[dukess]

/B0 still work too. Here no other way to reset counters. We can thinking about reset implementation through /R (/JR) and /S (/JS)

[1coderookie]

Thanks for clarification :)

[dukess]

I can add program 20006 (instead /B0 or additional to /B0) which will reset durations 20000-20005 to zero. It will work like program 1603.

[1coderookie]

I would suggest to let /B0 be as it is, no need to change that one into 20006. The command is known by the users and already described within the manual, so actually I don't really see any possible adavantages of a new special parameter number 20006 for that one..?

Just that you don't get me wrong: I don't have any problem or so that /B0 still exists - I just had to ask cuz I wasn't sure about the existence of the variants of the /A&/B-commands.. ;)

[dukess]

It was just a suggestion. :) The idea was this: since the durations are now available through programs 20000-20005, it is reasonable to reset them through program (20006).

Let's leave it for the future.

[fredlcore]

I think if we go through a reset via program numbers, then the parameters 20000 to 20005 should be "writeable", so you can set them to zero. That would be more intuitive. But I also don't see a pressing need to do this - especially since we now have decoded the underlying parameter. The way this calculation works was always error-prone and not very accurate: BSB-LAN was just watching out for these broadcast telegrams that come every time there is a status change. If BSB-LAN was doing something else at the same time, the broadcast telegram was missed and the calculation was off very quickly and sometimes by a lot (depending on how often your burner goes on and off).

Now the more accurate way would be to query parameter 10100 through your home automation software every 30 seconds (or less, if that much accuracy is needed) and then do the calculation from there, just the same way people do it with burner starts (parameter 8337) etc.

[dukess]

I think if we go through a reset via program numbers, then the parameters 20000 to 20005 should be "writeable"

It is no problem to do.

Now the more accurate way would be to query parameter 10100 through your home automation software every 30 seconds (or less, if that much accuracy is needed) and then do the calculation from there, just the same way people do it with burner starts (parameter 8337) etc.

Then, perhaps, we will delete the old version of the calculation? Or base calculations on query results to program 10100?

[1coderookie]

@dukess: /A has been removed - is /JA still available?

[dukess]

/JA removed too

[1coderookie]

Ok, thanks!

[hacki11]

Do we have a api versioning strategy? Currently I'm using /JA. How do I detect if i should use another endpoint?

[fredlcore]

Not yet, but I think it's time :). Do you have some kind of template we could use?

In this case, however, there should not be a need to adjust your code because users can just switch to the respective parameter numbers.

[konne]

@dukess can you please also add examples of the JSON API into the docu. So that is an example result of JR=700,... Like this is done for JS

[dukess]

@konne @1coderookie For /JR you need set only one mandatory field: {"parameter": 700}. Sofrware will return { "700": { "error": 0, "value": "3" }}. This value you need set in /JS. recently new field was added: "Destination". This value can be used for temporary destination changing. {{"parameter": 700, "value": 3, "type": 1}, {"parameter": 700, "value": 3, "Destination": 1, "type": 1}, {"parameter": 1600, "value": 1, "type": 1}} First object will send to default address (usually 0), second to address 1, third to default address. "Destination" can be used for /JQ, /JS, /JR commands. For /JC and /JK commands "Destination" can be set but have no sense.

@fredlcore How common are systems with multiple controllers? Does it make sense to add a command that will scan the bus for the presence of several controllers and display their list with addresses?

[konne]

@dukess thanks. can you please take me in the loop if any feature added or changed for the JSON interface. I'm trying to implement the bsbJS JSON interface 100% compatible and so I need the updates.

[fredlcore]

@dukess: That depends, technically almost every system has more than one bus member (heater and display unit). As for actual controller units, I could only guess, a few maybe. There was a proposal by a user once who wanted to have a dropdown-menu to select which would be the device to send commands to in the webinterface. But that would have required to define these units with human readable names, so I did not follow up on that. Not sure if we should now.

[1coderookie]

Parameter 6224 gives a human readable name though, so maybe that could be an option? E.g.: 6224 Konfiguration - Geräte-Identifikation: LMS15.001A100 It is pretty much unlikely that a user will have a system where two absolutely identical controllers are available within that specific setup. Usually one does have a main heating system like a gas fired system plus a solar system controller, an expansion unit or so. These are (in most of the cases) different controllers anyway (see manual for further informations about the different controller types). Two controllers of the same type would pretty much only occur if there's a system where two absolute identical heating systems (= bought at the same time) are connected via LPB due to the need of a cascaded heating system solution. But even in that case one should be able to distiguish these controllers by the busadress.

[fredlcore]

Yes, but if you have two EM bought at the same time, they will likely have the same value. Also, even if they differ a little, you would have to remember what is what. And then it's easier to just remember the bus ID and set it via /P

[hacki11]

• Is /JR in 1.x available or new?
• Is the 'p' in 'parameter' really lower cap?
• Has the error field the same meaning as in /JS?
• Is this a POST request, right?
• Can request one or many values? How do i specifiy multiple values in the request, how does the response look then?
• Is the 'parameter' field in the request really an integer unlike /JS?

[dukess]

/JR appear in 2.0 Case independed Yes Yes but it can be GET like JQ Multiple values allowed. Syntax like /JQ 'parameter' can be string or integer. 'parameter': "1" and 'parameter': 1 is equal.

Jürgen Schmid notifications@github.com 8 января 2021 г. 20:43:59 написал:

Is /JR in 1.x available or new? Is the 'p' in 'parameter' really lower cap? Has the error field the same meaning as in /JS? Is this a POST request, right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[hacki11]

@dukess thanks. can you please take me in the loop if any feature added or changed for the JSON interface. I'm trying to implement the bsbJS JSON interface 100% compatible and so I need the updates.

@konne If you like you can generate a JS client from the openapi spec right now. Not 100% finished but would be great to get feedback here as early as possible.

[konne]

@hacki11 where I can find the openspec file? In need to generate both the server and the client. Because the bsbJS lib that I'm developing at the moment has an 1:1 compatible json API to bsbLAN

[hacki11]

https://app.swaggerhub.com/apis/hacki11/BSB-LAN/2.0 There you can export the spec. Are you familiar with openapi codegen tools? You can generate server, client and servermocks

[konne]

@hacki11 yes I'm familiar with this kind of tool, also with CI/CD to have a fully automated generated npm,.. out of changes of the api.

1. thx for this great work, you have done already nearly all the work for writing the config.
2. I hope that I will find some time this weekend to play with your openapi files and add some small things that will come up in the next release of BSB

[konne]

@dukess Do we have a chance to make all properties in the json api case insensitive to that the openapi definition file can use for all property small letters and not starting capital letters. (for example on /JS with paramater, value & type) It would be also great to use in general names for data types

[dukess]

They are case insensitive. Moreover by fact parser check first letters in parameters names

Konrad Mattheis notifications@github.com 9 января 2021 г. 11:57:35 написал:

@dukess Do we have a chance to make all properties in the json api case insensitive to that the openapi definition file can use for all property small letters and not starting capital letters. (for example on /JS with paramater, value & type) It would be also great to use in general names for data types— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[fredlcore]

Can we consider your question closed, @1coderookie?

[1coderookie]

Yes, I think so.