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>
On server timeouts, it's possible for multiple minutes to elapse
between receiving the last pong on the old connection and attempting to
send the next ping on the new connection. If that time span exceeded 5
minutes, the binding went into a minutely reconnection loop, because it
never attempted to send a ping anymore, which led to lastPong not being
updated anymore.
To fix this, replace the timing dependent timestamp handling by a simple
counter which counts how many consecutive ping attempts didn't receive
an answer, and closing the connection after 5 unsuccessful ping
attempts. That new counter is now also reset whenever the connection is
restarted.
Fixes#14188
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>
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
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>
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>
* [homematic] Add HM-MOD-EM-8 properties
If a HM-MOD-EM-8 channel is configured to 'sensor' mode, it advertises a
STATE datapoint, which we should both display as non-advanced and give a
description.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
If a player goes offline (it e.g. lost power or network connection),
mark it as such in the thing status.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* [tr064] Normalize numbers in phone book entries.
Phone book numbers and numbers to be looked up might be formatted
differently (real world example: '+49 (12345) 67890' vs. '01234567890'
(where the former is phonebook formatting and the latter is the format
transmitted by the avmfritz binding). Make sure such formatting
differences do not cause lookup mismatches.
Signed-off-by: Danny Baumann <dannybaumann@web.de>
maniac103andGitHub