pistar-remote Questions

[AE5E]

I have been testing pistar-remote functions on a simplex and a duplex hotspot (both Pi-Star_RP1_V4.1.8) with these identical results:

1) hostfiles=9999995 When this command is sent the hotspot becomes momentarily unavailable. When this operation finishes the hotspot functions normally.
2) shutdown=9999996 When this command is sent the hotspot shuts down, the wifi connection is closed. Restoration requires a power cycle.
3) reboot=9999997 When this command is sent a reboot occurs. After which the hotspot becomes fully functional.
4) svcrestart=9999998 When this command is sent a fully functional hotspot becomes momentarily unavailable. After which it resumes, much like a reboot, but perhaps a little quicker.
4) svckill=9999999 When this command is sent the hotspot shuts down, the wifi connection is closed. Restoration of the hotspot requires a power cycle. It appears to me to be functionally identical to the shutdown command.

The first three of these commands work as I had expected, although shutdown and svckill could be interpreted in the same way.

What I had hoped would be the case is that after issuing svckill (or perhaps shutdown) that a subsequent radio issued svcrestart would resume the funactionality of the hotspot. But it doesn't, at least in my testing. This would be very convenient to the licensee of the repeater to achieve flexible remote control.

I refer above to 'hotspots', for the sole reason is that is what I used in my testing. My real goal is to implement these functions in our UHF DMR repeater, which uses the STM32_DRM from Repeater Builder. I was counting on that to behave the same as the hotspots. Had the results of my testing met my expectations I would have repeated these tests on the UHF DMR repeater. I did not do so as power cycling would require access to the repeater site, which is somewhat restricted..can't complain..we are unpaying guests!

I can control the UHF DMR repeater via zerotier as long as the internet connections remains active but shutdown and svckill causes a loss of the internet connections.

I had hoped that after a shutdown, or alternatively a svckill, that a svcrestart would remotely resume full functionality.

[M1DNS]

Host files... stop services and runs a host file update pulling down the latest host files for the active modes + dmr ID'S etc. after its finished it restarts services.

restart... stops services and restarts the Pi host sbc. Clearing memory ram, log files etc.

restart services... stops, then restarts the services associated with pistar. Memory, ram, logging etc are kept in situ and not cleared as in a restart.

killing services... stops all services associated to pistar, mmdvmhost, dmrgateway etc. etc. but keeps the underlying Rasp Pi OS running.

Shutdown... stops all services and shuts down the Pi, requiring a power reset to power back up.



Sent via smoke signals using my SM-G960F

[M1DNS]

Restart & restart services are prob. the two commands that make most sense here as if you issue a serv kill. Mmdvm host, dmrgateway, etc. (The softwares associated to making the pi and board run as a repeater) stop running. so there's nothing that will see or action your follow up RF requests.

If the services aren't running, you don't have a repeater, you just have hardware and an OS.



Sent via smoke signals using my SM-G960F

[AE5E]

'shutdown' and 'svckill' both require a power cycle to bring the repeater back to life. What I was hoping is that after one of the two commands that the repeater could be revived in response to a 'svcrestart' command. This would give the control operator what he needs without driving to the repeater site.

[M1DNS]

You seem to of missed the point of my reply, so I'll be a little more direct...

How can it accept the commands over RF if the software services and / or hardware running the repeater is powered down?

If either are off line, you have no functioning repeater. If mmdvmhost is not running theres nothing to Rx ur transmission.


Sent via smoke signals using my SM-G935F

[AE5E]

I didn't miss your point!

I had hoped that these commands might provide a means of suspending use of the repeater to all but the 'keepers' callsign and then allowing this restriction to be removed, all remotely.

I can currently do this remotely setting the access list using zerotier, but this would be more convenient.

[MW0MWZ]

I didn't miss your point!

I had hoped that these commands might provide a means of suspending use of the repeater to all but the 'keepers' callsign and then allowing this restriction to be removed, all remotely.

I can currently do this remotely setting the access list using zerotier, but this would be more convenient.

Shutdown is a system shutdown, so it does exactly what the host does if you issue a shutdown command, it really does require you to re-apply power to get it back.

SVCKILL is probably what you are looking for - it really will kill the MMDVMHost service - essentially killing the repeater, but the OS stays running, so you can go and start it back up (via dashboard or SSH connection), if you have no remote access to the Pi... that's where I would start.

[AE5E]

Andy, MW0MWZ:

Yes SvcKill does stop repeater usage while still allowing access to the dashboard via ZeroTier. From ZeroTier I can command a reboot on the dashboard or SSH.

It would be slick if after a SvcKill and repeater would still accept a SvcRestart via radio to return to service.

But I am satisfied..thanks for the existing capability

Ron, AE5E