12. Mai 2019 at 22:39 #45379
The functionality this plugin offers is definitely needed. I implemented a version myself but took a completely different direction.
-Used a digispark, a rotaty encoder, the arduino HID trinket library, and modified the script to generate a „Volume Up“, „Volume Down“, „Play/Stop Toggle“ signal through USB.
-Also bought a unit that basically already does that (but it was more fun to build my own)
-I run a background python process using the evdev library to capture events from my USB device and to send commands to the server through the REST API controlling the intended player’s volume.
-It’s working well and I can just plug the knob in a USB port which is less of a hassle than dealing with GPIO. Last thing I need to figure out is how to have the plug in install process launch my python script as a background process on boot.
Can you help with that last part so I can make the plugin available for those who want it?13. Mai 2019 at 19:05 #45384
If you’re not a hacker type, you can just get the following hardware:
If you are the hacker type, you can use the following:
-ATTiny dev board: https://www.ebay.com/p/Digispark-Kickstarter-Attiny85-Arduino-General-Micro-USB-Development-Board/1873410506?iid=113322552360
-EC11 5 pin rotary switch encoder
-Use the following Arduino script: rotaryKnobHID.ino in this github repo: https://github.com/thomashollier/max2play_knob
The github repo has the python scripts as well but it is all in progress so use at your own risk.
16. Mai 2019 at 6:29 #45412
- This reply was modified 8 months, 2 weeks ago by superVenicianFrog.
Great! Looking forward to seeing it. In the meantime, I hacked together a way to create, install, and start a systemd service during the plug in install. The service simply launches the python script. The next issue to solve is finding an elegant way to change the IP and MAC addresses, as well as the HID device name that the python script uses once the process is already running. I am thinking of a tmp file that the python script keeps an eye on but it seems a bit too hacky for my taste.
Again, if you are interested, I put the plugin in its current state on github:
https://github.com/thomashollier/max2play_knob -> Usbvolumeknob.tar16. Mai 2019 at 15:43 #45447
That’s what we added to the Plugin Builder! 😀
A startscript that let’s you quickly add a script to be executed in systemd.
You can get the additional script by making a Beta Update with the Plugin Builder installed.
Unfortunately, I’m out of the office for next week and a half but I’ll check out the plugin in detail when I’m back.25. Mai 2019 at 17:34 #45488
Maybe it has been asked before, but is it possible to make the microSDcard ‚read-only‘, so that the card does not get corrupted when the power is accidentally removed.
For the rest I am very satisfied with the Max2Play solution. I am using a Raspberry 2B with a HiFiBerry hat, together with a Squeezebox Touch and 2 Squeezebox Radios, all remotely controlled with the Android app Squeeze Ctrl from angryGoat.9. Juli 2019 at 23:10 #46241
re this volume topic, is there a way how to pass the squeezebox volume commands to a hifi receiver or stereo amp? My setup contains HiFiBerry Digi+ connected via tosslink to Stereo amplifier (Yamaha). I am able to control the volume of the stereo amp using network commands, so the ideal scenario would be to leave the Digi+ output to full (fixed) volume, and pass the volume control to the Yamaha amplifier.
That would mean a command stored somewhere in a config which would act as Volume+ and Volume- to trigger the volume changes whenever a user adjusts volume from iPeng or other Squeezebox app.
Or alternatively, to be able to trigger the volume changes using LIRC functionality, and again bypass the SW volume adjustments.
Thank you.12. Juli 2019 at 17:13 #46301
I am not quite sure I follow your recommendation. Well, I understand your suggestion and I read other posts in this forum related to the HW volume controls (https://www.max2play.com/en/forums/topic/volume-settings/).
I have been playing with the command line options, and your suggested
-o hw:1 -V Digitalworks the way that it disables the ability co control volume over the app (is kept constantly at 100%). But listen, the HiFiBerry Digi+ has no DAC nor AMP that could be controlled.
HiFiBerry:~ $ amixer -c1 Simple mixer control 'Tx Source',0 Capabilities: enum Items: 'S/PDIF RX' 'AIF' Item0: 'AIF' HiFiBerry:~ $ amixer -c1 scontrols Simple mixer control 'Tx Source',0 HiFiBerry:~ $
My question was if there is a way how to use the app to control the volume (for instance iPeng), but have every volume changes forwarded to an external AMP device over HTTP request, or LIRC.
The outcome would be that whenever someone tries to change the volume in the app, the actual volume adjustments would happen on the external amplifier. Max2Play would need to forward any requests for volume changes to either http commands (which would need to be set somewhere for each AMP manufactures, for instance DENON
http://your_receiver_address/MainZone/index.put.asp?cmd0=PutMasterVolumeSet/-45.0), or to LIRC output (again using config for the given AMP user has attached).16. Juli 2019 at 15:00 #46332
Okay, so you can get all the detailed documentation on the commands for Squeezebox control from our API-Examples. You can use the CLI for more detailed commands. Then, you would have to find a solution to connect these outputs to your specific hardware with commands as you mention. Then, you would need a solution to disable any actual volume change on the end of the software you actually use. Correct?
I’m not sure this is feasible but I will discuss it with our head developer in our next session.17. Juli 2019 at 11:56 #46344
I spoke with our head developer and this setup is not really feasible on the Squeezebox side as you would have to work around all software commands regarding volume control.
The most convenient solution would probably be a home automation app’s custom player volume control using your hardware’s API. We have a one-click installer of OpenHAB2 which probably fits the bill for this kind of setup.17. Juli 2019 at 21:30 #46352
many thanks for checking with the devs and letting me know. I kind of expected such result, as it would require some additional development (for instance command line option to allow handling volume controls externally – forward these as external commands using specific config). Maybe as a feature request for the future 🙂
And yes, I am able to control the volume using home automation. But still, I miss the user comfort of apps like iPeng.
Thank you.28. Juli 2019 at 14:26 #46508
Ich habe das Plugin jetzt auch bei mir eingefügt. Jetzt habe ich es auch hinbekommen dass es Befehle empfängt.
Zu meiner Konfiguration:
Ich habe eine Original Logitech Squeezebox Touch Fernbedienung mit einem Infrarot Empfänger auf GPIO 25. Die LIRC Datei habe ich von der LIRC-Datenbank herunter geladen.
Das Problem ist jetzt: Die Befehle werden manchmal X-Mal ausgeführt. Somit springt der Balken im Jivlite mehrere Zeilen nach unten. Manchmal scheint eine Unendliche Schleife zu wirken und das Display blinkt dann.
Ich habe versucht die Befehle der Fernbedienung mit „irrecord“ aufzuzeichnen. Nur steht in der Ausgabedatei nicht viel sinnvolles.
begin remote name test bits 0 flags CONST_LENGTH eps 0 aeps 0 one 0 0 zero 0 0 gap 50000 toggle_bit_mask 0x0 frequency 38000 begin codes KEY_0 0x0 end codes end remote
Kannst Du mir in dieser Hinsicht behilflich sein?29. Juli 2019 at 18:22 #46524
Ich habe es gemaess diesem Tutorial und auch mit einem anderen ausgeführt. Das Ergebnis ist das selbe.
Wie ich oben bereits geschrieben habe wird nichts schlaues in die Datei geschrieben.
Die Tasten der Fernbedienung kommen im Raspi an. (Schade dass ich das Bild nicht einstellen kann)
# Please take the time to finish this file as described in # https://sourceforge.net/p/lirc-remotes/wiki/Checklist/ # and make it available to others by sending it to # <[email protected]> # # This config file was automatically generated # using lirc-0.9.4c(default) on Mon Jul 29 18:08:32 2019 # Command line used: -d /dev/lirc0 /home/pi/lircd-fernbedienung.conf # Kernel version (uname -r): 4.19.30-v7+ # # Remote name (as of config file): fernbedienung # Brand of remote device, the thing you hold in your hand: # Remote device model nr: # Remote device info url: # Does remote device has a bundled capture device e. g., a # usb dongle? : # For bundled USB devices: usb vendor id, product id # and device string (use dmesg or lsusb): # Type of device controlled # (TV, VCR, Audio, DVD, Satellite, Cable, HTPC, ...) : # Device(s) controlled by this remote: begin remote name fernbedienung bits 0 flags CONST_LENGTH eps 0 aeps 0 one 0 0 zero 0 0 gap 50000 toggle_bit_mask 0x0 frequency 38000 begin codes KEY_0 0x0 end codes end remote
Der „irrecord“ teilt mir am Schluss mit, dass die Datei erstellt wurde.
Hast Du noch eine weitere Idee?6. Oktober 2019 at 15:51 #47236
The infrared part works well. I had to define my own remote, which also worked fine. What would be good is to have a way of submitting our remote controller definitions to you, so they can be added into a library and therefore build up a list of working remotes.
Best Regards, Anthony6. Oktober 2019 at 16:00 #47237
As regards buttons. It would be great if you could enter a table of PIN numbers (whether pull up or down) and associated commands.
I have created my own program (happy to send it to you if you want) which sets up the following associations, but it would be better if your plug in did this:
# Pin definitions
VOL_UP = 21
VOL_DOWN = 22
NEXT = 24
PREVIOUS = 20
PLAY_PAUSE = 16
ONE = 17
TWO = 27
THREE = 9
FOUR = 11
SHUTDOWN = 10
command = ‚mixer&p1=volume&p2=%2B‘ + VOL_INCR
command = ‚mixer&p1=volume&p2=-‚ + VOL_INCR
command = ‚playlist&p1=jump&p2=%2B1‘
command = ‚playlist&p1=jump&p2=-1‘
command = ‚pause‘
command = ‚playlist&p1=play&p2=__playlists/One‘
command = ‚playlist&p1=play&p2=__playlists/Two‘
command = ‚playlist&p1=play&p2=__playlists/Three‘
command = ‚playlist&p1=play&p2=__playlists/Four‘
call(„sudo shutdown –poweroff now“, shell=True)
You must be logged in to reply to this topic.