Turn on/off an external apparatus from Volumio

Volumio Development Development talks
#1

I know there is another thread, but this has a clear name and it is in the correct place.

Now, I will get soon what I need to build a switch that allows me to turn on/off my speakers from Volumio. I need it because my system uses about 50W even without music playing and I don’t want it on all the time.
That circuit will have a bypass switch, so that I can still force it on,if needed, and a switch to send an OFF signal to Volumio, if I want to do switch it off without the GUI.

The question is how to modify/improve Volumio to get a simple way to apply this.
Is there a sort of trigger that can be executed when playing starts, and another one for when the play stops? this way I may have a daemon running that gets notified and, after a delay since the last stop-trigger, turns off the speakers. This daemon would also monitor the input GPIO pin associated with the external pushbutton, so that if it is pressed, power gets cut immediately.

I can write scripts, but not much more. If there is a change to be applied to the WebGUI or to mpd, I will need very accurate directions, at least to know where that should be implemented.

As second option, I could have the daemon offer a separate webpage, where I can turn it on and off manually, but I think that a (optional) switch button in the webGUI (on/off/auto_delay) would be much better.

#2

Just an idea. Make your daemon query the status of mpd to know if it is in play, pause or stop mode. From command line:

pi@volumio:~$ telnet volumio.local 6600 Trying 192.168.1.22... Connected to volumio.local. Escape character is '^]'. OK MPD 0.16.0 

status
volume: 58
repeat: 1
random: 1
single: 0
consume: 0
playlist: 1838
playlistlength: 143
xfade: 0
mixrampdb: 0.000000
mixrampdelay: nan
state: play
song: 62
songid: 1517
time: 12:209
elapsed: 12.144
bitrate: 1033
audio: 44100:16:2
nextsong: 26
nextsongid: 1481
OK

This way there’s not need to modify the web UI and the system works as expected if you control Volumio/mpd from a phone or tablet.

#3

The daemon should poll continuously mpd, otherwise it would keep the speakers off until the first poll. Polling once per second (and keeping the speakers on for some minutes) would be probably acceptable, but working interrupt-based instead of continuous polling would be better.

Still, I didn’t know about polling mpd, so your suggestion will work as temporary solution! After I get the components.

#4

Take a look at the idle [SUBSYSTEM] mpd command. It waits until there’s some change at the server side so you don’t have to poll:

pi@volumio:~$ telnet volumio.local 6600 Trying 192.168.1.22... Connected to volumio.local. Escape character is '^]'. OK MPD 0.16.0 idle player ... nothing here ... ... now I press play changed: player OK
Now you could query the server to know its state (play/pause/stop). The subsystems are listed in the mpd commands reference page: pythonhosted.org//python-mpd2/index.html

Hope this help!

#5

Oops, found this browsing for other things:

erion.elmasllari.com/automated-s … i-and-mpd/

#6

Well, I haven’t started yet, but you provided me with all the info. Expect a script soon after I get the hardware running!

#7

I’m lurking this with extreme interest!

@lagna, are you a class-A guy? Somehow I feel so… So, which amp?

#8

behringer.com/EN/Products/B2031A.aspx because I want the sound as it was recorded, I don’t want a sound colored by the fancy speakers.
And obviously integrated bi-amp in the speakers, tuned specifically for those speakers, not a generic amp that tries to work well with any speaker, and speakers that try to be acceptable with any amp.
And also, 200W per speaker because I don’t want clipping.
And a sub to unload the cones of the main speakers from the high-excursion and distortion-inducing low frequencies.

It sounds better than many audiofile systems, just don’t tell them that an active system is better than theirs: they need to spend to feel fine :slight_smile: (just like the people worrying about the R-Pi power supply…).
Downside: 50 W at the wall, switched on without sound playing.

Of course you can buy better gear according to the same principle (monitor active speakers), I chose a cheap solution (550 euro total, 2nd hand sub included). I spoke with some very expert (=engineers, not audiophiles) guys (among them the author of DRC-FIR) that pointed me to a proven-quality Behringer product, not every Behringer is. For example, the B3031 is not ok.

But I also have a T-Amp (the original one) for another pair of speakers I don’t care about. But 12+12 W is a joke.

#9

I did better, I added a timeout to avoid turning on and off all the time.

[code]#!/usr/bin/expect –

set timeoff 600
set server localhost
set port 6600
#set onplay [lindex $argv 2]
set onplay /home/pi/gpio/poweron.sh
#set noplay [lindex $argv 3]
set noplay /home/pi/gpio/poweroff.sh
#set onstop [lindex $argv 3]

set timeout -1
log_user 0

trap {send “close\r”
exit} {SIGINT SIGTERM}

send_user “Starting connection to MPD [lrange $argv 0 1]\r\n”
send_user “On play: $onplay\r\n”
send_user “On no play: $noplay\r\n”
#send_user “On stop: $onstop\r\n”

#spawn -noecho telnet [lindex $argv 0] [lindex $argv 1]
spawn -noecho telnet $server $port

expect {
“OK MPD” {
send_user “Connected\r\n”
}
}

send “status\r”
expect {
“state: play” {
set currentState “play”
}
“state: pause” {
set currentState “noplay”
}
“state: stop” {
set currentState “noplay”
}
}
send_user “Initial state $currentState\r\n”
send “idle player\r”

for {} 1 {} {
expect {
timeout {
if { “$noplay” != “” } {
exec “$noplay”
}
send_user “Timeout, off speakers\r\n”
set timeout -1
}
“changed: player” {
send_user “Changed status player\r\n”
send “status\r”
}
“state: play” {
send_user “Status: play\r\n”
if { “$currentState” != “play” } {
send_user “State changed to play\r\n”
if { “$onplay” != “” } {
exec $onplay
}
set timeout -1
set currentState “play”
}
send “idle player\r”
}
“state: pause” {
send_user “Status: pause\r\n”
if { “$currentState” != “noplay” } {
send_user “State changed to pause\r\n”
set timeout $timeoff
set currentState “stop”
}
send “idle player\r”
}
“state: stop” {
send_user “Status: stop\r\n”
if { “$currentState” != “noplay” } {
send_user “State changed to stop\r\n”
set timeout $timeoff
set currentState “stop”
}
send “idle player\r”
}
}
}
[/code]

Now the question is: how to keep into account shairport?
Can anyone suggest me a very simple webserver that I can install just to provide a page where I can power on and off the speakers? I saw something python based but I cannot find it anymore.
It should just provide two buttons to execute the scripts.

#10

I have 4 scripts: poweron, poweroff, initialize_GPIO, handle_speakers.
The last two should run at boot.

Where should I put them? /etc/init.d? or somewhere else? I am not used to linux and I read different suggestions online.

#11

Hello everyone,
in the meanwhile I tried some ways to start the scripts at boot, but I was unsuccessful.
For example, I saved a bash script in /etc/init.d/init_speakers.sh and I gave it chmod +x and chown root:root, but it didn’t work.
I put the two commandlines in /etc/rc.local but at boot I found that file overwritten and back to the standard content!

Could you please help me?

#12

To start a script at boot, you need to format it in init.d format,

see here

http://www.novell.com/coolsolutions/feature/15380.html

Then

update-rc.d nameofyourscript defaults
Or, if you want to edit the rc local, make sure you copy it to

/var/www/_OS_SETTINGS/etc/rc.local

So it doesn’t get overwritten.

Let me know

#13

Oh thanks, I forgot about the overwriting you set up. I will modify the correct rc.local, I need just two lines for the command to be executed and it never needs to be stopped.

BTW as soon as you publish a new version with updated mpd and better filesystem, after waiting some days to be sure it has no issues (except SMB that I see it’s not going to be corrected :slight_smile:, I will reflash my card and then, from that image, I will give you all the changes I applied, so that you can integrate them. I am waiting because the new releases seem to have few improvements and I read about issues.

#14

Good! Yeah the SMB is not being corrected, do you have any idea of that? Also looking at the php code… I’m not touching it because I’m thinking of radically changing it… From the ground up…

#15

I am happy with using autofs for SMB, it’s easy enough.

#16

My opinion is that it does more or less all that is needed, if you add like two buttons for custom commands and you add the option to select which device actually is used (and which mixer is controlled by the volume control: in mine case it was the bass boost!), it would be fine enough.
Since you are basically the only one working on the project, it would be better to focus on other issues like SMB (I think really a LOT of people experience issues) and on kernel/distro related stuff (such as an easy update system, …).
Concerning click/pops on 96/24 outputs, I would just add a checkbox on the prefs to downsample to 48/24, it will solve the problem at basically no cost (24 bits are proven as important, but no one has been able to do the same with 88/96 kHz, they are basically marketing).

#17

Lag-na,

Where did you end up with your script efforts? Are the scripts available somewhere in their final form?

Thanks!

~ D

#18

volumio-customisation-script-nas-share-included-t1382.html

#19

Thank you! Looks very useful.

~ D