* [mqtt.homeassistant] Improve support for Lock component
* handle state and command payloads differing (as they do by default)
* expose full state possibilities and OPEN command by adding
a TextValue channel
* Recognize intermediate lock states as unlocked on the switch channel
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [mqtt.homeassistant] improve Cover support
* Add support for covers that report position
* Handle when command and state values for OPEN/CLOSE/STOP
differ (as they do by default)
* Expose the full cover state, since it can have tell you
if the cover is moving or not
* Handle covers that have a position only, but not a state
* add constants to clarify up/down values
* Be sure to parse percents from strings in RollshutterValue
---------
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [mqtt] Interpet incoming NaN as UNDEF for NumberValues
Since DecimalType and QuantityType don't support NaN, but
when you're linking to a topic that the device is using
floating point, NaN might happen.
---------
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [mqtt.generic] separate command parsing from cached value updating
fixes#12150
Previously, Value.update would parse the command, _and_ update the cached
value with that command. Which means that when sending a command towards
MQTT (instead of processing an update from MQTT), the cached value was
unintentionally updated. This prevented the REFRESH command from returning
the most recent value received from the device.
Separating the two concerns also makes the test more obvious what they are
testing, and vastly simplified a kludgy workaround that RollershutterValue
was using to be able to process Commands that aren't States.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [mqtt.generic] split Value::parseCommand into parseMessage
so that a particular value type subclass can have varying implementations
if it desires
---------
Signed-off-by: Cody Cutrer <cody@cutrer.us>
To mitigate issue https://github.com/openhab/openhab-core/issues/3125
(common thread pool exhaustion when combining parallel streams with
synchronization or locks)
Signed-off-by: Sami Salonen <ssalonen@gmail.com>
So that other pieces of openhab can know what unit it's going to be,
without it having a value yet. Importantly, any necessary conversion
that need to be applied to the other portion of the state description -
min, max, and step.
See also https://github.com/openhab/openhab-core/pull/3132
Signed-off-by: Cody Cutrer <cody@cutrer.us>
HASS registers availability topics before calling start(), so
the AbstractMQTTThingHandler was never subscribing/starting the
availability channel(s). So do so in start() of the base class.
I checked other implementations, and either they already handle
re-registering availabilityTopics in their start()
(GenericMQTTThingHandler), or they don't use availabilityTopics
at all from the base class and manage it themselves (Homie).
Note that this shows up as newly-added HASS things not having
a problem (because the components aren't discovered until after
the ThingHandler is started), but if you restart OpenHAB or
disable/enable the thing, the channels (and components) are
cached, thus how availabilityTopics are known before starting.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Range is 0..255, not 0..250.
rgb -> hsv -> rgb still isn't perfect, but it's better. In
particular, I found this when using HSBType.BLUE in a test,
and it was coming out as 0,0,250 in RGB. It now comes out as
a proper 0,0,255.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* New translations bluetooth.properties (Finnish)
* New translations danfossairunit.properties (Danish)
* New translations hdpowerview.properties (Danish)
* New translations jruby.properties (Italian)
* New translations miele.properties (Danish)
* New translations mqtt.properties (Italian)
* New translations openwebnet.properties (Italian)
fixes#10711
technically this code is in mqtt.generic, but it's only used by Homie.
in particular, if an incoming string doesn't match an enum, this will now
just ignore the value instead of raising an exception to be caught somewhere inside
of Hive MQTT, and eventually timing out and logging that mandatory topics weren't
received, instead of logging a pointer to the actual problem. this makes it so that
if there's a homie $datatype openhab doesn't understand (like duration), it will be
able to get to the point of just choosing a string channel
also did some minor debug logging cleanup for mqtt:
* fixed a typo
* when logging homie device name from the thing handler, use the config deviceid,
since we likely don't have the attributes from MQTT yet
Signed-off-by: Cody Cutrer <cody@cutrer.us>
