Concerned fields are:
- group in the "groups" list of an item
- UID of a linked channel in an item
- namespace of a metadata attached to an item
- UID of a thing
- "bridge" field of a thing
- channel id of a channel declared in a thing
- "type" field of a channel
A check was also added for the "profile" configuration parameter of a linked channel.
Related to #5057
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
* Create User32Ex with some mappings missing in JNA's User32
* Create WindowMessageHandler for subscribing to device change messages
The class, when run as a Runnable, creates an invisible window and uses that to listen for device change events for USB devices and serial ports. It listens in a blocking message loop, so it's necessary to call terminate() for the loop to exit and the run() method to exit. Results are sent to subscribing WindowMessageListeners.
* Refactor WindowsUsbSerialDiscovery to use a different approach to gathering device information
The previous implementation scanned the registry for USB devices on a fixed interval. This implementation changes most of the core logic, using SetupAPI as the primary source of information instead of the registry. That allows it to process less information to get to the information of interest, in addition to only "discovering" devices that are currently connected to the computer. The registry keeps the entries for all devices that have previously been connected as well, which would also be "discovered" with the previous implementation.
In addition, this implementation uses WindowMessageHandler to receive device change messages from Windows, making regular scanning unnecessary. If the WindowMessageHandler fails for some reason, the implementation will fall back to scanning on an interval, but this scanning is still using SetupAPI to acquire the data.
* Various thread-safety and consistency fixes
- UsbAddonFinder: Remove unused Set and fix concurrency behavior. ConcurrentHashMap is unsuitable here because it doesn't allow locking the full map, which is needed during "merging" and when resolving suggested add-ons.
- DeltaUsbSerialScanner: Make lastScanResult thread-safe.
- Ser2NetUsbSerialDiscovery: Make lastScanResult thread-safe, reduce the scope of locking to reduce contention and lessen how many locks are held at once. Make notifyListeners volatile for thread-safe access, and stop reacting to jmdns serviceAdded events. jmdns first fires serviceAdded when the service has just been discovered, but most of the information hasn't yet been gathered, and then fires serviceResolved once all the data has been registered. The data received in serviceAdded is incomplete and rarely useful, at best it's a "heads-up, this device might be resolved soon".
- UsbSerialDiscovery: Correct JavaDoc
- UsbSerialDiscoveryService: Minor logging tweaks, only log "Discovered new" the first time the device is "discovered".
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
org.openhab.core.automation.module.script...ScriptBusEventImpl was a copy of org.openhab.core.model.script...BusEvent,
which was removed in #5122.
In #5122, a org.openhab.core.automation.module.script...BusEventImpl was added, which is already used by the org.openhab.core.model.script bundle.
I think the ScriptBusEventImpl copy of the old BusEvent class was done to avoid a dependency org.openhab.core.automation.module.script => org.openhab.core.model.script.
As we now have a BusEventImpl in the automation bundle, we can use it for the DefaultScriptScopeProvider and get rid of ScriptBusEventImpl.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
Comparable to #3155.
JSR-223 automation add-ons often use the script actions from the org.openhab.core.model.script bundle.
The downside is that the actions are tied to XText or at least use some hacks to provide static access to OSGi services.
This refactors the BusEvent actions, making them available as ScriptExtension via import-preset ScriptAction.
The actions are wrapped for DSL rules, to stay backward compatible.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
Optionally allow providing a source, and then append (or directly) set
the REST package and authenticated username.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* Add AbstractThingHandlerDiscoveryService constructor for tests to use a different executor
* Add JavaDocs
* Make ThingHandler type generic
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
* Set event source for updates and commands from bindings according to new standards
In particular, prefix the channel UID with the package (org.openhab.core.thing), and
the channel UID becomes the actor.
Extends ProfileCallback to allow profiles to explicitly specify a source, and then
uses the new delegation syntax to append the channel UID source component in that
case.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* ScriptTransformationService: Fix engine closed too early
Currently, there are two issues:
When a ScriptRecord is cleared from the cache,
the ScriptTransformationService currently closes the ScriptEngine itself, without involving the ScriptEngineManager.
If a transformation script is invoked again after it has been cleared from the scriptCache, the ScriptEngineManager::createScriptEngine call makes the ScriptEngineManager first remove the old engine from its internal "store",
which includes invoking the scriptUnloaded hook. This invocation can cause an exception because the engine is already closed (by ScriptTransformationService) and hence function/method invocations inside the engine are not possible anymore.
Ff the engine implement Compilable, it is even closed two times by ScriptTransformationService, possibly causing an exception if the ScriptEngine doesn't handle multiple close() calls gracefully.
These issues are fixed by properly notifying the ScriptEngineManager when an engine should be removed and leaving the removal handling to the ScriptEngineManager.
The issues were discovered while working on #5062.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
lolodomoandGitHub
Holger Friedrich
Cody CutrerandGitHub
NadaharandGitHub
Edwin IngandGitHub
openhab-botandGitHub
Christoph WeitkampandGitHub
dependabot[bot]andGitHub
Florian HotzeandGitHub
Дилян ПалаузовandGitHub
lo92frandGitHub
Dan CunninghamandGitHub
