I couldn’t find any posts specifically related to this duplication of traps. I believe this may have resulted from the “Heartbeat” creating secondary traps within lines, as we include “Sensor Provider” information for the nodes. I’ve attached a screenshot of the fault, which shows 2xEdgar012, 2xEdgar017 and 2x Edgar117. There is only one of these traps in the field, but TrapNZ creates a duplication of these if I retire any other traps in this line. It’s not unmanageable, however does require the trapper to go back to the main screen to to then be able to sign the remaining traps off.
App version: 6.0.10
I have tried reinstalling the app, cleared my cache and tried signing in and out as well as synchonising the project. Other uses have the same fault.
Kia ora Emma,
I am seeing the same thing for those same traps. We’ll take a look and be in touch.
Thanks Andy. There is another issue, which I can’t tell if it’s linked to this problem or not, but there has been no heartbeat since 21st July for those traps. Our comms to our network are still working, but not the connection to TrapNZ via sensors.
The team can have a look Emma. I can see all the other remote monitoring providers have data coming in, so I suspect it isn’t a problem at the Trap.nz end.
@emma.whitton Yes, it appears the Sensor Provider and Sensor ID values might be incorrect.
The provider is usually the name of the sensor manufacturer (E.g. Econode, Encounter Solutions Ltd, MinkPolice, etc.). When you start typing, the matching provider names will automatically appear.
Sensor ID: the unique ID of the radio sensor from the provider (this is usually a serial number written on the sensor).