* New translations systeminfo.properties (German)
* New translations tado.properties (German)
* New translations bluetooth.properties (German)
* New translations bluetooth.properties (German)
* New translations mybmw.properties (German)
* New translations gardena.properties (German)
* New translations astro.properties (German)
* New translations avmfritz.properties (German)
* New translations chromecast.properties (German)
* New translations hue.properties (German)
* New translations logreader.properties (German)
* New translations icalendar.properties (German)
* New translations max.properties (German)
* New translations comfoair.properties (German)
* New translations denonmarantz.properties (German)
* New translations deutschebahn.properties (German)
* New translations dwdpollenflug.properties (German)
* New translations ecotouch.properties (German)
* New translations epsonprojector.properties (German)
* New translations exec.properties (German)
* New translations homematic.properties (German)
* New translations hpprinter.properties (German)
* New translations http.properties (German)
* New translations magentatv.properties (German)
* New translations awattar.properties (German)
HomematicIP added humidity and HVAC control mode under new channel
HEATING_CLIMATECONTROL_TRANSCEIVER|HUMIDITY. Those channels won't
show in PaperUI unless "Advanced" is selected. This pull request
adds those channels as standard.
Impacted HomematicIP devices: HmIP-BWTH, HmIP-BWTH24,
HmIPW-STHD, HmIPW-STH, HmIPW-WTH, HmIP-STHD, HmIP-STH, HMIP-WTH,
HmIP-WTH-2, HmIP-WTH-B
The devices HmIP-eTRV* and HmIP-WT only support CONTROL_MODE not
Humidity.
resolves: #11829
Signed-off-by: Dirk Benecke <dirkbe@web.de>
Signed-off-by: Dirk Benecke <dirkbenecke@Dirks-MBP.fritz.box>
When changing an enum value in the configuration, we used the wrong data
type: while the value in the OH config is a string (the 'option value' -
see HomematicThingHandler::getValueForConfiguration), internally we use
an integer (the 'option index'), so we have to do the option value ->
option index conversion when applying the new value.
This especially was a problem for HM-MOD-EM-8 devices, which check the
CHANNEL_FUNCTION enum value as part of their initialization routine.
When disabling/enabling them after changing the CHANNEL_FUNCTION enum
value, they went offline, because their initialization failed due to a
NumberFormatException (via
HomematicThingHandler::doInitializeInBackground ->
HmChannel::checkForChannelFunctionChange ->
HmChannel::getCurrentFunction)
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* [homematic] Fix min/max values for rollershutters
For dimmers, the 1.0 max value sent by CCU was already converted to
percent values in the item state description. Do the same thing also for
roller shutters.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* [homematic] Validate datapoint values before writing to config
HM config datapoint values on some devices can be out of their valid
range in some cases, particularly if they are unused by the device
currently [1]. Since openhab-core now validates attempts to update
configuration by the thing handlers, make sure we always send a valid
configuration even for those affected datapoints.
[1] One example for such behaviour is HmIPW-DRBL4, which has multiple
datapoints which depend on each other
- POWERUP_JUMPTARGET can have values OFF, ON, OFF_DELAY, ON_DELAY
- POWERUP_ONDELAY_VALUE, POWERUP_ONDELAY_UNIT are only used if
POWERUP_JUMPTARGET has value ON_DELAY
- likewise, POWERUP_OFFDELAY_VALUE and POWERUP_OFFDELAY_UNIT are
only used if POWERUP_JUMPTARGET has value OFF_DELAY
- if e.g. the POWERUP_JUMPTARGET is OFF, e.g. POWERUP_ONDELAY_VALUE
might stay uninitialized by CCU and/or device itself, in which
case it may be reported with an invalid value
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* Prevent the use of exponential notation
The CCU does not accept exponential notation in TCL scripts.
Fix#12301
Signed-off-by: Martin Herbst <develop@mherbst.de>
Sometimes invalid default values ended up in the default value for a channel of a thing type. Initializing the thing would fail completely complaining that it is not an allowed option. This patch makes sure those values are actually valid and attempts to correct them if they are invalid.
Signed-off-by: Flole <flole@flole.de>
The RPC protocol doesn't provide this value, so it always was made up
more or less arbitrarily. Since the UI now uses this value for
validation purposes, there are cases where valid values can not be
entered due to this step size (particularly for datapoints with more
than 1 decimal digit).
Fixes#12183
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* [homematic] Fix long button press handling for HM-IP devices
HM devices have the following long press cycle:
PRESS_CONT
PRESS_LONG
PRESS_CONT (N times for repetion)
PRESS_LONG_RELEASE
while (at least some) HM-IP devices use this one:
PRESS_LONG
PRESS_LONG_START
PRESS_LONG (N times for repetition)
PRESS_LONG_RELEASE
Add support for the latter case while keeping support for the former
case.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* [homematic] Track 'uses LONG_START datapoint' flag per-device
fix for bug #11969
After a restart of openHAB the function 'getScanTimeout()' is called before the member 'installModeDuration' has been initialized with the correct value from the configuration. With a large number of Homematic devices, the default value of 'installModeDuration' is too small to read in all Homematic devices from the CCU.
Therefore, when calling the function 'getScanTimeout()', the value is read directly from the configuration. The member 'installModeDuration' has been removed.
Signed-off-by: raykleibelt <54982000+raykleibelt@users.noreply.github.com>
* New translations astro.properties (Finnish)
* New translations astro.properties (German)
* New translations bluetooth.properties (German)
* New translations boschshc.properties (Italian)
* New translations comfoair.properties (German)
* New translations dwdunwetter.properties (German)
* New translations epsonprojector.properties (German)
* New translations gpio.properties (German)
* New translations heliosventilation.properties (German)
* New translations homeconnect.properties (German)
* New translations homematic.properties (German)
* New translations ipp.properties (German)
* New translations jruby.properties (Hungarian)
* New translations jsscripting.properties (German)
* New translations jsscripting.properties (Hungarian)
* New translations map.properties (German)
* New translations map.properties (Hungarian)
* New translations mqttbroker.properties (Italian)
* New translations nanoleaf.properties (German)
* New translations ocean.properties (German)
* New translations openhabcloud.properties (Finnish)
* New translations samsungtv.properties (Hungarian)
* New translations shelly.properties (German)
* New translations snmp.properties (German)
* New translations sonos.properties (German)
* New translations spotify.properties (German)
* New translations tr064.properties (German)
* New translations tradfri.properties (German)
* New translations unifi.properties (German)
* New translations unifi.properties (Hungarian)
* New translations valloxmv.properties (Finnish)
* New translations volvooncall.properties (German)
* New translations xslt.properties (German)
* Add default translations for binding add-ons
This makes the texts used by these add-ons translatable with Crowdin.
To keep the PR simple, it only adds default translations for add-ons which do not yet have any default translations properties file.
We can do follow up PRs for adding missing key/values to add-ons that already have these files or to remove duplications.
There are several add-ons in this PR that do have non-English translation files, so I'll upload those to Crowdin when the PR is merged.
Signed-off-by: Wouter Born <github@maindrain.net>
* Use globally unique id for registration of callback to allow ...
the connection of multiple OH installations with one CCU.
The bridge id is not sufficient for this purpose because it is same in
all OH installations.
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Retry callback re-registration after connection is resumed
Some services on the CCU need longer to start and are not available
immediately after the connection to the CCU has been resumed.
Improves the solution for #8808Fixes#10439
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Description was missing.
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Changed setting name and description to avoid confusion
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Added a troubleshooting tip to solve a communication problem
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Shortened the label name to follow the guide lines
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Print more information about the reason for the failure
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Using scheduler thread pool and simplified configuration
Instead of configuring separate values for retry delays and number of
retries only the maximum time for retries can be configured.
The init method uses fixed delays.
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Don't retry to send if gateway does not answer at all
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Improved reconnect handling
- unregister callback not necessary if connection is lost
- wait 30s until clients and servers are restarted to give the gateway
some time to recover
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Spotless
Signed-off-by: Martin Herbst <develop@mherbst.de>
* Cancel an active future if the binding is stopped
Signed-off-by: Martin Herbst <develop@mherbst.de>
The XStream.setupDefaultSecurity method is deprecated since XStream 1.4.18.
It no longer does anything, because this is the default in newer XStream versions.
Signed-off-by: Wouter Born <github@maindrain.net>
HM devices provide not only 'long press' events, but also 'long
press continued' (sent in configured long press interval) and 'long
press released' events. So far, those events were swallowed in the
button datapoint handler.
Improve the situation by forwarding those events to the button trigger
channel, making them usable in e.g. rules that react on button long
presses.
A double press timeout of 2 seconds is too long and disturbs single
press processing. Additionally, for double press processing to be
useful, the first press would need to be swallowed until double press
timeout elapses, which is not what happened here: the first PRESS was
sent out as SINGLE_PRESS event, making it impossible to meaningfully
distinguish the 'single press' and 'double press' events within rules.
If needed, double press handling can be implemented equally well within
a rule.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
Currently openHAB and the CCU are using different values for the same state of a rollershutter.
Added information about this under Troubleshooting and listed some examples.
Signed-off-by: Michael Bredehorn <michael@bredehorn.nrw>
The set of available HM-MOD-EM-8 channels varies depending on the
function a given channel is configured to use, which is why for those
devices we can't determine a static ThingType, but instead must populate
the thing channels on initialization. The existing code already handled
that case, but missed registering channel types for the dynamically
generated channels, which is why those channels were not shown in main
UI.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* Fixed a rare NPE introduced while replacing commons-lang
* Provide additional null pointer checks
It is possible that the meta data returned for some device does not
contain a default or maximum value.
Fixes#10945Fixes#10961
Signed-off-by: Martin Herbst <develop@mherbst.de>
