ESP32- can you use a wifi connection to switch a GPIO pin using a button on the IOS app?

There is an ESP32 demo that will light an LED when a button is pressed on the IOS app. This uses BLE and works fine when I try it. I want to be able to do something similar but using WiFi- not BLE (range is so short).
The BLE demo uses GATT characteristics which would allow you to define different actions based upon different button presses. There doesn’t appear to be anything functionally the same as this for a WiFi connection.
Is this even possible? Looking over all the demos, I don’t see any with apps that contain buttons, or labels that communicate with the embedded board, using anything except BLE.
One of the things I’ve tried:
On my embedded Tab I connect a GPIO output pin to a cloud event
On my Application tab I connect a button to a cloud event
On the cloud tab, there are now two separate cloud events, which I wire together
Everything compiles/ downloads OK, but nothing happens. Not surprising, as I wouldn’t think you’d have to connect two cloud events together like that.

Thanks for any advice.


Yes, this is possible. On your app, connect your button (or toggle switch) to a cloud event. Then in the cloud tab, connect this to a cloud command with a boolean data type. On the embedded tab, connect that cloud command to your GPIO pin.

Cloud Events always go to the cloud, and Cloud Commands always come from the cloud. I’ve attached an example you can try. WiFi Cloud Command.atmo (15.6 KB)


Thanks Nick. I am presently working on feed back for the other thread which you responded to. I’ll try this next.

Thanks Nick. That worked fine- I’ll look at the project elements in detail, and I should be OK to go from there.
I’m much more familiar with writing in C++ using various WiFi/cloud libraries on various MCUs.
I’ve written for Circuit Cellar magazine for 20+ years and have an article out every 2 months. IoT is a popular topic right now, and I’ve been trying out various boards, software, cloud services. I’m a bit skeptical about platforms that “write the program for you” (from past experience with early Cypress PSoC’s version of this, as well as Atmels). In those cases, the manufacturer only had to worry about their own chips and compiler/IDE, and even then it was only a limited success, in my opinion. You fellows are going much further by embracing numerous MCUs, albeit in a more limited scope of Cloud-based apps only.So, I am interested to see how things go.
My forum questions were aimed at getting enough experience together to do up a modest hardware/software project, as that is the format of most of my articles.
Best regards

@Nick. Incidentally, that sample you sent me won’t work “out of the box” on a ESP32 DevkitC (which I have). This board doesn’t have an LED on IO13, (only a power LED) so it won’t light of course. Even if you know this, and put a 'scope on IO13, it won’t change, as the port mode is set to open drain, and there is no load on it without the LED. You have to use push-pull output mode for it to show up on a 'scope. I notice other ESP32 demos also assume there is an LED on IO13, so they won’t work either on ESP32 DevkitC. A note to this affect might be handy in the ESP32 guide/ESP32 DevkitC section.
Also, I tried to expand upon your demo to have two switches controlling 2 GPIOs. The WiFi Cloud Command_BM1.atmo (25.6 KB)
Basically, i’m just adding one more of each element, configured for the second switch and GPIO pin.
This compiles with no visible errors, and downloads OK. But when I go to add a device, I have to disconnect/connect the USB cable before it shows up at all. And then it won’t provision it- it comes up with “an error occurred while provisioning the device” on the bottom status line.
If I look at the ESP32 UART debug output, I am seeing a lot of lines indicating it is being configured as a BLE device and is starting advertising. This makes no sense to me on a WiFi project, as I know the ESP32 can’t do both at once.
I CAN re-provision the board if I go back to your original WiFi Cloud comnand .atmo file, and start all over again.
Obviously there is a lot more to this platform than what I have figured out so far. Sorry to be a bother.


I will look into this for you this week. I’ve seen some GPIOs cause issues/conflicts with BLE…

We don’t use BLE and WiFi at the same time. When you’re connected over BLE, WIFI is disabled and vice versa.


Attached is the bootup serial debug file I get with the program
discussed in my latest response (via forum). I couldn’t upload a
text file from the forum itself.

(Attachment ESP32_debug_output.odt is missing)

Hi Nick:
Sorry, I think I confused things by putting two topics in one post. The first section was only to note that the ESP32 demo programs that light an LED won’t work on all ESP32 boards, since they don’t all have an LED on IO13 (or have any GPIO-driven LED on the DevKitC that I have).
In the 2nd section, I was puzzled that the WiFi CLoud Command demo that you sent me worked fine with just 1 switch, but not with 2. I was using GPIO12 for the second “LED” output, but had nothing hooked to it (I just monitored it with a 'scope). I believe GPIO12 has some function in the bootstrap mode, but I have nothing hooked to it, so it can’t be affecting anything.
I switched my program to use GPIO14 instead, and nothing changed- it downloads the code OK, but is not discovered in the “Add device” function, so I can’t provision it. So, the GPIO# is not the problem, but the fact that I can’t provision it points to some problem in the code.
As far as BLE/WiFi are concerned, I was aware that the ESP32 won’t handle both at the same time. What troubled me is that a atmo program (WiFi Cloud command example using 2 switches) that strictly uses WiFi, would result in debug printouts at boot time that indicate that BLE is being activated.
However, since I can’t provision it, I can see in the long error readout that it can’t read the WifI configuration file, so it won’t connect to my WAP. Looks like it falls back to BLE, in this case.
( I sent the serial debug output by email to you, as forum rejects a text file in the upload menu)
I’m a complete novice regarding atmosphere, but it looks to me like you can’t invoke 2 instances of either (WiFi) cloud command or cloud event, since that is the only difference between the working demo program, and what I am trying.
I also wonder how the WiFi Cloud command demo, that you sent me, knows enough to use WiFi, as there is no WiFi connection element present. I guess that the lack of any BLE characteristic elements is the clue.
Thanks for your efforts on this.

Attached is the bootup serial debug file I get with the program
discussed in my latest response (via forum). I couldn’t upload a
text file from the forum itself. (5.31 KB)


I just spent a little time looking to this, and found a bug that affects projects with multiple cloud commands. There will be a fix included in the next release to remedy this.

If you’d like in the meantime, I can make a modification to your example so it uses one cloud command as a workaround…


Thanks Nick. i’m glad i’m not crazy… I don’t’ have a defined project in mind that needs this (just looking for article material as I noted in another post)
But. Let me guess at the workaround:

  1. Assign each IOS app switch a binary-weighted value.
  2. Add them up and use a cloud command to send the integer value
    On the imbedded side it gets more difficult I think
  3. Receive a cloud event as an integer.
  4. Use the function elements to AND that value with 1,2,4,8 etc.
  5. Set †he individual GPIO lines from the outputs of the various function elements.
    I haven’t thought it through critically yet, so this might not work. If you’ve already composed a workaround, I would be interested in getting the .atmo file.

My solution is similar. Combine the two toggle switches into one encoded cloud event.

0 -> turn GPIO1 off
1 -> turn GPIO1 on
2 -> turn GPIO2 off
3 -> turn GPIO2 on

You can use 4 comparison elements (or some function elements) to route the values accordingly.

Note that the “value” property of the Cloud Event on the app side is pure javascript, so you can do something like value ? 1 : 0 for toggle switch 1 and value ? 2 : 3 for toggle switch 2. I haven’t tried it yet, but it seems like it would do the trick.

There will be a fix for this issue in the next release. Let me know if you run into any more problems.


Hi Nick: Your solution works- I edited my program to match and it works fine. I didn’t know about the Javascript on the App side of things, and this makes it easier to do.
I’ll be interested to see if you fellows can solve the AVR-IoT WG problem that brought up in another thread. I wrote an article about this board when it first came out. At the time I couldn’t follow Atmel’s demo code, even though I write a lot of my own C code to do similar things on ESP32 etc.
Part of my motivation for looking into Atmosphere, was to see if I could do something useful with the AVR-IoT WG board (using Atmosphere) and write a follow-up to the orig. article.

Hi Nick- I spoke too soon. My program works fine on the PC-emulated App view. However, it does nothing when I try it out from the atmosphere app on my iPad. The original 1 button demo program worked on both the PC and the iPad. Also, I notice the Bluetooth icon in the app view flashes a few times at start up, then stays lit. I don’t see why BLE is being invoked for this program though.
I even tried deleting my program/device from the atmosphere app on my iPad, and adding a device again from there. That didn’t work either. I don’t think I should have had to do this in the first place, however.
Nothing is coming easy!!

It won’t work seamlessly with the ESP32, since it can’t do WIFI And BLE at the same time. When BLE is connected, it cannot use the WiFi to check for new cloud commands. On the app view in your PC web browser, it works since that’s not doing any BLE connection.


Why is it using BLE in the first place? I’m not calling for it. The iPad app should be able to monitor the cloud for commands via WiFi alone. There is a separate ESP32 demo program that works via BLE.
I am certainly missing something here.

When you open up the app view on your iPad, it automatically connects to the ESP32 over BLE. We have a feature in our queue to implement that will allow users to override this, which would be useful in situations like yours.


Thanks Nick. That explains the Bluetooth icon blinking. I think that the developer should have the choice of picking WiFi or BLE - it seems to follow that if I put BLE elements on the workspace, I’ll get BLE, if I use WiFi elements I’ll get WiFi. Maybe I missed something in Atmosphere’s esp32 guide, but this default behaviour seems counterintuitive to me.
Also, no matter how wrong my element choice/interconnect wiring might be, I have never seen an Atmosphere compile error.In conventional C coding, most errors would certainly be flagged - so you don’t waste time downloading and testing something that certainly won’t work.