LoRaWAN Decoders

[UBWH]

For Discussion - LoRaWAN Decoders

Looking for feedback on the idea to add LoRaWAN Decoder to Tasmota.

LoRaWAN 101

The basic elements are:

1. End Device (e.g. a Temp Sensor). Sends data packets that are just a bunch of bytes containing the sensor data. Syntax decided by the manufacturer.
2. LoRa Gateway (Radio basestation). Receives packets via radio, checks integrity, then and passes on raw data packets to the Network Server (NS).
3. Network Server (NS) Manages the LoRa protocol, and passes encrypted packets onto the Application Server (and/or an MQTT Server)
4. Application Server (AS) Manages device pairings. Decrypts packets. Then optionally parses (Decodes) the sensor data for user presentation. Often passing on further via MQTT.

Items 2, 3, and 4 are often combined in a single appliance. eg Dragino LPS8v2

Tasmota LoRaWAN Bridge covers items 2, 3, and the Decryption part of 4 above.

If implemented, the AS decodes the sensor raw binary payloads - and every manufacturer/device is different! To facilitate this, there are public databases of decoder scripts that can be copied into the AS for each device type that it needs to decode. Here is a widely used decoder script database

Here is the JavaScript decoder for my Dragino LHT52.

A Decoder takes a byte-array Payload like: [10,21,1,253,127,255,1,104,25,209,194] and turns it into

{  "Systimestamp": 1746522562,
   "Hum_SHT": 50.9,
   "TempC_SHT": 25.81
}

Adding Application Server Decode Functionality to Tasmota

Today, Tasmota can only pass on a decrypted byte-array via MQTT to (e.g.) HomeAssistant or other platforms. That means every consumer of that byte-array has to build their own decoder in (e.g.) HomeAssistant

I have a working AS decoder implemented in Berry running today.

• No codebase changes. All in Berry. No custom builds.
• The elements are:
  1. a Berry script lorawan_decode.be that:
     • subscribes to the tele/xxxx/SENSOR MQTT messages, looking for the LwReceived packets sent by the Tasmota LoRaWAN bridge.
     • dynamically loads (once only) decoder scripts (also written in Berry) from the file system, if they exist
     • asks the decoder script to decode the byte-array Payload
     • reports the result via MQTT
     • Not big. 1.3 kB uncompiled size
  2. Decoder scripts (e.g. LHT52.be):
     • written in Berry
     • closely modelled on the TTN decoder script database.
     • 1~3 kB uncompiled size

So now, I get two MQTT messages for every LoRaWAN sensor transmission:

{
  "LwReceived": {
    "0xAE3D": {
      "Node": 1,
      "Device": "0xAE3D",
      "RSSI": -30,
      "SNR": 7.7,
      "DevEUIh": "A840414E",
      "DevEUIl": "4F5CAE3D",
      "FPort": 2,
      "Payload": [10,21,1,253,127,255,1,104,25,209,194]
    }
  }
}

... and ...

{
  "LwDecoded": {
    "0xAE3D": {
      "Systimestamp": 1746522562,
      "Hum_SHT": 50.9,
      "TempC_SHT": 25.81,
      "Device": "Dragino LHT52"
    }
  }
}

User Procedure

• Download into File System from repository:
  • lorawan_decode.be
  • decoder.be files needed (e.g. LHT52.be), or write a new one
• modify autoexec.be to load("lorawan_decode.be")
• associate each device with its decoder. (e.g.) LoRaWanDecoder<x> LHT52

Items for Discussion

1. Comments?
2. I am happy to release my Berry scripts - but to where? Maybe here: /tasmota/berry/lorawan/decoders/lorawan_decode.be and /tasmota/berry/lorawan/decoders/vendor_xxx/model.be and
3. I would also need to add a new command that associates each end device with its decoder script. LoRaWanDecoder<x> LHT52 (Like LoRaWanAppKey<x>). Then the MQTT LwReceived message would include e.g. {...,"Decoder":"LHT52"}
4. Add documentation, User Guide. Where?

[arendst]

Using Berry for decoding was exactly my plan when providing un-decoded MQTT messages.

2. Suggested folders are fine.
3. The goal of the un-decoded message is that all information for decoding is provided. I don't see why there needs to be a relation between the device and a single berry script. I would expect to have one berry script receiving the MQTT message and depending on it's contents decodes the corresponding values based on DevEUIh (manufacturer), FPort (device type) and Payload length.

Example for MerryIoT DW10:

{"LwReceived":{"0x1FB5":{"Node":2,"Device":"0x1FB5","RSSI":-29.0,"SNR":10.5,"DevEUIh":"00161600","DevEUIl":"00001FB5","FPort":204,"Payload":[1,3,32,0,0,3,1,2,0]}}}

and with LoraWanName2 MerryIoT DW10:

{"LwReceived":{"MerryIoT DW10":{"Node":2,"Device":"0x1FB5","Name":"MerryIoT DW10","RSSI":-31.0,"SNR":11.5,"DevEUIh":"00161600","DevEUIl":"00001FB5","FPort":120,"Payload":[1,15,22,47,0,0,2,0,0]}}}

Example for Dragino LDS02

{"LwReceived":{"0x4AD6":{"Node":1,"Device":"0x4AD6","RSSI":-36.0,"SNR":11.0,"DevEUIh":"A840410E","DevEUIl":"71894AD6","FPort":10,"Payload":[138,104,1,0,0,0,0,0,0,0]}}}

and with LoraWanName1 Dragino LDS02:

{"LwReceived":{"Dragino LDS02":{"Node":1,"Device":"0x4AD6","Name":"Dragino LDS02","RSSI":-34.0,"SNR":11.3,"DevEUIh":"A840410E","DevEUIl":"71894AD6","FPort":10,"Payload":[10,128,1,0,0,0,0,0,9,0]}}}

In this case a relation between LoRaWanName and a decoder script could also be used satisfying your suggestion.

4. Documentation could be added to our docs site and Lora page at https://tasmota.github.io/docs/LoRa-and-LoRaWan-Bridge/. preferrably adding a new page dedicated to LoRaWan decoding.

[UBWH]

@arendst

Thanks for your response.

You recommended:

1. One Berry script for all supported devices
2. Use LoRaWanName to associate with a decoder script
3. Use DevEUIh (manufacturer), FPort (device type) and Payload length to decide which decoder to use, as in this existing code:

 if (0x001616 == manufacturer) {                           // MerryIoT
      if (120 == node_data->FPort) {                       // MerryIoT door/window Sensor (DW10)
        if (9 == node_data->payload_len) {                 // MerryIoT Sensor state 

One Berry Script
Let's say Tasmota LaRaWAN becomes popular ( 😁 ) and the number of supported device decoders comes close to this: TTN Supported Devices, then the single decoder Berry script would become huge, and a maintenance nightmare.

OK - let's be more realistic, and still optomistc. Tasmota ends up with support for 100 device decoders. Still - that is a pretty big Berry script file.

My I idea was:

• One (smallish) Berry script that decides (at run time) which decoder(s) are needed, and then loads the specific decoder script(s) for the device types only on demand.
• That is much more modular, and does not fill the file system with a decoder file that has a lot of un-needed code.

LoRaWanName => Decoder Script
Yes. I thought of that. But let's say we have 4 x LHT52 Temp Sensors, reporting to the same Tasmota Bridge, and we have a decoder script called deco_LHT52.be

Would have to give all 4 the same name.

• LHT52
• LHT52
• LHT52
• LHT52

, when users would probably want to use names like:

• Temp - Outside
• Temp - Inside
• Temp - Shed
• Temp - Garden

It is pretty 'cheap' (code-wise) to add a new command/field LoRaWanDecoder<x>

Decide Decoder based on DevEUIh/FPort/Payload length
Not sure this will not work - But if it does it is very elegant.

I am not sure DevEUIh uniquely identifies the device type. I can not find that requirement in any of the LoRaWAN docs. Do you have a reference somewhere that confirms this?

The most relevant I can find is:

The DevEUI (Device EUI) in LoRaWAN is a 64-bit unique identifier assigned to a device, and it does not directly reveal the manufacturer name. The first part of the DevEUI, the first 24 bits, is an OUI (Organizationally Unique Identifier) allocated by the IEEE Registration Authority, which identifies the organization that assigned the device identifier. You can use this OUI to find the organization that assigned the DevEUI, but it might not be the manufacturer.

So ... DevEUIh will identify a GROUP of devices that have a common organisation. No more.

As a data point, my two Dragino devices (and your LDS02) have these DevEUIhs

• LHT52: A840414E
• LHT65: A8404161
• LDS02: A84041??

Dragino MAY use the last byte of DevEUIh as the device model identifier - but we should not rely on that.

I notice that your decoder code only looks at the high 3 bytes of DevEUIh. Data packets from other Dragino devices might be (incorrectly) parsed by your LDS02 code if FPort/Payload length matched.

manufacturer = Lora->settings.end_node[node_data->node].DevEUIh >> 8

[arendst]

OK. You're right. I had a small subset to decide where to distinguish them :-)

I'll add the command/field LoRaWanDecoder<node> <defined decoder name> so you can go forward making it all happen in Berry ;-)

As every configured node will take memory space (currently about 40 bytes + LoRaWanName) + 'LoRaWanDecoder`, I'll try to find a way how to populate these dynamically based on user input and JSON persistent data. Currently there is room for four nodes but considering the growing functionality of the gateway this may increase so reserving in advance for 10 nodes will cost too much possibly unused RAM. I'll wotk on that.

BTW using your changes does the Dragino LHT52 join seamlessly? I rewrote the EU868 part to also use different frequencies for RX1/RX2 but my (just received) EU868 LHT52 refuses to listen to my Join response. Joining the MerryIoT does work fine though.

[arendst]

Latest dev (v14.6.0.2) adds command LoRaWanDecoder.

I would prefer to name decoders without spaces. For now it's not a problem but I hate spaces so I suggest you name the berry decoder like DraginoLDS02 or Dragino_LDS02.

[UBWH]

I was assuming the LoRaWANDecoder name would be saved in the FileSystem (LikeAppKey).

In this /.drvset000

{
"AppKey":"77FBAA35996E2A8F2CEAC17E6ED1FDF8",
"DevEUIh":2822783329,"DevEUIl":1197257255,"DevNonce":38456,
"FCntUp":207,"FCntDown":5,
"Flags":1,
"NAME":"0xB227",
"Decoder":"LHT52"                      <---------------- New
}

[arendst]

It is as DCDR. I choose that name as you're not really supposed to access it. Every MQTT message will hold the decoder name as decoder for easy access by berry or whatever decoder needs to activated.

{"LwReceived":{"Dragino LDS02":{"Node":1,"Device":"0x4AD6","Name":"Dragino LDS02","RSSI":-33.0,"SNR":10.5,"Decoder":"DraginoLDS02","DevEUIh":"A840410E","DevEUIl":"71894AD6","FPort":10,"Payload":[138,86,1,0,0,0,0,0,0,0]}}}

[UBWH]

What is your feeling on the names of the decoder files (that I will release as a PR).

• No spaces in names (Heard that loud and clear)
• Should the decoder file include the manufacture's name?

My plan is to have a file structure in the repo like this (modeled on the TTN repo of decoders)

• Vendor A
  • Model A
  • Model B
• Dragino
  • LDS02
  • LHT52

The only drama would be if

• Both Dragino and some other vendor sold a product with same name which is unlikely (e.g. two LDS02 vendors)

AND (!)

• user wanted to decode BOTH products on one Tasmota installation

(Easy fix: Just download both files from the Repo and rename one of them)
LDS02 and LDS02b`)

So the MQTT would look like

 {"Dragino LDS02":
  {"Node":1,
     "Device":"0x4AD6", 
     "Name":"Dragino LDS02", 
     "Decoder":"LDS02",
     ...
  }
 }
}

In other words ... not sure need to include vendor name in documentation examples.

[UBWH]

Q: BTW using your changes does the Dragino LHT52 join seamlessly? I rewrote the EU868 part to also use different frequencies for RX1/RX2 but my (just received) EU868 LHT52 refuses to listen to my Join response. Joining the MerryIoT does work fine though.

A: Yes - both my LHT52 & LHT65 join seamlessly. I just add the AppKey, press the reset button on the LHT decice, and wait a little while. Went through that process many times in my testing.

BTW - there is a small comment in my code ... It does NOT actually change freq for RX1. (This is a //TO DO in the code). The changes were already getting a bit complicated, so I wanted to do the PR as everything was working OK.

In AU915, RX1 has to follow Freq/DR rules, but RX2 must be on a fixed/well-known Freq/DR. Kinda a 'fall back' in case RX1 is not received I guess. Anyway - my code relies on RX2 to get the packet to the end device. The TO DO should be addressed, and I might re-visit that after the next release.

[arendst]

I have RX1 now added to my local test code. For AU915 I use your implementation. It appears thar EU868 also needs this so I implemented it for EU868 too with different frequencies and DW.

Alas, the LHT still fails to join.

Another problem I'm chasing is watchdog exceptions on ESP8266 using RX1/RX2 changes. working on it for some days now and getting close I feel ...

EDIT: Fixed. Caused by sending response with SF12 which just takes too long for an interrupt handler. Rewrote to handle response outside interrupt handler (Needs new function SleepSkip().

[UBWH]

FYI: lastest Dev Build works great with LoRaWanDecoder1 LHT52 and my Berry Decoder scripts.

Thanks.

Working on PR to add the Berry files & Documentation.

[arendst]

I'll add support for SetOption147 - If it is activated, Tasmota will not publish MQTT messages, but it will proccess event trigger rules so we can supress the original MQTT message while providing the decoding message.

Currently this won't work as the decoder is initiated by the LwReceived MQTT message.

I need to dive into berry how to pick-up the message from the rules/berry engine.

[arendst]

I'm stil terribly struggling with the LHT52 failing to join :-(

I've connected the LHT52 serially and am able to see the Join process:

***** UpLinkCounter= 0 *****

TX on freq 868500000 Hz at DR 3

txDone

RX on freq 868500000 Hz at DR 3

rxTimeOut

RX on freq 869525000 Hz at DR 0

rxTimeOut


***** UpLinkCounter= 0 *****

TX on freq 868100000 Hz at DR 3

txDone

RX on freq 868100000 Hz at DR 3

rxDone

JOINED


***** UpLinkCounter= 0 *****

TX on freq 868500000 Hz at DR 0

txDone

RX on freq 868500000 Hz at DR 0

rxTimeOut

RX on freq 869525000 Hz at DR 0

rxTimeOut

The darn thing says JOINED (in my case on 868.1MHZ and DR3) and then continues the initial join process instead of sending a JOIN complete message. To me it looks like the LHT52 is not performing the correct procedure....

[arendst]

Finally a successful join after serial configuring the LHT52 for fixed frequency and datarate. Apparently the above log shows successful join but tries to send a time request on DR0 while I need DR3.

Pity I need to serial config dragino devices but so be it.

[UBWH]

I did not need to set a fixed freq on the LHT52 for the JOIN process.

Do you have a commercial gateway (I am using Dragino LPS8v2, with Chirpstack Network Server).
This allows me to watch all the messages that go back and forth including the joining process - if I configure the LSP8v2 with the LHT52 AppKey and Tasmota is either off, or has 000000 appkey.

This REALLY helped me as I could see what a 'good' JOIN looked like AND the subsequent up/down packets that quickly followed to see what requests/answers were going back & forth.

I note in EU868:

The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz)

I assume you are using that.

Also - I use the CFList in the JOIN-ACCEPT to tell the end device to use a fixed freq.
See https://lora-alliance.org/wp-content/uploads/2020/11/lorawan_regional_parameters_v1.0.3reva_0.pdf
section 2.2.4 for EU868

None of the above directly answers your question. I do remember my JOIN-ACCEPTs were not working initially - but that is when I relalised that in AU915:

• Downlinks must be on different Freq/DR than the uplink
• That forced me to add the code that changed the SX chip freq AND do a Lora->Init() when going back into listen mode.
• I think that was the only fix I had to do to get JOIN to work.

BTW - I do not even have the USB-C breakout thing to allow me to send AT commands to the LHT52.

[arendst]

Thx for the info. I hed deduced the same and implemented different RX1/RX2 for EU868 in latest dev release.

The problem with Dragino on EU868 is that they send a join request on DR3 followed by next message being on any frequency with DR0. Alas that won't work with Tasmota SX12xx hardware. Now that I configured it to stay on a single frequency and DR it works fine.

10:01:41.788 MQT: tele/t3s3b/SENSOR = {"LwReceived":{"Dragino LHT52":{"Node":3,"Device":"0xAD89","Name":"Dragino LHT52","RSSI":-7.0,"SNR":10.8,"Decoder":"LHT52","DevEUIh":"A8404154","DevEUIl":"175CAD89","FPort":2,"Payload":[8,145,1,205,8,127,1,104,37,159,63]}}}
10:01:41.876 MQT: tele/t3s3b/SENSOR = {"LwDecoded":{"Dragino LHT52":{"Systimestamp":1747296063,"Ext_SensorConnected":true,"Device":"Dragino LHT52","TempC_Internal":21.93,"Hum_Internal":46.1,"TempC_External":21.75,"Ext_SensorType":1}}}

Using a LPS8v2 for debugging sounds like a great idea. I might order one for future development and debugging.

[UBWH]

"send a join request on DR3 followed by next message being on any frequency with DR0"

But - if the CFlist (that only allows one freq) is included with the JOIN-ACCEPT, then the LHT52 should not use any freq on the next Uplink except the one allowed in the CFlist.

That how my AU915 LHT52 works.

[arendst]

From what I understand for EU868 that the CFList extends the three predefined frequencies 868.1, 868.3 and 868.5 with up to 5 user defined frequencies making it worse.

[arendst]

BTW I just updated your berry LwDecode.be to support supressing of LwReceived MQTT message when SO147 is enabled. Making responses cleaner.

13:36:55.055 MQT: tele/t3s3b/SENSOR = {"LwDecoded":{"Dragino LDS02":{"Alarm":false,"DoorOpenLastDuration_mins":19,"Battery_mV":2676,"Device":"Dragino LDS02","DoorOpenEvents":19,"DoorOpen":false}}}
13:36:57.396 CFG: Lora saved to file
13:36:58.088 MQT: tele/t3s3b/SENSOR = {"LwDecoded":{"Dragino LDS02":{"Alarm":false,"DoorOpenLastDuration_mins":0,"Battery_mV":2670,"Device":"Dragino LDS02","DoorOpenEvents":20,"DoorOpen":false}}}
13:37:01.153 MQT: tele/t3s3b/SENSOR = {"LwDecoded":{"Dragino LDS02":{"Alarm":false,"DoorOpenLastDuration_mins":0,"Battery_mV":2670,"Device":"Dragino LDS02","DoorOpenEvents":21,"DoorOpen":true}}}
13:37:07.609 CFG: Lora saved to file
13:41:42.184 MQT: tele/t3s3b/SENSOR = {"LwDecoded":{"Dragino LHT52":{"Systimestamp":1747309263,"Ext_SensorConnected":true,"Device":"Dragino LHT52","TempC_Internal":23.37,"Hum_Internal":40.7,"TempC_External":22.87,"Ext_SensorType":1}}}
13:41:47.823 CFG: Lora saved to file

[UBWH]

EU868 CFList

Reading this doc: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan_regional_parameters_v1.0.3reva_0.pdf

2.2.4 EU863-870 JoinAccept CFList

I see the problem. The EU868 CFlist can only ADD to the 3 default channels ... not replace them. AU915 is different.

If present, the CFList SHALL replace all the previous channels stored in the end-device apart from the three default channels.

That implies Tasmota in EU will miss 66% of all uplinks - unless (as you do) hand-configure the end device to use one channel.

Bummer

[arendst]

Partly correct.

Once a join succeeds like the MerryIoT does I send a LoRaWan command to keep the frequency fixed at 868.1 (I cannot remember which). This works fine on the MerryIoT but Dragino does not support this.

Anyway, thinks for thinking with me.

[arendst]

Latest dev release adds GUI support to lorawan decoders.

[UBWH]

Great minds think alike!

I was going to suggest exactly this. How cool is that!

[UBWH]

Here is the other idea that I have not proposed ... and not sure if I should:

It is great that Tasmota supports LoRaWAN as the 'basestation' that can RX sensor measurements.

The Holy Grail would be if Tasmota sensors could be 'clients' of LoRaWAN. Yep - I get it ... 'too hard'. Also would need hardware that supported BOTH LoRa and the sensors we care about. Impractical.

But .... my LilyGoT3S3 came preinstalled with Meshtastic - which of course I immediately overwrote with Tasmota. But I did a bit of googleing on Meshtastic.

• Runs on LoRa. So long-disatance and no Line-of-sight requirement; unlike WiFi.
• Open source
• It is a mesh (of course). Because of that the 'range' can be huge as messages are relayed over mutiple hops to final destination.
• Think of it as like SMS. Short messages that hop as needed through the mesh to a destination Meshtastic node.
• A phone running a Meshtastic App typically connects to a nearby Meshtastic node via Bluetooth (or WiFi or serial !)
• That destination node can be an MQTT broker !!!!! e.g. AliExpress product
• Arduino code exists on Github to make a Meshtastic 'client'
• AliExpress (e.g.) has many cheap Meshtastic nodes.

What if:

• Tasmota could be a WiFi 'client' (or Bluetooth client if available on the ESP32) of a nearby Meshtastic node
• Send infrequent, short messages (of JUST sensor data) destined for an MQTT Meshtastic gateway. Similar to the 'encoded' data from a LoRaWAN sensor.

Suspect it would be a lot of work - but opens up the idea of using remote Tasmota devices/sensors (relays, temperature, ...) e.g. on a large farm, without the need for line-of-sight WiFi links.

[arendst]

And to top it off:

Same decoding as Zigbee devices (notice last seen for sensor and battery). Lot less lines for many devices

[UBWH]

Unreal!

You have been busy.

Love it

[UBWH]

Just got back from overseas ... tried latest nightly dev build

:-)

[UBWH]

Question: With the new-improved Decoder design, there seems no way to get the raw, unencrypted data payload.

If Decoder is present we get the encrypted payload, and the decoded sensor data (e.g.)

08:33:42.462 LOR: Rcvd (5557784) '40B090530080260102F2231B88582B2BB2B4FCC3994F27F0', Freq 915.200, BW 125.0, SF 10, RSSI -27.0, SNR 7.7
08:33:42.474 MQT: tele/LWG-T3S3_5390B0/SENSOR = {"LwDecoded":{"MyLHT52":{"Hum_Internal":64.8,"Ext_SensorConnected":false,"Device":"Dragino LHT52","TempC_Internal":21.8,"Node":1,"Systimestamp":"2025-06-19T07:32:53","Ext_SensorType":1}}}
08:33:43.021 CFG: Lora saved to file

If decoder is NOT present, we only get the encrypted payload (e.g.)

08:42:04.715 LOR: Rcvd (6060038) '40B2905300801500025281AC3C2533B20624CEADEC30', Freq 915.200, BW 125.0, SF 10, RSSI -60.0, SNR 7.2

Is there a way to get/see the unencrypted data payload?

[arendst]

Does SO147 0 work for you?

[arendst]

If not, I could move the decoder up and when no decoding took place, depending on SO147, display the unencrypted data.

[UBWH]

Success with SO147 0

11:11:55.109 MQT: stat/LWG-T3S3_5390B0/RESULT = {"SetOption147":"OFF"}    
11:17:38.226 MQT: tele/LWG-T3S3_5390B0/SENSOR = {"LwReceived":{"MyLHT52":{"Node":1,"Device":"0xAE3D","Name":"MyLHT52","RSSI":-31.0,"SNR":7.7,"Decoder":"LHT52","DevEUIh":"A840414E","DevEUIl":"4F5CAE3D","FPort":2,"Payload":[8,107,2,120,127,255,1,104,83,227,157]}}}

I did NOT make any code changes

[arendst]

Let's keep it this way then. I've tried to make it show LwReceived when LwDecode failed but this fails due to intertwined berry and C MQTT messages. In the end this becomes a mess.

So the current solution will do.

[UBWH]

Question:
If I have set a decoder like this:

14:01:12.188 CMD: lorawandecoder4  xxx.be
14:01:12.191 RSL: RESULT = {"LoRaWanDecoder4":"xxx.be"}

how do I set the decoder back to an empty string ("")?

14:02:37.708 CMD: lorawandecoder4  ""
14:02:37.711 RSL: RESULT = {"LoRaWanDecoder4":"\"\""}
14:02:41.811 CMD: lorawandecoder4  ''
14:02:41.814 RSL: RESULT = {"LoRaWanDecoder4":"''"}

[arendst]

Just fixed to standard Tasmota mode: Use a single quote to reset name like LoRaWanName " and LoRaWanDecoder4 "

[UBWH]

Just built latest DEV version
Program Version 15.0.1.1 (tasmota32)
Build Date & Time 2025-07-08T15:24:16

But this did not work

09:45:52.390 CMD: lorawandecoder6                            <--- never used
09:45:52.393 RSL: RESULT = {"LoRaWanDecoder6":""}  <--- empty string

09:46:01.400 CMD: lorawandecoder1 ''                         <--- try to set to empty string
09:46:01.403 RSL: RESULT = {"LoRaWanDecoder1":"''"}
09:46:02.452 CMD: lorawandecoder1
09:46:02.455 RSL: RESULT = {"LoRaWanDecoder1":"''"}  <--- not empty

[sfromis]

Better read the post by arendst carefully, especially the monospaced examples. To clear the old value, you should use a single quote, not two apostrophes. Here, "quote" is what some call double quotation mark ("), where apostrophe may called single quotation mark (').

[arendst]

Works as designed:

13:02:35.421 CMD: lorawandecoder1
13:02:35.422 SRC: WebConsole from 192.168.2.1
13:02:35.422 CMD: Grp 0, Cmd 'LORAWANDECODER', Idx 1, Len 0, Pld -99, Data ''
13:02:35.436 MQT: stat/t3s3b/RESULT = {"LoRaWanDecoder1":"LDS02"}
13:02:40.078 CMD: lorawandecoder1 "
13:02:40.079 SRC: WebConsole from 192.168.2.1
13:02:40.079 CMD: Grp 0, Cmd 'LORAWANDECODER', Idx 1, Len 1, Pld -99, Data '"'
13:02:40.093 MQT: stat/t3s3b/RESULT = {"LoRaWanDecoder1":""}
13:02:41.535 CFG: Lora saved to file
13:03:05.151 CMD: lorawandecoder1 LDS02
13:03:05.152 SRC: WebConsole from 192.168.2.1
13:03:05.152 CMD: Grp 0, Cmd 'LORAWANDECODER', Idx 1, Len 5, Pld -99, Data 'LDS02'
13:03:05.166 MQT: stat/t3s3b/RESULT = {"LoRaWanDecoder1":"LDS02"}
13:03:06.128 CFG: Lora saved to file

[UBWH]

My mistake!

Works fine.

[UBWH]

I have written a Berry driver to allow node configuration with the WebUI.

Could easily be added to LwDecoder.be

Make a PR? or Not?

[arendst]

I’m currently out of PC access but if you manage to add this to lwdecoder would be nice. I suggest to use 16 tabs as I did with the timers page. It looks like tabs but if you dive in deeper you’ll notice it’s much easier. Lokking forwa d to your pr.

[UBWH]

Just realised that RSSI is not included in LwDecoded MQTT messages

SetOption118 OFF

22:52:13.744 LOR: Rcvd (63506089) '40B190530080D900022797F0D89D1E528F8845D0054538CB', Freq 915.200, BW 125.0, SF 10, RSSI -23.0, SNR 8.8
22:52:13.754 MQT: tele/LWG-T3S3_5390B0/SENSOR = {"LwDecoded":{"D20-LS":{"TempC2":3276.7,"TempC1":16.9,"Node":2,"Device":"Dragino D20","TempC3":3276.7}}}

SetOption118 ON

22:49:52.764 LOR: Rcvd (63365109) '40B190530080D80002A66A60D4AD4F70B9853EA1077DBE9E', Freq 915.200, BW 125.0, SF 10, RSSI -21.0, SNR 7.7
22:49:52.771 MQT: tele/LWG-T3S3_5390B0/SENSOR = {"D20-LS":{"Node":2,"Device":"0x4E9F","Name":"D20-LS","RSSI":-21.0,"SNR":7.7,"Decoder":"D20.be","DevEUIh":"A8404178","DevEUIl":"2B5C4E9F","FPort":2,"Payload":[15,90,0,169,0,0,12,127,255,127,255]}}

As it is (generally) important to monitor BOTH sensor values & RSSI, how do I get both reported to MQTT (without toggling option 118)?

e.g. using my LPS8V2 Dragino gateway I get these MQTT messages:

  "DevEUI": "a8404149f35c4ea0",
  "data": {
    "Distance": 603,
    "Bat": 3.93,
    "Sensor_flag": 1,
    "Interrupt_flag": 0,
    "Node_type": "DDS75-LB",
    "TempC_DS18B20": "327.60"
  },
  "time": "2025-07-22T07:38:41.551993+00:00",
  "fcnt": "10379",
  "fport": "2",
  "rssi": -73
}

[sfromis]

Since each decoder is providing the JSON data going into the LwDecoded structure in the JSON, it will only have the fields from there, and checking the pertinent decoder, I see that the function decodeUplink is called with RSSI as a parameter, but ignoring it when it puts fields into the map for the JSON payload.

Incidentally, I happened to notice that LwDecode.be is a bit broken in not respecting the Tasmota configuration for FullTopic. Here's an example for how this can work:
https://tasmota.github.io/docs/Berry-Cookbook/#build-mqtt-topic-string-based-on-fulltopic-configuration

[arendst]

Thx. Just updated LwDecode.be with "correct" topic code.

[sfromis]

I usually prefer building the topic in init(), instead of issuing commands every time. Of course, you could also lessen the impact in MQTT messages by prefixing commands like _Topic (this feature was introduced later than the example from docs), as setting the silent flag in tasmota.cmd only declutters the Tasmota console itself. Just tweaked the docs example.

[arendst]

Thx again.

[UBWH]

Indeed .. I can modify the Decoder file to include RSSI. Thanks.

But - will wait for Theo in case he has other ideas.

[arendst]

Will pick it up today.

[arendst]

Added RSSI to decoded messages:

11:58:37.901 MQT: tele/t3s3b/SENSOR = {"LwDecoded":{"Dragino LDS02":{"DoorOpen":false,"BattV":3.138,"Alarm":false,"Device":"Dragino LDS02","DoorOpenEvents":47,"Node":1,"RSSI":-93,"DoorOpenLastDuration_mins":0}}}

[UBWH]

Guys,

I have run into a problem integrating the MQTT decoded data into HomeAssistant.

I think the solution is to change the format of the Decoded MQTT to include a unique identifer for every LoRaWAN sensor (= DevEUI)

Today

• we can have 16 different LoRaWAN sensors connected to one Tasmota instance.
• All sensor measurements are reported under ONE MQTT topic like:
  tele/LWG-T3S3_5390B0/SENSOR

{"LwDecoded":{"D20-LS":{"TempC2":3276.7,"TempC1":18.3,"Device":"Dragino D20","Node":2,"rssi":-30,"TempC3":3276.7}}}
{"LwDecoded":{"DDS75L":{"Distance":971,"Device":"Dragino DDS75-LB/LS","Node":3,"BattV":3.942,"rssi":-24}}}
{"LwDecoded":{"LHT52":{"Hum_Internal":50.3,"Ext_SensorConnected":false,"Device":"Dragino LHT52","TempC_Internal":19.49,"Node":1,"Systimestamp":"2025-07-26T12:16:58","Ext_SensorType":1}}}

The problem is that platforms like HomeAssistant (HA) need to have one-topic-per-sensor.

I have a Dragino LPS8v2 gateway that poses a similar problem. I solved that with a 'demultiplexer` which does this:

• Reads the MQTT message
• Re-issues another MQTT message that gives a unique topic per sensor

Example

Original MQTT message:
Topic: LPS8v2/2a748c/SENSOR
Value:

{ "DevEUI": "a84041f35a5c678a", 
  "data": {"Node_type":"DDS75-LB","Bat":3.57,"Interrupt_flag":0,"TempC_DS18B20":"327.60","Distance":0,"Sensor_flag":0}, 
  "time": "2025-07-26T12:15:33.161498+00:00", 
  "fcnt": "95", 
  "fport": "2", 
  "rssi":-32 
}

New MQTT messsage:
Topic: lorawan/dragino_a84041f35a5c678a/data
Value:

{"Node_type": "DDS75-LB", 
 "Bat": 3.57, 
 "Interrupt_flag": 0, 
 "TempC_DS18B20": "327.60", 
 "Distance": 0, "Sensor_flag": 0
}

Comment

• The device (friendly) NAME is not unique enough.
  • If a user changes the NAME, it breaks the display in HA
  • If multiple Tasmota instances report to the same MQTT server, then there becomes a requirement that no two sensors share the same name [Edit]

Suggested fixes to MQTT messages

Topic: Unchanged. e.g.tele/LWG-T3S3_5390B0/SENSOR
Value:

{"LwDecoded":"<devEUI>",
  "data":{"name":"D20-LS","TempC2":3276.7,"TempC1":18.3,"Device":"Dragino D20","Node":2,"rssi":-30,"TempC3":3276.7}
}

I don't like this much as it requires a Demultiplexer = messy, and could be a breaking change

Maybe a better option is a new SetOption to toggle the decoded MQTT message format (Old/New), or to enable an additional new message:
Topic:tele/LWG-T3S3_5390B0/SENSOR/<devEUI> or tele/LWG-T3S3_5390B0/<devEUI>
Value:

{ "name":"D20-LS",
 "TempC2":3276.7,
 "TempC1":18.3,
 "Device":"Dragino D20",
 "Node":2,
 "rssi":-30,
 "TempC3":3276.7
}

This is better as no demultiplexer needed: Topic is unique per sensor

Comments?

[arendst]

Does latest change to LwDecode using SetOption83 1 solve your issue?

[UBWH]

Not really:

SO83 OFF

14:26:31.512 MQT: tele/LWG-T3S3_%06X/SENSOR = {"LwDecoded":{"DDS75L":{"RSSI":-24,"Node":"DDS75L","rssi":3,"Device":"Dragino DDS75-LB/LS"}}}
14:26:49.631 MQT: tele/LWG-T3S3_%06X/SENSOR = {"LwDecoded":{"D20-LS":{"RSSI":-30,"Node":"D20-LS","rssi":2,"Device":"Dragino D20"}}}

SO81 ON

14:31:06.693 MQT: tele/LWG-T3S3_5390B0/STATE = {"Time":"2025-07-26T14:31:06","Uptime":"0T00:05:18","UptimeSec":318,"Heap":234,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":20,"Objects":271},"POWER":"ON","Wifi":{"AP":1,"SSId":"UniFi","BSSId":"DC:9F:DB:1C:E0:60","Channel":11,"Mode":"HT40","RSSI":100,"Signal":-41,"LinkCount":1,"Downtime":"0T00:00:03"}}

14:31:31.434 MQT: tele/LWG-T3S3_%06X/SENSOR = {"DDS75L":{"RSSI":-25,"Node":"DDS75L","rssi":3,"Device":"Dragino DDS75-LB/LS"}}
14:31:49.535 MQT: tele/LWG-T3S3_%06X/SENSOR = {"D20-LS":{"RSSI":-30,"Node":"D20-LS","rssi":2,"Device":"Dragino D20"}}

1. Something has broken the MQTT topic:tele/LWG-T3S3_%06X/SENSOR should be tele/LWG-T3S3_5390B0/SENSOR in my case
2. I could write a DeMux in HA to convert

tele/LWG-T3S3_5390B0/SENSOR {"D20-LS":{"RSSI":-30,"Node":"D20-LS","rssi":2,"Device":"Dragino D20"}}

to

tele/LWG-T3S3_5390B0/D20-LS {"RSSI":-30,"Node":"D20-LS","rssi":2,"Device":"Dragino D20"}

but using the name (D20-LS) is asking for things to break if the user changes the name.

PS: I see I also need to update the Deice Decoder files (I only upgraded LwDecode.be to do this quick test) but that will not change my comments.

Is there a mechanism for Berry to get the devEUI? If so .... I will have a go at getting the change I need into LwDecode.be

[arendst]

Something has broken the MQTT topic:tele/LWG-T3S3_%06X/SENSOR should be tele/LWG-T3S3_5390B0/SENSOR in my case

Yes, the topic has been updated according to a "documented" procedure but I see it fails replacing %06X. I'll see how to fix this.

The way you use names is questionable as one could also decide to use unique names per receiver like I dor for the mailbox at the road:

But in the end we probably need to add SO89 and SO125 like being used in zigbee and LoRaWan internal decoders. This is, again based on unique names.

[arendst]

Is there a mechanism for Berry to get the devEUI?

The most obvious solution is to add it to the LwReceived massage currently being send to LwDecode.

EDIT: It's already there as DevEUIh and DevEUIl

[arendst]

OK.

Using latest LwDecode.be you'll get this result:

16:53:24.739 HTP: Console
16:53:27.818 MQT: tele/t3s3b_E19A90/SENSOR = {"LwDecoded":{"Dragino LDS02":{"RSSI":-84,"Node":1,"Alarm":false,"Device":"Dragino LDS02","DoorOpenEvents":75,"DoorOpen":false,"BattV":3.132,"DoorOpenLastDuration_mins":2}}}
16:53:28.817 CFG: Lora saved to file
16:53:40.129 CMD: so89 1
16:53:40.129 SRC: WebConsole from 192.168.2.1
16:53:40.129 CMD: Grp 0, Cmd 'SO', Idx 89, Len 1, Pld 1, Data '1'
16:53:40.132 MQT: stat/t3s3b_E19A90/RESULT = {"SetOption89":"ON"}
16:53:40.712 CFG: Saved, Count 152, Bytes 4096
16:53:44.367 MQT: tele/t3s3b_E19A90/SENSOR/A840410E71894AD6 = {"LwDecoded":{"Dragino LDS02":{"RSSI":-84,"Node":1,"Alarm":false,"Device":"Dragino LDS02","DoorOpenEvents":76,"DoorOpen":true,"BattV":3.132,"DoorOpenLastDuration_mins":2}}}
16:53:45.418 CFG: Lora saved to file
16:53:52.779 CMD: so89 0
16:53:52.779 SRC: WebConsole from 192.168.2.1
16:53:52.780 CMD: Grp 0, Cmd 'SO', Idx 89, Len 1, Pld 0, Data '0'
16:53:52.782 MQT: stat/t3s3b_E19A90/RESULT = {"SetOption89":"OFF"}
16:53:53.351 CFG: Saved, Count 153, Bytes 4096
16:53:56.570 MQT: tele/t3s3b_E19A90/SENSOR = {"LwDecoded":{"Dragino LDS02":{"RSSI":-87,"Node":1,"Alarm":false,"Device":"Dragino LDS02","DoorOpenEvents":76,"DoorOpen":false,"BattV":3.138,"DoorOpenLastDuration_mins":0}}}

Notice the use of SetOption89

[UBWH]

Fantastic .... will give it a try

[UBWH]

Worked perfectly. Thank you!

22:21:26.572 MQT: tele/LWG-T3S3_5390B0/SENSOR/A8404149F35C4EA0 = {"DDS75L":{"Distance":974,"RSSI":-25,"Node":3,"BattV":3.948,"Device":"Dragino DDS75-LB/LS"}}
22:21:45.180 MQT: tele/LWG-T3S3_5390B0/SENSOR/A84041782B5C4E9F = {"D20-LS":{"TempC2":3276.7,"TempC1":17.3,"RSSI":-33,"Device":"Dragino D20","Node":2,"TempC3":3276.7}}

But .. this page no longer highlights the selected Node. [I see the selected node number goes BOLD on selection - but that is easy to miss]

Not sure which update caused that but must have something to do with this change
OLD

  webserver.content_send(
     "<style>.inactive{background:#10537c;}.active{background:#1fa3ec;}</style>"

NEW

 webserver.content_send(
     "<style>"
     ".tl{float:left;border-radius:0;border:1px solid var(--c_frm);padding:1px;width:12.5%;}"
     ".tl:hover{background:var(--c_frm);}"
     ".inactive{background:var(--c_tab);color:var(--c_tabtxt);font-weight:normal;}"
     ".active{background:var(--c_frm);color:var(--c_txt);font-weight:bold;}"
     "</style>"

[arendst]

You'll need to update tasmota firmware too. It now contains the colors as CSS variable which makes accessing the tasmota gui colors from berry a lot easier.

[UBWH]

Yep - that worked

[ZioFabry]

Sorry guys... I worked on @UBWH code without partecipate on this thread... my fault....