Archived Forum

Could it be the DHCP lease expiring? In your router, have you given it a fixed IP address?

Thanks for the reply. I had considered something like that but I don't think it is that - I checked the router settings and they're the standard DHCP settings.

See this for another way to disable power saving on the edimax wifi dongle.

http://raspberrypi.stackexchange.com/questions/36714/wifi-edimax-ew-7811...

If you look down the page you'll find the following setting which I'm hoping has fixed my issues with this. Haven't had a failure for a week or more since doing this which is no proof it's fixed it of course.

sudo nano /etc/modprobe.d/8192cu.conf

then add the following.

# Disable power management
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1
 

Excellent @Bramco, thank you very much! Now you mention this, it rings a bell and I believe I made this change on my other Pi which hopefully explains why that's working ok.

I've made the change and have everything (well, almost everything) crossed that it fixes the issue. I'm pretty confident that it will do.

Thanks again, Josh

Great to hear you have solved the issue. However it's strange you have had this issue, other users have reported good wifi stability using edimax and the emonPi our pre-built image. The emonPi has got a wifi -check script which should run as a con job ever 5min. 

Cold you check the log file: $ tail /tmp/wificheck.log. You should see:

Starting WiFi check for wlan0
Mon 14 Dec 13:00:01 GMT 2015

Performing Network check for wlan0
Network is Okay

Current Setting:
          inet addr:192.168.0.53  Bcast:192.168.0.255  Mask:255.255.255.0

It has been brought to my attention that this script may need to be ran as root. In the new pre-built image (beta release) based on the new Raspbian Jessie the wifi-check script is in the root conjob. I have just tested by unplugging my router here and then switching back on and the emonPi with the new image connected just fine.

If you have a chance could you test? If it's not working and the log shows a permission error you can move the cron entry in $ crontab -e to $ sudo crontab -e this will execute the wifi-check script as root. 

I've just checked the new image and the file /etc/modprobe.d/8192cu.conf does not exist. I'm wondering if I should include the power management fix in the new image as a precaution. However it might well be ready built in to the distribution? As Wifi re-connection is working fine I think I'll leave it out for the moment. 

Our of interest what % signal strength does the emonPi LCD show?  

Hi

The wifi log contains the text you pasted above (apart from the timestamp & IP@ being different, of course!). The timestamp is (very) recent so the script is running.

It also contains these errors:

rm: cannot remove `/var/run/wifi-check.pid': No such file or directory

/usr/local/bin/wifi-check: line 63: /var/run/wifi-check.pid: Permission denied
Performing Network check for wlan0

I looked in /var/run and indeed there is no pid file so that might be a permission issue somewhere.

The signal strength currently shows 68% which is pretty typical from what I've seen.

If my wifi problem doesn't disappear following the 8192cu change, I'm thinking that it might be a good idea to temporarily modify the crontab file so that each wifi check output is appended to the log to avoid potentially useful data loss (default is to overwrite).

Thanks, Josh

Yes, I agree it would be a good idea to append rather than overwrite the log. However I'm worried what will happen over a long period of time when /tmp fills up. I think we will need to implmenet a log deleting / roatation scheme if I change to appending 

Glyn,

I'm assuming this isn't part of the pi install guide that Paul wrote recently?

If not then it would be good to get this included.

Re adding the /etc/modprobe.d/8192cu.conf fix as wel. I can't see it hurting. If you check with google for fixes for this issue there are quite a lot of references to the fix. Maybe overkill but losing wifi can be a real pain, especially if it happens when you can't get access to the system as happened to me recently.

Hi

Can't add anything technical here but may add a small additional point.  I found that my wifi dongle stopped responding to when I navigated to the IP address, usually every day.  It required operation of the reset button.  The odd thing was that although I could not access it, it was still sending the data to emonCMS.  I solved my issue by crawling around and feeding an ethernet cable. I now have an IP address for wifi and ethernet -   I do not know  whether the ethernet is keeping the dongle fully alive but I have been able to access the dongle every time since.  That is about two weeks ago.  

Sad to say but I lost connectivity again yesterday. Admittedly I rebooted the router a few times to resolve some other issues but would have expected the Pi to reconnect as usual.

Under these circumstance I usually do a reboot, but I understand that this leads to a loss of cached data that might otherwise get sent to emoncms.

Is a better solution to pull and re-insert the dongle?

"but I understand that this leads to a loss of cached data that might otherwise get sent to emoncms."

Unfortunately the emon-pi variant of emonhub (as included in the standard emonPi image) no longer buffers data, the data is only buffered between 30sec sends and if the network is not available when it attempts to send the data is not retained.

Try changing the "ifdown wlan0" line to "ifdown --force wlan0" in the wifi-check script. the ifdown script will only bring down wlan0 IF it believes it is configured (up) and could be wrong, --force just does it regardless.

To get the bottom of the problem you may need to use an Ethernet cable to ssh in while the wifi is down, neither rebooting or removing/installing the dongle is ideal.

Paul

Hi Josh, I had the same problem with my wifi, dropping the connection after 18 to 24 hours. Mine uses the r8188eu driver which may be similar to yours. My fix was to use...

sudo nano /sys/module/r8188eu/parameters/rtw_power_mgnt

...to change the 0 to 1, and no drops for a couple of weeks. There is only that one character in the file. See if you have such a file, maybe r8192cu or similar.  Worth a try anyway.

Thanks for the info & tips, I'll see if it was a one off by monitoring it over the next few days/week and if not I'll fiddle with the script and driver settings.

So I had another drop this afternoon after a spontaneous router reboot (BT are wonderful like that).

This time I connected an ethernet cable before the reboot to see what I could find (this isn't something I could leave in place, the cable is about 10m long and runs over the floor like a trip hazard). The log file /tmp/wificheck.log reads:

Starting WiFi check for wlan0
Tue Dec 22 17:15:01 UTC 2015

/usr/local/bin/wifi-check: line 63: /var/run/wifi-check.pid: Permission denied
Performing Network check for wlan0
ifdown: failed to open statefile /run/network/ifstate: Permission denied
ifup: failed to open statefile /run/network/ifstate: Permission denied

Current Setting:

rm: cannot remove `/var/run/wifi-check.pid': No such file or directory

This leaves me wondering if running the script as toor might help as suggested?

From what I understand, this would involve editing user "pi"'s crontab file to remove the associated entry, and then adding the entry in root's crontab file using the sudo command. I'll try that to see if it helps...

Josh

Ok, so I made the cron job changes and ran a test to see what was what by rebooting the hub while the pi was connected via wifi. There were some odd messages in the log file:

Starting WiFi check for wlan0
Tue Dec 22 17:45:01 UTC 2015

Performing Network check for wlan0
ifdown: interface wlan0 not configured
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument

But regardless of them I'm happy to say that wifi connectivity was re-established, so it appears that my problem might be solved. Just in time for Christmas - hurray!

Note: I had to remove the entry I initially added to /etc/network/interfaces since that also resulted in an error message appearing in the log file.

*Sigh*

I checked my device today only to find it had been offline for over a day because it had connected to a FON SSID instead of my own wireless network.

Not sure why this happened, but in any case I went into /etc/wpa_supplicant/wpa_supplicant.conf and deleted all SSID entries other than my own network.Hopefully this might stop it connecting to other networks in future..?

I am also having this problem.

I tried the wifi script also after modifying the location of the pid file as it was wrting in a read only area.

adding also a ping to the router to check connectivity and reestablish it in case.

But again today the emonpi was disconnected!

EmonPi and router are in line of sight (6/6 meters) and when connected the emonpi gives 60% signal stregth (emonpi is in a electrical cabinet recessed) and router beyond a shelf with heavy cabling . but there's 60%.

Note that at the same distance there is a wifi thermostat connected to the same wlan that has no problem since ever.

So why are we having this trouble? 

How many other people have it?

I purchased the EmonPi on kickstarter back in may 2015.

I am going to open an issue on github as I could not fin any open.

Any help from the support team is highly appreciated

KR

Permission denied message is due to the fact that the script tries to write in /var/run and this, when partitions are RO, is a no write area.

change the path in the script to temp.

Did not solve for me however.

Anybody with another dongle and working?

TX

I have been using a different dongle:  the LB LInk BL-LW05-AR5.  It has a big antenna and good range.

However, I suffered from the same disconections (not on emonPi, on emonBase with older version).  

The fix for me was to change the way WiIfCheck operates.  WiFiCheck works by checking to see if the Pi has an IP address:

# We can perform check
echo "Performing Network check for $wlan"
if ifconfig $wlan | grep -q "inet addr:" ; then
    echo "Network is Okay"

I found that my router would hand out DHCP addresses, but somehow would close the connections after a random period of time, while still reserving the IP address.  This caused WiFiCheck to report a false positive.

The fix for me was to change WiFiCheck to ping either my router (192.168.1.1) or better, Google (8.8.8.8) instead of checking for "inet addr:".  This has been 100% reliable on at least 10 different Pi's.

Disclaimer:  I do not have an emonPi or know what is installed on one by default.  

Here is the code, from "#Settings" downwards:

##################################################################
# Settings
# Where and what you want to call the Lockfile
lockfile='/var/run/WiFi_Check.pid'
# Which Interface do you want to check/fix
wlan='wlan0'
# Which address do you want to ping to see if you can connect
pingip='192.168.1.1'
##################################################################
echo
echo "Starting WiFi check for $wlan"
date
echo 

# Check to see if there is a lock file
if [ -e $lockfile ]; then
    # A lockfile exists... Lets check to see if it is still valid
    pid=`cat $lockfile`
    if kill -0 &>1 > /dev/null $pid; then
        # Still Valid... lets let it be...
        #echo "Process still running, Lockfile valid"
        exit 1
    else
        # Old Lockfile, Remove it
        #echo "Old lockfile, Removing Lockfile"
        rm $lockfile
    fi
fi
# If we get here, set a lock file using our current PID#
#echo "Setting Lockfile"
echo $$ > $lockfile

# We can perform check
echo "Performing Network check for $wlan"
/bin/ping -c 2 -I $wlan $pingip > /dev/null 2> /dev/null
if [ $? -ge 1 ] ; then
    echo "Network connection down! Attempting reconnection."
    /sbin/ifdown $wlan
    sleep 5
    /sbin/ifup --force $wlan
else
    echo "Network is Okay"   
fi

# Check is complete, Remove Lock file and exit
#echo "process is complete, removing lockfile"
rm $lockfile
exit 0

##################################################################
# End of Script

After changing che script as per previous script i keep having the problem . max 2 days and  it is out of network.

How many other users are having the problemi?

Please help. This way the device is simply unusable!!!!

Disconnected again! Please advise. Is there a version without this problem?

I don't know if I'm helping or making things more complicated for you... but two other things I've tried in the past with some success (this was before implementing the ping-based wifi_check detailed above):

1.  Use a CRON job to restart the pi every 12 hours

2.  Add multiple access point credentials in wpa_supplicant.conf (if you have more than one WiFi network available) using the priority feature.  This gives the wifi system some options in case the preferred network is not available.  

My wpa_supplicant.conf file looks like this (passwords have been replaced with xxxxxx):

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
    ssid="Office"
    psk="xxxxxxxxxxx"
    priority=10
}
network={
    ssid="Barn"
    psk="xxxxxxxxxxx"
    priority=9
}
network={
    ssid="Bridge"
    psk="xxxxxxxxxxxx"
    priority=8
}
network={
    ssid="8Z8QD"
    psk="xxxxxxxxxxxxxxx"
    priority=7
}
network={
    key_mgmt=NONE
    priority=0
} 

Here is my version of the problem.

Today I rebooted the wirelessAP connected to my home lan. My Pi then did not reconnect when the AP came back up (although other items reconnected fine). Rebooted Pi still no connection. Hot plugged net cable into Pi and everything instantly came to life wireless and cable.

In this instance I cannot see that inserting an auto reboot into the code will help????

Hi guys, 

I feel your pain, I have been doing my best to try and get to the bottom of this issue. Unfortunately I have not been able to replicate. Every emonPi and emonBase that we have running at home or in the lab have never disconnected from Wifi. I am using the standard Edimax Wifi dongle with a Sky router with a WPA2-PSK Wifi network. Over 1.5K emonPi's have been shipped and to my knowledge this thread is the only reports of WiFi issues. I think we need to try and collate some better info as to what could be the common cause:

I have started an open google doc spreadsheet, I would be most grateful if you could fill out your details:

https://docs.google.com/spreadsheets/d/1B7n57g2iOf-2OJGQMFfXknhfroisKn1AtAnDEzWmS98/edit?usp=sharing

One thing that all my emonPi install locations have in common is relative quite WiFi spectrum, there are only a couple of other WiFi networks present in the vicinity. I don't know if this could make a difference. I think this is a Linux / Raspberry Pi issue rather than a specific emonPi issue. 

Trying to work out exactly what physical actions cause it.

So far have run from Lan all day no probs. Just hot plugged wifi dongle into Pi. Sure enough after approx 5 mins it came up. Disconnected lan cable and now running on dongle. lets see? The 5 min delay time(written into script somewhere I believe) is a bit of a pain. If I had not known about it I would have assumed that no connection was going to be made and started rebooting etc! Will let it run overnight and then try reboot of AP.

See post above.

This am all was still working perfectly. I then rebooted the wifi access point that the Pi is connected to.

15 mins later the Pi has not reconnected. All other wifi connections were reinstated immediately. Wifi dongle has no blue light. Hot connected lan plug which worked (via lan) immediately. WIfi dongle then reconnected to wifi AP after approx 7 mins (definately more than 5). Disconnected lan cable and all ok again.

What that means as far as the script goes I have no idea. The long time delays are irritating unless you know about them and I would imagine are unnecessary in a mains powered device? I imagine that the Pi still thinks that it has a lan connection (as it did at boot) and therefore does not restart the dongle?