Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add new MQTT Playlist topics #505
Add the following new topic handlers in Playlist::MQTTHandler()
The following should eventually be deprecated:
While working on this, it occured to me that we don't have a clean divide between our "status" commands and our "set" ones. (It noticed when watching the debug logs and every "playlist" message published by FPP was also being consumed by Playlist::MQTTHandler since fpp subscribes to itself. )
We could leave it and just waste the bandwith, but the "correct" solution would be to have have a "status" and "set" level after the FALCON_TOPIC level. This would be a change to every topic. Instead of totally breaking backwards comparability, I'm proposing we keep the publish tags where they are, but change all the "set" tags to have a "set" level. Thus we would have
We would then only subscribe to the /set level, avoiding unnecessary network traffic (and cpu for checking) on the bounce back. This proposal would mean moving /event and /set to under the the /set branch as well to be clean.
I'm on the fence, but would lean in this direction of having a 'set' level rather than having to have 'set' on the end of each topic. We can always respond to both for a short period of time and then in a future version (3.x later this year) drop support for any sets not under /set
I think that for simple devices handling one single piece of a tree, having set at the end makes more sense, but for our structure with fpp having lots of branches, having a set level makes more sense.
added a commit
Mar 16, 2019
I think the patch looks good. Are you going to modify Playlist::MQTTHandler() to handle the ALLPLAYLISTS or playlist name part of the topic? If not, we should probably leave all that out of the doc file for now until it is supported. I think we can go ahead and add support in the topic even if we don't have support in the player yet. That way topics won't have to change later when more users have tied into the MQTT support. I may be playing with some of this soon because I want to tie my FPP-based picture frame into my Home Assistant install so HA can either pause the playlist or turn off the monitor when I am not home.
Thanks for the review. @cpinkham
Based on my testing, MQTTHandler() will respond to ALLPLAYLISTS/... and $PLAYLIST/.... the same way. (See lines 1755 though 1781 in patch for ALLPLAYLISTS support. The playlist specific versions are right after so that we can provide different behavior in the future.
I would recommend also including PR #507 otherwise the /next /prev MQTT calls don't work as expected.