also fix the conditional for JSON attributes on other components,
and make the channel read only.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
but only for newStyleChannels, which is already a breaking change of
most channels getting renamed for 4.3 anyway
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
Use the `subtype` field to collapse multiple DeviceAutomation components into
a single channel.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
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>
In particular, use the color_mode attribute to tell us which color space to parse in,
instead of trying to guess. Some devices will fill out attributes not-pertinent to
the current color mode, and their math might be... less than optimal.
Also sync color temp and color channels when the color_mode is the opposite.
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>
While it's useful in general to not have to copy/paste a MQTT message into a JSON
parser to verify syntax, it also includes details about fields that are the wrong
data type that a generic JSON parser won't catch. A la #17375.
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>
* [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] add support for Update component
This component is fairly non-standard - it doesn't add any channels.
Instead, it provides several properties to the thing, and also adds
a thing configuration allowing you to trigger an OTA update on a
Home Assistant device from MainUI.
---------
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.homeassistant] interpret a dimmable light as OFF properly from zigbee2mqtt
zigbee2mqtt can send a brightness of say 99, with a state of OFF, when a bulb is
off. make sure if state is sent, it overrides all other inferences
* handle brightness but not color bulbs
---------
Signed-off-by: Cody Cutrer <cody@cutrer.us>
