search

fredlcore / BSB-LAN

LAN/WiFi interface for Boiler-System-Bus (BSB) and Local Process Bus (LPB) and Punkt-zu-Punkt Schnittstelle (PPS) with a Siemens® controller used by Elco®, Brötje® and similar heating systems
231 stars 84 forks source link

[FEATURE REQUEST] New command /QS #412

Closed 1coderookie closed 3 years ago

1coderookie commented 3 years ago

@fredlcore & @dukess Hey guys, I was just thinking about something else: Could you add a new command /QS (= Q short) which does pretty much the same like the old /Q (before we added the whole parameter search at the end) but only displays the following lines for the query of the bus participants:

Teste Geräteadresse 0...
Gerätefamilie: 96
Gerätevariante: 100
Geräte-Identifikation: RVS43.222/100

Teste Geräteadresse 1...
Gerätefamilie: 107
Gerätevariante: 100
Geräte-Identifikation: RVS46.530/100

and so on. So it should only query and list the a) devices available at the bus and b) show the address, the device family, the device variant and the device identification of each device at the bus.

The reason for that is the following: when a user comes up with a problem/question, we can now ask him to send us the output of /CO. That's great already. But it would be even more helpful, if we als could ask him to send the output of /QS, so that we can see which devices are available at the bus. If we ask for /Q in this case, then a) the output is pretty long and we don't really always need the additional informations and b) the query of /Q itself takes long for the user due to the new parameter search/query.

First I though to probably add this query to the /CO command, but maybe it's even better to have this feature as an independent one.

What do you guys think of that? I think it would/could be a nice and helpful feature when it comes down to quick support..

fredlcore commented 3 years ago

Hm, I see the advantage to a certain extent, but I would vote against this for two reasons: The first one is - as often - flash memory. For a function that would only spare specific users a little bit of time (we're talking about a few minutes max), I would not want to sacrifice our still limited space. And since the users want our help, I don't think they will not be willing to do what we ask for. The second reason is that we actually need updated "full" outputs once in a while because if we get a /Q from user A and then another one from user B from whom we get new parameters, then some of these might also work on user A's heater - which we will only find out if we get a new /Q from user A (provided that he has also updated BSB-LAN, but that's a requirement we always state when problems occur. Users generally do not get back to us once their system is up and running. In cases such as this, we would have the chance, and I would like to make use of it ;)...

1coderookie commented 3 years ago

I agree with the memory concerns of course (and sure, I don't know how memory consuming this would be), but actually not with the second reason, because /QS shouldn't replace /Q in any way, it's just supposed as a short device(s) check when it comes down to support in the forum. But you're right, people could wait these few 'additional' minutes of /Q when they're asking for help.. ;)

fredlcore commented 3 years ago

I know that you mean it as a short device check (which I think is useful) and not as a replacement for /Q - the question is when if not in such a situation people would be sending us updated /Q outputs. At least I hardly ever hear from people again - unless they have a problem. And if we then ask them for the shortened /Q we're giving away an opportunity to get an updated /Q...

1coderookie commented 3 years ago

Aaaahh ok, now I got what you meant ;) Yes, you're absolutely right, didn't think about that - so I'll close this..