Woo Hoo! Commenting out those two lines ( arm_freq=1200 and gpu_mem=16 ) & rebooting the Pi Zero, and it appears in the router’s CP.
After typing in the LAN IP I get the “Welcome to your emonPi” page. This is presumably what @lgheorghe was seeing on Getting setup wizard page instead of login . I clicked on the wifi option, and then after reconnecting to emonpi.local I get in to a bit of a loop - searching for networks (again).
Not sure how important this is - possibly related to the above - but above the Welcome page there is a warning message
**Warning** : file_get_contents(/etc/wpa_supplicant/wpa_supplicant.conf): failed to open stream: Permission denied in **/var/www/emoncms/Modules/setup/setup_model.php** on line **24**
The Pi is powered through my emonTx, with the wires connected as per @pb66 's second schematic:
4: 5v > 5v
6: Gnd > gnd
8: tx > tx
10: rx > rx
12: p12 > rts
I am able to ssh in to the Pi, but my linux skills are so limited that I although I am able to use some very basic commands (cd and ls etc), am not yet able to poke around (or change) anything. (EDITORS Note: Good job probably 
)
So, progress (thank you all), but still not quite there yet.
what are the permissions of /etc/wpa_supplicant/wpa_supplicant.conf?
i.e. what’s the result of
ls -l /etc/wpa_supplicant/wpa_supplicant.conf
Last login: Thu Aug 27 09:20:24 2020 from 192.168.2.30
pi@emonpi : ~ $ ls -l /etc/wpa_supplicant/wpa_supplicant.conf
-rw------- 1 root root 219 Aug 27 09:16 /etc/wpa_supplicant/wpa_supplicant.conf
pi@emonpi : **~ $
Well I suppose that setup_model.php is run as the pi user, so it won’t be able to read that, as it says. wpa_supplicant.conf is -rw-r–r-- 1 root root on my emonBase so I suppose you need to add the extra read permissions. i.e.
sudo chmod go+r /etc/wpa_supplicant/wpa_supplicant.conf
I don’t understand why it was -rw------- to begin with though. How was it created?
edit: I just looked at a pi zero i fairly recently set up with buster and wpa_supplicant.conf is root-only access on there too (there’s no emoncms on that m/c) so perhaps there’s some conflict between raspbian defaults and emoncms expectations? Maybe @TrystanLea would know?
Yeah those 2 lines have been an issue for quite sometime, unless you are running a Pi3. But I believe on the latest image @TrystanLea has now moved back to using the default setup (allowing the Pi to set these) which caters equally for all Pi’s.
What I believe is happening (and this is true and tested on the pre-emonscript images so may have carried over) is that your wpa_supplicant file in the boot directory is overwriting the OEM’s (modified permissions) file at start up as it is designed to in the OS image, then the OEM stuff (emoncms?) isn’t able to read/write as needed.
This has been addressed in previous images by loading the image to a sdcard then putting it in a Pi with Ethernet so that you can modify the location and symlink the OEM copy and then you can modify the wpa_supplicant file at will on a PC or via ssh or indeed still use the emoncms setup.
See Wifi config on Pi Zero using emonSD - #4 by pb66 although the rpi-rw is no longer needed and I think the source location of the OEM file has maybe changed to.
Brian or Trystan may be able to advise more on the current image, I have to say I thought this was going to be implemented on the emonScripts images TO enable the use of Pi Zero’s without any additional difficulties. Perhaps that was missed or not working quite right? What files do you have in the boot folder?
ls -la /boot
anything there wifi related that isn’t the wpa_supplicant file?
What is odd is that this has just worked for me (adding in the wpa file) in the recent past.
Thanks all - very interesting. In case it is of help / use, herewith the result of ls -la /boot
pi@emonpi : ~ $ ls -la /boot
total 52574
drwxr-xr-x 4 root root 4096 Jan 1 1970 .
drwxr-xr-x 21 root root 4096 Oct 17 2019 …
-rwxr-xr-x 1 root root 23966 Oct 17 2019 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 24229 Oct 17 2019 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 23747 Oct 17 2019 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 23671 Oct 17 2019 bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root 24407 Oct 17 2019 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root 25293 Oct 17 2019 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 25422 Oct 17 2019 bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 26463 Oct 17 2019 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 27082 Oct 17 2019 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 25277 Oct 17 2019 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 40559 Oct 17 2019 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 52296 Oct 17 2019 bootcode.bin
-rwxr-xr-x 1 root root 98 Aug 27 09:12 cmdline.txt
-rwxr-xr-x 1 root root 4096 Aug 27 09:34 ._config.txt
-rwxr-xr-x 1 root root 1821 Aug 27 09:15 config.txt
-rwxr-xr-x 1 root root 18693 Oct 17 2019 COPYING.linux
-rwxr-xr-x 1 root root 0 Oct 17 2019 emonSD-17Oct19
-rwxr-xr-x 1 root root 0 Jan 1 1980 emonsdinit
-rwxr-xr-x 1 root root 3073 Oct 17 2019 fixup4cd.dat
-rwxr-xr-x 1 root root 6167 Oct 17 2019 fixup4.dat
-rwxr-xr-x 1 root root 9247 Oct 17 2019 fixup4db.dat
-rwxr-xr-x 1 root root 9249 Oct 17 2019 fixup4x.dat
-rwxr-xr-x 1 root root 2657 Oct 17 2019 fixup_cd.dat
-rwxr-xr-x 1 root root 6736 Oct 17 2019 fixup.dat
-rwxr-xr-x 1 root root 9808 Oct 17 2019 fixup_db.dat
-rwxr-xr-x 1 root root 9810 Oct 17 2019 fixup_x.dat
-rwxr-xr-x 1 root root 145 Sep 26 2019 issue.txt
-rwxr-xr-x 1 root root 5310624 Oct 17 2019 kernel7.img
-rwxr-xr-x 1 root root 5628040 Oct 17 2019 kernel7l.img
-rwxr-xr-x 1 root root 13230592 Oct 17 2019 kernel8.img
-rwxr-xr-x 1 root root 5029176 Oct 17 2019 kernel.img
-rwxr-xr-x 1 root root 1494 Oct 17 2019 LICENCE.broadcom
drwxr-xr-x 2 root root 15872 Oct 17 2019 overlays
drwxr-xr-x 4 root root 512 Aug 26 15:31 .Spotlight-V100
-rwxr-xr-x 1 root root 4096 Aug 26 15:34 ._ssh.txt
-rwxr-xr-x 1 root root 770816 Oct 17 2019 start4cd.elf
-rwxr-xr-x 1 root root 4733128 Oct 17 2019 start4db.elf
-rwxr-xr-x 1 root root 2769540 Oct 17 2019 start4.elf
-rwxr-xr-x 1 root root 3683816 Oct 17 2019 start4x.elf
-rwxr-xr-x 1 root root 685668 Oct 17 2019 start_cd.elf
-rwxr-xr-x 1 root root 4854728 Oct 17 2019 start_db.elf
-rwxr-xr-x 1 root root 2877988 Oct 17 2019 start.elf
-rwxr-xr-x 1 root root 3792232 Oct 17 2019 start_x.elf
-rwxr-xr-x 1 root root 4096 Aug 26 15:34 ._wpa_supplicant.conf
pi@emonpi : ~ $
Would it still be a good idea to run this command ?
sudo chmod go+r /etc/wpa_supplicant/wpa_supplicant.conf
Why would you expect to find anything wpa_supplicant-related in /boot?
I would of expected putting a wpa_supplicant file in /boot “to work” too, the only reason it didn’t work on earlier images was that they booted in RO mode so the OS couldn’t over write the existing file with the one found in /boot. Although I would expect issues with the OEM WiFi setup due to permission issues, but the wifi should connect ok even if the wifi setup page isn’t able to modify it moving forward.
I don’t see anything there that looks WiFi related, other than your " ._wpa_supplicant.conf" file.
-
Because that is where you are supposed to put it if you want the OS to use a preset wpa_supplicant from the next boot.
-
Because that is/was “the fix” and the best way to ensure easy access to the wifi settings when there is no Ethernet to get around being “locked out” due to a network change of SSID or PSK, you can just whip out the SD card and edit any text file in the /boot partition from any OS, it doesn’t need to be mounted as a Linux file-system.
By putting the wpa_supplicant.conf file on the boot partition under any other name, strictly NOT “wpa_supplicant.conf” it will always be accessible and will not trigger an over write at boot time.
1 Like
Numpty question: JFTAOD, and I don’t even know if it matters, but when I uploaded the wpa_supplicant.conf file to the SD card it was called just that … ie: wpa.suplicant.conf ; not sure why it now says _wpa_supplicant.conf . Or does this happen as part of the overwrite during boot?
The wpa_supplicant.conf file that gets used is the one in /etc/wpa_supplicant/. The one with the same name in /boot/ is used at first boot time to set that one up if you need wireless to work from first boot, just the same as the empty ssh file in /boot.
See the documentation at Raspberry Pi Documentation - Configuration and linked documents.
It seems like emon… has some kind of grossly bodged arrangements on top, but I know nothing about them.
Correct, I don’t need to look at the documentation, I’ve been using these for years and fully understand how they work.
The emonSD image does have “other routes” to editing the wpa_supplicant.conf and I’m not able to comment on the intricacies of the current setup, but have simply highlighted the necessary “Pi zero” fix for previous emonSD images. It’s a fix that resolved all the previous hurdles (No Ethernet, emon “pi” user access for the wifi module plus manual sdcard access for when there is no Ethernet and the wifi creds need changing) that (I believe) would still work with the current image.
I was using this method way before it was needed for the emonSD images as it was more convenient for several reasons, like taking a demo unit from site to site and not needing to hook up Ethernet to get on the client’s wifi etc. Martin Harizanoff (original RFM2Pi developer) also used the same approach.
1 Like
Wild accusation. Can you support that with evidence (other than hearsay)?
OK - a bit more progress. I can now access the Pi Zero through both ssh and via a browser. I have the emoncms splash screen, asking for a Username & Password (to log in), or to Register.
Do I want to register with a new Username etc? That seems counterintuitive (as I want this to be a daughter / slave to my emonPi & it’s account etc). Or do I create a new User, and then somehow connect the two later?
TIA
If this is just a slave device to a central master then it might be useful to Ser up a user just to be able to edit emonhub.conf, perform updates, check admin stats etc via the web GUI. Just because you create a user, doesn’t mean you must collect/save data, although many would argue a redundant copy of the data might one day be useful if you have a major issue and lose data.
Thanks @pb66 ; I have now set it up with a new username etc, and have successfully run a Full Update within the Pi Zero’s Emoncms > Admin.
This next question is so embarrassingly basic, but how do I now set the emonTx that is hard wired to the Zero to talk to the main emonPi? I have two unknown Inputs within the emonPi’s emoncms, but I am fairly sure they are rogue and shouldn’t be there (& in the past I have just ignored them).
Maybe I just add a copy/duplicated/ammended section within the emonPi’s emonhub, giving it a new Node No, such as
[[7]]. **CHANGE THIS 7 TO AN UNUSED NUMBER, SUCH AS 50**
nodename = emontx4 **CHANGE THIS TO A NEW NAME, SUCH AS emontx6**
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units = W,W,W,W,V,C,C,C,C,C,C,p
But then how to get the emonTx / Pi Zero to talk to the emonPi?
No such thing as a stupid question (unless you have been told the answer before).
Did you use miniterm to set the serial to be on?
Did you set up an interfacer for the serial data? If not it is in the thread.
Are you going to use the emoncms on the PiZ at all? If not, in emonhub config, just point the MQTT interfacer to the main emoncms host IP.
Set the base topic to be emon/TX2/ or what ever so it loads the values into a node called TX2.
Just leave it as emon/.
I’m running a modified MQTT interfacer (PR submitted ages ago) so I cannot be absolutely certain the config parameters are correct. If not you will see errors in the logs.
1 Like
Note - I don’t think it affects you, but you can’t transmit a NodeID greater than 30 from the emonTx itself. Once it’s past the radio hop (that’s a JeeLib limitation), the choice is open up to 255 (I think).
[Edit] Node 50 would come out as Node 18 ( = 50 & 31 - the bit-wise AND) ]
1 Like
Your options are quite similar to when you were first setting up these with the emonESP, you can choose MQTT and/or HTTP, either sends direct to any emoncms instances of your choice. The main difference is that you can have as many target emoncms’s as you wish because you are using emonhub at the source end and that emonhub will buffer the data where as the emonESP couldn’t. This is of great help if you need to take the server (master) device offline for any reason and/or you have LAN outages eg router update or power interruptions etc. However, only the buffered HTTP data is of any use since the MQTT data is not (currently) timestamped in emonhub, it gets timestamped on arrival at emoncms, not much use for data acquired an hour ago and only just being sent due to a network issue. I would therefore always recommend using HTTP for any data being posted remotely ie any dependence on outside HW use HTTP only use MQTT for posting data on the same machine (if you must).
There will be no need to make any changes at the master emonhub.conf as the data is going direct from the slave emonhub to the master emoncms.
1 Like