Rpi-jukebox-rfid: Define basic functionality

[s-martin]

In the course of reorganisation and restructuring the project, I would suggest to define a basic functionality, which is always delivered, preconfigured and always working :-)

My incomplete list of features for basic functionality:

• USB RFID reader
• USB sound cards
• Web interface
• Buttons (I'm unsure, which scope should be basic functionality and what should be optional; But I'm sure with @veloxid's PR #763 we have a big step forward in standardizing buttons)

Optional or "plugin" features:

• "HAT" sound cards
• Spotify
• Displays
• MQTT
• GMusic?

[MiczFlor]

Hi @s-martin,

good start and just at the right time (see below). I guess there are some questions where we need to make a decision before we standardise default installs and features.

Regarding the core functionality, I would actually like to leave the GPIO buttons out. The simple difference being:

a) plug and play USB
b) get your soldering iron out

It does make a big difference to me. Mainly: you need to have a soldering iron, know how to use a soldering iron and buy extra techy parts (resistors, etc) to do the job. Plug and Play USB should be out of the box.

Out of the box

So my out of the box Phoniebox would be:

• USB RFID reader
• Web Interface
• Audio out via mini-Jack

Soundcards

Bringing us to sound cards... from testing the quality, I actually would prefer to suggest either one of these products over a cheap USB-Soundcard:

• Ground Loop Isolator / Entstörfilter Audio
• HDMI splitter with 3,5-mm-Stereo-HDMI Audio-Extractor

Either one of these delivers good sound - actually much better than the USB-Soundards that you plug into the Pi.

Buttons

I agree, I would like to deliver a standard config file based on @veloxid PR. What functionality it should cover, I am not sure. What's the must have?
And I think it should come in a way that it also supports the rotary knob for volume that many people use.
(NOTE: as soon as somebody decides to use a GPIO soundcard, obviously, the water gets muddy :)

Optional plug-in features

I started working on this and called them components. Going through the code and wiki, I came up with this list of components:

• compontents
  
  
  
  • rfid-reader (see: https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/RFID-Reader-Special)
    
    
    
    
    
    • rfid-reader-KKMOON
    
    
    
    • rfid-reader-MFRC522
    
    
    
    • rfid-reader-PCSCD
    
    
    
    • rfid-reader-RC522
    
    
    
    • rfid-reader-RDM6300
    
    
    
    • rfid-reader-RFIO-RC522
    
    
    
    • rfid-reader-serial-RDM6300
    
    
    
  
  
  • soundcards
    
    
    
    
    
    • soundcard-HiFiBerry
    
    
    
    • soundcard-WM8960-Hi-Fi-HAT
    
    
    
    • soundcard-PAM8403
    
    
    
    • soundcard-TPA3118
    
    
    
    • soundcard-DAC-ES9023
    
    
    
  
  
  • gpio-buttons
    
    
    
    
    
    • gpio-buttons-default-arcade
    
    
    
  
  
  • gpio-rotary-dial
    
    
    
    
    
    • rotary-KY-040
    
    
    
  
  
  • displays
    
    
    
    
    
    • dot-matrix-module-MAX7219
    
    
    
  
  
  • services-streaming
    
    
    
    
    
    • Spotify
    
    
    
    • GMusic
    
    
    
  
  
  • audio-protocol
    
    
    
    
    
    • bluetooth
    
    
    
    • AirPlay-Shairport-Sync
    
    
    
  
  
  • smart-home-automation
    
    
    
    
    
    • MQTT-protocol
    
    
    
  
  

[s-martin]

I think the rationale "basic/core functionality is everything without soldering" is very reasonable and keeps the entry barrier low.

My vision for GPIO related plugins/components would be that we provide a couple of presets (maybe combinations of components active people here are already using) and then the pin numbers would be already configured by the installer.

Once again I think PR #763 would make that easier, because the installer would only change the configuration file.

Of course we can't provide any arbitrary combination of components, but usually most new users implement a configuration somebody already has.

Maybe we could think about, if we want to use Python for such a configuration script and use the bash script only for basic installation like packages and then trigger the configuration script. At least I'm more comfortable with Python and I think this could also keep the entry barrier lower. And a Python script could be "unit tested" more easily.

[MiczFlor]

Hi @s-martin
I also think PR #763 would make configuring GPIO themes easier for a preset of GPIO related buttons / rotary knobs. We would need somebody to be able to test it. I have no GPIO (yet). Will try to build a new testbed for Phoniebox in the near future and build a button enhanced version.
What functionality should the buttons cover?

Obvious actions:

• play / pause
• next / previous track
• volume up / down

Possibly actions (with a question mark):

• see ahead / back in current track playing
• stop?
• replay current track?
• replay current playlist?
• loop on / off
• randomise currently playing list?

... what else? How can we nail down a concrete list for the first config file for Phoniebox GPIO? (and what soundcard should that involve, or would it only be built in jack or HDMI audio via splitter?)

[s-martin]

I think the obvious actions should be the default ones, maybe stop could also be added.

From my point of view the other actions are highly use case dependent.

[fredg02]

Optional _plug-in_ features

I started working on this and called them _components_. Going through the code and wiki, I came up with this list of components:

* compontents

  * rfid-reader (see: https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/RFID-Reader-Special)

    * rfid-reader-KKMOON
    * rfid-reader-MFRC522
    * rfid-reader-PCSCD
    * rfid-reader-RC522
    * rfid-reader-RDM6300
    * rfid-reader-RFIO-RC522
    * rfid-reader-serial-RDM6300

Copying my comment from #825:
Mentioning the type of the component in the subsubfolder again seems redundant to me. I'm not even sure that the component name has to be added to a requirements.txt's file name, if there is one.
E.g. For the RFID reader PN532 components/rfid-reader/PN532/requirements.txt seems unique enough to me.
WDYT?

[s-martin]

If the requirements file is located in the sub directory I guess we don't need the name again.