2

I have an ESP32 recording values from an ADC at a rate of 1 sample/second.

I need the ESP32 to send new values to a device (let's say a smartphone app for now, eventually via a server), as they are recorder on the ADC.

I've been wondering which is the best way to go about this :

  • Option 1: [what I've got set up now] The iOS app sens a request for a new value every second. The ESP32 then sends a response, which contains an array of every value recorded since the last request. Problem: This seems costly and very... 'lazy' (can't word it better, it just doesn't feel like a good approach)

  • Option 2: the iOS app sends a request to 'subscribe' for changes in the ESP's ADC. Is this considered good practice ? which is the best way to go about this ? Google search with keywprds 'ESP32' 'http' 'stream' 'ADC' yielded results with audio and video applications

  • Option 3: ESP POSTs new values to server. iOS app then retrives them by requesting them from server OR server pushes latest values to app.

I've been researching this for the past two days, unsuccessfully. I'm not very experienced with this, which means I don't know the right terms & keywords to research this without asking for a lead...

Improve this question
2
  • 1
    The main point is: What is this for? Do you really need all values or can you lose some samples? Will you have wifi for the ESP in option 3? Do you have any more infrastructure?
    – Marco Tulio Souza
    Commented Aug 31, 2019 at 23:26
  • 1
    Ideally, I'd get all values but can afford to lose some. The ESP should be connected to wifi all the time but it can happen that the connection is lost. Insfrastructure limited to ESP and phone app on local network for now, but can and probably will be extented to incluse a server hosted on gcloud
    – kmn
    Commented Sep 1, 2019 at 20:49

1 Answer 1

Reset to default
5

From what you're asking, I believe you should use MQTT protocol, it seems to fit your architecture. You'll need to have a mqtt server/broker that will receive the data from the device and then send them to the app.

Simply put in MQTT protocol you'd have "topics" that the client (your app) will subscribe to. The device will push it's data to the topic and the subscriber will receive the new data on a notification.

For instance :

you'll subscribe to the topic at your_broker.com/mqtt/deviceA/temperature the device A will push it's data to the broker (whenever it can), and then the broker will send the new data (if possible) to all client that have subscribed to the topic deviceA/temperature.

See : http://mqtt.org/ and https://github.com/espressif/esp-mqtt

You can try to build another custom architecture but this one is pretty good and pretty lightweight. Plus it's very easy to deploy and to scale.

Improve this answer
3
  • I disagree. The infra he has is the iOS app and an ESP. Single user, single MCU. No need for MQTT here. One can simply run a webserver on the ESP and have those values ready for a GET request from the phone. Easy and fast. No need to kill mosquitoes (lol) with a bazooka
    – Marco Tulio Souza
    Commented Sep 3, 2019 at 16:51
  • 1
    I agree to your disagreement (lol), OP says in comment "Insfrastructure limited to ESP and phone app on local network for now, but can and probably will be extented to include a server hosted on gcloud" which made me think that the polling stuff is mostly for development purpose then he'd like to scale.
    – YCN-
    Commented Sep 4, 2019 at 9:26
  • I do believe that you have to thing about scaling whenever you do anything, therefore, I only disagree with you in this specific case. For 1-10 devices I think a HTTP server with the ESP will do fine, but for more devices, MQTT is indeed the best fit solution.
    – Marco Tulio Souza
    Commented Sep 4, 2019 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.