Vraag

LoRa downlink messages komen verkeerd aan

  • 12 July 2017
  • 15 reacties
  • 1512 keer bekeken

Hoi,

Ik ben al een paar dagen bezig berichten te versturen naar een arduino via LoRa. Hier zijn heel wat problemen aan vooraf gegaan, maar sinds vandaag kan ik ook daadwerkelijk berichten versturen. Nu heb ik alleen het volgende probleem en ik kom er niet uit. Het contact kan gemaakt worden en mijn arduino krijgt ook de berichten binnen, alleen als ik meerdere malen hetzelfde bericht stuur krijg ik verschillende responses terug. Deze responses lijken volledig random en geven niet de payload weer die ik wil verzenden. Hierom denk ik dat ik iets fout doe bij het maken van de token.

Hieronder heb ik een voorbeeld van het versturen van een bericht (alleen DevEUI anoniem gemaakt):
[
'DevEUT' => '0000000000000000',
'FPort' => (int) 1,
'Payload' => '3535',
'AS_ID' => 'asidnnts',
'Time' => '2017-07-12T20:00:13.020+02:00'
]
Deze dingen voeg ik samen om te hashen:
DevEUT=0000000000000000&FPort=1&Payload=3535&AS_ID=asidnnts&Time=2017-07-12T20:00:13.020+02:00

De as-key die ik gebruik is:
65b8a22af9e1042bfca017de9f419e35

Hier komt de volgende token uit:
14795a728cbf9722203fff70e5e8aabc5ba610de0fa843df5efc1debc379a804

Dus de post doe ik naar:
https://api.kpn-lora.com/thingpark/lrc/rest/downlink?DevEUT=0000000000000000&FPort=1&Payload=3535&AS_ID=asidnnts&Time=2017-07-12T20:00:13.020+02:00&Token=14795a728cbf9722203fff70e5e8aabc5ba610de0fa843df5efc1debc379a804

Ik gebruik de volgende curl instellingen:
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => '',
CURLOPT_URL => Configure::read('LoRa.downlinkUrl') . '?' . http_build_query($query),
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_FOLLOWLOCATION => true,

Deze call gaat goed en ik krijg een message: Request queued by LRC
Dit gaat dus goed.

Maar ik krijg op mijn device rare pakketjes binnen die ook nog eens verschillen van mekaar, terwijl de payload constant hetzelfde is.

Kan iemand mij vertellen wat ik fout doe, zodat ik dit probleem snel kan verhelpen?

Groet,
Christian

15 reacties

Reputatie 7
Badge +11
Beste @ErikV, sorry ik heb uw bericht gemist. Hebt u inmiddels support ontvangen en lukt het om verder te gaan?
Helaas heb ik ook een probleem met onleesbare downlink-berichten.

Op poortnummer 1 werkt het allemaal prima, payload data komt aan bij de node zoals het bedoeld is. Echter bij hogere poortnummers klopt de lengte van de payload wel, maar de inhoud is steeds verschillend.

Ik gebruik een betaald Lora abonnement.

Wat doe ik fout?
Een paar voorbeelden, steeds voor device 0059AC00001716F6. Er is steeds FFFF naar het device gestuurd, die payload komt ook steeds aan. In de Thingpark Wireless Logger zien we bij de downlinks steeds de volgende data terug: 490e, c6f1, 917d en 5edc. Allemaal vandaag verstuurd (13-12-2017) tussen 11:53 en 12:28 Duch Time.
Reputatie 7
Badge +11
@RutgerS, als u hier informatie over kunt verzamelen, help ik u graag met uitzoeken van de verklaring! Als we weten welke berichten afwijken, dan laat ik de technische dienst daar naar kijken!
Willekeurig zal het niet zijn 🙂.
Zal ik dieper in KPN eens een Poke wagen?
Reputatie 7
Badge +11
Hi @RutgerS, ik weet hier niet direct de verklaring voor te geven. Wat kan ik mij voorstellen bij de tijdsafhankelijkheid? Zijn er bepaalde tijdsperiodes waarop het anders gaat of is het geheel willekeurig?
Dank voor je reactie Tim.
De payload encryptie is mij duidelijk.
In de Thingpark wireless logger zijn zowel de verstuurde uplink en downlink te zien. Inzomen op die messages laat de data (de payload zelf) zien.
Bij de uplink is dit de originele data, bij de downlink is deze (tijdsafhankelijk) gecodeerd. Ik zoek een verklaring waarom dat zo is.
Reputatie 7
Badge +11
Hi @RutgerS,

Fijn dat u inmiddels verder bent gekomen!

Om eerlijk te zijn is het issue met @christianspijkerboer destijds door de technische dienst verder opgepakt. Ik weet even niet wat hier uiteindelijk uit is gekomen.

Zowel uplink als downlink berichten zijn gesigned met een SHA token. Bedoelt u dit misschien?
Hi Tim,

We zien inmiddels dat de downlink wel goed in het oorspronkelijke formaat aankomt in het device. Ze staan alleen in Thingpark "gecodeerd", terwijl de uplink niet "gecodeerd" is.
Is daar een reden voor?
Hi Tim,

Was dit probleem al opgelost? Wij hebben hetzelfde probleem namelijk.
Payload die we naar Thingpark sturen, zien we in Thingpark terug met dezelfde lengte, maar steeds weer anders. Als we "00" Hex sturen, zien we respectievelijk "7A", "3C" en "99" terug.
Er is helaas niet zoveel leesbaar hierover. In de technische documentatie van Thingpark staat dat we de payload Hex moeten meegeven.
Reputatie 7
Badge +11
Het beste antwoord heb ik even ongedaan gemaakt.

Helaas heb ik nog steeds moeite met het vinden van je account. Wil je mij anders in een privébericht meer gegevens sturen? Gelieve jouw Thingpark ID (login) en ook e-mailadres.
O ik druk op iets verkeerd, mijn probleem is nog niet opgelost!

Het is voor het bedrijf NNTS, onze customer id is nnts 001 (zo uit mijn hoofd)
Reputatie 7
Badge +11
Hi @christianspijkerboer,
Ik ben even vergeten dat ik niet op DevEUI kan zoeken in Thingpark 😱
Sorry, op welke bedrijfsnaam staat het account?
Hoi Tim, erg bedankt voor de reactie!
Ik heb namelijk nog geen voortgang geboekt, ik kan nog steeds uplinks van mijn device ontvangen en downlinks versturen, maar ik krijg niet de data binnen op mijn device van de downlinks die ik verwacht.

Ik heb mijn DevEUI ingevuld als mijn klantnummer. Let wel dat ik in bovenstaand voorbeeld de verkeerde devEUI gebruikt heb om te de token te genereren, zodat jullie dit na konden doen.

Hopelijk kunnen jullie me snel verder helpen! Groet, Christian
Reputatie 7
Badge +11
Hi Christian, welkom op het LoRa Forum van KPN! 😃
Goed om te lezen dat het u lukt om berichten te ontvangen en te versturen. Dat zou in feite betekenen dat u alles goed doet. In de post zie ik dan ook niet direct een fout terug. Om beter met u mee te denken, wilt u uw DevEUI invullen in het klantnummer veld in uw forum profiel? Daarmee kan ik en mijn collega's uw account opzoeken en met u meekijken. Indien het nodig is om hiervoor hulp van een specialist te vragen, hebben we meteen uw gegevens erbij.

Ik zie graag uw reactie, hopelijk hebt u inmiddels alweer voortgang geboekt?

Reageer