2

Cameras 4.4.4

offline cameras
status checks

When a camera is unplugged, a status check is performed regularly, to see if it has been plugged back in.
Due to a race condition, it was possible to get several such checks in a short period of time, which generates unwanted network traffic. This is now fixed.

SDK 9.0.0

3

Core 1.3.7

com.prosyst.util.ref.Log
security

There was a security error about missing permission to get org.osgi.service.log.LogService when logging through com.prosyst.util.ref.Log. This is now fixed by using privileged calls.

SDK 9.3.2

4

Core 1.3.7

com.prosyst.util.ref.Log
system properties
no debug

When setting log level via system properties, the debug logs do not show. The com.prosyst.util.ref.Log#setLogLevel(int loglevel) was modified to use configurations from the ConfigurationAdmin for different bundles and that resolved the issue.

SDK 9.3.2

5

Core 1.3.7

com.prosyst.util.ref.Log
OSGi log service

There was a race condition between com.prosyst.util.ref.Log and framework service registry. This has been fixed by improving tracking of org.osgi.service.log.LogService.

SDK 9.3.2

6

Device Access 3.4.3

REST

The Device Access didn't send any REST event when the framework was started with security. Now it is fixed.

SDK 9.0.0

7

Framework 8.5.4

storage error
Buddy policy

There was an error loading framework storage, when a bundle(s) with Eclipse-BuddyPolicy header was present, causing the bundles to be re-resolved. This is now fixed.

SDK 9.3.2

8

KNX 5.4.1

KNX datapoints
invalid values

Previous versions of KNX bundles have no special handling of invalid values for certain datapoint types. There was a value validity check on the KNX DPT API, but not Device Access abstraction layer.
This is now fixed and if an invalid value is reported on a datapoint of a Sensor/Actuator/Setpoint device item, the value inside the item's Quantity value is set to Double.NaN.

SDK 9.0.0

9

KNX 5.4.1

KNXnet/IP discovery

KNXnet/IP discovery was working successfully only inside local network and failed to discover KNXnet/IP servers through a more complex network setup.
The reason for this was that KNXnet/IP discovery packets were sent with default value for their time-to-live (TTL) option, which meant that they stayed only inside the subnet. The fix now sets time-to-live options to 64 and KNXnet/IP servers outside the local subnet can be discovered too.

SDK 9.0.0

10

SHIP 2.2.8

SHIP device status

In some rare cases it was possible that the status of a SHIP device remained ONLINE even though the underlying SHIP connectivity was disabled on the physical device and SHIP connection was closed. This is now fixed and SHIP device status is reported as expected.

SDK 9.0.0

11

SHIP 2.2.8

required bundle permissions

The com.prosyst.mbs.ship.driver.commands bundle was missing required permissions and was not working as expected when OSGi framework was started with Java Security Manager enabled. This is now fixed.

SDK 9.0.0

12

SHIP 2.2.8

SHIP websockets fragment size

If the system property of SHIP websockets fragment size had an invalid value, the SHIP client and server implementations did not fallback to default fragment size. That might lead to unexpected runtime errors. Now it is fixed.

SDK 9.0.0

13

SPINE 2.4.3

required bundle permissions

Some SPINE bundles were missing required permissions and were not working as expected when OSGi framework was started with Java Security Manager enabled. This is now fixed with updated bundles and permissions added accordingly.

SDK 9.0.0

14

WebSockets 1.1.8

maximum open connections
race condition

A race condition, when WebSocket connection is closed before subscription was fully initialized, resulted in failure to decrement the open connections counter.
As a result, eventually maximum open connections limit was reached and further attempts to open connections failed. This issue is now fixed.

SDK 9.3.1

15

Z-Wave 5.0.10

Custom Device Classes or
Device Items registered twice

When a device is securely included, all custom provided Device Classes or Device Items that do not define a specific Command Class ID (i.e. annotated with @ZWaveCommandClassId) are registered both in the root and secure child device. This is now fixed.

SDK 9.0.0

16

Z-Wave 5.0.10

pre-included devices
battery-powered devices
Wake Up Notification

Battery-powered devices already included in the controller network before starting the Z-Wave stack are never configured and associated even after the device sends a Wake Up Notification. This is now fixed.

SDK 9.0.0

17

Z-Wave 5.0.10

Log Configuration

Log Configuration instances were left behind undeleted after Z-Wave bundles are uninstalled. This is now fixed.

SDK 9.0.0

18

Z-Wave 5.0.9

custom Device Class/Device Item implementation
missing instances

If a custom Device Class or Device Item implementation was provided, but did not fully match the manufacturer indicating properties, neither custom nor default Device Class implementation instances were created. This is now fixed.

SDK 9.0.0

19

Z-Wave 5.0.9

Color Switch Device Item

No ColorSwitch Device Item was registered for devices, supporting versions higher than 1 of the respective Z-Wave Command Class. This is now fixed.

SDK 9.0.0

20

Z-Wave 5.0.9

missing system only Device Items or
Device Class Objects

The system Device Class Objects or (depending on the setup) Device Items were missing after the Adapter bundle was being updated. They appeared again after restarting the framework. This is now fixed.

SDK 9.0.0

21

Z-Wave 5.0.9

Blood Pressure sensor metrics

Quantity metric values and Item attributes within the Device Access layer regarding Blood Pressure sensor type were incorrectly represented. This is now fixed.

SDK 9.0.0