Unable to Read Hex Properties - Bug(?)

[JWhiteUX]

it appears that the following hex is having issues being read/displayed.

https://mappers.helium.com/uplinks/hex/8929a198ec3ffff

[phlupp]

Same issue here

https://mappers.helium.com/uplinks/hex/891f134cdb7ffff

Error message: TypeError: Cannot read properties of undefined (reading 'timestamp')

The API call returns a empty record
https://mappers.helium.com/api/v1/uplinks/hex/891f134cdb7ffff

It seems to affect hexagons which were updated by the same device

[phlupp]

May be it is a bit different

The API returns different results:

Error TypeError: Cannot read properties of undefined (reading 'map')
https://mappers.helium.com/api/v1/uplinks/hex/8929a198ec3ffff

returns:
"Internal Server Error"

It seems to bee the same issue as in #104

Error TypeError: Cannot read properties of undefined (reading 'timestamp')
https://mappers.helium.com/api/v1/uplinks/hex/891f134cdb7ffff

returns:
{ "uplinks": [] }

Should I open a new issue for this?

[kent-williams]

No need, I'll be investigating this tomorrow.

[phlupp]

Just a bit more information I figured out:

in the case of https://mappers.helium.com/api/v1/uplinks/hex/891f134cdb7ffff this hex was updated by a tracker build by me. I just noticed that the integration return a Uplink Insert Error in Helium Console.

The reason was that altitude was provided as FLOAT and not as requested as INT.

It seems that https://mappers.helium.com/api/v1/ingest/uplink creates an empty data record even it repots an insertation error.

Maybe this issue can be already prevented in the uplink API

[danak6jq]

I ran into the "altitude must be an int" issue as well with a DIY tracker emulating an LGT-92. The standard LGT-92 decoder (as provided in the Helium Mappers Quick-Start https://docs.helium.com/use-the-network/coverage-mapping/mappers-quickstart ) does not make sure the 'altitude' attribute is an int - the Dragino LGT-92 uplink spec encodes this as a 'meters * 100' value, and if the mote encodes a non-integral value, that's what the decoder passes to Mappers.

Most people will configure their LGT-92 SGM=0, i.e., limit UL packet size to 11 bytes and omit pitch/roll and altitude. Of course over-achiever me haplessly built my mote to send the 15-byte UL without rounding altitude to an integral value and Mappers returns an error 400 when the altitude isn't an integral value. Experimentally, I use Math.round() in the LGT-92 decoder and that fixed Mappers integration (I'll update the mote to do this in the sent value).

[ To be fair, 0.01m resolution is pointless, GPS altitude accuracy is more like 10m ]

Is there any reason Mappers doesn't simply round an otherwise valid numerical value here instead of rejecting the request?