Here we can all chat about fixing the AT+ command structure and the associated responses.

User avatar
By igrr
#1080 Okay, pushed my work-in-progress code here: https://github.com/igrr/atproto
I'll finish the argument parsing stuff for extended command syntax today, it will then be possible to implement ESP-specific IP/WiFi commands.

Sorry, haven't spent as much time on this as I hoped in the past two days, been trying to get my new Logic Pro 8 cleared through the customs :evil:
Ivan.
User avatar
By igrr
#1416 A quick update on the AT protocol implementation: basic commands now work on esp8266.
I got rid of driver/uart.c, so now the only dependency on the old AT protocol example is uart_registers.h.
Next up: move input handling into a separate task, implement TCP commands.
Plus, I also plan to add an MQTT implementation controllable via AT commands, might be useful to take some load from arduionos out there.
User avatar
By longinus
#1445
igrr wrote:Plus, I also plan to add an MQTT implementation controllable via AT commands, might be useful to take some load from arduionos out there.


I'm REALLY interested in this! My home automation network runs basically all on MQTT.
So as I'm playing with the ESP modules hooked to sensors/etc, I have to use a UDP to MQTT bridge in my server. Works fine, but I would love to cut the UDP-Middleman. Where you planning on making the modules capable of both sending an receiving MQTT messages?

If you need any help testing this stuff, I would definitely help out!
User avatar
By igrr
#1457 Actually you are more than welcome to share any ideas regarding MQTT API. E.g. what AT commands should we implement, what would be the arguments and the return values. Getting the API right is more difficult than the actual implementation, which is well demonstrated by the lousy TCP/UDP API in the original AT firmware.

Proposals on the TCP/UDP commands and the way they should work are also welcome, btw. Especially regarding ways to handle data transfer for multiple concurrent sessions.