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

[paul-]

If you want to used gpio to control Jivelite, you will need to simulate keyboard events. I think this is covered in the Jivelite thread.

[chill]

LMS is the problem......you need to halt the system first. You can build or buy power relays. To drop power after the kernel shuts down.

I've been trying to understand the foregoing discussion so that I can shutdown my pCP LMS server(s) safely. I'd appreciate guidance on whether I've got it straight.

From the 'gpio-shutdown' section here:

The default
configuration uses GPIO3 with a pullup, so if you connect a
button between GPIO3 and GND (pin 5 and 6 on the 40-pin header),
you get a shutdown and power-up button.

So I believe I need to enable the gpio-shutdown overlay on the tweaks page, and specify a pin number - I assume this replaces the default GPIO3 mentioned above.

With a button connected between the specified pin and GND, a press of that button will call the pcp-powerbutton.sh script in /home/tc. That script will safely shut down pCP, issuing a 'halt' command to prevent corruption of the SD card caused if prefs or cache are being written when the power is cut.

If I'm on the right lines, should that button be a momentary button or a latching button? Does pCP restart when the pin is grounded a *second* time, or when the connection to ground is broken? If a momentary button is required, that button should presumably *not* be configured as part of an sbpd setup.

I just tried "gpio-shutdown" but it does not shutdown the pi as the readme suggests it only does "Player power off"

the next button push does "Player power on"

Jeff

Jeff - did you get this resolved?

[chill]

Reading more carefully, it seems like the button should be a momentary button: "After shutdown, the system can be powered up again by driving GPIO3 low."

So grounding the pin while pCP is running will call the pcp-powerbutton.sh script, which issues the 'sudo /sbin/poweroff' command. Grounding GPIO3 while it's shut down will use built-in RPi functionality to restart it. I also note that GPIO3 has an external pull-up resistor, so the pull-up setting in the 'tweaks' configuration should presumably be 'off' if using GPIO3 - or does this setting have no effect on GPIO3?

Something to play with this evening. I have a DIY button panel, with a 'red' button that currently uses sbpd to power off the local player (short press) or restart LMS (long press). Assuming it's not possible to use the button configured for the gpio-shutdown overlay to also function with sbpd, I'll remove those two functions from my sbpd configuration and connect that button to GPIO3 instead.

If I were to use a different pin for the gpio-shutdown, say GPIO26, then grounding that pin would power off, and grounding GPIO3 would restart, so a SPDT toggle switch might work (GPIO26-GND-GPIO3). Would it matter if GPIO3 stays grounded after a restart? Would it matter if GPIO26 stays grounded after shutting down?

[chill]

Grounding GPIO3 apparently performs a 'wake from halt', so it seems it'll only work if the Pi has actually been halted (e.g. by /sbin/poweroff?), rather than having the power interrupted. In its 'halted' state the Pi can then have the power removed safely. I think a toggle switch isn't such a good idea after all, but using a momentary button to ground GPIO3, to either halt the system or wake it up again, seems like the way to go.

[chill]

These settings seem to work for the gpio-shutdown overlay:



Grounding GPIO3 while the system is running will shut it down, grounding it again wakes it up.

[chill]

Wait... it doesn't seem reliable - sometimes works and sometimes doesn't. Coming back from a 'halt' (e.g. if I manually issue the 'sudo /sbin/poweroff' command in a terminal) seems reliable, but shutting down seems intermittent. Haven't spotted a pattern yet.

[meq123]

Wait... it doesn't seem reliable - sometimes works and sometimes doesn't. Coming back from a 'halt' (e.g. if I manually issue the 'sudo /sbin/poweroff' command in a terminal) seems reliable, but shutting down seems intermittent. Haven't spotted a pattern yet.

I'm surprised that works for you at all. I could never get mine to shut down using GPIO pin 3.

What I do - and it seems to work reliably, so far - is to use a different pin for shutdown (GPIO 4 in my case) and then GPIO 3 for restart. Then I wired both of these and ground (3 wires) to the same double-pole momentary switch. Thus the two pins are independent but both grounded at the same time when you push the button.

[chill]

Interesting. I wonder if it's the hard-wired pull-up resistor that's different then. Or the fact that I2C uses GPIO3.

Feeling a bit guilty about spamming this sbpd thread with this discussion....

[paul-]

Yes, i2c uses gpio3, if you are using a DAC hat, most of those use i2c to control the dac, and you cannot use GPIO3 for anything else.

Lets move the discussion over here

https://forums.slimdevices.com/showthread.php?109270-PiCore-Player-and-gpio-poweroff-gpio-shutdown-overlays

[chill]

In my case I don't have a DAC hat - no hats at all in fact. Testing so far has been with a bare 3B+.

EDIT - just saw your suggestion to move the discussion.

[chill]

Steering the discussion back to sbpd, I've just spotted that there's a 'stopserver' command. Would it be sufficient to issue this command, via a button press in sbpd, before pulling the power? Would this ensure that no writing to cache and prefs is taking place at the moment the power is pulled, and hence prevent corruption of the SD card?

[paul-]

you could issue a script to shutdown the server, but issuing a OS halt command is much easier.

[chill]

I agree that issuing the halt command is easy enough, but in a setup that's already using sbpd a script wouldn't be necessary. Isn't it just a case of adding a new command to sbpd_command.cfg, say:

XLMS=["stopserver"]

...and then assigning that command to a GPIO button press? Since 'stopserver' is an LMS command I'm assuming this stops LMS only, leaving pCP running, but since LMS is apparently the only process that might corrupt the SD card, it should then be safe to pull the power.

[meq123]

If you want to used gpio to control Jivelite, you will need to simulate keyboard events. I think this is covered in the Jivelite thread.

Well i just finished reading through the 100 (!) pages of the Jivelite thread (I assume this is the one: https://forums.slimdevices.com/showt...r-piCorePlayer). Couldn't find a thing about gpio and/or simulating button presses

[paul-]

Sorry to mislead you....Jivelite thread to understand key presses. Gpio Keys are handled by

https://github.com/raspberrypi/linux/blob/74a357602c469b159202ce7ef629d7e8fd8ba97c/arch/arm/boot/dts/overlays/README#L691

Not sure if anyone has actually tried it. Best to start a new thread with what you are trying.