Bug Report & Resolving collaborall STA Server

[Kattouw]

Hi All,

Hereby a place to put out all your bugs!
P.S. Please add each bug/comment on the main level discussion and reply additional comments in the thread of the issue.

Thanks in advance 😊

[hylkevds]

The list of EntitySets on the landing page does not correspond to the actual list of EntitySets.

For instance, https://sta-server.collaborall.net/v1.1/TaskingCapabilities is not listed, but does work.

[Kattouw]

Should be working now 😄

[hylkevds]

NavigationLinks with a cardinality of 1 don't seem to work, for example:

Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException
vendor/laravel/framework/src/Illuminate/Routing/AbstractRouteCollection.php:130

The GET method is not supported for route v1.1/TaskingCapabilities(1)/Thing

Other examples:
https://sta-server.collaborall.net/v1.1/Observations(1)/Datastream
https://sta-server.collaborall.net/v1.1/Observations(1)/Datastream/Thing
https://sta-server.collaborall.net/v1.1/Observations(1)/Datastream/Thing/Locations

[Kattouw]

Should be working now 😄

[justinschembri]

CLOSED

When trying to post to Locations (programatically):

requests.exceptions.HTTPError: 405 Client Error: Method Not Allowed for url: https://staserver.collaborall.net/v1.1/Things(6)/Locations

[Kattouw]

Should be working now 😄

[justinschembri]

Yes, though I've encountered something new (will post below)

[hylkevds]

$select on properties doesn't work for Things:

https://sta-server.collaborall.net/v1.1/Things?$select=properties

Returns:

{
      "error": {
            "code": "STA-400",
            "message": "Invalid $select syntax: unknown property 'properties' on the requested entity",
            "target": "$select"
      }
}

[Kattouw]

This is now working, Can you verify?

[justinschembri]

CLOSED

This query is returning a 400:

https://sta-server.collaborall.net/v1.1/Datastreams?
$filter=name eq 'temperature_air'
&$expand=Sensor(
  $select=@iot.id,name
  )

{
"error": {
"code": "STA-400",
"message": "Invalid $expand syntax: unexpected character '.' at position 19",
"target": "$expand"
}
}

I'm starting to recall that $expand hasn't been implemented yet right?

[Kattouw]

Hi Justin,

The $expand with nested $select (incl. @iot.id) is now fixed and deployed. Example that previously returned STA-400 and now works:
/v1.1/Datastreams?$filter=name eq 'temperature_air'&$expand=Sensor($select=@iot.id,name)

Also addressed in this release: nested $orderby inside $expand, and a consistent OGC error envelope for 404/405.

Thanks for reporting and please let me know if this solves the issue.

[justinschembri]

Yes, that works! There's another issue which is now actually from my side but is a difference between the FROST and your implementations ... will make a seperate comment.

[justinschembri]

I've found a small difference between the FROST and Collaborall implementation with respect to how they deal with a Datastreams observationType field. I've been happily (and incorrectly) creating Datastreams on FROST implementations with a value instant:

STA v1.1 technically enforces a ValueCode for this field, and Collaborall's server seems to enforce it:

{
   "error":{
      "code":"STA-422",
      "message":"observationType must be one of: http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement, http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_CategoryObservation, http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_CountObservation, http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_TruthObservation, http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation.",
      "target":"observationType"
   }
}

Is this intentional on FROST's side @hylkevds or am I missing something?

Edited: I patched the entities on the wbd-rd server so you can't see the old 'instant' value.

[hylkevds]

Yes, FROST does not enforce the exact values of observationType.

Considering the field will be removed in version 2.0, there is not much point in enforcing it now :)

[justinschembri]

CLOSED

Similar to the above comment, the Collaborall server is stricter on the enforcing of the datastreams unitOfMeasurement field. I have syntactically messy datastreams for passive infrared that has this following unitOfMeasurement:

{
   "unitOfMeasurement":{
      "name":"idle | active",
      "symbol":null,
      "definition":"boolean, active when motion was detected"
   }
}

FROST accepts this but the collaborall server tosses:

{
   "error":{
      "code":"STA-422",
      "message":"The unit of measurement.symbol field is required.",
      "target":"unitOfMeasurement.symbol"
   }
}

---

Furthemore, the Collaborall server does not accept this Datastream as valid:

{
   "name":"passive_infrared",
   "description":"PIR.",
   "observationType":"http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_TruthObservation",
   "unitOfMeasurement":{
      "definition":null,
      "name":null,
      "symbol":null
   },
   "observedArea":{
      "type":"Point",
      "coordinates":[
         14.371062,
         40.950099
      ]
   },
}

The null values, which should be acceptable if I've interpreted the standard correctly are not accepted:

Note: When a Datastream does not have a unit of measurement (e.g., a OM_TruthObservation type), the corresponding unitOfMeasurement properties SHALL have null values.

[hylkevds]

Yes, the lists in the spec are not exclusive: Other encodingTypes are permitted

[Kattouw]

@justinschembri, this should be fixed!

Let me know how you get along.

[justinschembri]

Still get the same error about encodingType!

[Kattouw]

Sorry, can you try again?

[justinschembri]

Yes, this issue is closed, but there's another issue I'll raise in a separate comment :)

[justinschembri]

Getting closer, this seems like a trivial albeit breaking issue, POST is not allowed for /Datastreams(n)/Observations:

{
   "error":{
      "code":"STA-405",
      "message":"The POST method is not supported for route v1.1/Datastreams(148)/Observations. Supported methods: GET, HEAD, OPTIONS."
   }
}

[Kattouw]

Fix implemented, see below

[justinschembri]

Separate issue with filter and using a substringof comparison operator not working:

https://sta-server.collaborall.net/v1.1/Things?$filter=substringof(%27name%27,%20%27netatmo%27)

Returns:

{
   "error":{
      "code":"STA-400",
      "message":"Invalid $filter syntax: expected comparison operator, got '(' at position 12",
      "target":"$filter"
   }
}

[Kattouw]

Fix implemented, see below

[Kattouw]

Hi @justinschembri,

Both issues from your 13 July reports are fixed and deployed. 🎉

1. POST on /Datastreams(n)/Observations

You can now create an Observation directly under its Datastream — the parent is taken from the URL, so the body doesn't need a Datastream link:

POST /v1.1/Datastreams(148)/Observations
{
"phenomenonTime": "2026-07-14T10:00:00Z",
"result": 21.5
}
Returns 201 with a Location header pointing at the new Observation. The FeatureOfInterest is auto-resolved from the Datastream's Thing's current Location (OGC § 10.2.1), same as a top-level POST /Observations. If you do include a Datastream link in the body it must match the URL id, otherwise you'll get a 400.

2. substringof (and friends) in $filter

substringof, startswith, endswith and contains now work. One thing worth flagging on your original example — the OGC/OData argument order for substringof is substringof(, ), so the property goes second:

GET /v1.1/Things?$filter=substringof('netatmo', name)
(Your earlier call quoted both arguments — substringof('name', 'netatmo') — which has no property to match against; that now returns a clean 400 rather than the parser error.) Note the other three take the property first, matching OData: startswith(name, 'netatmo'), endswith(name, '01'), contains(name, 'atm'). Matching is case-sensitive.

Thanks again for the detailed reports — let me know if anything's still off!

[hylkevds]

substringof, startswith, endswith and contains now work. One thing worth flagging on your original example — the OGC/OData argument order for substringof is substringof(, ), so the property goes second:

The way I always remember the order of parameters is that you can build a sentence:

<param 1> <functionname> <param 2>

so in this case:

'netatmo' substringof name
name contains 'atm'

GET /v1.1/Things?$filter=substringof('netatmo', name) (Your earlier call quoted both arguments — substringof('name', 'netatmo') — which has no property to match against; that now returns a clean 400 rather than the parser error.) Note the other three take the property first, matching OData: startswith(name, 'netatmo'), endswith(name, '01'), contains(name, 'atm'). Matching is case-sensitive.

Formally, substringof('name', 'netatmo') should not return a 400, but a false, and thus an empty result set. There is no requirement that one of the parameters is a constant and the other is an attribute reference. They can both be constants, though that is not very useful, or they can both be attribute references. For instance:

substringof(name, description)

returns all entities where the name is contained in the description.

• Stations that have their name in their description: https://airquality-frost.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1/Things?$select=id,name,description&$filter=substringof(name,description)&$count=true
• Stations that do not have their name in their description: https://airquality-frost.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1/Things?$select=id,name,description&$filter=not%20substringof(name,description)&$count=true

[justinschembri]

Mostly Success!

Hey @Kattouw, congratulations, I'm successfully using the same ingest pipeline on both FROST and the Collaborall server for most of my systems! 🎉

Here are my Things:

3 x Netatmo NWS03
10 x Milesight AM308L
10 x Milesight AM103L
1 x Dragino LSN50v2-S31
8 x Kinemetrics ETNA2 -> though there is a bug here, see below:

The iot.count is pretty high: "@iot.count": 16118923, guess you've been stress testing things too?

---

New Bugs

Some new bugs that came up with only one of my datastreams which makes a query using phenomenonTime range instead of a time instant:

400 Client Error: Bad Request for url: https://sta-server.collaborall.net/v1.1/Observations?$filter=phenomenonTime eq 2026-07-15T07:44:16+00:00/2026-07-15T07:49:16.005000+00:00

If you're wondering why I do this, its to prevent duplicate observations being created, especially for pull based systems (although now thinking of it I see a potential bug where two observations with exactly the same phenomenon time clash ... anyway, that is my problem!)

[hylkevds]

If you're wondering why I do this, its to prevent duplicate observations being created, especially for pull based systems (although now thinking of it I see a potential bug where two observations with exactly the same phenomenon time clash ... anyway, that is my problem!)

Simply change to URL to be Datastream-specific:

https://sta-server.collaborall.net/v1.1/Datastreams(1)/Observations?$filter=...

Depending on the indices in the database, that may even be faster.

[Kattouw]

Thanks both, a batch of fixes is now deployed.

@hylkevds: you're right, thank you for the correction.

Now works:

GET /v1.1/Things?$filter=substringof(name, description)
And your sentence mnemonic ( → 'netatmo' substringof name) is a much nicer way to remember.
Matching is case-sensitive.

@justinschembri nice! I see a lot of items indeed on the server! I will add a duplication finder to see if we can "clean" up a little.

phenomenonTime with an interval; phenomenonTime eq / no longer 400s; the interval literal is parsed. One caveat: we persist an interval's start instant, so the match is on the start. For range/dedup queries the fully-conformant idiom is:
/v1.1/Datastreams()/Observations?$filter=phenomenonTime ge and phenomenonTime le
(and, as hylkevds noted, scoping to the Datastream is also faster).

[mathisvfr]

Hi, we're connecting our new sensors to the Collaborall STA server and noticed the server appears to be down as of today (July 18).

What we're seeing:

• SSL: The certificate is self-signed (CN=tb-nl01-hclnxs016a.srv.teamblue-ops.net), causing CERTIFICATE_VERIFY_FAILED errors for any client that validates certificates
• 404: /FROST-Server/v1.1 returns a 404 Not Found
• Root page: Returns "Please stand by while configuration is in progress"

Is the server being reconfigured? Let us know if there's an updated URL or ETA. Our connector will automatically resume pushing once it's reachable again :)

[Kattouw]

Hi Mathias,

We have implemented our own STA Server, so we do not host a FROST application.
Therefore; the endpoint is not /FROST-Server/v1.1, but just /v1.1. Examples can be found in this discussion.

Concerning the certificate, I guess this is the certificate from your side. We see that it is a teamblue-ops.net certificate, which I guess you use to host your connector?

Which endpoint did you use to see the message: "Please stand by while configuration is in progress"? We cannot find this sentence in our server.

Let me know if we can support you.

[mathisvfr]

Oh wow, fixed it and now have access. Thanks for the quick response!

[bharkema]

Hi all,

We've successfully pushed our dummy data and can maintain a stable connection to the Brabantse Delta database. The one problem we ran into is when creating the sensors: the Collaborall FROST server (sta-server.collaborall.net) rejects our payload because it expects the metadata field to be a string, while we're currently sending it as an object.

Example payload we're sending:

{
  "name": "Dummy fill-level sensor DUMMY-1 1.0.0",
  "description": "Vendor-supplied fill-level sensor",
  "encodingType": "application/json",
  "metadata": {
    "model": "DUMMY-1",
    "firmware_version": "1.0.0"
  }
}

The server responds with an HTTP 422:

{
  "time": "2026-07-22T09:25:01.135690567Z",
  "level": "WARN",
  "msg": "vendor error (unclassified, treated transient)",
  "service": "geonovum-sta-translation",
  "op": "ingest",
  "err": "resolve entity chain on target \"https://sta-server.collaborall.net/v1.1\": frost http 422: frost: POST /Sensors returned 422: {\"error\":{\"code\":\"STA-422\",\"message\":\"The metadata field must be a string.\",\"target\":\"metadata\"}}"
}

So POST /Sensors fails with STA-422 – "The metadata field must be a string." We'll need to agree on how metadata should be encoded: either we serialize the object to a string on our side before sending, or the Collaborall server needs to be configured to accept an object.

Worth noting: in the OGC SensorThings spec the meaning of Sensor.metadata depends on encodingType. We're currently sending encodingType: "application/json" with an object, which is why Collaborall may be insisting on a string (e.g. it might expect a URL to the metadata instead of an inline object), while Brabantse Delta tolerated the object.

[Kattouw]

Fixed and deployed. POST /Sensors now accepts metadata as an inline JSON object as well as a string, so your payload with encodingType: "application/json" and an object metadata goes through. Mo need to pre-serialize on your side.

One thing to be aware of on read-back: Sensor.metadata is stored and returned as a string (the OGC response type for the field is a string), so the server serializes your object to canonical JSON on write. Your {"model": "DUMMY-1", "firmware_version": "1.0.0"} will come back as the equivalent JSON string rather than a nested object. If your ingest pipeline round-trips and re-reads it, that's the only difference to expect.

A plain string (a URL to SensorML/PDF, inline XML, or an already-serialized blob) keeps working exactly as before. Thanks for the clear report. Let us know if you managed to get it all working (or the issues you're experiencing).

[hylkevds]

the Collaborall FROST server (sta-server.collaborall.net)

Important note: The collaborall server is not a FROST-Server, but a completely different, unrelated implementation.