I had a very similar issue, and managed to resolve it by following the quoted process found in the below link (please note I have a ESP8266-12E & it worked for me but do not guarantee it is the solution for all).:

https://github.com/esp8266/Arduino/issues/95#issuecomment-96399149

*** ROOT ISSUE - ESPTool.exe is NOT correctly erasing flash, allows module to get "borked" and is then "unborkable".
Above wall of text can be summarized as "sometimes on windows modules get to a state where uploads stop working", and many people suggest many different hardware-related fixes. They didn't work for me, and simply grabbing the esptool.py script and running:
F:\Users\timm\Documents\Arduino\PythonESPTool>python esptool.py --port COM5 --baud 76800 erase_flash
put the module back into an uploadable state.
Manually asking esptool.exe to erase the module did not work.... so esptool.exe as packaged here has a bug wrt erasing that esptool.py doesn't.

So - for all other frustrated windows users, if you bork your module and it stops working, do the following until this bug is fixed:

install Python2.7 (google for instructions)
download esptool.py from this git distro into a local directory (hope this link keeps working - https://github.com/themadinventor/esptool, I could not find in this GIT repo)
open a command window in the same directory and run "python esptool.py --port COM5 --baud 76800 erase_flash"
use your IDE to download your prev sketch, should now work again.
I'm going to try to diddle the platform.txt file to use this instead of the esptool.exe, if it is easy I'll report back.
This may be hard to reproduce, if I find a sketch that consistently breaks esptool.exe I will share, but please comment IF this approach helps you out of a "stuck" module so the smart guys (Ivan, looking at you) can prioritize and look into whether it's worth fixing/replacing esptool.exe.

Quick thought did you factory reset the max! devices before trying to pair? I found mine wouldn't work until they had been reset due to the pairing with the cube.

Sorry on the road ATM, but will look when i get home. Here is some pics of my wiring I have on my phone in case that is some use.

it should be families select 4 I believe, did you go into the max.conf and uncomment all the lines under ti cc1101 module? you may need to set gpio to 25 (not 23) and don't uncomment the the additional section. Reboot, then you should see 4 max! when "sudo homegear -r", "ls"

I believe I used this one: [https://forum.homegear.eu/t/CC1101-no-physical-device-found/921/2]

@Stuart-Middleton attached is an example of the items that get loaded when connected to openhab2 via homegear and the homematic binding.

@Stuart-Middleton Although I mentioned my difficulties, I would suggest that you at least have a look at homegear and openhab (or the openhabian bundle to make it easier) as it does give great access to the devices and opens up very easy use of MQTT.

FYI, I bought a CC1101 connected it up to an RPI, setup openhab, homegear, the homeatic binding, and within minutes I had all of the devices listed and complete control over them all. Well I can say that is where it has ended, I am struggling to either find pre-written logic or writing my own to control everything. The issue isn't so much writing it as such, but choosing which system should host it. This dilemma exists, as I have everything else in my vera, I am getting into node-red, and now also have openhab/homegear in the loop, I don't want to fracture my set up too much from a control interface point. I like the idea of keeping the WAF where it is, so I will probably still need to have some sort of control via the vera and therefore one of the apps that the other half is still happy with.

I'm having a small issue, and I can't see why. I had to reload and now every time I try to load it I get the following before it terminates. This is from fresh install.

Traceback (most recent call last):
File "main.py", line 204, in <module>
Main()
File "main.py", line 96, in init
self.doLoop()
File "main.py", line 111, in doLoop
buttonCheckHeat("main")
File "/home/pi/PiHeating/heatinggpio.py", line 173, in buttonCheckHeat
MaxInterface().checkHeat(0)
File "/home/pi/PiHeating/max.py", line 56, in checkHeat
self.switchHeat()
File "/home/pi/PiHeating/max.py", line 486, in switchHeat
roomTemps = CreateUIPage().createRooms()
File "/home/pi/PiHeating/webui.py", line 224, in createRooms
actualTemp, roomOpen, roomMode)
UnboundLocalError: local variable 'roomOpen' referenced before assignment

I have to say using Vera and the boiler switch attached to that is a great solution, if I could just get past one problem. I wonder if anyone else is experiencing this, but I find the time taken for the valves to respond to the temperature changes is a little slow. Lets say I set the required temperature to 19c most rooms jump to 20/21 before the valves close enough to actually prevent further heating to the room.

My thoughts at the moment are to see if I can somehow directly communicate with the valves or maybe set offsets for each temp on the valves so they read a couple of degrees high.

Anyone have any thoughts?

Just saw the explanation txt appear, thank you so much, it means I can double check what I set was correct.
Funnily I noticed as it just appeared when I was searching the code to work out a couple of bits.