Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Add device ID to MQTT poll endpoint #681

Open
uschindler opened this issue Dec 5, 2024 · 8 comments
Open

[FEATURE REQUEST] Add device ID to MQTT poll endpoint #681

uschindler opened this issue Dec 5, 2024 · 8 comments

Comments

@uschindler
Copy link
Contributor

While implementing the cool new MQTT /poll endpoint, I had that idea which IMHO would better fit the new topic structure:

Currently the /poll MQTT endpoint is on top level. You can send parameters to update, but if you don't want the default device, you have to use some crazy syntax:
image

I'd propose to use (conforming to the new topic structure) /<devid>/poll instead and simplyfiy the payload to only accept parameter numbers or category/parameter numbers pairs.

This is just a suggestion for further improving the topic structure and get rid of crazy payload syntaxes. No need to implement that ASAP or at all. See it as discussion point.

The only downside of that syntax is that you need "one poll per device" which is IMHO acceptable.

@fredlcore
Copy link
Owner

I'm not sure what the "crazy syntax" is supposed to be. It's either a list of simple numbers in the same way you'd use them when using the web-interface or in the web-configuration, or a list of parameters in topic-notation. For most users (i.e. all users who use the BSB bus), they won't have to worry about the device ID anyway because in BSB, you will always use device ID 0. So in that case, those users would use exactly the same payload, just not send it to the topic BSB-LAN/poll but BSB-LAN/0/poll. I don't see the improvement here...

@uschindler
Copy link
Contributor Author

uschindler commented Dec 5, 2024

The improvement is only to make the topic structure more clear. For all other get/set it requires device ID, but for polling you need to send device id inside the payload. This is inconsistent.

If you want to poll a single parameter, you also need dev id in topic.

So basically this is a suggestion to make it more clear with a consistent topic structure without using special sytax inside the payloads. It's a syntactic improvement because you are already improvig the topic structure, which is very nice now (although I would have used "state" or "get" instead of "status" for the getter. "status" is commonly used in MQTT only for online/offline LASTWILL messages)!

@fredlcore
Copy link
Owner

The most logical syntax would be to use BSB-LAN/0/16/700/poll, exactly mirroring /status, /setetc.
The idea of BSB-LAN/poll was to have a shortcut. To expand this shortcut by adding /poll somewhere else down the hierarchy doesn't really make sense because with the same reason, you could also argue that /status and /set should also be applied directly under the /devID topic in order to have consistency.

@fredlcore
Copy link
Owner

BSB-LAN/poll also makes migrating from the BSB-LAN-internal logging to MQTT logging easier, because you just need to copy whatever you have in the webinterface. For some people who poll 20 parameters, that's easier than splitting that up into polls for two or more devices etc.

@fredlcore
Copy link
Owner

Bottom line, if I were to implement /dev_id/poll, then BSB-LAN/poll would have to go in order to not introduce any confusion due to the different syntax. And the consistency between the web-interface and the notation for the BSB-LAN/poll syntax in my opinion trumps any potentially more logical syntax.

@uschindler
Copy link
Contributor Author

Let's keep this issue open for a while, this is mostly cosmetic, but let's others comment on that.

The most logical syntax would be to use BSB-LAN/0/16/700/poll, exactly mirroring /status, /setetc.

That's already implemented, but has the problem of not being bulky. Of course this perfectly fits the topic structure.

BSB-LAN/poll also makes migrating from the BSB-LAN-internal logging to MQTT logging easier, because you just need to copy whatever you have in the webinterface. For some people who poll 20 parameters, that's easier than splitting that up into polls for two or more devices etc.

Of course. This is what I did before splitting the lists into multiple update frequencies. But for those who copypaste from web interface, it should poll on all devices, if no dev id is given in payload.

Anyways, I am fine. It was just a discussion point. No need to implement anything. It keeps the discussion of your project alive on Github.

@fredlcore
Copy link
Owner

Sure, I appreciate any suggestions!

But for those who copypaste from web interface, it should poll on all devices, if no dev id is given in payload.
This I don't really understand: If you post 700/710/712/8326 to BSB-LAN/poll, you get the results from the default destination ID. Why should it poll on all devices? If you want a different device, you use the ! notation that is consistent across the web-interface, including the log settings. Even if you have different update frequencies, you copy-paste those parameters that you poll every 5 minutes to one automation and then the others to poll every 1 minute or so. No need to learn any new kind of notation if you're not really planning to dive deep into MQTT syntax ;)...

@uschindler
Copy link
Contributor Author

OK, I thought the log settings poll on all devices. Sorry. I don't have multiple devices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants