emonPi / emonBase Raspberry Pi 3 WiFi Issues

I have heard reports of a couple of users having the issue where the on-board Raspberry Pi 3 WiFi connects and get’s given an IP address however they are unable to access the Pi via this IP address. The IP address shows up in the router’s IP DHCP table and shows in the WiFi config in Emoncms.

I have been unable to replicate the issue with all WiFi networks I have tested the RasPi3 with latest emonSD-03May16.

I have added this thread as a placeholder for other uses to add their reports. How about a quick poll.


Do you have issues with using on-board Wifi on RaspberryPi 3 on emonPi / emonBase?

  • No issues, onboard WiFi works great :grin:
  • YES, I’m having issues :frowning: (post below)

0 voters

Check that the reporter doesn’t have WiFi isolation enabled on their wifi router;
Wireless isolation stops two wifi devices from being able to communicate when they are connected on the same SSID.

Its worth a check.

1 Like

I just received my emonPi this week. In setting it up it will connect to the wifi but once I disconnect the ethernet cable, there is no communication to the wifi ip address. If I plug the ethernet cable back in, I can communicate on the eithernet and the wireless ip address.

Sorry to hear your having issues. Could post a screenshot of the Emoncms Wifi page? Have you tried shutting down the emonPi and removing both the Ethernet and power then powering back up with no Ethernet cable connected?

This is an old issue that has been around a while, see “22dec image WiFi issues” Ethernet and WiFi do not play well together on the emonPi. If you choose just one and stick to it (from boot) you should be ok.

i was having issues. Had a static wifi and static fixed setup. But my wifi was showing a dynamic address on the emonpi screen. Would work with both static and dynamic wifi for a while, then stop. Could then only access via fixed.

Have removed wifi connection and now just using fixed. Prob has now gone (so far - 2 days)

reported in this thread

So I am still having issues with this. I tried shutting down & removing the Ethernet cable: still no wifi connection to the emonPi. Plug the Ethernet cable in and I can ping both the wifi and the Ethernet addresses. The admin page shows that the wifi is connected:

From your screenshot I can see the emonPi is connected to your wifi with IP 192.168.2.126. Am I correct that you can ping and connect to this address when the Ethernet is connected but when the Ethernet is removed you cannot connect to this address? If so, this is very strange behaviour.

Could you test connecting the Wifi to a different network? Maybe try and test connection to a WiFi hotspot created by a smartphone?

Thank you Glyn.

Connecting to another access point worked fine so the issue is with the access point, not the emonPi.

Hi

I too am having issues connecting using Wifi. First I had to SSH into the pi, run raspi-config and set the wifi location to GB as I use Channel 13 (by default my WiFi network was not discoverable by the emonPi). Once this was changed, the wifi network could be seen by the pi, but entering the wifi password and clicking connect appears to do nothing. I have also tried editing dhcpcd.conf with a static address for wifi and editing the wpa_supplicant.conf file with my SSID and password. (Yes, rpi-rw enabled first). Rebooted the pi with no ethernet cable plugged in, and on the LCD screen it still says the wifi is the startup AP on 192.168.42.1

Any idea what’s wrong?

Cheers

Update:

I have since re-installed a clean copy of emonSD 07Nov16 and expanded that onto the 8GB SD card.
I have set up a 2nd WiFi access point on my home network using a spare router and set to Channel 8.
Connected to emonPi over ethernet, registered it onto my new 2nd WiFi point and that works fine. SSH into emonPi, altered the WiFi country to GB to enable channel 13 access & rebooted. EmonPi is still connected to my 2nd wifi point on ch8 and can now see my original wifi point on channel 13. Attempt to switch to my original WiFi network on Ch13 and it refuses to connect. I have then moved my original channel 13 WiFi network down to a lower channel, but still unable to access that.

Both original and 2nd WiFi points have security options of {WPA2-PSK-CCMP][ESS]. Original wifi network SSID is “enigma”, the 2nd temp WiFi SSID is “colossus”. The passwords are alphanumeric with no special characters beyond a to z upper/lowecase and 0 to 9 numbers.

The wifi network “enigma” which is usually on ch13 is on a Draytek Vigor 2850 with mixed b,g & n modes (tried just b & g mode only too, no luck). The 2nd wifi router “colossus” is an older Thomson TG585V7 with b & g modes supported.

I own a raspberry pi zero w with stock raspbian install and that has no issues connecting to my original wifi network “enigma” using ch13 or another channel, so I can only assume there is an issue with the WiFi configurartion that is different on the emonPi distribution.

The only clue I have as to why I cannot connect to my usual WiFi network is this message in the log file:
Sep 9 17:48:02 emonpi wpa_supplicant[22779]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:1f:9f:15:0a:c3 reason=3 locally_generated=1
Full log here: https://pastebin.com/0Juxz6sD

Any ideas?

According to this, CTRL-EVENT-DISCONNECTED … reason=3" usually comes up when failing to get a dhcp lease. (post #5 in the thread)

That’s odd. All DHCP requests are handled by another device on my network, not the Draytek or Thomson WiFi points. 192.168.1.200 to 250 are available for DHCP allocation and an address of 192.168.1.201 was given via DHCP when connecting via the 2nd temp wifi. If there was an issue with DHCP allocation, why could my DHCP server give an address to any other device connecting to my original network, and not to the emonPi, yet then happily give it an address via the 2nd WiFi set up for testing? Doesn’t seem likely that the root issue is DHCP to me.

Might not be. But have you verified the emonPi was assigned an address from your DHCP server?
Or tried rebooting your DHCP server to eliminate that as a possibility?

The DHCP server is an internet router supplied by my ISP, so logging is scant on it. What is revealing is this…
Using the web config page for wifi on emonpi, I have unticked my 2nd wifi network “colossus” which worked, ticked “enigma”, my original wifi network. Entered the password and clicked Save & Connect. Gave it a minute to attempt connection. Checked in the /etc/wpa_supplicant/wpa_supplicant.conf file and the SSID for colossus is there, but not for enigna, the network I am trying to connect to. This is why I think there is a bug in the emonpi web interface for handling wifi. A stock pi install has no issues connecting to this wifi network.

I’ll probably end up pulling a few floor boards leading to my meter cupboard and running ethernet. Really don’t want to set up another WiFi network just for the power monitoring - want to save energy not plug more things in!

Just for the heck of it, have you tried manually modifiying wpa_supplicant.conf
to include the SSID (and other info) for enigma?

That worked! Very strange indeed! Some sort of bug in the emonPi web interface which doesnt allow switching between wifi networks looks like the bug to me. Thanks for the suggestion!

And so begins a whole new journey of tinkering & energy monitoring! :slight_smile: :grin:

Good to hear you got it working.

That’s one for @glyn.hudson

YVW, S!

Enjoy, and have fun!

May be related or not. I have a number of APs in the house (different SSIDs) with the Sky provided router providing the DHCP facility.

I have noticed an increasing number of issues, mainly on Win 10 machines but iPhone and Android as well, where it appears to be connected but there is no data flow. Switching to a different AP solves the problem. It seems to be worse when the device wakes from sleep.

I believe it is an IPV6 issue but cannot prove it. I have switched off IPV6 internally but it has only improved marginally.

All my PIs run on fixed IPs so I’ve not seen the issue there. When I get a moment I’m going to setup a Pi-Hole and PiVPN machine and use that DHCP to see if there is any difference.