[ANNOUNCE] SqueezeButtonPi - Tool to use buttons and rotary encoders on a RPi

[kingswindsor]

Just to report that I have installed Squezebuttonpi and wiringpi etc successfully but not getting any response from twiddling the rotary encoder. Setting up verbose reporting I get the 'discovery' messages too. The encoder in on GPIO 23 and 24 and I have used those numbers in the sbpd command. Same hardware config that works with Moode.

Sent from my SM-N9005 using Tapatalk

[pippin]

Just to be sure: this means that the encoder is connected to pins (physical pins) 16 and 18 and ground (the center pin)?
Or are you pulling down against 3.3V?

[pippin]

Agreed. Then we can move sbpd.tcz into the repo with the next update.

I'll play around with some more configurations over the weekend, maybe I'll add another option to use encoders and buttons pulling down from 3.3V

[paul-]

I tried both the PLAY and POWR command. But I'm getting tired, I may have done something else stupid. Let me take a fresh look at everything tomorrow.

Found my problem, I sent you a pull request. If you mac address has a leading 0 in a segment, it was not auto setting the mac properly. If your mac looks like this, b8:27:eb:0a:dd:0d it is being sent to the LMS server as b8:27:eb:a:dd:d

Until things get merged and recompiled You can hard set your mac on the command line with --mac=b8:27:eb:0a:dd:0d

Note: do not use capital letters in your mac address, LMS does not like that.

[pippin]

Found the problem, I sent you a pull request.

Ah, LMS needs leading zeroes, I remember.
How does this work in SqueezeLite? Does it correct the MAC when using it?

Because that code is actually taken from SqueezeLite so I'd expect it to behave the same way as there.... (that's the idea behind that).

Edit: merged.

[paul-]

Ah, LMS needs leading zeroes, I remember.
How does this work in SqueezeLite? Does it correct the MAC when using it?

Because that code is actually taken from SqueezeLite so I'd expect it to behave the same way as there.... (that's the idea behind that).

Is it the JSON interface that needs it?

[pippin]

Is it the JSON interface that needs it?

Yes, but I thought anything that uses the MAC as playerID. I always convert them before sending in iPeng, that's probably why I forgot about it here.
But isn't it the same in SlimProto? Or does that use network-format MAC addresses? Have to look it up...

[paul-]

I've respun the sbpd.tcz in post #5 to support the pi0W which was added to libwiringpi v2.42 released on March 1st.

It's untested at this point. Don't have a pi0W yet.

Ralphy, wiringPi is already up to 2.44 lol.

There is a fix for the ZeroW.

[kingswindsor]

Just to be sure: this means that the encoder is connected to pins (physical pins) 16 and 18 and ground (the center pin)?
Or are you pulling down against 3.3V?

Yes, physical pins 16 and 18 but against 3.3v. Not right?

Sent from my SM-N9005 using Tapatalk

[pippin]

Yes, physical pins 16 and 18 but against 3.3v. Not right?

Sent from my SM-N9005 using Tapatalk

No, right now sbpd expects you to pull up (from ground).
It's just a configuration option, I'll update it over the weekend to support both varieties.

Is there no longer a risk of frying the GPIO chip when pulling down from 3.3V is the software enabled pull-up resistors are not yet enabled and you use the encoder/button?
I read in some articles that this was a problem with at least some Pi models so that people recommended to still use hardware resistors with such a setup.

[kingswindsor]

I believe there is still a risk of frying the GPIO chip and I do have the pins protected with a resistor and zener diode (via a rasp.io break out board at the moment for convenience). I'm assuming it will need protection unless advised otherwise! Would it no still b needed if I reconfigured the centre pin to go to ground?

Sent from my SM-N9005 using Tapatalk

[pippin]

Don't take my word for it but my understanding is that by default the GPIO pins are on ground level so unless you activate the Pulldown-Menüs resistors software wise, nothing happens if you connect them to ground.
If you connect them to 3.3V, otoh, you get quite a bit of current so you probably always want to add external resistors. The advantage then is that you don't need your software to specifically activate anything

[cubii]

Which buttons?

Hi,
i am also building a Musicbox with picoreplayer and i am looking for some buttons.
So i found this script, which seems to be very useful, but did not try it.

But because the script is only useful if you have some buttons, i have another question:
what buttons do you use?
I cant find any buttons which have some engraved or painted Symbols on it like play, pause next etc. on it.
Any body has seen something like that?

greetings
cubii

[kingswindsor]

I'll play around with some more configurations over the weekend, maybe I'll add another option to use encoders and buttons pulling down from 3.3V

Pippin, I was just wondering if you have had a hence to update the software? I'd be happy to help test it. P.S. I've put the centre pin to ground but it still doesn't do anything when I turn the rotary encoder.

Sent from my SM-N9005 using Tapatalk

[pippin]

Pippin, I was just wondering if you have had a hence to update the software? I'd be happy to help test it. P.S. I've put the centre pin to ground but it still doesn't do anything when I turn the rotary encoder.

Sorry, I wasn't really able to test. My last test system is now away, my old one uses an old RPi1 and is horribly slow and my new test device is a rpi0w which doesn't yet work with piCorePlayer which I've used for testing so far.

I have created a "testing" branch in the repo which contains a change that should allow a configuration parameter for pulling up/down (last parameter, 1 for down, 2 for up).

Have you tried "-v" (verbose mode) to see what happens? Don't you get any interrupts at all from the encoder?