if multiple DeviceTrigger components share a topic, and each
has a payload value configured, only messages matching that
payload should be delivered to the corresponding channel
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
* [mqtt.homeassistant] Fix jinja usage in availability templates
Use the local Jinjava, instead of implicitly depending on the Jinja
transformation service.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
* [mqtt.generic] Support chaining transformations without an intersection symbol
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
Similar to how UP/DOWN are processed for rollershutters.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
Modify code which leads to build error with new version of SpotBugs.
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
Closes#16276
This is how it mostly works already anyway
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
* [mqtt] Treat incoming empty string as NULL for most types
Empty strings are often received when deleting retained topics when a device
goes offline, or as the result of a transformation that is missing
a value (such as a "scene" event from zwave-js-ui, which sends JSON with
a timestamp and the scene value, then immediately sends a value to the topic
with only a timestamp).
For string channels, add a configuration value to allow setting a specific
string for treating as NULL, since empty string can make sense for that
type.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
That are used by the Home Assistant binding, but may be useful
for others.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
* [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>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
* [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>
