Archived Forum

I'm not having that problem here.  Wifi works as expected.

Works fine for me. Can you take a look at /var/log/wificheck.log? 

These are the last 3 entries of the wifi log, for this I unplugged the Ethernet cable at 21:53 and reconnected it at 22:00, during those 7mins I could not ssh in nor open emoncms in a browser, I tried both ip addresses and "emonpi/". I also refreshed the device list on my router and there was no mention of the emonPi, I also have fing connected on my phone which showed the emonPi disappear at 21:53 and reappear at 22:00 (with 2 ip addresses). These 3 logs are before, during and after the 7mins "no cable", bizarre I know !!! 

Starting WiFi check for wlan0
Thu  7 Jan 21:50:01 GMT 2016

Performing Network check for wlan0
Network is Okay

Current Setting:
          inet addr:192.168.1.69  Bcast:192.168.1.255  Mask:255.255.255.0

Starting WiFi check for wlan0
Thu  7 Jan 21:55:01 GMT 2016

Performing Network check for wlan0
Network is Okay

Current Setting:
          inet addr:192.168.1.69  Bcast:192.168.1.255  Mask:255.255.255.0

Starting WiFi check for wlan0
Thu  7 Jan 22:00:01 GMT 2016

Performing Network check for wlan0
Network is Okay

Current Setting:
          inet addr:192.168.1.69  Bcast:192.168.1.255  Mask:255.255.255.0

pi@emonpi:~$

Ok tried this again from a fresh 22dec image downloaded and installed to a formatted sdcard, this time I had also taken the steps of deleting any reference to emonpi from my routers dchp tables, I even cleared my windows pc's browser cache and even run "IPConfig /flushDNS" to remove any trace of emonpi. I even deleted it from the fing app on my phone.

emoncms wifi scan shows my usual networks (2 of my own, plus I recognize the neighbours too), I am able to add my psk "connect" and "refresh", the fields are fully populated and "connected". I can navigate to the IP given in the wifi details and arrive at emoncms, in fact I can open 4 different pages, the ip of emonpi's eth0, the ip of emonpi's wlan0, the url "emonpi/" and also "emonpi.home/".

Both ip's are listed in the router, (and the wifi ip has been changed this time around so I know it is a new record), bothe ip's are found in fing.

As soon as I remove the Ethernet cable all 4 pages will not refresh, "page not found". there are no active connections in the router table for emonpi nor is it found by fing. 

I waited 10 mins for the "wifi script" to have been called twice and tried all again no change,

Plugged the Ethernet cable back in and all 4 pages refresh, fing shows 2 connections (2x ip's) as does the router.

I have been through this multiple times now and the result is the same.

Is there a full build guide for the 22dec image for me to check?

For the record this is using a standard edimax wifi dongle, I have several but this particular one was supplied by the OEM shop, It was working perfectly ok on this emonpi with the previous image, unfortunately I do not recall which it was probably the 17june but I cannot ne sure.

I have multiple Pi's using various dongles and I do not have any wifi issues usually, this emonpi hardware has also never posed a problem before, this can only be an issue with this image, granted other uses may not of experienced this issue but I have nothing non-standard and have not altered the image in any way other than copying the default.emonpi.settings.php over to settings.php and using the wifi module to connect to the network.

Paul

Ok, I have now found if I reboot without the Ethernet connected it's a very slow process but eventually it will connect via wifi, I noticed there is absolutely no led activity on the dongle for a considerable amount of time though, in fact I had pretty much given up and was doing something else when I saw a blue flicker and moments later the "unfound" page refreshed in the open browser. I thought maybe it was dependent on the reconnection script to make the initial connection which could take up to 5mins but the wifi check script logs still show no problems.

Paul

Hi Paul, 

Thanks for testing this. I would love to get to the bottom of what is causing the issue for you. I am also running the stock 22nd Dec image and wifi has been totally solid on my emonPi since I powered up before Christmas. 

There was a long standing problem with the old 17thJune image that the wifi-check script was being called in the 'pi' user crontab but it requires root to run properly. In the 22nd Dec image the cron entry was moved to the root sudo crontab.

The wifi check script is installed with:

sudo cp /home/pi/emonpi/wifi-check /usr/local/bin/wifi-check
sudo chmod +x /usr/local/bin/wifi-check

Here is the script: 

https://github.com/openenergymonitor/emonpi/blob/master/wifi-check

Thinking more about it, maybe it would be best so symlink the script to rather than cp so we can update if needed? 

Hi Glyn

I do not think this has anything to do with the "reconnection" script, my logs above seem to prove that and as you point out those permission issues where resolved before the 22dec image. Plus this should not be dependent on the "reconnection" script for the initial connection. With or without a "reconnection" script all my Pi's have always been able to switch to the wifi connection after removing the Ethernet cable, in fact I would usually ssh in set up wifi, use ifup and ifdown to establish the wifi connection, ssh in via the wifi ip to confirm the wifi, then unplug the Ethernet thus losing the first "Ethernet" ssh console connection, but the second "wifi" console would continue without any interruption. This is not possible (for me) with this image.

I previously mentioned that iwconfig and ifconfig tools were not installed on this image. I have since found this to not be the case. There is in fact, a "difference" in the PATH settings, (I would consider it broken, but cannot rule out it's intentional) on both "normal" jessie and wheezy. Both those commands get a result. Yes, you probably need to elevate with "sudo" for actions, but for checking connections, it's not required. But in this image, you get

-bash: ifconfig: command not found

Whilst trying to establish the origin of this OS build, I tried tools such as "hostnamectl" which too works fine on "stock" jessie. It's not found on this image, and even sudo doesn't work this time. But  "/usr/bin/hostnamectl" does work.

Is the PATH issue by design? Is that why the prompt is red, not green? Or is that just a colour preference?

Now I have the use of ifconfig and iwconfig the plot thickens. Right now, I have the emonPi/22dec.img and a Pi2/Jessie.img side by side on the bench. Both have the same dongles and are connected to the same network. However they are also both showing an active eth0 connection which is odd, as I only have one Ethernet cable.

When I checked, the cable is connected to the Pi2, not the emonPi When I unplug it and run ifconfig, it no longer shows an ip address for the eth0. If i connect it again, "ifconfig" shows an ip. This is as I expected based on recollection. The emonPi however, does not show any signs of recognizing the Ethernet cable is present or not, using "sudo ifconfig" it seems to retain the ip and shows an active connection, despite the cable not being connected, this is unlikely to be a retention/retrying  scenario as when I first noticed it the Ethernet cable had not been connected for over 12hrs.

Currently, I believe the emonPi is not switching to the wifi connection automatically as it is not aware the Ethernet is missing, unless rebooted without the cable, as I found. Now I have "found" the tools I can do some further ifup and ifdown tests, but I have no idea why the eth0 is not updating, could it be somewhere in the ifup ifdown type scripts there is a path issue?

I've spent a considerable amount of time on this however I do not intend using this image, if you wish to get to the bottom of it I will continue some tests, but there is little point pursuing this for my benefit alone. I'm surprised I'm alone in this as I am using a stock emonPi, freshly downloaded 22dec.img, edimax dongle and a very standard bthomehub router/network, there is nothing odd there! and I have no issues on any of my other Pi's.

I am pretty confident the PATH issue though, will probably cause other issues even if it's not the root cause for the wifi issue that currently only effects me.

Paul

Hi Paul, 

Thanks for helping debug this. Yes on the on MINIBIAN image ifconfig must be launched by /sbin/ifconfig. Does your emonPi wifi work after a reboot after Ethernet is removed? Do you know how the Path issue could be fixed so ifconfig another other scrips could be executed without specifying /sbin?  

Yes, wifi will work after a reboot after Ethernet is removed if the Ethernet is removed before the reboot, if rebooted with the Ethernet connected and then disconnected nothing changes.

I think this is to do with not having the "allow-hotplug" stanza in /etc/network/interfaces, I haven't had a chance to test it yet but it stands to reason as the "auto" setting will only do something at boot not on a system event.

It seems the PATH is intentionally configured differently in this image, there are no paths to any system files for a standard user, on the minibian site it says a root user is enabled and the password is raspberry, but this isn't the case on this image, did you change it? if so how? I'm guessing the pi user is not that root account due to the path issue.

Paul 

some useful links 

https://minibianpi.wordpress.com/how-to/wifi/

MiniBian and wifi (HOWTO & preconfigured image)

Hi Paul, 

Ah great, so the WIFI is working after a reboot once Ethernet is un plugged. To me this seems like acceptable operation since the user flow at setup is to connect  to Ethernet to setup Emoncms user account and connect to Wifi then shutdown and move the emonPi to desired install location and connect CT's etc and then power up without Ethernet what which point Wifi will connect. 

I have just looked at mt network interfaces file and I actually have "allow-hotplug wlan0", I must have added this manually. I will make sure this is included in the next image release. Can you confirm that it does fix this issue. 

Yes, I manually created the Pi user on first boot of Minibian:

apt-get install sudo

adduser pi

adduser pi sudo​

allow-hotplug wlan0 will not affect whether the eth0 reacts to being connected or not.

Reading some more, it seems allow-hotplug is dependent on some other stuff that I'm unfamiliar with "udev"? and I do not know if it's fully functional in Minibian or not. The more I learn bout Minibian, the less I like it.

If you are happy with that level of operation, I think I'll leave it there. Personally, I would expect at least the same level of operation to be tempted away from official Raspbian. IMO, by far the biggest advantage of the official releases is we know more about them and what we don't know, is easily found. 

Paul

Paul - just wanted you to know you are not alone.  I am seeing some of these same issues.

I am using a new SD card and the emonSD-22Dec2015.img file.  With both the ethernet & wifi connected, I did the initial setup of user ID & password and wifi ID and password.  I think the emonPi did its first boot emonpi update soon after.  I eventually removed the ethernet connection and I lost connection to the emonPi.  I could not connect via the wifi IP address.

I did a paper clip shutdown, removed the ethernet and then powered up the emonPi.  It was a very s-l-o-w process to connect via wifi.  I am guessing 5 minutes and maybe closer to 10 minutes before I could get any webpage loaded.

ifconfig does not work.  sudo ifconfig works as expected.
route -n doesn’t work.  sudo route -n works as expected.

I know none of this is new info.

I normally connect the emonPi via ethernet but I'd be happy to connect via wifi and test something to help.

Jon

Thanks for letting us know. I'm not the only one seeing this. At least now it's validated as not a one of a kind. Anyone else experiencing the same issue and reading this, will know not to spend too much time trying to resolve it unless needed.

Paul

Hmm same problem here. Spent hours trying to work it out before coming to this thread! Unfortunately I do not have the skills to debug this so I hope it will be solved by one of you gents.

Did a complete reset of the software. reregistered and set up wifi with lan cable connected. Hot unplugged the lan cable and it continued to work.

Powered down and restarted and connected immediatly.

Has the software been updated?

3 days up , no issue

see thread by Jmoloney re similar issues. Having spent some time trying to work out what is physically causing this: Hot unplug or plug of lan cable. wifi dongle seems to take 5+ mins to come alive and reconnect. Which initially confused me. My issue then is if wifi AP or router is rebooted whilst Pi is connected by Wifi. the connection is lost and does not restart. If the lan cable is then hot plugged in the wifi does come back up but only after 5+ mins.

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. 

I am currently working on rebuilding the Dec22 image from scratch using Raspbian Jessie minimal as the base image. Hopefully this will help fix the Wifi issues. I will post new beta image in a week so.