Hi all,
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).
Main features:
Sends information about Mopidy state on any change:
- Playback status
- Volume
- 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.
Hi guys.
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.
3 Likes
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?
Thanks!
Rudy
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.
Mopiqtt is really awesome. It’s snappy and works really well. I also run an instance of Openhab and the OpenHab software wasn’t as quick plus filled up the logs with messages… So I’ve switched my rules over to mqtt and am finding it great!
Thank you for this project!
1 Like
I’m glad you found it useful.
Thanks!
