Bluetooth 4 remote

It boils down to the guts inside this plastic enclosure and whether it's easily reprogrammable. Ideally, it needs to be NRF51/52 family with SWD. 

By the way, no need to withhold the source. We know where to find it: https://www.aliexpress.com/item/33055385661.html?spm=a2g0o.productlist.0.0.4551369fow1Q3l&algo_pvid=8ff74506-6c59-439d-a252-58fd08ee4b01&algo_expid=8ff74506-6c59-439d-a252-58fd08ee4b01-22&btsid=0bb0623915991889105157836e38ef&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

I think posting a link to facilitate a discussion would be fine. But seems like this forum has been open about people advertising and selling stuff as long as it's relevant to the main theme of the forum. No crime there at all.  

If it's actually using BLE 4.0, there is a very good chance it is NRF.  $4-5 is the retail price. When these things are produced in volume, the production cost can go below a dollar per unit.  

I can't tell from you images what it runs. It would help to post the picture of the actual chip.  If it's any of the nrf, it would be easy to reprogram via SWD but now I think of it this may not be necessary at all. I would just document the protocol and add support for it on the VESC nrf side. It would make little sense in my view to rip out all the guts of this device just to use it's plastic shell. Well, for one off DYI project it would be fine I guess.

If, however, SWD port can be easily accessed without effectively destroying the plastic enclosure, or, even better programmed without opening via DFU, that would make most sense. Otherwise, using the existing comm protocol will do the trick. It would be easy to add to the existing code on the vesc side.

I've had some good luck programming an NRF based watch (https://vesc-project.com/node/1814) to control vesc from the touchscreen, run motor detection, and getting telemetry data. I think it would have a great application for things like hydrofoils because it's water proof but will likely work well for skate boards and such. Making relevant data large print on the screen make it work for ebikes pretty good as well.

And initially, I was using NRF chip on my 20kw controller (https://vesc-project.com/node/1477) but I switched to esp32 as the it's 1/3 of the NRF cost and is a power house of performance and features. 2 core 240Mhz, wifi, 16Mb of flash memory, etc. I can process video stream on it if I want.

 As for the joystick, I would check what's being actually sensors there. Analog would be cool but digital would work to some degree as well. Depending on what the application is. Just mving the cursor, etc. It would be fine.

Can't be Beken chip if the other remote it BT 4.0 BLE. Beken is 3.0. 

Seems like there are programming pads there, so it can be reprogrammed. I can't see the SDK or some sample codes readily available for this chip but I haven't looked too deep. In any case, I think with this device and similar ones with obscure hardware, it would be just much less effort to document the protocol and add it to the VESC Bluetooth code. It would take a few lines of code versus cannibalizing the plastic enclosure, ripping and replacing the board. Not worth the trouble if the same can be achieved within the software. For a one off DYI project may be fine though.

Yes, the GATT protocol would be the same provided that it's implemented to the standard on this chip. In your first link, there is a table with keycodes that seem to be the protocol for this remote.

So you would just need process those codes when they are received and map them to whatever action is desired from VESC. I am still not clear whether the joystick is analog or digital. The keycodes suggest the output is digital even though the joystick may be connected to analog inputs on the chip.

That table is just the mapping of the functions for Android and iOS. Not a description of the protocol. I doubt it's sending a constant stream of data all the time, that would not be effecient. It's likely sending it when a button is pressed or a joystick is used. But you can't tell for sure with chinese programming. You would need to pair the device to a BT dongle connect to a terminal or to phone running a Bluetooth terminal to see what it is sending. Then document all the events at the byte level.  

nrf24 is older tech and still good for it's purpose. It has some advantages over BLE, I believe, mainly lower latency. But it's not Bluetooth 4/5. With that said, I'd go with NRF51/52 because BLE is the industry standard today which means it's compatible with so many devices including pretty much any phones, watches, etc. Benjamin's code would run pretty well even on NRF51 as it has pretty small fotprint, so if the lowwest cost is the priority, I'd go with 51. I've personnally used NRF52840 but I run my adapted Arduino style code that has other features. First I went with this chip because it had 1Mb of flash compare to 512kb in 52832 and, yes, having USB makes uploads simple. Either will work equally well though. It's mostly about the cost and future proofing where you would actually ever need extra memory and performance. 

Looks like a good strategy for a prototype. Once you figure out which module works for you best you can remove the other footprints. I liked NRF52840 a lot as you can do so much with so little memory but ended up going to esp32. I thought 4Mb default SPI flash size would give me more than I will ever need but quickly hit the limit because BLE and Wifi libraries alone took about 1.5Mb before you even start adding any of your code. Then 1/2 of flash needs to be reserved for OTA partition and you end up with somee meager 300-500kb that gets eaten up quickly as you start adding more libraries. Thankfully, 16Mb versions are readily available and the price is about the same as for 4Mb. I now have full files system, I can use OTA and I can load complete VESC images onto ESP32. It works great and the price of the chip is 1/2 of the NRF52840.   

Nope, I didn't port VESC code to esp32. It would be a huge undertaking porting it even to another STM32 chip. I am using esp32 as the communication module that talks to the STM32 via UART. Basically replacing NRF.

Exactly for the reason you specified, to be able to use OTA over WiFi. I can load the bin image to ESP32 and push it to VESC STM32 chip. For my purpose, OTA is very important because once thousands of controllers are deployed, there should be seamless way to fix bugs and add functionality seamlessly without requiring customers to use USB or even a phone app.

I would not call any chip good or bad choice per se, it depends on your goals. NRF is a great chip for the latest BLE functionality which is good but requires extra devices to make communication. ESP32 is two core has tons of performance and memory and wifi on top of it. Consumption is in fact high when it runs full speed but you can bring it down to as little as 2.5µA in hibernation mode. Lot's of flexibility to mange power consumption.