Parameters vs Codes - Githubissues

Greetings. I ahve received and successfully connected a BSB Lan adapter to an LPB bus, thanks for that. I was able to read couple of Parameters and learned that there is a mapping between standardized Parameters and device specific codes. I have a technical list of codes with descriptions matching my device and was wondering if there is a raw level access possibility to retrieve raw data based on codes.

Actual requests:

1) If not available i would like to request this as a feature for both, the general purpose access capability as well as supporting identification and interpretation of new parameters.

2) Generally i was wondering if the mapping internal to the BSB lan "device" (ie the total combination of Arduino, Network Interface and BSB LAN module) is the right engineering decision, both from a support and technical view. Technically having this mapping inside the device eats up resources which apparently has been a topic at some point during development. Secondly moving this intelligence into an external library allows for esier / faster development for reasons in request 1 and simpler updates / additions as no raw code needs to be edited, compiled and flashed.

While 2 is more of a personal preference, request 1 i think would generally be important as when ther e is documentation available but no support in BSB LAN internal mapping, then the device logic appears like an unneccesary block in the road.

In any case thanks for the work that has been invested in this project.

Hi, I'm not sure if I follow your terminology. I assume that "standardized parameters" means what we call "parameter numbers" (e.g. 8700 for outside temperature). These are not standardized because several parameters with the same functionality have different parameter numbers on different systems (the error category is the "worst" example for that). With "device specific codes" you seem to refer to what we call "command IDs" which are part of every data telegram to tell the heating system what function is to be accessed. Then you say you have a "technical list of codes with descriptions" matching your device. Could you post that one here so it's easier to say what kind of "codes" you are referring to? Because right now I have no idea what you mean with "raw level access possibility to retrieve raw data based on codes" - raw level access to the heating system? To BSB-LAN?

Therefore I don't fully understand your requests. As for 2, I assume you suggest to move the contents which are now in BSB_lan_defs.h to somewhere else but you don't say where. SD-Card? Not feasible because - apart from introducing an element that is prone to wear and tear - all definitions (even if reduced to just the device specific parameters) would have to be loaded into RAM. This might work on a Raspberry Pi, but not on an embedded system, even the Due which has a lot more RAM than the Mega. And you still would have to go to the site and replace the SD card. Storing the parameter definitions in flash memory as we do now, led us to move from the Mega to the Due for memory reasons, but now we have approx. 200kb free flash memory - sounds little, but the complete code just eats up only appox. 50% of flash memory available. So we now have lots of space available, in terms of new parameters (where each parameter line consumes 17 bytes) that would be space for more than 10,000 parameters. So for now and the forseeable future, space is not an issue.

Furthermore, I don't follow your argument that an external library (however this may be implemented) would be easier to maintain. For developers, it's all in one external file (BSB_lan_defs.h) which is flashed in one go and which can be done remotely if you connect BSB-LAN via USB to a NAS or local server where you have shell access to. I can sit on the train and flash a new firmware including new parameters with just calling one script. That would not be possible (at least not without major additions to the code) if the code would be separated and partly stored on SD card.

Maintaining BSB_lan_defs.h as part of the code also is necessary to maintain downward compatibility for the many users who are still using the Arduino Mega. Even if the main code is no longer maintained for this platform, they can still get the current BSB_lan_defs.h and have the up-to-date parameter list available.

But again, I may have gotten your idea wrong because I probably haven't understood what this "list of codes" refers to and what kind of raw level access you are talking about. Once this is clear to me, we can think about proposal 1.

Just in case... same person different account. Happend to use the wrong account above...

About "standardized" vs "raw"... within BSB Lan a (standardized) set of IDs has been choosen to universally represent real world information in a common way independent of device specific (raw) IDs under which that information is stored within that given device.

Both suggestions are related to a situation where one would consider BSB LAN to operater closer to what a Modem is/was. Both do not intend to rule out higher level capabilities such as above mapping or 24h value averaging, but they both do not consider these used. It would be a mode of eperation or specific /additional) URL requests where BSB lan acts as a bridge or agteway for low level messages. WIth those, BSB Lan may optionally provide Bus or connection specific encapsulation for actual data (in case such does exits. haven't read the docs on LPB or BSB) such as wapping actual request IDs and data with headers or checksums.

Example: BSB lan is configured for a bus type (eg LPB).

If applicable for the protocol, half raw mode: A request is made to BSB where the request URL specifies target address (segment/device) and data ID. BSBlan creaters protocol specific wrappers, sends out the request, unwraps the repsonse and replies with device specific, untranslated raw result.

Full raw request would send bytes provided with the request URL 1:1 onto the bus. A response request would fetch a numer of N raw bytes from BSBlan response buffer or wait for them to arrive, where N=0 replies with all raw bytes currently in response buffer. That is, plain modem function.

Specific for request 2, the suggestion considers BSBlan for a case where BSBlan does not operate standalone, but where there is another application using BSBlan as a remote gateway/modem as in request 1. With such a setup the interpretation of data as currently maintained in BSBlan source code (BSB_lan_defs.h?) may be maintained in the library executed by the higher level application interfacing BSBlan remotely. This includes the possibility to load device specific configurations at runtime as part of the configuration of said application. For example this would be a BSBlan interface library imported by python code.

just for addition, operation of that using MQTT may actualy be the preferable way. SUch that sending request or bytes to an MQTT topic would have them sent to the device BSB an responses are sent back to another topic.

Ok, I seem to halfway get what you want, but what good would that do? If BSB-LAN would still do the calculation of the destination, read/write type, checksum, telegram length etc., what kind of raw data would you like to send? And for the person who would write the corresponding "high level" application, they would have to keep track of all the additions and sometimes changes in the decoding of the dozens of data payload types.

On the contrary, sending unusable data payloads might have unexpected effects on the heatings system. Who would make sure that the "higher level" application is sending sensible data? In the end, if something goes wrong and your heating system breaks, people will probably (also) blame BSB-LAN. This is not what I would want.

But maybe I still don't get what you want in the end. Maybe you could come up with a very concrete example what you want to do in real life and what benefit this would have in contrast to already existing functions of BSB-LAN such as MQTT/JSON control which makes BSB-LAN easily accessible to a number of sophisticated home automation systems.

By the way: URL-Command "/Y" allows you to query a command ID with a given query type and returns the raw data, such as /Y06,053D0521 would query the outside temperature for most (but not all) device types. You must have the DEBUG definement enabled for that purpose.

snippets:

... but what good would that do?

Allow external applications access where such has not yet been implemented. Allow for a much easier and accessible process than described in chapter 10 of the BSB user manual https://1coderookie.github.io/BSB-LPB-LAN/kap10.html

already existing functions of BSB-LAN such as MQTT/JSON control which makes BSB-LAN easily accessible to a number of sophisticated home automation systems.

but impossible to access data not already documented and implemented.

And for the person who would write the corresponding "high level" application, they would have to keep track of all the additions and sometimes changes in the decoding of the dozens of data payload types.

Flexibility. It is IMO easier done and maintained outside of Arduino code and more accessible to a wider audience. I dare to predict it would be easier for BSB lan project itself. I think it might be possible to have a common description format where either, the BSB lan config as well as an external version for different purposes could be generated from.

On the contrary, sending unusable data payloads might have unexpected effects on the heatings system. Who would make sure that the "higher level" application is sending sensible data? In the end, if something goes wrong and your heating system breaks, people will probably (also) blame BSB-LAN. This is not what I would want.

I understand what you say, however it is commonly accepted. If such repsonsibility where the case, no open source code would exist, GPL would not exclude liability and the BSB project itself would not have a disclaimer. Not allowing the access seems like an unnecsessary block in the way and in a sense contradicts the idea of open.

If BSB-LAN would still do the calculation of the destination, read/write type, checksum, telegram length etc.

That would be a comfort that BSB lan currently provides.One may or may not choose to provide that for raw access. IMO owuld be nice to have he choice.

what kind of raw data would you like to send?

Any. Certainly simple read requests for any data point available would be an initial target. Eg right now i know there is this temperature measurement somewhere in that device of mine, but i just cant get at it because BSBlan doesnt know about it yet and it doesnt let me try to find it easily, whereas it really could.

I'll go and read up on the /Y request

Sorry, this is still not concrete enough for me. Don't get me wrong, I'm all in favor of making the protocol and access to it as open as possible, but there is no existing application or a programmer who would be willing to provide all the work necessary on the other side (i.e. the "high level" application). So at least I'm not going to put any time and energy into this until that is the case. You are of course free to add to this if you want to, but maybe you should get more aquainted with the project in the first place, because your example with the temperature measurement is exactly what /Y is for and it is used in the brute force scripts that are provided with BSB-LAN. All the parameters from 10200++ were identified that way, but it's not that easy to figure out what is what.

By the way: If you really want low level direct access, you can do this without BSB-LAN's software and just use the adapter: Since it hooks on Serial1, all you need to do is to open the serial port with 4800bps, 8E1 and send and read. The checksum algorythm is crc32 and the structure of the data telegrams is explained in the manual. So that way you don't even need BSB-LAN's software and can just write a little script that does what you want, shouldn't be more than a couple of dozen lines of code.

I'm closing this for now, if you would like to continue the discussion, please e-mail me. I don't like to have these kind of discussions where only one part knows who the other one is.

fredlcore / BSB-LAN

Parameters vs Codes #165