This is the Base64-encoded full LoRaWAN packet, including your encrypted application payload. Using an online decoder you can see that this matches a hexadecimal representation of 0x40B6140126005701013749AB0B88494D, which is what you’ll see in the gateway’s Traffic page in TTN Console. In the online decoder you’ll also see that the encrypted application payload is 0x3749AB when displayed as hexadecimal.
To decrypt that application payload, you’ll need the secret AppSKey, which is either hardcoded (for ABP devices) or has been sent during the Join Accept (for OTAA; which incidentally is supported by some single-channel test gateways, as some do support downlinks, though then your node might still try to use a different frequency if the first OTAA Join Request does not succeed, like for LMiC).
As TTN knows those secrets, TTN Console will show the decrypted application payload in the Data page of your application. No thinking required there.
If you need help decoding the application payload, then give us some example fake sensor values and their matching decrypted application payload, and a link to the documentation of that LoraCode format (probably this). (I won’t be spending time to help you on that though; see below.)
Also, to make the test gateway mimic a sensor, I guess the following from the documentation needs to be enabled, using the proper values from a dummy device in TTN Console:
GATEWAYNODE 1;
#if GATEWAYNODE==1
#define _DEVADDR { 0x26, 0x01, 0x15, 0x3D }
#define _APPSKEY { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
#define _NWKSKEY { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
#define _SENSOR_INTERVAL 300
#endif
While the online decoder accepts 00000000000000000000000000000000 for the secrets, obviously you’ll need to change those to match some device in TTN Console, to see any data there. Note that the online decoder now shows DevAddr = 260114B6 (which is in the non-encrypted LoRaWAN headers), and rejects the all-zeroes when validating the MIC, using the all-zeroes NwkSKey, so I guess you already made some changes there?
Or, you might actually see someone else’s true LoRaWAN packet?
Or, don’t waste your time on that at all? If you just want the temperature or air pressure around the WiFi-enabled ESP hardware, then you simply don’t need LoRaWAN at all.
I’d say, forget the fake LoRaWAN sensors. Instead add a single-channel test node to your setup, and put it at least a few meters from your gateway to truly dive into LoRaWAN.