Could you help confirm the best approach for dual-target SensorThings delivery?

[mathisvfr]

We now push observations to both STA servers in parallel (WBD-RD and Collaborall), but this currently reuses one shared datastream ID mapping for both targets. Since datastream IDs may differ per server, would you prefer that we implement per-target datastream mappings (for example by server URL), so each push resolves IDs independently and avoids cross-server ID mismatches?

[hylkevds]

Hard-coding Datastream IDs on the sensor side is usually not a good idea, since the Datastream id is usually server generated. What I usually do is query the server to find the correct Datastream, based on some fixed device properties. For instance, LoRa sensors have a DeviceEUI that is unique for the LoRa device, and each value usually has some key that is related to the ObservedProperty. The DeviceEUI can be stored in the properties of the Thing, and the value-key (lets call it streamKey) can be set on the properties of the Datastream. Finding the correct Datastream is then a matter of using the query:

v1.1/Datastreams?$filter=Thing/properties/deviceEui eq '<dev eui here>' and properties/streamKey eq '<stream key here>'

Or, if the sensor knows its actual ObservedProperty by name, you could do:

v1.1/Datastreams?$filter=Thing/properties/deviceEui eq '<dev eui here>' and ObservedProperty/name eq '<obs prop name here>'

Of course, that last one only works if the device only measures each ObservedProperty once.

[mathisvfr]

Thanks, this was very helpful.

Implemented your approach: instead of relying on hard-coded Datastream IDs, we now resolve Datastreams dynamically at push time using OData filters (first deviceEui + streamKey, with ObservedProperty/name and Thing/name fallbacks). We also store streamKey on Datastream properties and accept device_eui / stream_key in incoming readings.