Host cluster failed to handle message: no device matches uplink

[GusVanherfH3OT]

Hi all

I read some topics already regarding this issue, but i didn’t find a solution or a workaround for the time being. The situation is the following:
I had a working setup in TTN v2 with sensors and gateways configured in v2. Now, i added the same gateway to TTN v3 and i created a new application for the same sensor, also in TTN v3.
When i try push the data throught the v3 gateway, i have 2 problems:

1. the v2 sensor uplink is not handled in the v2 application anymore
   
   
2. the v3 sensor is also not handled by the v3 application:
   
   

> {
>   "name": "gs.up.drop",
>   "time": "2021-05-03T15:59:53.864448959Z",
>   "identifiers": [
>     {
>       "gateway_ids": {
>         "gateway_id": "a840411f6cdc4150",
>         "eui": "A840411F6CDC4150"
>       }
>     }
>   ],
>   "data": {
>     "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
>     "namespace": "pkg/gatewayserver",
>     "name": "host_handle",
>     "message_format": "host `{host}` failed to handle message",
>     "attributes": {
>       "host": "cluster"
>     },
>     "cause": {
>       "namespace": "pkg/networkserver",
>       "name": "device_not_found",
>       "message_format": "device not found",
>       "correlation_id": "d23f5d33e5d0418da344fd422067ce2f",
>       "cause": {
>         "namespace": "pkg/networkserver/redis",
>         "name": "no_uplink_match",
>         "message_format": "no device matches uplink",
>         "code": 5
>       },
>       "code": 5
>     },
>     "code": 5
>   },
>   "correlation_ids": [
>     "gs:conn:01F4S0R5GF7MX41C2KTCRTFGBC",
>     "gs:up:host:01F4S0R5GNWM2KQXP6DMSMRS7X",
>     "gs:uplink:01F4SFA5ZX16Y099CBGHKKCSZC"
>   ],
>   "origin": "ip-10-100-12-248.eu-west-1.compute.internal",
>   "context": {
>     "tenant-id": "CgN0dG4="
>   },
>   "visibility": {
>     "rights": [
>       "RIGHT_GATEWAY_TRAFFIC_READ"
>     ]
>   },
>   "unique_id": "01F4SFA608CE22V3BH3G3F921C"
> }

Now, what can be an explanation for this? The gateway is not forwarding the proper uplink json structure as documented here: https://www.thethingsindustries.com/docs/the-things-stack/concepts/data-formats/ ? Something else?

And what can be a workaround?

1. keep my gateway & sensor in TTN v2? But what if the cluster shuts down?
2. Wait for new FW on the gateway? I already reached out to Dragino.
3. wait for TTN to handle these uplink json just like they did in TTN v2?
4. Something else?

Thanks already a lot in advance for your input!
Kind regards
Gus

[descartes (Nick McCloud)]

@GusVanherfH3OT

the v2 sensor uplink is not handled in the v2 application anymore

This is a screen shot of the v3 console so it’s not showing the v2 sensor uplink not being handled by v2 application. It’s just showing a non-matching uplink in the v3 console.

It is a TTN v2 DevAddr which would need entering in to the v3 setup if that is your device and it’s on ABP.

@GusVanherfH3OT

the v3 sensor is also not handled by the v3 application:

That’s not a TTN DevAddr so expected not to match.

I don’t think any workaround is needed - many of us now have devices on both v2 & v3 with gateways on both and it’s routing fine.

What is your device?
Did you put new keys in to your device?
How is the device configured and if it’s on ABP, what is its DevAddr?
Did you tell your gateway to point to the new v3 address?
Which Dragino gateway model do you have?
What firmware is it running?

[GusVanherfH3OT]

Hi Descartes

THanks for your reply!

@descartes

This is a screen shot of the v3 console so it’s not showing the v2 sensor uplink not being handled by v2 application. It’s just showing a non-matching uplink in the v3 console.

It is a TTN v2 DevAddr which would need entering in to the v3 setup if that is your device and it’s on ABP.

There is no data coming in anymore on the v2 application, so not really sure what you want to see? Last update was from this afternoon.

How do i add the DevAddr in the v3 setup?

For the new v3 sensor, i created a new devaddr, nwkskey & appskey and put it in the sensor, and now the sensor is indeed seen ONCE. But there is a different error:

{
  "name": "gs.down.send",
  "time": "2021-05-03T17:23:54.400797040Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "a840411f6cdc4150",
        "eui": "A840411F6CDC4150"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
    "raw_payload": "YOtTCyaAAAAAWsctyH/7FzkFWW+Fx0Sqk1GNmbXTkC5CzFXtrLtK53I8G1Q3uJRz7KSGXRAq37w=",
    "request": {
      "downlink_paths": [
        {
          "uplink_token": "Ch4KHAoQYTg0MDQxMWY2Y2RjNDE1MBIIqEBBH2zcQVAQw769zgMaDAip48CEBhDQ4MXRAyC4u7CQnY0F"
        }
      ],
      "rx1_delay": 1,
      "rx1_frequency": "868100000",
      "rx2_frequency": "869525000",
      "priority": "HIGHEST",
      "frequency_plan_id": "EU_863_870"
    },
    "correlation_ids": [
      "gs:conn:01F4S0R5GF7MX41C2KTCRTFGBC",
      "gs:up:host:01F4S0R5GNWM2KQXP6DMSMRS7X",
      "gs:uplink:01F4SM3ZZR0AG500J93DWCJ5TE",
      "ns:downlink:01F4SM40D026SE8SY9MXGRE2JZ",
      "ns:uplink:01F4SM3ZZSMM66TATGHYFYWT6B",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F4SM3ZZSC7G1K9BKW23W1FBG",
      "gs:conn:01F4S0R5GF7MX41C2KTCRTFGBC",
      "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01F4SM40D0CZK0XVM46N07NQ0M"
    ]
  },
  "correlation_ids": [
    "gs:conn:01F4S0R5GF7MX41C2KTCRTFGBC",
    "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01F4SM40D0CZK0XVM46N07NQ0M"
  ],
  "origin": "ip-10-100-12-248.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F4SM40D0DFR2C7E2XCS77HG5"
}

Even though data should come in every 2 minutes, that’s currently not happening. The sensor is only seen once.

@descartes

What is your device?
Did you put new keys in to your device?
How is the device configured and if it’s on ABP, what is its DevAddr?
Did you tell your gateway to point to the new v3 address?
Which Dragino gateway model do you have?
What firmware is it running?

• it’s a beco-x water sensor: BECO X, Ultrasonic Water Meter, China, Factory, Suppliers, Manufacturers
• New keys are put in the sensor
• ABP, devaddr is now 26:0B:53:EB
• yes, the gateway is to the right v3 adr (eu1.cloud.thethings.network)
• Dragino LG02 (just a small one to do some testing). The plan is to move to the LG308.
• FW/ lgw-5.4.1609858793

Thanks!!
Gus

[descartes (Nick McCloud)]

@GusVanherfH3OT

There is no data coming in anymore on the v2 application, so not really sure what you want to see?

You made a statement about the v2 console but provided a picture of the v3 console …

@GusVanherfH3OT

Dragino LG02 (just a small one to do some testing

That’s not a gateway, that’s what we call a Dual Channel Packet Forwarder, the big and equally illegitimate brother of the Single Channel Packet Forwarder. These are detrimental to the network, which strangely enough, you’ve just discovered and as they are so disruptive, we ask people to disconnect them immediately.

Your device expects to transmit on any of 8 channels to a gateway that can listen for activity on 8 channels & the associated spreading factors simultaneously. A DCPF can only hear two channels and it’s ability to operate CAD makes it’s ability to listen on those two channels across all the SF’s is questionable.

So, turn off the LG02, return to vendor and await your LG308.

As for the error message, a quick forum search will reveal the information you need.

[GusVanherfH3OT]

1. after re-adding it as an OTAA device following the Best Practices | The Things Stack for LoRaWAN, the issue is resolved.
2. as i read somewhere, i will move the v2 application to the v3 and also configure it OTAA.

Thanks for your replies, Descartes.

[descartes (Nick McCloud)]

Your use of a DCPF is unacceptable and will lose uplinks as much as ABP does, so not only have you not solved the problem, you continue to disrupt the community network.

@GusVanherfH3OT

i will move the v2 application to the v3 and also configure it OTAA.

This makes no sense what so ever, there is no concept of configuring an application for OTAA.

[GusVanherfH3OT]

Descartes

As said, we will go with a proper lorawan gateway that follows the guidelines, so no worries.
As much as I appreciate you taking the time to read through my issue and commenting on it, maybe it can also be done in a constructive way.
If I would have al the answers, I would not als the questions on this forum.

With moving the application, I indeed mean configure the device otaa.
So with a good lorawan gateway and the sensor linked, I guess the issue is resolved? Or are there other enhancements that you see?

Cheers
Gus

[descartes (Nick McCloud)]

Your response brazenly ignored my request to disconnect your LG02, so I’m not sure what sort of response you could possible expect.

As such I am being constructive to the entire community by making it clear that non-gateway devices are not to be linked to TTN. What if your devices were suddenly unable to uplink because we stopped warning users about the impact of these non-compliant transceivers?

We don’t expect people to come here with all the answers, I learn new things weekly, often daily, but we do ask that those that ask questions are guided by the answers given, however inconvenient they may be. LoRaWAN has many nuances that can not be picked up with the setup of a device & gateway so it is important that the shared radio waves are properly managed. If it appears someone is not clear on the key concepts, for the good of the community, the community must highlight gross errors in concepts, nomenclature or configuration.

[bluejedi]

@GusVanherfH3OT

maybe it can also be done in a constructive way.

Let me be a bit more clear here. Please read the following:

Single Channel Packet Forwarders are deprecated and NOT Supported [guidelines]

@descartes actually has been very constructive and polite.

[GusVanherfH3OT]

Okay, thanks guys for the input.
So next step is to switch to a proper lora gateway (TTN indoor gateway or the Dragino LPS8)

Kind regards
Gus