TTGO Lora 1.7.0 issue respect 1.6.1

[sdomotica]

I'm using TTGO Lora 868 v1 with success as Lora receiver working fine with 1.6.1

If I upgrade to 1.7.0 I receive error on packet receive on the console LORA packet deserialization failed: InvalidInput, buffer capacity: 768

This is the info for updated board

I'dont have a old firmware to rollback. I tried to install form the github but without success.

Bye Sandro

[its-grandpa]

You can download the old version (1.6.0) https://github.com/1technophile/OpenMQTTGateway/releases site. https://github.com/1technophile/OpenMQTTGateway/releases/download/v1.6.0/ttgo-lora32-v1-868-firmware.bin

[sdomotica]

I tried with your suggested link and files. Let me explaing with some pictures

These files 1.7.0 work fine

These files 1.6.0 and different comination not

[its-grandpa]

I don't use this tool, I compile from source with VSC. I look at the pictures, the combine bin button is not active when uploading 1.7

[sdomotica]

it's only rollover on mouse.

[nikito7]

How to fix without downgrade?

[sdomotica]

openmqttgateway it's very very interesting project. But we have an issue with latest version and lora packets. I asked to rolleback, using the official guides and received this answer.... I'm writing my self a code for lora to mqtt gateway

[nikito7]

LoRa is limited for json.

With json I need 400 bytes 🫣

openmqttgateway it's very very interesting project. But we have an issue with latest version and lora packets. I asked to rolleback, using the official guides and received this answer.... I'm writing my self a code for lora to mqtt gateway

Maybe it is the best option

[sdomotica]

I have two implementation with different lenght message. Seems that now the message should be very very short. No way to rollback the only solution is find another tools.

[nikito7]

I use ChaChaPoly Encryption.

But add hex to json decoder maybe it's to much changes.

Changed buffer size from 768 to 1024 don't fix the error

[1technophile]

If you upload the temperature sensor on another node does it work for you? https://github.com/1technophile/OpenMQTTGateway/tree/development/examples/LoraTemperature

@nikito7 you can't fork a project licensed with GPL V3 and publish it under MIT.

[nikito7]

Ok about license.

This is the minimal json without error:

N: Send on /LORAtoMQTT/LoRa_cpha8 msg {"id":"LoRa_cpha8","EBx":1,"Ser":2,"ERR":72,"up":53373,"rssi":-53,"snr":9.25,"pferror":729,"packetSize":128}

If I add model got the error.

My packetSize is fixed.

There is any relationship between packetSize and json buffer?

Anyway lora it's limited to 256 bytes (hardware limit) and channel bandwidth.

[sdomotica]

If you upload the temperature sensor on another node does it work for you? https://github.com/1technophile/OpenMQTTGateway/tree/development/examples/LoraTemperature

@nikito7 you can't fork a project licensed with GPL V3 and publish it under MIT.

Please consider that the lora message can be not a Json ma simple string.

[1technophile]

Please consider that the lora message can be not a Json ma simple string.

Do you have an example?

[sdomotica]

Please consider that the lora message can be not a Json ma simple string.

Do you have an example?

I have this type of sensor https://www.makerfabs.com/lora-soil-moisture-sensor-v3.html

And with OMG 1.6.0 works fine and this is the messagge managed by your gateway, if use I 1.7.0 the getway has this error LORA packet deserialization failed: InvalidInput, buffer capacity: 768

The message is simple text "ID010770 REPLY : SOIL INEDX:5862 H:100.00 T:1.77 ADC:624 BAT:857"

[1technophile]

"ID010770 REPLY : SOIL INEDX:5862 H:100.00 T:1.77 ADC:624 BAT:857"

Does this come from their stock firmware ?

If yes I suppose that it could be interesting to use auto discovery to create the device into HA ?

[sdomotica]

"ID010770 REPLY : SOIL INEDX:5862 H:100.00 T:1.77 ADC:624 BAT:857"

Does this come from their stock firmware ?

If yes I suppose that it could be interesting to use auto discovery to create the device into HA ?

Yes, is message from stock firmware. An I was able to use your OMG 1.6.0 very fine. I created a flow management in nodered to create a "autodiscovery" sensor in HA. But you changed something in 1.7.0 and it don't work anymore. And I cannot upload the 1.6.0 firmware as per previous post. For this reason I'm writing myself a gateway per Lilygo. It's really a pity don't can use anymore (from 1.7.0) your very very good implementation. Bye Sandro

[1technophile]

With the v1.7.0, I published a compatible example with the LoRa gateway, as there is no data format for this type of communication. The proposed format uses JSON. Unfortunately, I did not have a Makerfab soil sensor to test with. But I see the issue. Mainly, we were only processing JSON, not basic messages. A test version will be available tomorrow.

[1technophile]

You can try a fix in development: https://docs.openmqttgateway.com/dev in 1h15

[sdomotica]

You can try a fix in development: https://docs.openmqttgateway.com/dev in 1h15

Now works fine as per 1.6.0 I have another sensor similar soil moisture publishing text message and the issue is fixed for me. Thank a lot for the support

[1technophile]

Could you share different messages like this: "ID010770 REPLY : SOIL INEDX:5862 H:100.00 T:1.77 ADC:624 BAT:857" And explain each value?

[sdomotica]

HEX message is sniffed , not mine.

I have two implementation of lora sensor. And for both same "receiver" TTGO v.1

One is soil moisture using this sensor https://www.makerfabs.com/lora-soil-moisture-sensor-v3.html

the sensor send tex message as this: "ID010770 REPLY : SOIL INEDX:5862 H:100.00 T:1.77 ADC:624 BAT:857" In the wiki you can find how the message mix the info

https://wiki.makerfabs.com/Lora_Soil_Moisture_Sensor_V3.html

The second end node is build myself and is based on Heltech Cubecell

And send a text message as this: "Sdomotica2 1.950 | batt1 6898 | batt2 4218"

[nikito7]

There is no easy way to create a standard.

For small data sensors json it's the best option.

For large data sensors, binary like LoRaWAN.

LoRa has different size limits, it depends on Data Rate etc

Chip itself support at maximum 256 bytes.

[sdomotica]

There is no easy way to create a standard.

For small data sensors json it's the best option.

For large data sensors, binary like LoRaWAN.

LoRa has different size limits, it depends on Data Rate etc

Chip itself support at maximum 256 bytes.

256 bytes are ok for the project.

[nikito7]

Ignore ChaChaPoly Encryption code.

This is how create something like LoRaWAN...

https://github.com/nikito7/LoRa-ChaChaPoly-Notes/blob/877b73c72b80f6bd38f398df24171fecfcccdefa/v2-hex/gateway-omg/block2-notes.cpp#L83

This time I removed too much code... Maybe I need to add it again later. Now that issue it's fixed.

Sender example:

https://github.com/nikito7/LoRa-ChaChaPoly-Notes/blob/877b73c72b80f6bd38f398df24171fecfcccdefa/v2-hex/node-sender/src/main.cpp#L143

Use array and change LoRa.print to LoRa.write

[nikito7]

There is no easy way to create a standard. For small data sensors json it's the best option. For large data sensors, binary like LoRaWAN. LoRa has different size limits, it depends on Data Rate etc Chip itself support at maximum 256 bytes.

256 bytes are ok for the project.

You can change sender to use json.

It's the best way to integrate with OpenMQTTGateway.

And possible in future auto discovery

[1technophile]

You can change sender to use json.

By changing the code or is it configuration?

[nikito7]

You can change sender to use json.

By changing the code or is it configuration?

Changing the code I think. If the code it's open.

About data rates:

https://lora-developers.semtech.com/documentation/tech-papers-and-guides/the-book/packet-size-considerations/

[sdomotica]

I saved the files for future rollback :-)