RELEASED

01 Aug 2024

v1.6

WPE 1.3.x, 1.4.x, 1.5.x, PosApp, PosLib

PUBLIC

POS-554

Deleting a single network break the area matching for shared areas

When network is deleted/purged also internal area (zone) bounds information is deleted from the other networks. This happens when the area has not been bound into any specific network, but is used by all the networks (for example WNT defines areas in this way). In this case, the deletion of some network leads to a situation, in which nodes from other networks are not anymore located into the floor plan(s) where there were shared areas.

High

v1.6.0

v1.7.0

Yes

The issue can be fixed by restarting the WPE services, which will cause the area information to be refreshed from WNT. Please note that if WPE is used in a stand alone mode, then issue can be fixed by configuring the area information again.

POS-545

Area deletion does not work correctly if there are multiple networks configured into WPE

It is possible to configure multiple networks into WPE by adding anchors or areas that are linked to different networks. In such case, if area deletion is called without specifying the network (as done by WNT), the area is deleted only from the common and the first network’s data structure. This causes that the tags might be still located within the “already deleted” area in the rest of the networks. This will cause exception inside WPE, as the data structures are not in-sync.

Medium

v1.6.0

v1.7.0

Yes

The issue can be avoided by restarting the WPE services after areas have been deleted.

POS-542

Calculated tag floor might differ from the floor of the matched area

WPE may locate tag to a certain floor and simultaneous match it to and area in a different floor. This kind of situation might occur since tag location calculation and area matching use only the (currently 3) strongest anchors, while floor matching algorithm uses all the anchor information provided in the measurement.

The described situation is expected to be unusual and may occur only if the anchors in different floors are densely deployed and overheard without too much of radio signal attenuation between the floors.

Medium

v1.4.0, v1.5.0, v1.6.0, v1.7.0, v1.7.1

No

For the calculation logic there is no direct workaround. However, client system can build logic to check if the area and floor information provided by the WPE is coherent to recognize potential problems with the logic.

POS-558

Backend location calculation time is returned as timestamp if WPE is not able to calculate location

WPE will return backend location calculation time, instead of measurement timestamp, when it is not able to calculate location.

Low

v1.6.0, v1.7.0

v1.7.1

No

-

POS-541

Floor matching has limited support for scenarios where some anchors are located on floors and some not

Current WPE floor matching has limited support for situations, where some anchors are located within buildings and floors and some not (in which case they are located e.g. to WNT “world map”). This kind of configuration is not supported, if such anchors with mixed floor and non-floor configuration are within the same radio range. In such cases, WPE locates the tags to a floor within a building, even if the actual calculated location might be correctly outside the building / floor.

Low

v1.4.0, v1.5.0, v1.6.0, v1.7.0, v1.7.1

Yes

If there is a need to have a configuration, where all the anchors are not located on building floorplans, the suggestion is to create a “background” floor for the surrounding areas and attach those anchors that are not in other floorplans to that.

POS-473

Incorrect measurement time

When using WPE with WNT the reported measurement time is not set correctly for all the calculated locations. This is due to WPE using the first measurement time for all the measurements in a batch. This can cause relatively big error in the measurement time value due to different latencies for the messages in the mesh network.

Low

v1.5.0

v1.6.0

No

POS-360

WPE: SSL error

In some rare occasions ssl_transport_security.cc can trigger an error: OPENSSL_internal:WRONG_VERSION_NUMBER This is a known error of the gRPC library (open Issue #9538). The library will be updated once a fix for this issue exists. In case of occurring WPE will have to be restarted.

Low

v1.3.1, v1.4.0, v1.5.0, v1.6.0, v1.7.0, v1.7.1

No

POS-334

WPE: TLS connection to MQTT does not work

Setting up a TLS connection to MQTT from WPE does not work because of lack of CA root certificates in the WPE Docker image

Low

v1.3.1

v1.4.0

No

POS-327

WPE: Area definition always requires "uid" field

Area configuration does not allow to use only uuid (string) and requires that uid (uint64) field is also defined.

Low

v1.3.1

v1.4.0

Yes

The field uid must be defined

POS-298

WPE: When configuration from WNT is disabled areas are still injected

When configuration form WNT is disabled areas can still be injected by from WNT.

Low

v1.3.1

v1.4.0

No

POSAPP-62

PositioningApp: incomplete measurements in autoscan mode

Due to a potential race condition in autoscan mode the measurement set can in be incomplete in some random instants. This can result in higher position error than expected.

Medium

v5.0.0

v1.2.1.2

Yes

The recommended production mode for tags is NRLS and for anchor opportunistic. These modes are not affected by the error observed in autoscan mode.

21 Jan 2021

v1.0A

1^st version of Wirepas Positioning Engine Errata document (with POSAPP-62)

08 Jun 2021

v1.1

Added new errata: POS-298, POS-327, POS-334 and POS-360

30 Sep 2021

v1.2

Updated POS-360 by adding v1.5.0 to the list of Affected Versions (Errata)

13 Apr 2023

v1.3

Added new errata: POS-541, POS-542

Updated POS-360 by adding v1.6.0 to Affected Versions (Errata)

03 Oct 2023

v1.4

Added new errata: POS-545

04 Jan 2024

v1.5

Added new errata: POS-473 and POS-554

Updated POS-545 by adding v1.7.0 as Fix Version (Errata)

01 Aug 2024

v1.6

Updated POS-541, POS-542 and POS-360 by adding v1.7.1 to Affected Versions (Errata)

Updated POS-558 by adding v1.7.1 as Fix Version (Errata)