The other way of assigning at the AP a fixed IP based on the unique MAC each esp chip has is also another work around. It was more obvious in my case to have the PIC MCU send a couple of bytes describing what it can do and the current state of leds and switches. It isn't the best of solutions...the server normally is the slave and the esp the client is master...here the client reports its data to the server and obeys commands sent from the server. The server allows an android to connect and will relay data about device (PIC MCU) states to it and also relay commands.
Using the esp as a server didn't look like a good fit since that would mean multiple 10 or more servers each with their own switches leds to control.
The human readable and async AT commands have been a real pain with several hundred lines of code and several timers just to turn the AT into a bullet proof interface. As soon as a synchronous interface is working for the esp8266 ;the AT commands will be in the rear view mirror. Further once the esp8266 MCU tool chain is working cutting out the AT stuff at the source and replacing it with a synchronous interface with robust commands that are Acked or Nacked by any attached CPU.