It’s the timing around DE, I had the exact same thing on a lab rig with an F103.

HAL_UART_Transmit returns when the last byte has gone into the data register, not when it has left the shift register. Then you wait 5 ms on top. At 9600 one byte is about 1 ms, and a fast meter starts answering within a few ms. While DE is high, /RE is high too, so the receiver is off and the first bytes of the reply are gone. And because HAL_UART_Receive is only called after that, anything that came in meanwhile is lost or sits half in the data register.

The echo comes from the other order: if the receive is already armed while you transmit and /RE is low for a moment, you read back your own request.

Drop DE the moment the transmit complete flag (TC) is set, and arm the receive right after:

__HAL_UART_CLEAR_FLAG(&huart2, UART_FLAG_TC);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_8, GPIO_PIN_SET);
HAL_UART_Transmit(&huart2, req, 8, 100);
while (!__HAL_UART_GET_FLAG(&huart2, UART_FLAG_TC)) {}
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_8, GPIO_PIN_RESET);
__HAL_UART_FLUSH_DRREGISTER(&huart2);
HAL_UART_Receive(&huart2, rx, 9, 200);

Better still, use interrupt or DMA receive with the idle line interrupt, then a 3.5 character gap ends the frame and you don’t need to know the length in advance. The F103 has no hardware DE pin for RS-485, newer families do, which saves all of this.

Kevin is closer. Bluetooth 4.0 is the version of the spec that introduced Low Energy, so “BLE” is part of 4.0 and every version after it. A “Bluetooth 4.0” device can be classic Bluetooth, BLE, or both. For battery sensors it’s almost always BLE in practice. Ask the first vendor to confirm in writing.

The bigger question is your second one. Hermetry takes data over MQTT, HTTPS or LoRaWAN, so neither sensor talks to it directly. You’d need a gateway near the motors that listens to the sensors and reports each one as a child device in Hermetry (one gateway login, each sensor shows up as its own device with its own history and alarms). That only works if the vendor documents what the sensor sends: the advertising format, or the BLE characteristics to read. If the data only ever goes into their phone app and they won’t tell you the format, it’s not getting into Hermetry, whatever version it is.

So the question to send both vendors: “Is the data format documented so a third-party BLE gateway can read it?”

IPAddress has fromString(), so no splitting needed:

IPAddress ip;
if (ip.fromString(brokerStr)) {
  client.setServer(ip, 1883);
}

But Ciaran’s point: for Hermetry you don’t want an IP at all. Its broker is TLS on 8883 and needs SNI, so you must connect by host name. setServer() has a version that takes a host name, which works for your Pi too if you type its name or IP as text:

char brokerHost[64];   // global, lives as long as the program

void applyConfig(const String &s) {
  s.toCharArray(brokerHost, sizeof(brokerHost));
  client.setServer(brokerHost, 8883);
}

The global buffer is the important bit. PubSubClient keeps the pointer you pass, it doesn’t copy the text. If you pass brokerStr.c_str() from a String that goes out of scope at the end of setup(), the pointer dangles and it’ll try to connect to garbage later. I lost an afternoon to that in my final year project, the board connected on first boot and then never again after a reconnect.

Make the parameter long enough for the Hermetry host on your device’s Connection details card, 64 characters is plenty.

I did a tracker board for my RF module last year and got the same “slow fix, half range” result on rev A, so this is mostly what my lecturer took apart on it.

Keep the top pour, but make it a real ground: connected to the layer 2 plane with stitching vias everywhere, especially along every RF trace and around each RF section. Space them about 3 to 5 mm apart, tighter near the RF parts. A pour with a few random vias is a floating patch that resonates, and that alone can cost you sensitivity.

Do not split the ground. Isolate the sections by placement (each radio in its own corner, the noisy LTE power stuff away from GNSS) and, if needed, by a stitched fence of vias, but keep one continuous plane underneath.

Under and around the chip antenna and the patch: follow each antenna’s datasheet keep-out exactly. No copper on any layer in the chip antenna’s keep-out, and the patch wants its specified ground area under it. Michael is right too: give the two antennas different edges and ideally opposite corners.

Run your RF traces as grounded coplanar waveguide at 50 ohms (calculate with your stack-up, the vias on both sides are part of it) and leave a pi-network footprint at each antenna feed so you can tune later.

Then measure: send the LoRa RSSI and SNR and the GNSS satellite count and time to fix as readings with every message, and compare rev A against rev B on one chart. That’s the easiest A/B test you’ll get.

Yes. That blog is for a broker on your own home network, that’s why it has a 192.168 address. For Hermetry there’s no IP you should use at all: connect by the host name from the Connection details card, TLS on 8883. TLS needs the name (SNI), so the pinged IP fails, and plain 1883 is refused unless the profile allows plain MQTT, which it doesn’t by default. rc=5 is “not authorised”, and the actual reason ends up on the device’s Log tab, worth a look.

import ssl, json, paho.mqtt.client as mqtt

HOST = "<host from Connection details>"
TOKEN = "<access token>"

c = mqtt.Client(client_id="reefer-01")
c.username_pw_set(TOKEN)                  # token as username, no password
c.tls_set(cert_reqs=ssl.CERT_REQUIRED)    # normal public CA bundle
c.connect(HOST, 8883, keepalive=60)
c.loop_start()
c.publish("v1/telemetry", json.dumps({"temperature": -18.2}), qos=1)

With paho 2.x you need mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="reefer-01") instead.