Kiwi auto-poweroff if unused

dl7awldl7awl
in KiwiSDR Discussion
Hi kiwifriends,

as this is my very first post here, first of all I wish to say hello and thank you, John, and all other contributors, for this exciting project! It kind of opens a new and interesting world. :)

I'm still experimenting with my new toy which is not (yet!) public. I'm considering to implement some auto-poweroff if no user is present for a certain time. This would have two benefits: averagely it will save energy, and as it may need extra action to turn the kiwi on, it can also be some barrier against non-human users (bots).

Obviously, such a project will have to consist of three parts:
  1. a shell script inside the beagle, which shuts it down (/sbin/poweroff) if the timeout-criteria is fulfilled - this is already working
  2. a piece of external relay hardware, which physically turns power off if it detects that kiwi has been shut down (this detection could, for example, be done by watching the kiwi leds with a suitably placed LDR or, more elegant, by watching the current consumption which drops significantly after shutdown)
  3. a web page which will be presented instead of the powered-off kiwi to allow potential users to turn it on (this will be easy for me as I'm running some web servers anyway)
Points 2 and 3 could be (later) done with help of some simple and cheap ESP8266 based hard-/software, I think. For now, I'm especially considering point 1. I have already made a script which seems to do the job properly - but probably not the best way. The main question: how can a shell script reliably know if the kiwi is currently in use by users or not? I don't dare to dive into the details of the kiwi process, this should be a "black box" for me. The ms command (make status) is so horribly slow and probably CPU-consuming that I didn't take it longer into account after some tests. The only fast and non-invasive way I finally found is to look at the status info given by /bin/systemctl -l status kiwid - it contains string parts like 01.. where a digit represents a used RX channel, while a point stands for an unused one. However, this needs some weird parsing - only the most recent line containing ARRIVED or LEAVING must be observed, the interesting part string must be isolated, and the non-point characters in it must be counted to get the number of currently active users. If this returns 0 for all checks within the configured timeout span, the kiwi can be powered off. But I found that for unknown reasons in some cases, but not always, the digit of the last leaving user remains in that string forever, so a "minus 1 correction" seems necessary if it's a LEAVING line and the count is 1.

As said, it seems to work fine. But it's not elegant, and it's almost impractical to be tested under all possible conditions. I'm almost sure that there must be a better, simpler and more reliable way. Any hints?

Another question arises with point 3 and is regarding registration at kiwisdr/public and sdr.hu which I'm not yet familiar with. The "native" xyz:8073 address of my kiwi can't be the public one in my case, as it won't respond if the kiwi is off. So another URL is needed as the offical address, and it must lead to a web-/CGI-space on one of my 24/7 servers which must act in dependence of the current kiwi state: If the kiwi is on, it must redirect to it. If not, it must present a page with a switch-on button and according hints. No problem so far. But now we have two URLs: the "official" one, and the real, but hidden "native" address. The kiwi itself doesn't know the first, so I'm in doubt whether it is at all possible to register an address which is not the "native" one.

Thanks and 73,

Manfred

Comments

  • PowernumptyPowernumpty
    edited February 2020
    Hi Manfred,
    The /status link has users so it should be possible to read that directly or even curl from another box or local "curl http://localhost:8073/status | grep users="

    I'm pretty sure it has been covered before (by people who understand this stuff) so once others read your post you'll pick up a more sensible answer.

    On the page while down, again there was a useful post on NGNIX reverse proxy, that should cover fail over.

    Regards
    Stu
  • dl7awldl7awl
    Thanks, Stu. I wasn't aware of the existence of the status link, but that seems perfect!
  • jksjks
    The best way to determine the instantaneous user connection state is described here:
    http://forum.kiwisdr.com/discussion/comment/7982/#Comment_7982

    I'm not sure I understand your last paragraph fully. I think about all you can do is offer a single public URL that goes to your always-on server. If the Kiwi is up then your server will do an immediate "303" redirect to the Kiwi. If not the user sees the power-on switch. There of course would be no listing on rx.kiwisdr.com and/or sdr.hu while the Kiwi is powered off. Nothing you can do about that.
  • G8JNJG8JNJ
    Hi Manfred,

    Welcome to the KiWi Klub :-)

    An interesting idea that may be particularly useful if you are running an off-grid KiWi.

    I'd personally be interested to know.

    How much power this actually saves, especially if you need to use external processes and hardware in order to implement it.

    Is the threat of non-human users (bots) significant and would this additional barrier make any real difference ?

    What would be the implication with respect to GPS acquisition ?

    Regards,

    Martin - G8JNJ
  • dl7awldl7awl
    Thanks, John, for your hint regarding the /users link!
    There of course would be no listing on rx.kiwisdr.com and/or sdr.hu while the Kiwi is powered off. Nothing you can do about that.

    Okay, good to know. (I wasn't quite sure how fast a kiwi disappears from the lists if it is offline.) So if I'm using auto-poweroff, I must live with my kiwi being almost invisible - which of course makes the auto-poweroff idea less attractive. ;) However, I'm intending to make the concept complete anyway.

    Hi Martin,
    I'd personally be interested to know.

    I'll keep you up to date. The next steps will take some time, but the first part from my above list can already be shown. This is currently my simple power-off-script on the kiwi: 
    #!/bin/bash

timeout=30                     # Timeout in Minutes

timeout=$((timeout*4))         # Timeout in terms of loops
countdown=$timeout
while true ; do
   sleep 15
   rxuser=$(wget -q -O- http://localhost:8073/status | grep -m1 "^users=" | sed -e 's|users=||')            # gives no. of active users
   if [ "$rxuser" == "0" ] ; then
      countdown=$((countdown-1))
      if [ "$countdown" == "0" ] ; then
         /sbin/shutdown -P now
         exit
      fi
   else
      countdown=$timeout
   fi
done
    The script (I called it shutdownd) can be placed almost anywhere (I made a directory /root/mystuff for things like this). To automatically start it as a daemon on boot, I placed the line /root/mystuff/shutdownd & in /etc/rc.local. (I have other modifications to rc.local, so I put this line between them and the final exit 0 line.)

    With this script, the kiwi power consumption drops from abt. 12.5 Watts down to 1.9 watts if idle for more than the configured time (measured while using an old 5V/2A linear power supply, originally from a long-forgotten Iomega zip drive, which is ideal for the kiwi). It should be noticed that the real timeout is slightly longer than configured, as one loop takes a little bit more time than only the sleep command alone. This could be adjusted, but as the exact time is not critical, I didn't care.

    Is the threat of non-human users (bots) significant and would this additional barrier make any real difference ?

    I don't have own experiences with bots, as my kiwi is not yet public. But the existence of such thread suggested me that it could be a serious problem. And yes, I think that the need of a manual switch-on action can be an effective bot barrier - at least as long as this is a rare feature and unexpected from the bot's point of view.

    What would be the implication with respect to GPS acquisition ?

    I don't see any problem - or I don't understand the question (possibly due to my limited understanding of how GPS is working in the kiwi).

    73,

    Manfred
Sign In or Register to comment.