New versions of Adlink Edge SDK are released on a regular basis. This page lists all the known issues for Adlink Edge SDK V1
You may also want to read the following:
Edge SDK Known Issues
| Report ID. | Description |
|---|---|
| THINGAPI-1196 | Applications can fail with E_INVALID_REF_NAME: name has invalid format On older Debian 9 distributions (9.6, in particular), the C++ RoundTrip example applications can fail, with messages indicating the tag group names or tag names are invalid. This is an issue with the dynamic libraries used by the application. Moving the exact same executables to an updated Debian 9 distribution (Debian 9.12 was tested) resolves the issue. Workaround: Upgrade to a recent Debian 9 distribution. |
| THINGAPI-1037 | FlowIdFilters not working on Purged samples A read(), read_next() or data-available listener may return purged samples with flow id's that do not match the configured 'flowIdFilters' property of the Thing's input. Workaround: You must filter such purged samples manually. Each such sample will have the following characteristics: a) the flow-state will be PURGED; b) if the sample is IOT_NVP_SEQ data, there will be no values in the returned sequence; c) if the sample is PROTOBUF data, then VDataSample::hasData() will return false. |
| THINGAPI-623 | A Python Listener class defining a constructor may cause a Segmentation Fault/Access Violation A Python Listener class that defines a constructor (that is, a __init__ method) must call the super class's __init__ method, otherwise a Segmentation Fault/Access Violation will occur when a listener instance is added via a call to one of the Python API's add_listener methods. Workaround: See the Python API User's Guide for an example of a well formed listener class with a constructor. |
| THINGAPI-438 | Control-C not received by Python applications during blocking read/read_next During a blocking call to Thing.readIotNvp, Thing.readNextIotNvp, Selector.readIotNvp and Selector.readNextIotNvp, any Ctrl-C interrupt will not be received by the Python engine. |
| THINGAPI-533 | Excessive cpu-load for ThingAPI read-operations on large (e.g. multi-megabyte video-)samples When applicable: if cpu-monitoring tools such as 'top' shows about equal amount of system-time and user-time for read-operations Work-around: to reduce the cpu-load create 2 environment variables with appropriate values: export MALLOC_TRIM_THRESHOLD_=-1 (which causes 'mmap' to be used rather than malloc for large memory-chunks export MALLOC_MMAP_THRESHOLD_=4000000 (a value greater than the sample/video-size) Consequence: increased memory-usage of a process which decreases the amount of available RAM for all other processes |
| THINGAPI-766 | Python API treats IOT_INT8 as a Python string In Python, a data type of IOT_INT8 gets incorrectly converted into a python String. It is intended to be an integer value with range -256 through 255. |
| THINGAPI-880 | NodeJS API is incomplete The NodeJS API shipped with earlier releases of EdgeSDK remains incomplete. In particular: * the NodeJS API contains no support for listeners. * Examples that rely on listeners are not available. * No User's Guide is available. |
| THINGAPI-933 | Protobuf examples without 'CMAKE_BUILD_TYPE=Release' on Windows Protobuf Examples configured on Windows without '-D CMAKE_BUILD_TYPE=Release' appear to work. However during a build, errors appear: "error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug'". Work around: Add "-D CMAKE_BUILD_TYPE=Release" to the cmake command. |
| THINGAPI-934 | Limitation: Pre-1.4 applications cannot fully inspect Protobuf TagGroups Applications such as the 'thingbrowser' application inspect all TagGroups found on a DataRiver, and provide information on their contents by making use of TagGroup methods such as getToplevelType(), getTopLevelTypename(), getTypeDefinitions() and getType(). Pre-1.4 versions of such applications will 'see' Protobuf TagGroups, but they will not be able to find information their content. Migration to 1.4: When such applications are migrated to 1.4, developers must examine their use of the above methods. On Protobuf TagGroups, they will now throw a C++ exception. Migrated code should first examine the result of the new method 'TagGroup::getWireFormat()' to determine whether the Tag Group is the 'familiar' NVP_SEQ-format or the new PROTOBUF-format. New TagGroup methods are provided in 1.4 to examine the contents of a protobuf tag group. See the C++ User's Guide for details. |
| THINGAPI-937 | Windows: C++ Examples cannot use the default Visual Studio 'generator' On Windows, the C++ examples cannot be configured without explicitly specifying -G "NMake Makefiles" on the command line. Without this option, CMake attempts to use the default Visual Studio generator. However, some of the C++ examples cannot be configured this way. Work-around: add the option -G "NMake Makefiles" to the CMake command line, and then use nmake to build. This process is described in the examples README file. |
| THINGAPI-940 | Windows+Protobuf: C4275 and C4800 Warnings in header files EgdeSDK Protobuf applications compile with a C4275 and C4800 warnings. These can safely be ignored. Google documents that C4800 is unavoidable ADLINK is researching how C4275 can be addressed. Work-around: These warnings can safely be ignored. |
| THINGAPI-1187 | ARMv7 Ubuntu 18.04 DDS does not support Secure DataRiver apps The underling Vortex OpenSplice build does not contain the libraries necessary to execute secure DataRiver applications. |
| THINGAPI-1188 | ARMv8 Ubuntu 16.04 DDS does not support Secure DataRiver apps The underling Vortex OpenSplice build does not contain the libraries necessary to execute secure DataRiver applications. |
| THINGAPI-1189 | jsontgc wheel installs but does not run in Python 3.5 The Python wheel adlinktech_jsontgc-1.7.0-py3-none-any.whl successfully installs in Python 3.5. However, if you attempt to run it, you receive: "ImportError: cannot import name 'metadata'". The design intension for the wheel is to require Python 3.6 or later. However, the default pip version supplied with Python 3.5 does not respect this limitation. This primarily affects the ARMv8 Ubuntu 16.04 version of EdgeSDK. Work around: Install a later version of Python. |
Operating System/Platform Related Issues
- As of ADLINK Edge SDK version 1.0.1, Ubuntu 14.04 is not supported.
- As of ADLINK Edge SDK version 1.1, Ubuntu 18.04 support has been added.
- As of ADLINK Edge SDK version 1.3, Ubuntu 18.04 AArch64 support has been added.
- As of ADLINK Edge SDK version 1.4, Python 3.8 on Linux has been added.
- As of ADLINK Edge SDK version 1.6, Python 3.9 has been added.