V 2.2.0 incompatibility

AndreiC
Posts: 10
Joined: Sat May 27, 2017 7:04 am

V 2.2.0 incompatibility

Postby AndreiC » Thu Mar 29, 2018 1:27 am

Version 2.2.0 introduced the +DIST_STA_IP message being sent by the module. There isn't any documentation for this message, so I don't know when I can expect to receive it.

Will the ESP8266 AT Command Examples document be updated to include the messages introduced in 2.2.0?

Andrei


disegni
Posts: 1
Joined: Thu May 10, 2018 9:01 pm

Re: V 2.2.0 incompatibility

Postby disegni » Thu May 10, 2018 9:08 pm

Is it possible to disable the

+STA_CONNECTED:<sta_mac>
+DIST_STA_IP:<sta_mac>,<sta_ip>
+STA_DISCONNECTED:<sta_mac>

messages when clients are connecting to the AP? (I can't find a way in the AT command user guide)

Ideally, this could be done with the AT+SYSMSG set of commands, perhaps implementing another flag other than bits 0-1.

This would be very important for backward compatibility, which is now broken for me, unless I find a way to disable them, and it should serve as a warning about implementing new messages that aren't optional to enable.

Thank you.

AndreiC
Posts: 10
Joined: Sat May 27, 2017 7:04 am

Re: V 2.2.0 incompatibility

Postby AndreiC » Fri May 11, 2018 4:42 am

Yes, the messages are listed in the appendix. Now, can you give me an idea as to when they are generated and what they mean?

My original query was prompted by a whole lot of code falling on its face due to a change in the responses that are generated in V2.2.0. If you take the Arduino stance where you never inspect the messages coming from the module, and just power type commands at the module, 2.2.0 may actually work. But I am actually responding to what the module returns from my commands and the responses have changed, but the changes are not documented anywhere.

The alternatives are to laboriously inspect the SPI conversation, on an oscilloscope, to discover how the protocol works now and submit the findings here, asking for clarifications, and have the developers say "yes". Or I could let the developers save face and just ask for someone to document how the protocol works by way of updating an existing document. Nobody gets called out for messing up the protocol, nobody gets upset.

Her Majesty
Posts: 329
Joined: Mon Oct 27, 2014 11:09 am

Re: V 2.2.0 incompatibility

Postby Her Majesty » Tue Jun 05, 2018 2:50 pm

Just curious, why not just ignore those messages? Do not parse those new messages, will it still make troubles?

AndreiC
Posts: 10
Joined: Sat May 27, 2017 7:04 am

Re: V 2.2.0 incompatibility

Postby AndreiC » Wed Jun 06, 2018 12:16 am

How do you ignore a message? Well, first you have to accept whatever the module gives you, then recognize the message, then decide to ignore it.

You've accepted and recognized the message, what you do with it is reasonably simple, just throw it away.

Great, now, update your AT command set and there is a bunch of new messages. The documentation set does not tell you when to expect the new messages, nor gives you any indication if they are important or not.

Either way, you have to accept the messages, recognize them...wait...how can you recognize them if you don't know they are coming, what they look like, or if they are important.

I suppose I could arrange my code to ignore everything except +IPD messages, but now I'm throwing away all of the state information about my connection. Did the connection succeed or fail? Did I get my > prompt to send my message? Since I ignore responses, how will I know when the send has completed?

And why would the authors send out these messages if I should just ignore them? Don't they add any value?

Remember, we're talking processor to processor here. This isn't a toy that a human talks to using a terminal program. A program has to be configured to "ignore" messages, humans can just look, not understand, and ignore.

Who is online

Users browsing this forum: No registered users and 2 guests