AndyTaylorTweet / Pi-Star_Binaries_sbin

Repository for Pi-Star Binaries
http://www.mw0mwz.co.uk/pi-star/
43 stars 41 forks source link

Add remote reconnect command #53

Open kn2tod opened 2 years ago

kn2tod commented 2 years ago

Add ability to initiate wifi reconnect sequence via a remote command

1) new file: batch file (pistar-reconnect) that duplicates the wifi reconnect sequence given in the wifi.php; invoked by pistar-remote.

2) mod to pistar-remote: add DMR command code to initiate the wifi reconnect batch file

3) mods: misc: return system to RO mode following hostfile updates; handle error when DMR log file is empty.

Note: User will need to add appropriate entry to /etc/pistar-remote and make codeplug changes to utilize this feature:

[dmr] TG commands : hostfiles=8999995 reconnect=8999994 <-----

kn2tod commented 2 years ago

Add: pistar-config-backup: same as config-backup php: back up configurations via command line (in case the dashboard means is not accessible; ref: https://forum.pistar.uk/viewtopic.php?t=4366&sid=a206a36ec2ee881d951569c6ed02c017

kn2tod commented 2 years ago

Thoughts? Comments? New feature - does not change any current functionality.

MW0MWZ commented 2 years ago

Please seperate the config back from the wifi re-connect - they are two different things. For the remote command to re-connect the wifi - sure i can add that in, but why make a bash script for that, when you can call it all from python?

W0CHP commented 1 year ago

I suggest adding /etc/dgidgateway to the pistar-config-backup script. It's part of "stock Pi-Star", and it's consistent with the dashboard backup/config functionality: https://github.com/AndyTaylorTweet/Pi-Star_DV_Dash/blob/1a4a0d30af2c6c24d40ea42a40371f89b2eeaf45/admin/config_backup.php#L73

kn2tod commented 1 year ago

Ouch! How the heck did I miss that?!?! Thanks!

W0CHP commented 1 year ago

The same way I always seem to miss things, too. 🤦🏽‍♂️ 😂 Happy to help 👍🏽

kn2tod commented 1 year ago

I coded the reconnect command process the same way the host file update process is coded - using an external script to implement the "details". "Hooking" in code like this gives a certain flexibility to making changes going forward, given that additional steps (error checks/retry logic) might need to be added - all without messing with the invoking process. It is consistent with your original logic for the host file update process. And, who knows, the external script could be "personalized" to include/experiment with rewrite rules and the like without incorporating those into the core (public) code. Does this make sense?