I’d like to be able to show the location of stationary devices on a map widget for a large ranch. There could be 100s of these devices, but they will not move.
What do all of you think the best strategy would be?
Store location data, per device in immutable location bucket/device
Still have to get it into the bucket and the best way would be scripting, maybe a daily script?
Advantage is single device for the map widget (is that good?)
Store location data in parameters - do a query when map widget starts
Seems to be very logical.
It would be sort of real-time- optimizes storage
Store location data in parameters - but COPY infrequently to device store
Seems to fit better with idea of map widget
Requires a copy over analysis script which wouldn’t be horrible.
Store location data in TAGS
Doesn’t seem like the way TAGS wants to be used, but TAGS are easier than parameters
You can save the current location of each device in its own device bucket as a normal variable, for example (like storing GPS readings)
The issue is that it’s very awkward to load hundred devices in a single dashboard.
You can to create an analysis script and an auxiliary device/entity, with some action enabled, you can make the analysis write into the aux device bucket and have all the info belong to the same group. For example, this script can query either on demand or scheduled to write all the current locations into a single variable in this aux device. Then you just have to call it once when setting up the dashboard. You will have multiple points with the same group, but only “one” device to manage.
Parameters/Tags: The Map Widget cannot natively plot pins from parameters or tags; it exclusively reads from Device Storage.
Immutable Storage: This is the correct path. Since the devices are stationary, you only need to send the location data once. TagoIO keeps the last known value indefinitely, so no daily scripts are needed. (Keep in mind that Immutable devices follow a data retention, if it expires, the data must be resent)
The Best Strategy: Two Approaches
1. The “TagoIO Way” (Scalable & Native)
If you have 100+ separate devices in your account, simply send a single location variable to each device once.
How to display: Create a Blueprint Dashboard. In the Map Widget, select the Blueprint device.
Why: It’s the most scalable. If you add 50 more devices, you just tag them. The map will automatically update without any changes to the widget or scripts. Plus, “Infoboxes” (popups) work better with this 1-to-1 relationship.
2. The “Single Organization Device” (Centralized)
If you prefer to store all 100+ locations inside a single “master” device (like an Entity), you must use the group field to prevent the map from treating the data as one moving device.
Since your main objective is to display all sensor locations within your organization, the most effective approach is to create a specific “organization” device to represent it.
Here is the recommended workflow to handle this:
Store the latitude and longitude information in the Configuration Parameters (CFG) of each individual sensor.
Create an analysis/script to list all sensors belonging to the organization (use tags to filter these).
Have the script retrieve the coordinates from each sensor’s CFG and generate a new data payload. Here is an example:
{
"variable": "sensor_location",
"location": {
"type": "Point",
"coordinates": [
-74.0038742,
40.72445889999999
]
},
"group": "69de63148bc465000a2ef356" // Insert the sensor's device ID here
}
Post this generated data to the organization device.
In your Map widget settings, navigate to the Visual tab and set Group samples by to Groups.
By assigning the sensor’s device ID to the group field in the payload, the Map widget will automatically group and display the pins correctly for your stationary devices.
… no longer works as it is converted to the Point format GeoJSON.
I would put in a request that the MAP widget information is more complete on a single document as I’ve spent lots of time on this strategy, writing different tests and trying different things to get the behavior I want.
I also used “Ask Documentation” which is GREAT BTW, but it uses very old information.
You are absolutely correct, and I apologize for the confusion. Agree that the data must be in the GeoJSON (Point) format to ensure the pins are correctly rendered in the Map widget.
Thank you for your feedback regarding the documentation. We will bring this point as an improvement to the team responsible for the documentation. Our goal is to update the “Map Widgets” guide to make it more comprehensive and clear, ensuring other users don’t face these same doubts in the future.
