I working with several arduino board and now I need to control them via a web interface.

Via web interface I want to activate GPIO.

I have two ideas:

  1. Each arduino acts as web server and I can control the GPIO via the Arduino web page. Basically one browser tab for each arduino.
  2. Use the MQTT protocol to exchange message with the arduino boards. Furthermore I think to use an raspberry as web server and as MQTT broker. Each arduino board is subscribed to a specific topic and through a web page, hosted on the raspberry, I can control the Arduino GPIOs.

The first solution I very quicly and simple.

Regarding the second option, I don't know how to send MQTT message via a web page. I read that I need to use Websocket. Is it right? Need I to write code in Javascript or what?

My second question is: Can the MQTT broker manage both MQTT and MQTT over Websocket at the same time? Otherwise I need to use the Websocket also on Arduino.

Another option is to built a Python script with GUI that allow to send MQTT messages to Arduino.

Is there a best way?

Thanks for the help!

1 Answer 1


What you've written all seems reasonable to me.

MQTT traditionally runs over TCP1, but your browser does not allow webpages to open a raw TCP socket. There are proposals to allow that, but I doubt they'll be implemented any time soon. So, your browser can't connect to a MQTT broker only supporting TCP connections.

The solution is, as you've identified, to use a WebSocket—these are supported by the browser and so some JavaScript code can be used to connect to an MQTT broker through a web page. HiveMQ have an example you can play with, or you can try a library such as MQTT.js which supports WebSocket communication with an MQTT broker.

Most brokers—and all I'm aware of—won't care about whether a client is a WebSocket or TCP client. You can happily connect both to one broker, and you can find instructions on how to configure a Mosquitto broker on Stack Overflow2.

With regards to a best way... it's up to you. If you are happy with JavaScript, then there's no problem using that. If Python's easier, do that (you wouldn't need to set up WebSockets support that way). You could even just use pre-built client software if you didn't care about the UI too much.

1 MQTT 3.1.1 does allow for TLS or WebSocket connections also; see section 4.2 of the specification. There is a variant, MQTT-SN, where the requirement for TCP is relaxed. Either way, you're probably not worried about MQTT-SN for your use case.

2 Note that on Windows, the Mosquitto build does not have WebSocket support enabled. You will need to build Mosquitto yourself if you want to use it on Windows. Alternatively, you could try a different broker that doesn't restrict you in this way.

  • Thanks Aurora0001 for yor reply! My idea is to build a web page with JS code that sends MQTT messages to the broker (Raspberrry Pi). My only concern was the coexistence of TCP and Web Secket MQTT connection. What do you think about Mosquitto Broker? I can install Mosquitto Broker on the raspberry and run it like a service.
    – Federico
    Commented Jun 20, 2018 at 10:24
  • 1
    As I say, TCP and WebSockets can happily co-exist. If you go down the WebSockets route, it really doesn't matter what your web server is (even a static file host would work) as it's the client-side JS that matters. If you did the MQTT connection through the Pi and then wanted to make a web page to control that (i.e. not websockets), Python would probably be easier to use as it's got many more web frameworks than C.
    – Aurora0001
    Commented Jun 20, 2018 at 10:28
  • My idea is to use a raspberry as MQTT Broker. The webpage open a websocket to publish messages on a specific topic. Finally the messages as routed by the broker server ( in my case an Raspberry)
    – Federico
    Commented Jun 20, 2018 at 12:16

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.