Maintenance

[TerryJC]

Hmmm. I'm not sure what is going on there, but I can now get in to both Tiny TVs. The uptime command shows that they've only been up for about 2.5 hours. Is the power to the shops turned off overnight?

[TerryJC]

Just seen your post in the Tiny-TVs Topic. For some reason, I'm not getting Alerts from there.

[Penri]

OK Strangely my notifications are working fine!

[TerryJC]

Penri,

The next time you are in, could you recycle it and check the temperatures with the Web App? No rush, as long as the music and bells continue to work, I'll let sleeping dogs lie. Tuesday looks like the warmest day according to the latest forecast, so it would be good to see how the CPUs are coping with the solar gain.

I guess a lot of things have got in the way of this and I am still unable to log in to the Minster Pis.

I would also like to retry deploying the antenna on the extension lead when you have time Penri. The last time you did it, I was having trouble with the WiFi analyser software so was unconvinced that moving the antenna outside the Minster building was having no effect.

If we really can't get the WiFi to remain connected for more than a few days at a time, then a rethink will be needed, especially since the Tiny-TVs that are powered 24/7 are still responding after 13 days.

[Penri]

Apologies, there have been too many things to do first thing when I’ve arrived at WMT these past days.

[TerryJC]

Power Management was raised again on the Raspberry Pi Forums and after various suggestions I was able to turn this off. To check the current status, send the command:

Code: Select all

pi@minster-music:~ $ sudo iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"WMT-Guest"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: C4:E9:84:26:E7:00   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=32/70  Signal level=-78 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:8948   Missed beacon:0

As you can see Power Management is marked as on. Then use sudo iwconfig wlan0 power off:

Code: Select all

pi@minster-music:~ $ sudo iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"WMT-Guest"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: C4:E9:84:26:E7:00   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=32/70  Signal level=-78 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:9014   Missed beacon:0

I'll keep logging into the Music Pi for a few days to see if this works.

[TerryJC]

Well I think that proves that once and for all, Power Management isn't the problem. This morning I found that I was unable to log into the Minster Pi. That's less than 2 days since the last reboot when I turned it off. Apart from the fact that it might have been raining at WMT at the time, that's pretty conclusive.

Penri,

I think we'll have to retry the Antenna relocation exercise again; sometime when it isn't raining and you have the time.

[TerryJC]

Catching up with the current situation.

Penri relocated the Antenna a few days ago with little effect on the signal strength and error count. As a result I've modified the Minster Music Code to perform a reboot of the Pi every night at 11 pm. There was already a 'resetnormalopening()' function, called by apscheduler at 2300 which really didn't do much except change the variable 'enable_late' to False (whether it was True at the time or not). This was to ensure that if the 'Late Hours' facilty had been set, it wasn't forgotten.

I changed the 'resetnormalopening()' function to 'reset()' (and its call from apscheduler) and added the following code:

Code: Select all

def reset():                   # Reboot the Pi to maintain WiFi connection and reset everything
    print('Rebooting Pi in 30 seconds..')
    logger.info("Rebooting Pi in 30 seconds..")

    time.sleep(30)

    subprocess.call('reboot')

This code has been tested here and installed at WMT. The Minster system has been rebooted by Mandy, so tomorrow morning, I'll check that the Pi is still running and that the log contains the necessary entry.

[Penri]

I could log in this morning although the WiFi signal was intermittent.

[TerryJC]

This morning I was able to log in again, although I noticed that the log rotator functionality seems to have failed in that the current log has not been renamed to include the previous day's date log at midnight. I'm unsure why, but I've changed the code to do the reboot at 9 am instead of 11 pm. The software will then have been running all day before the log is rotated, instead of for only an hour.

I will keep monitoring it.