Custum LoRa sensor

First I love all the great work here and the great stable connection from the BLE gateway. Thank you :slight_smile: !

Now I’m trying to make a custom arduino LoRa sensor for the LoRa gateway, but after several days trying I cannot make it work :frowning: .

  • I used option 1, uploading from the web with the ttgo-lora32-v1-868 environment. (I also used option 2, uploaded by VSC, but I don’t see any difference for my settings)
  • for the gateway I use the TTGO 868 V1.0 version, for the sender I use the TTGO 868 V1.6 version (versions)
  • for the sender I use a BME280 sensor.

In the Serial monitor from the sender i get the following data format:

{“tempc”:20.5,“hum”:47.6,“pres”:1026.7}

In the “home/OpenMQTTGateway_ESP32_LORA/LORAtoMQTT” MQTT topic i get the following data format:

{“rssi”:-44,“snr”:0.75,“pferror”:-15275,“packetSize”:39,“hex”:“BB22B8593E69C3223A7E242C35AC2BF8ED6DE2F6380EBE2FB9AA395E6D77222AF1F09A162A397C”}

What am I doing wrong, someone has a idea?

I used the following sketch for the sender:

#include <Wire.h>
#include <LoRa.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>
#include <ArduinoJson.h> // Include the ArduinoJson library

#define SDA 21
#define SCL 22
#define LORA_SCK 5
#define LORA_MISO 19
#define LORA_MOSI 27
#define LORA_SS 18
#define LORA_RST 23
#define LORA_DI0 26

Adafruit_BME280 bme;

void setup() {
  Wire.begin(SDA, SCL);
  Serial.begin(115200);
  while (!Serial);
  if (!bme.begin(0x76)) {
    Serial.println("Could not find a valid BME280 sensor, check wiring!");
    while (1);
  }
  SPI.begin(LORA_SCK, LORA_MISO, LORA_MOSI, LORA_SS);
  LoRa.setPins(LORA_SS, LORA_RST, LORA_DI0);
  LoRa.enableCrc();
  LoRa.setSyncWord(0x12);
  if (!LoRa.begin(868E6)) {
    Serial.println("Starting LoRa failed!");
    while (1);
  }
  Serial.println("LoRa sender module started!");
}

void loop() {
  float temperature = bme.readTemperature();
  float humidity = bme.readHumidity();
  float pressure = bme.readPressure() / 100.0F;

  char tempStr[10];
  char humStr[10];
  char presStr[10];

  dtostrf(temperature, 4, 1, tempStr);
  dtostrf(humidity, 4, 1, humStr);
  dtostrf(pressure, 6, 1, presStr);

  String jsonData = "{\"tempc\":";
  jsonData += String(tempStr);
  jsonData += ",\"hum\":";
  jsonData += String(humStr);
  jsonData += ",\"pres\":";
  jsonData += String(presStr);
  jsonData += "}";

  Serial.println(jsonData);

  LoRa.beginPacket();
  LoRa.print(jsonData);
  LoRa.endPacket();
  
  delay(10000);
}

I bought 2 new LoRa modules. Now I use the same TTGO 868 V1.6 for the sender and a TTGO 868 V1.6 for the gateway. And it works!

So good to know for other people. The TTGO 868 V1.6 and the TTGO 868 V1.0 won’t match. Always use the exact same board to be sure it works.

Now I only need to find out how to get the Build in Auto discovery to work. I can do it manually by programming a whole arduino code for that, but somehow it is build in the OMG software already.

I will try first. Are there documentation for that? I cannot much about it.

1 Like

Good to know that you got it working.
I would start by taking a look to the DHT discovery which is a simple example to start with

Thank you for the reply!

I will take a look on this example and have a try this evening.

We could also add a sensor code example to the repository that works directly with the LORAtoMQTT gateway, I think it would help user starting.
Idealy this example could be used by the gateway to autodiscover message. We could use the builtin temperature sensor of the ESP32 to push a temperature value via LORA and create the temperature sensor automatically with HA.

Search for this function in OMG code to get the temperature intTemperatureRead() if you are interested in such development.

That could be a great example! Although I’m trying to read through alle documentation I cannot seem to find a good example for this.

Let me know if I can help with writing documentation steps or sth :slight_smile:

I now tried all different type of codes for the Lora sensor device. But I cannot make it work.
Which format the sensor module should send?

In the ZmqttDiscovery.ini DHT example it shows:

{{"sensor", "temp", "dht", "temperature", jsonTempc, "", "", "°C"},{"sensor", "hum", "dht", "humidity", jsonHum, "", "", "%"}};

In the Sensor page it shows:

{"tempc":21,"tempf":69.8,"hum":51}

One important, but maybe simple step that I don’t understand, the auto discovery function from sensors, does it only work if you connect a sensor TO the gateway? Or can it detect with auto discovery when it is connected TO a ‘sender module’ that SENDS through LoRa to the gateway?

Somehow on the OMG website the sensors are explained, but nowhere from where it should be or can be connected.

I need the following:

Is this correct?

Yes this is correct, I would just add a nodeId to the message, so that you have a differentiation between the sensors.

Auto discovery for lora is not develop, it works already if you attach a dht to the gateway or if the gateway sees a BLE wireless sensor.
So we should consider the Lora node as a kind of BLE sensor.

I will share examples

I managed to get it work :slight_smile:. The BME280 connected to the I2C pins from a ‘new’ sender/gateway is directly recognized inside the gateway-device by uploading it with PlatformIO.

But sadly the value’s are not send by LoRa to a other gateway. And It seems it only works if this device is connected to WiFi, that shouldn’t be the case when trying to create a Long distance sensor.

I experienced there are multiple ways. I now defined the ttgo-lora32-v1-868 in the platformio.ini and in environments.ini I changed the [env:ttgo-lora32-v1-868] environment to:

[env:ttgo-lora32-v1-868]
platform = ${com.esp32_platform}
board = ttgo-lora32-v1
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.wifimanager32}
  ${libraries.lora}
  ${libraries.bme280}
build_flags =
  ${com-esp.build_flags}
  '-DZgatewayLORA="LORA"'
  '-DZsensorBME280="BME280"'
  '-DZmqttDiscovery="HADiscovery"'
  '-DLORA_BAND=868E6'
  '-DLORA_RST=23'           # for the TTGO LoRA V2 version i'm using
  '-DGateway_Name="OpenMQTTsender_BME280_ESP32_LORA"'
  '-Dwifi_ssid="xxx"'
  '-Dwifi_password="xxx"'
  '-DMQTT_SERVER="xxx"'
  '-DMQTT_USER="xxx"'
  '-DMQTT_PASS="xxx"'
custom_description = LORA communication 868Mhz using arduino-LoRA
custom_hardware= ESP32 TTGO LORA V1

And thank you for your messages :slight_smile:

So that would mean I cannot use the auto discovery mode in this way, and have to manually define the sensors in home assistant with mqtt yaml or nodered?

That’s would be a real pity then. I appreciate all the great work, but that’s not very functional with the LoRa gateway compared to how the BLE and the 434 or RF gateway works.

Cannot I change a LoRa OMG firmware in PlatformIO, which:

  • sends first a auto discovery message with LoRa to the MQTT homeassistant/sensor/xxx_sensor_name/config topic (to automaticly create a new MQTT device in HA)
  • then send the LoRa received sensor values as a MQTT payload to the home/xxx_sensor_name topiq (or indirect to the homeassistant/sensor/xxx_sensor_name/config topic)?

Or can I somehow upload a customised LoRa OMG firmware for the sender AND a upload the OMG firmware for the LoRa gateway to make that work?

Sorry for all the questions, I’m just really enthusiastic to make a LoRa auto discovery function work. I could use it then in so many situations :smiley: !

The current state of the project involves that you need to develop your own node/sensor, we are not providing code for it (we may do so in the future)
For this users should start from these examples:

The counterpart of this is that there is no structured messages coming from the sender, or at least no convention agreed for the moment.
And to do autodiscovery, we will need this. To go further on the LORA implementation we need:

  • define a structured format of LORA payload
  • Provide an example with a structured format of data for the LORA node sender
  • implement auto discovery into the LORA gateway

Regarding the structured payload format there is at least 2 approaches to discuss:

  1. encoded like LORAWAN or BLE sensors are doing
  2. not encoded like we see into the MQTT messages from OMG

Approach 1 will enable more data to be carried into the payload but less readability
Approach 2 will limit the payload size and increase the power consumption of the node but with more readability.

For approach 1, we could leverage the existing decoder technology
Approach 2 would be faster and easier to implement.