ESP8266 Community Forum

- Sun Feb 22, 2015 7:41 pm #10466 Hi Community, In order to operate an ecosystem of these ESP8266-based sensors at customer sites across the internet (as is presumably the intention for any IoT business), we need to be able remotely manage them, ideally we'd have access to the lua console over IP ( ala the telnet server in the nodemcu examples area), or better, over some protocol that passes through firewalls like mqtt. Any work or progress in this area? With this we could even be able to perform firmware updates remotely in future.

I use the ESPlorer IDE right now over serial, but it would be lovely if I could manage a remote ESP over IP with it and not be tethered to it by usb. telnet is a bit low-level to manage files etc

I came to the ESP8266 world having used spark.io which has nice web-based IDE and cloud API and management features. Hope nodeMCU can enable ESP8266 with these abilities to make it useable in real-world products...

Thanks

- Sun Feb 22, 2015 11:00 pm #10481 I am working on an IDE and console as the primary example for my lhttpd port. When it's done, you should be able to edit files, upload, compile, and run scripts all from a browser. Follow my progress in the Script Examples forum.

- Mon Feb 23, 2015 1:17 pm #10533 Interesting thanks. But these https based IDEs are only good from the local lan (or through a firewall with port-forwards)? we really need a proper cloud mechanism. couldn't mqtt be used a s a 2-way message transport with something like the telnet server example? its beyond my coding ability for sure...

- Mon Feb 23, 2015 2:15 pm #10539 You basically have two options, regardless of the protocol:

1. The ESP is a server. it is always on and handles requests as they are submitted, but requires firewall port forwards to reach from outside.

2. The ESP is a client. It cannot receive requests but asks another server if there are any outstanding requests. The server responds with any messages that are in that devices queue. In order to simulate real-time connectivity, the device must poll the network for new requests often, but that translates to higher cost on your cloud server.

So what are you actually trying to achieve? It will be much cheaper to implement a software update that polls a few times a day than a full pub/sub implementation that polls fast enough to simulate an interactive session.