One way to allow those devices to communicate with each other is via a central server (which I already have available), but it would also be nice to allow devices to communicate directly to each other in an ad-hoc manner. For example, Amazon dash buttons can be used to run arbitrary scripts from a router using dnsmasq when they connect to their configured access point. With the Raspberry Pi running an AP and dnsmasq, the dash button can directly connect without having to go through the server first. However, having the RPi also connected to the WiFi allows for it to access the internet (say to upload logs of activity, or register it's services to a central IoT server on the LAN or WAN) without requiring me to have to script in tasks to bring the WiFi interface up and down to switch between AP/client modes. This would also mean it would always be available remotely.
One of the downsides of the RPi Zero W is that it doesn't have a wired ethernet interface, so having both a WiFi AP and Client mode running at the same time allows it to have LAN/WAN access, while still being able to directly connect with other devices. The added benefit is that since both interfaces are wireless, it can go almost anywhere within range of WiFi, without cable restrictions.
Finally, having the ability to route traffic through the RPi would mean they could potentially be set up in a daisy-chain manner to extend the range of available WiFi access.
x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
(... etc)
And a question do you know why ap0 doesn't show up in you iw dev command? It seems you are only changing the addr not the device name.With respect to your question, I didn't post a log from iw dev after a reboot, but ap0 does appear after reboot.
Before proofreading my post, I originally included output from iw dev at the end to show everything working, but realized output from ip addr was more useful, since it shows actual network addresses and up/down connectivity. I may just re-add that for clarity. Thanks!
Incidentally, the framework (headlessPi [3]) we use to run "apps" in the browser and configure the system is all open source and easy to configure for your own use.
[1] https://github.com/headlessPi/headlessPi-setup [2] https://mime.co.uk/products/mearm-pi/ [3] https://github.com/headlessPi/headlessPi
The idea is that if wifi is not configured or can't connect, then the Raspberry Pi would switch to AP mode. When you connect to the SSID, you would see a web page where you can configure your home wifi SSID and password, or choose a network from a list.
Does something like this already exist? I think it could be used in a lot of different projects, including RasPlex [1] and RetroPie [2]. I haven't looked at those projects for a while though, so maybe they already have that feature.
For client, the range seems really good, thought not nearly as good as something like a cell phone, probably by about half.
For AP mode, the uplink speeds from the device connected to the RPi seems to be almost completely uninhibited, while downlink is pretty bad. This is where the poor antenna comes into play, since the RPi can't broadcast its SSID very strongly, and really only works well within LOS of the device. From another room, download rates drop pretty low, to sub-5Mb.
It may not work very well for transmitting video or something, but it's certainly good enough for low-bandwidth applications.
I'm just now finding this when i'm about to hit the hay -- so I lack the cognition to go through it -- but i'd like something like this for a project of mine that involves a pi-zero-w that needs to maintain a connection with my cellphone while on the go -- and dump data when within range of a known AP.
While this seems to behave sanely, you may run into issues where your device will drop session with the RPi AP due to "no internet connection". Assuming you're running Android, your device may ask if you want to remain connected to that AP, or it might just disconnect due to lack of internet. That's entirely device-dependent, but there's nothing inherently making this not work based on my instructions. It just might take some extra work on the device-side to make sure it doesn't try to drop the connection.
I would love to know as well. I mentioned it somewhere, but during boot, there are a few cryptic Broadcom driver errors which a Google search turned up little to know info on. It's hard to say, but it seems like something in the system has to stabilize before everything works.
I need to have a fail-safe where one device will usually be connected to WiFi and other devices may not for a myriad of reasons.