I'm somewhat surprised the weirdness of the register map didn't factor into the solution. I found it extremely weird that the data types are described with twice as much space as they need in the definitions in 7.2 :
double : Floating data. This data is handled in 4-word units. One data per eight addresses
Eight modbus addresses is 128 bits, when it's definitely spelled out as a 64 bit double. And when I manually decoded the hexadecimal returned in doing a raw read on the first many registers, I found the value you expected to be at 30012 to really be at 30006, which would make sense to me if all that data is in order but the producer of the document got the "Register Number" column wrong because the data type key has the number of registers required for a data type doubled.
Yes you can plug in additional serial ports into the USB ports on the MangoES. The serial adapter does need to be compatible with Linux. The port should be automatically recognized. You can go to a serial data source in mango and click the Refresh button next to the serial port drop down list to see and select the new serial port.
I believe you are referring to the 'Character encoding' on the modbus data source test tools. This encoding is not referring to the transmission protocol, which could be RTU or ASCII, but instead refers to the encoding of fixed or variable length string requests. It will use the transport setting (ASCII / RTU) from the data source regardless of the setting for the character encoding on the point locator. If you select one of the String data types from the data type drop down, you will see the encoding field become editable. The ASCII in that box is opposed to being UTF8 or UTF16, not RTU.
Ethernet? I suspect so, but I've only used a standard ethernet cable for that purpose (haven't ports been self detecting and switching for a half decade or so? https://en.wikipedia.org/wiki/Medium-dependent_interface#Auto_MDI-X ). Then you'll probably have to give your ethernet interface a static ip on the same network or listen for its IPv6 address and use that.
We have not tested it unto the point of failure on temperature (we did try from the OS to thermally fail (CPU ~95C for many hours), though, just not from roasting the computer over an open fire). The supplier of the major component suggests their board is suited to run from -10C to 70C, with thermal CPU throttling occurring at 95C and temperature shutdown at 110C.
Mango's free version enables up to 20 data points. You would probably also not want to use the NoSql module in a free system.
I haven't personally tried to connect to a NEST device, but some searching makes it look like it would take some effort. It may be possible with the HTTP Retriever, but if not it may require either a Firebase4J integration or some interesting solution utilizing another API: https://www.firebase.com/docs/rest/quickstart.html
Belkin's API doesn't seem too readily available... I didn't sign up to enter their documentation. There is a 3rd party Python implementation, it appears.
Sounds to me like you have two devices that are not compatible to be on the same network.
There are two types of modbus reads for holding registers. One is where Mango requests a single register and the other is where Mango requests multiple registers. For 4 byte registers it's normal for the device to require the multiple register read so that makes sense. You could try changing your Max Register read to 2 which should be ok for your device with 4 byte registers but your other device may not like this so you might be forced to create two separate networks for each type of device.
The update rate is stored in the serialized data so it's not going to be available in an SQL statement. The only thing I can think of without writing any Java code would be to grab it out of the JSON from the export page or the API.