Script to programmatically control hotspot services

[dj3mu]

The requirement

As, in Germany, we're not allowed to run private stations in unattended mode, I would like to bring the hotspot services (and thus radio transmissions) up and down programmatically while keeping the RPI itself running 24/7.

I want to do this based on cron schedule. But also remote-controlled by other ways. For example integrated in some home automation (which knows how to detect whether I'm at home) via ssh command.

Proposed solution

So I checked what pistar-update, pistar-remote and others are doing and concluded that the systemctl stop ... would be a way forward.

I'm not clear whether my approach is the best way to shut down the hotspot (or at least the radio). However, I wanted to share this with the community. I'm surely open for any other suggestions that fit the above requirements.

Request for feedback

If this separate script is an acceptable way forward and if the owners agree, I would submit another PR which removes the code duplication and calls the pistar-services instead of systemctl stop ... at least at all the places where services are supposed to be controlled all together.

[AndyTaylorTweet]

You should only need to stop/start MMDVMHost and DStarRepeater since those interact with the radio, the rest of the services are the network end of the system and can stay running.

You would also need to stop the ".timer" for each of those and also the pistar-watchdog service - its job is to keep all the daemons running.

There is most of a script in place already for keeper operations that uses bluetooth to detect the keeper's cellphone - if the phone is in proximity, continue - if not, replace the public callsign with the private one.

This could be adapted to give the choice to just kill the radio services.

[dj3mu]

Sorry for the delayed reply. Ham radio is only a hobby and sometimes other things take priority ...

I am aware of the keeper and also had a look into its source code.

The locked mode seems to indeed fit my requirements. Especially because I forgot to mention (in my requirements), that I want ircddb to be shut down, too, because I probably want to bring up another hotspot at some other location that should "take over" the call-sign routing.

But keeper currently has nothing that would allow me to control it's lock/unlock from any other outside entity.

• I'd, for example, need at least two intervals for weekdays: Sleeping and at work.
  Surely I could "hack" the Python script for it. But isn't that "re-inventing the wheel"? Just for that purpose cron does provide the optimal flexibility and, with the already existing expert config page for crontab, a quite convenient possibility for configuration.
• Bluetooth smartphone detection
  While this is perfect for stand-alone operation, it doesn't cover my case where a presence detection is already handled by the smarthome server. Additionally, keeper is not even running for me due to missing BT. It is my current understanding that with some modems (like my MMDVM HS_Hat), BT must be disabled on the RPI due to colliding interfaces. Actually I'd prefer to only have one entity that handles the presence detection and then controls all dependent services.

My requirements would be fulfilled if keeper would get some interaction capabilities. This could be

1. A listening TCP socket on which keeper accepts commands like status, stop and start.
   Those commands could be sent by whatever other entity (even netcat would do).
   But this has the disadvantage of no authentication (if the socket listens on the public interface, it could be misused). This could, however, be overcome by only listening on localhost (which should be the default)
2. A command line utility that interacts with keeper via one of the Linux IPC concepts.
   That seems quite some effort. To be honest, I don't have the time to implement this. Especially as I'm comparatively new to Python.
3. A "command file" that keeper looks for every time it wakes up from its "sleep". When found, it reads a command from the file and then deletes the file.
   This would be simple and generic as there are a lot of ways to create a file with some short text. E.g. a simple echo "stop" > /var/pistar-keeper/command.file
   But this sounds a "kind of hacky".

So would a re-work of keeper in one of the above ways be acceptable?

On the other hand: Isn't all of this quite a lot of effort for something that can be handled by a simple and straight-forward shell script containing a couple of systemctl calls?

[dj3mu]

As there's no resolution (merge or reject comment) and also no further feedback for more than a month, I assume this is somehow not really wanted, even though it would still be fully optional to use the script.

So I'll find another solution for the OMs of our local radio club and me.

Please feel free to close this PR. I'm not angry about it and I'm really thankful for all the work that has already been spent on Pi-Star.