So the issue you're probably running into there is that unlicensed radio spectrum is noisy. There's lots of stuff which transmits there, especially cheap wireless electronics like wireless doorbell ringers, wireless LED controllers, and this "power cost" monitor you're looking at. Are you sure you're not just swamped in noise? The receiver you linked to automatically scales so that noise will look like a signal. What comes out when the power monitor isn't connected? If it still looks like the same gibberish you've been getting, there's your problem.
You'll notice the massive number of complaints under that receiver from people who say "I can't get it to connect!" or "it gives garbage data!" and a whole bunch more giving advice on how to fix it. Likely the device you're trying to read has devised a similar scheme to properly encode its data.
For actually trying to "reverse engineer" the protocol, this is normally boring and slow but methodical and logical.
Start by simply taking the receiver you have and hooking it up to something like an oscilloscope in one shot mode and then hook up the receiver that came with your monitor. Then when the encoded packet comes from the cost monitor, save the waveform from your oscilloscope and what it corresponded to from the software output. Then when the next packet comes through, compare what changed in the waveform to what data you received. Slowly, you should be able to figure out what's going on.
In general, the reason you don't see too many amateur reverse engineering jobs is because there's a lot of intuition involved with reverse engineering these things. For example: you'll probably see that even with a single change in data (i.e. a new packet comes with only a change in temperature by 1 degree) there may be multiple changes in the packet. This could be from a checksum packet, but how was it formed? Is it a CRC16? Or simply a sum of all the bits in the packet?
A tool which might help would be a cheap logic analyzer.
Good luck! I hope that helps.