Changed username to userName, otherwise the username is not imported correctly and auth does not work.
Signed-off-by: e36Alex <alexander18011984@me.com>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
Depending on device configuration and used central [1], HM devices may
indicate long press repetition either by a single PRESS_CONT event or by
a PRESS_CONT + PRESS_LONG combination. In the latter case, make sure to
not generate a LONG_REPEATED trigger channel event for both PRESS_CONT
and PRESS_LONG, but instead keep LONG_REPEATED generation to the
PRESS_CONT handling.
[1] I'm not sure what a real CCU is doing, but for Homegear, a
configured long press timeout of less than 1s generates only
PRESS_CONT, while a timeout of more than 1s generates
PRESS_CONT + PRESS_LONG ... see [2].
[2] https://github.com/Homegear/Homegear-HomeMaticBidCoS/blob/master/src/BidCoSPeer.cpp#L1711-L1716
Signed-off-by: Danny Baumann <dannybaumann@web.de>
* make VirtualDatapoint belonging ContactSensor for more devices available
---------
Signed-off-by: niclas18 <87126599+niclas18@users.noreply.github.com>
* 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>
