search

MiczFlor / RPi-Jukebox-RFID

A Raspberry Pi jukebox, playing local music, podcasts, web radio and streams triggered by RFID cards, web app or home automation. All plug and play via USB. GPIO scripts available.
http://phoniebox.de
MIT License
1.38k stars 397 forks source link

🚀 | Shutdown after [Time] idle #1970

Open DarthBlair opened 1 year ago

DarthBlair commented 1 year ago

Feature Description

If the Box wasn't user for a while, the Raspberry shuts down.

What functionality would you like to see in your phoniebox?

Enable/Disable Option for idle Shutdown Configurable Timer for Shutdown

How do you envision the feature to work from a users perspective?

If the Option is Enable an the box wasn't user für the configured Time it will shut down the pi to save power.

PsychoD commented 1 year ago

+1 I really miss this functionality in future3...

votti commented 1 year ago

I also would appreciate this a lot.

https://github.com/MiczFlor/RPi-Jukebox-RFID/blob/0326c9a60fbdb91ea36290979a8c488560187186/src/jukebox/components/timers/__init__.py#L80-L91

seems to indicate that someone has already thought about this before. Does a POC implementation of any of the options already exist?

votti commented 1 year ago

I was wondering: are the rpc calls also published under a topic in the message cue? As far as I can tell this is not the case, but would be useful.

To me having tracking:

Together would enable to determine the idle time and decide for a shutdown

pabera commented 1 year ago

I think the functionality is already there.. and you hinted the right spot in the code. The only thing missing is a frontend integration.

You could try to execute the time command from the RPC CLI.

hoffie commented 6 months ago

2332 has a working attempt at implementing an idle shutdown timer.

@votti

time since the playerstatus has last been not paused -> could be derived by listening to the playerstatus topic

I have implemented that (a bit more generalized: any change in player status is considered activity).

time since last rpc call -> listing to the rpc call topic -> additional filtering to ignore some call may be necessary

I have not implemented that part. Instead, I chose to monitor relevant file changes (configs & audio content). That should capture any administration tasks such as adding new cards, changing configs and updating audio content. In addition, I have added tracking for active SSH sessions (mostly aimed at developers or builders who are in the process of configuring/updating and don't want to be caught by an unexpected shutdown). Do you think not implementing the rpc logic misses anything relevant? I couldn't think of anything and was worried about false positives instead (i.e. if any component/extension would use some kind of polling via rpc calls that would be considered activity, without knowing if that makes sense at all).

@pabera

I think the functionality is already there.. and you hinted the right spot in the code. The only thing missing is a frontend integration.

You could try to execute the time command from the RPC CLI.

I haven't found that code though. Maybe I have missed it? :)

pabera commented 6 months ago

@votti

time since last rpc call -> listing to the rpc call topic -> additional filtering to ignore some call may be necessary

I'd be interested in some use cases. A few calls won't interfere with MPD, but ultimately it boils down to either "play" or "don't play". I think with the current implementation, a high percentage of use cases are covered. Thoughts?

@hoffie I updated my comment. I believe I confused the Idle Timer with Sleep Timer :-)