This page collects guidelines and best practices on how to use Thingsee IoT devices and services for commercial use.
Design data storage for your use-case
Thingsee Operations Cloud forwards sensor data as Thingsee Messages to your cloud. It is recommended that your cloud handles the Thingsee Message JSON and extracts the data to a database/storage in such format that fits best to your specific use-case and queries.
Decide how to handle thing identity
All Thingsee devices are anonymous by default. The only identifier visible within the firmware, Thingsee Operations Cloud and Thingsee applications, is the product serial number.
Build thing identity in your application cloud
Thingsee design highly recommends that you build the identity within your application cloud by mapping the serial number (tsmTuid) to your application-specific identifier or location.
Build thing identity in Thingsee (instead of your cloud)
Thingsee Field Operations services provides a full-set of functionality so that the identity of the usecases, devices, locations and assets can be build and fully managed within Thingsee Operations Cloud. This is a perfect option for customers who don’t have existing customer identity pool or APIs, or want to move to use full Thingsee Field Operations solution to manage their device/asset fleet.
Do not use gateway identifier (tsmGw) for business logic
Do not use tsmGw information within Thingsee messages to identify your installation, location or a customer. If your customers A and B are in close proximity, then it is fully possible that some customer B sensors are routing through customer A gateway and vice versa. Therefore you must build your customer identity and inventory based on the sensor’s tsmTuid information only.
If this is really a blocker to your design then there are ways to change this, but it will cause some other issues to your logistics and inventory operations. We can have a call if you need to find out more about this.
Do not assume that messages are in timed order
Due to nature of how mesh network works and buffers its messages, it is not quaranteed that the messages are coming in an exact sequence as send by the sensors. You must assume that there can be messages that arrive late and not in order. You should use tsmTs property to verify measurement/reporting time.
Be prepared for duplicate messages
Once again, due to how the mesh network and buffering works, it is fully possible that you will receive the exact same message twice (or more). You should use tsmTuid + tsmId + tsmTs properties to determine if the message is actually a duplicate to something you have already received.