I don’t think so. I don’t have an emonPi running at the moment (so no screenshot), but the received RSSI is the number in brackets at the end of the list of data bytes, or at the bottom of the Inputs page - unless your emonPi is so old that it has a RFM12B, not the RFM69CW (pictures for identification in ‘Learn’, but I don’t think any emonPi’s were ever made with a '12B).
So yes, that is totally wrong. The RSSI field ISN’T something the emonTx is measuring, it’s a field added by the emonPi that gives the strength of the received signal from the emonTx.
It’s +7 dBm by default. JeeLib fixes it, and doesn’t allow you to change it. That doesn’t mean you can’t, but there are caveats: it’s possible to cook and kill your RFM69CW if you turn the power up without an effective aerial to radiate the power away (ask Dan Bates - he found out the hard way), and unless you’re using a 5 V d.c. power supply, then the emonTx might crash if it tries to transmit when the mains voltage is very low - that’s because the original a.c. supply was designed only to support the RFM12B which needs far less peak current to transmit.
If you want to try a higher power, take JeeLib out of the sketch and substitute the rfm.ino file out of the 3-phase sketch, see EmonTx stops sending data - no led activity until reboot - #18 by Robert.Wall
If you have several transmitters all on the same channel, that file doesn’t check for ‘channel busy’ before transmitting, so you might have more collisions. If that seems to be a problem, a version that we’re testing appears to solve that.
RFPWR is what you change. 0x99 is the default (+7 dBm), maximum is 0x9F (+13 dBm).