this is to inform you that I have just released first version of the package Mopiqtt, a Mopidy’s integration to allow managing the music server through MQTT messages (based on mopidy-mqtt-NG, recently unmaintained).
Sends information about Mopidy state on any change:
- Playback status
- Track description
- Playlists list
Reacts to control commands:
- Playback control
- Tracklist control
- Volume control
- Load & play a playlist
- Request playlists list
This package is mainly useful to Node Red users, who can embed in their flows a full control over Mopidy by simple mqtt-in or mqtt-out nodes. Of course, it can be used by any other MQTT client too.
The full commands set is shown Github’s project webpage.
Few example nodes in Node-Red (self explaining):
List, select and play a playlist:
A Dashboard example:
Hey @fmarzocca glad you got your mqtt setup working and have improved upon it.
It would be nice and polite to notify @odiroot of your improvements in the form of a pull request and an issue on the original project GitHub - odiroot/mopidy-mqtt: Control and observe Mopidy state via MQTT protocol or at least should that your project is a fork of project and not credit Mopiqtt/setup.py at main · fmarzocca/Mopiqtt · GitHub your self for the work of others.
As seen on odiroot’s repo, we can trace up the commits to GitHub - magcode/mopidy-mqtt: MQTT features for Mopidy which is thus credited for his contribution. Your project should adopt the same standards whilst waiting for your code to be integrated to upstream…
I have already wrote to odiroot and if you read the Readme of my repository, the first line credits him, exactly the same way he did for magcode. I don’t see any issue, I am working with Open Source for 30 years, so I am very well aware of this. Thanks for your timely note.
I just noticed this thread. Thank you @arthurlutz for representing me.
Although I don’t feel slighted in any way
My work was just a quick hack to work with my ESP32-based remote controller.
I have since moved houses (twice!) and my needs changed so I didn’t have the motivation to push any work to my repo. Also considering the state of mopidy-spotify, I had to switch to spotifyd anyway.
I will make a deprecation note. @fmarzocca has my full blessing.
I haven’t installed yet, but I’m curious for feedback on this use case:
I’m making an NFC mopidy controller for the toddler (as it seems like many a geek does).
I want it to be portable (I’m installing inside a Fisher Price record player). And battery operated.
Right now I’m thinking of an ESP32 with a PN532. Both have very lower power modes… I think I’ll be able to get the standby, but with RF active, down to about 50uA.
But when it comes up, I need to connect fast before that toddler (or adult) gets distracted.
My question here is mostly, Is MQTT a good frontend for controlling Mopidy? Is it fast?
Do you think this is a good use case for Mopiqtt or does something else come to mind?
Mopidy can be controlled from MQTT for sure. That’s the job of this package…
Concerning your use case, I am not sure I understood it but, as long as you have a MQTT broker available, you can use it.