Beantwoord

Lora https endpoint

  • 11 January 2023
  • 28 reacties
  • 357 keer bekeken

Hallo,

Sinds 10 januari na 13:25 lijkt het formaat van de data wat naar het HTTP endpoint gaat gewijzigd, 
voor die tijd zag het er zo uit:
[{"bn":"urn:dev:DEVEUI:....:","bt":1.667058215E9},{"n":"payload","vs":"....."},{"n":"port","v":2.0},{"n":"TIME_ORIGIN","vs":"THINGSENGINE"}]
na die tijd:
[{"bn":"urn:dev:DEVEUI:....:","bt":1.673357143769e9,"n":"payload","vs":"...."},{"n":"port","v":2.0},{"n":"timeOrigin","vs":"NETWORK"}]
Geen probleem, programmatuur aangepast waardoor het weer werkte. 

Elk half uur stuur ik data door maar tot mijn verbazing zie ik tussen 10-1-2023  13:25 en nu (11-1-2023 21:50) dat er zes keer toch weer data wordt verstuurd in het 'oude' formaat.
Hoor graag hoe dat mogelijk is :-)

Met vriendelijke groet,
Frans
 

icon

Beste antwoord door Rick S. 24 January 2023, 09:39

Bekijk origineel

28 reacties

Reputatie 7
Badge +6

Goodmorning @adekam,

Great to hear, thank you! 
If you have any other questions, feel free to create a new topic. 

@Rick S.  Can confirm, thanks for the updates.

Reputatie 7
Badge +6

Hey @adekam

Thanks for the message!
I understand that the second update to the network was completed this week. So it should work fine now and you shouldn't see any difference in the messages anymore.

Hi Rick, any news from the specialists yet? It’s been another week now and we’ve been missing quite some data that we have to put significant effort into getting it to our platform another way.

 

Reputatie 7
Badge +6

Hey Arie, 

Thanks for your message!
I think the question is still relevant so no need to start a new topic with this question. Following your response above, I have asked the specialists to assist in answering these questions. For now, I can confirm that the first update was completed on 16-05. For the other questions I am still waiting for an answer from the specialists. It's taking longer than usual because there were a few high priority projects. Our apologies!

Hi @Rick S. 

This thread has been marked as ‘Answered’, so please let me know if I should start a new thread with my question above, or if it's still relevant to this discussion. Could you have a look at it?

Kind regards,

Arie

Hi Rick,

Was one of the updates on 16-05-2023 by any chance?
We had some odd behaviour with our devices. A short description:

< 16-05-2023 08:53 normal situation

22-05-2023 we were alerted that the destination for the devices was changed, and instead of */iot it was now *//iot
22-05-2023 we changed the destination URLs back to */iot
22-05-2023 requests were coming in again, but failing parsing. Payload bodies were raw hex values, where before they were JSON formatted. Running the hex values through a hex-ascii converter like: https://gchq.github.io/CyberChef/#recipe=From_Hex('Auto') we see the familiar body again.
The headers for the failing and successful requests differ.:
 

missing in failing request: “accept”, “accept-encoding”, “content-type”, “things-plug-uuid”,
different: user-agent & x-amzn-trace-id

All these devices are still in our freemium project.

The decoders are set as follows, and have not been modified since creating them:

  • Could you clarify where the URL change came from?
  • Could you explain why the request headers differ?

Kind regards,

Arie

Reputatie 7
Badge +6

Good afternoon everyone,

I have been in contact with the specialists again and I understand that a definitive solution has now been found for this problem. This will roll out with 2 updates on the network. The first has already been done and the second will follow soon. Soon this problem will no longer occur.

Hi Rick,

 

Thanks! 

Reputatie 7
Badge +6

Hey Filip, 

Thanks for your patience! 
I understand that my colleagues are going to research this issue further next week. So hopefully I can give a substantive update on the issue and the solution next week

Reputatie 7
Badge +6

Hey Filip,


I have previously raised this issue with our specialists and they indicated that further investigation should be done. However, at that time there were other matters with a higher priority. I can't say what the situation is now. I retransmitted the issue. If I get feedback, I will of course get back to you.

Hi Rick,

 

We have just ran into this problem ourselves. Sometimes a device reports as expected (the expected json object) while sometimes it reports the full payload in hex format.

 

Best,

Filip

Reputatie 7
Badge +6

Goedemiddag @adekam & @FransP,

Na jullie reacties van donderdag heb ik dit signaal gelijk doorgezet naar de specialisten. Ik kreeg vanochtend de reactie dat zij dit weer verder willen gaan onderzoeken. Het is alleen op dit moment niet duidelijk wanneer dit afgerond kan worden i.v.m. meerdere projecten. 

Hallo Rick,

Bij mij zie ik het nog dagelijks 1 of meerdere keren fout gaan, na 21-2 geen verbetering dus.

Groet,
Frans

Bij ons geeft het inderdaad problemen sinds 21-02, omdat in de nieuwe opmaak de header “content-type”:”application/json” niet meer standaard mee wordt gegeven. Dit is soms wel / soms niet het geval, en de webhook waar wij mee werken interpreteert de data dan als 1 hex waarde waardoor onze parser faalt.

Ik zou er wat dieper in moeten duiken hoe vaak het wel / niet goed gaat. Maar zo op eerste inspectie lijkt het dat de locatieberichten wel die header meegeven, maar de payload maar een enkele keer, en de body is dan nog in de oude opmaak.

Reputatie 7
Badge +6

Goedemorgen @adekam,

Geen probleem om aan te haken hoor!
Ik ben er weer even achteraan gegaan en ik heb begrepen dat de fix sinds 21-02 geïmplementeerd is.  De berichten zouden nu dus alleen in de nieuwe opmaak verwerkt moeten worden. 

Als je dit niet zo ervaart of tegen andere zaken aanloopt hoor ik het graag en gaan we het natuurlijk verder onderzoeken. 

Dag Rik,
Ik haak maar even aan in dit topic. Heb je al meer zicht wanneer de fix er is?
Naast het feit dat de request body anders is geformeerd, zijn ook de headers anders van de twee requests.
Zo was de “content-type” header altijd gedefineerd, en is dat in de nieuwe structuur niet meer zo.

 

Reputatie 7
Badge +6

Goedemorgen Frans, 

Na het navragen bleek mijn vermoeden correct. De fix is nog niet helemaal geïmplementeerd. Bij deze fix werden er direct nog wat andere zaken meegenomen, waardoor het wat tijd nodig heeft. Het gaat nu echter niet lang meer duren. Als het goed is krijg ik ook nog een berichtje als het zo ver is. 

Reputatie 7
Badge +6

Goedemorgen Frans, 

Excuses voor de late reactie! 
Na het laatste bericht van de specialisten heb ik (nog) niet de bevestiging gekregen dat het opgelost is, dus fijn dat je het meld. Ik ga er van uit dat het nog in behandeling is (ook al had ik eerlijk gezegd ook al de oplossing verwacht). Natuurlijk geef ik dit signaal weer door.

...en nog steeds niet goed, het lijkt een lastig probleem 😏

...helaas het gaat nog steeds fout 😒

Hallo Rick S.,

Goed te horen dat de oorzaak gevonden is.
Sinds gistermiddag 12:05 zie ik het ook niet meer fout gaan, het lijkt dus opgelost te zijn.

Bedankt weer voor het uitzoeken en met vriendelijke groet,
Frans

 

Reputatie 7
Badge +6

Goedemorgen Frans, 

Ik heb inmiddels weer een terugkoppeling gekregen van de specialisten en er blijkt inderdaad wat mis te gaan. Er wordt op dit moment bij elk bericht van een device een nieuwe flow gegenereerd en opgeslagen. Wanneer er ongeveer tegelijkertijd een locatie-bericht en een payload-bericht binnenkomen (wat gebruikelijk is) ontstaat er een zogeheten race-conditie. Als de payload als eerst wordt verwerkt, gaat de payload SenML in de nieuwe opmaak en de locatie in het oude formaat. Als het locatie-bericht eerder is gaat het andersom. De reden hiervoor is dat de flow tegelijkertijd wordt geüpdatet, wat niet mag en waardoor er een exception optreedt. Gelukkig is dit nu boven water en wordt er gewerkt aan een oplossing. 

Hallo Rick S. ,

Dank voor je reactie.

De destination is niet offline geweest en ook nu gaat het nog regelmatig mis, van de laatste drie dagen heb ik even de tijden erbij gezocht waarbij ik verkeerde formaat binnenkreeg:
14/01/2023 14:28:27 , 14/01/2023 16:28:31 , 14/01/2023 16:58:32 , 15/01/2023 05:28:53 , 15/01/2023 06:28:54 , 15/01/2023 06:58:55 , 15/01/2023 17:29:13 , 15/01/2023 19:29:16 , 15/01/2023 22:29:21 , 16/01/2023 03:29:30 , 16/01/2023 09:59:41 , 16/01/2023 12:59:46 , 16/01/2023 19:29:57 , 16/01/2023 21:30:00 , 17/01/2023 01:30:07

Elk half uur stuur ik meetgegeven door en meestal gaat het dus goed :-)  De parser heb ik aangepast zodat deze met beide formaten overweg kan maar ergens gaat er dus iets mis lijkt me.

Met vriendelijke groet,
Frans

Reputatie 7
Badge +6

Goedemorgen @FransP,

Toen ik het topic tegen kwam ben ik dit ook na gaan vragen bij de specialisten. Ik kreeg de volgende terugkoppeling: 

Als de destination onbereikbaar is geweest kan het zo zijn dat het tot 24 uur later afgeleverd wordt. Dat zou dan zijn gestart in de legacy tak en dan 24 uur later daar ook worden afgehandeld. Op 10 januari is de nieuwe FlowEngine live gezet, dus dat lijkt overeen te komen. Meer informatie over de wijziging is te vinden op de Upcoming changes in KPN SenML pagina. 

Reageer