To add to Andrey's to-the-point answer:
Be sure to understand how these device communicate with other systems (data collector servers?), especially with regards to the timing intervals and patterns (being polled? pushing data to the collectors?). Then, choose the port security scenario, features and timers suitably. Also consider how CAM table aging of the switches and the sensor device's own ARP cache coordinate with that.
Depending on chosen port security scenario (fixed, sticky, aging), devices which stay silent for longer than port security aging and/or CAM table timers might run into trouble, as soon as they want to start or to resume communication.
They might be forced into a timeout/retransmit situation, because port security and CAM learnig might take just enough time to drop the first one or two frames from the device (when it is ARPing for it's default gateway, for example). Such a timeout/retransmit situation might be unproblematic; depending on the upper layer protocol/application (e.g. with UDP), it might become an issue: The device might remain unaware of the first datagram being discarded by port security, and you might end up missing a data point on the collector altogether.
A series of 2960-X and an NFC card reader had been keeping me busy for almost a week until it became clear what was happening. It turned out to be unsolveable on the given 2960-X, even with TAC support. Eventually we lowered the ARP timeout on the upstream router (an SVI on a Cat6500, in this case) to a value below the switch's CAM timeout. CEF running on the router would then perform active ARP cache maintenance before each ARP entry would timeout. That caused replies from the card reader devices which in turn helped the switches to keep the CAM and port security tables up to date.