Open JWhiteUX opened 2 years ago
phlupp
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago No need, I'll be investigating this tomorrow.
phlupp
commented
2 years ago 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
commented
2 years ago 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?
it appears that the following hex is having issues being read/displayed.
https://mappers.helium.com/uplinks/hex/8929a198ec3ffff