Improve javadoc by explaining the different defined context values.
I have added "rule", "channel", "channeltype" and "cronexpression" as those are used within the automation module.
The i18n service uses "location" as context value and expects a map to be rendered.
Signed-off-by: davidgraeff <david.graeff@web.de>
A cron trigger module is actually not that "Generic" and a useful trigger type for a lot of rules.
Therefore I suggest to remove the visibility "HIDDEN" with this PR.
I have also added a context "cronexpression" to the TEXT configuration value, so that UI's can offer a cron expression
selection widget.
(we currently have: 'time','item','script','channel','dayOfWeek','rule')
Signed-off-by: davidgraeff <david.graeff@web.de>
Remove inconsistent visibility "PUBLIC". This value is not documented (there is only HIDDEN and VISIBLE) and this is the only module type that uses PUBLIC instead of just not setting this value at all.
Signed-off-by: davidgraeff <david.graeff@web.de>
The change with unit classes parent (#617) causes it to report missing imports of tec.uom.se when using static import. Before the change this was not a problem because the parent class was SmartHomeUnits. This change adds a new parent class for all units.
Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl>
The classes ImperialUnits and SIUnits both extended SmartHomeUnits. But the classes are used a singletons.
Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl>
For the runtime dependencies a template from the EnRoute project has
been used. To allow further customization and usages of different Maven
scopes, we migrate the template to this repo.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* handle different possible service PID types
The property value "service.pid" can use different types:
* String
* String[]
* Collection of String
Only "String" has been supported.
https://github.com/openhab/openhab-core/pull/557 adds support for
String[]
https://github.com/openhab/openhab-core/pull/559 removes the support for
String[] again and adds support for the Collection type List only.
This commit ensures that String arrays and every collection type is
supported, regardless which (valid) type is used by the OSGi framework
implementation.
Fixes: https://github.com/eclipse/smarthome/issues/6710
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
This addresses https://github.com/eclipse/smarthome/issues/5099 by adding a command description with command options along with the state description.
Command options will give a hint to UIs about the specific commands a channel provides. Command options could be rendered as a drop down and also represent the current state or rendered as push buttons to simply send a command to the ThingHandler.
The infrstructure basically copies the StateDescription infrastructure with CommandDescriptionProviders and an `DynamicCommandDescriptionProvider` interface for bindings to hook in and provide dynamic command options.
Signed-off-by: Henning Treu <henning.treu@googlemail.com>
The io.rest.sitemap integration test has already been moved to a pure
JUnit test of the respective bundle.
Related to: https://github.com/openhab/openhab-core/pull/499
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The ready marker logic is created to hide the real usage. The ready
marker uses an "identifier" that is not specific or limited to bundles.
Currently the bundle symbolic name is used as bundle identifier.
That "convention" needs to be known at several different places.
There should be one method that created an identifier for a bundle and
"no one" needs to care about the implementation details.
Another point is that the bundle symbolic name that has been used is
optional. It may be null e.g. for bundles that has been installed by the
synthetic bundle installer mechanism etc.
The runtime assigns a bundle ID to an installed bundle that remains the
same for the bundle (see JavaDoc). The bundle ID is present all the
time.
The implementation of the "get identifier for bundle" has been choosen
to use the BSN -- if available -- (as before) but fallback to a custom
one using also the bundle ID (to be unique).
So we can provide always a non null identifier for a bundle.
It should be easily to change the identifier creation now if there is
every any need for.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
If a bundle misses a BSN the bundle cannot be installed.
We should provide a method to uninstall the bundle that has been created
by the synthetic installer itself.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
