MiBoxer FUT089Z remote: Converter improvements & fixes #10049
Conversation
Device observed to report every 4h, set to 6h (21600s) for safety margin
No functional changes - moved existing fromZigbee converters, exposes, and configure function into a modernExtend function while preserving identical behavior.
Added optional numeric sensors for hue, saturation, color_temperature, and level values that can be enabled via the 'expose_values' device option. These sensors capture the actual parameter values from remote control actions.
- Add zone-specific group ID configuration options (zone_1_group_id to zone_8_group_id) - Implement dynamic zone group mapping with configurable defaults - Add event handler to update device configuration when zone options change - Update configure function to use dynamic zone mapping instead of hardcoded values - Maintain backward compatibility with default group IDs (101-108)
- Implement zone suffix detection based on group ID and device options - Create zone-aware converters that add zone suffixes to action names - Add legacy_actions option to control action naming behavior - Generate dynamic action exposes for all 8 zones (on_zone_1, off_zone_1, etc.) - Support fallback to legacy action names when legacy_actions is enabled - Actions are automatically suffixed with zone number based on group ID mapping
…r FUT089Z - Change zone_actions option to be opt-in (false by default) - Legacy action names (on, off, etc.) are now the default behavior - Zone-specific actions (on_zone_1, off_zone_2, etc.) only when zone_actions=true - Improves backward compatibility and reduces breaking changes for existing users - Users can still access zone-specific functionality by enabling zone_actions option
src/devices/miboxer.ts
Outdated
| // Override the action with zone suffix | ||
| return { | ||
| ...baseResult, | ||
| action: `${actionName}${zoneSuffix}`, |
There was a problem hiding this comment.
I decided to implement everything as user-configurable additions which should not break existing installations.
Does this not change the reported actions?
There was a problem hiding this comment.
Good point. It actually does not change the actions, because the actionNames are set to the same values as in the base converters, and zoneSuffix is empty as long as options.zone_actions is not set (cf. https://github.com/Koenkk/zigbee-herdsman-converters/pull/10049/files#diff-4b260b5fd015375f2e9086bc4ae23698b90809745669fc924fe8188b84153cd3R51).
However, the actionName parameter is superfluous (it's actually a left-over from the local converter I started with) and I should better use baseConverter.action here. Fix is on the way.
| fz.battery, | ||
| fz.tuya_switch_scene, | ||
| // Add converters for numeric sensors (always included, but they check options internally) | ||
| actionPropertyConverters.hue_saturation, |
There was a problem hiding this comment.
the on/off converters already expose action_level, I don't think we need these?
| new exposes.Binary("expose_values", exposes.access.SET, true, false).withDescription( | ||
| "Expose additional numeric values for action properties (hue, saturation, level, etc.)", | ||
| ), | ||
| new exposes.Binary("zone_actions", exposes.access.SET, true, false).withDescription( |
There was a problem hiding this comment.
Instead of making this an option, I think it's more logical to include the `zone in the property, so e.g. in case of a zone 1 on, the following is published:
{
action: on,
action_zone: 1
}
I got one of these remotes recently, and while there has already been a lot of awesome work by others to get it supported in Zigbee2MQTT, it still took me a while to collect all the bits and pieces to get everything running to my satisfaction. Here's what I came up with - I believe that this will ease setting this up also for others, and I hope that you consider at least parts of this worthy to be added - lmk what you think.
Since this device is available for several year now and probably actively used in many installations, I decided to implement everything as user-configurable additions which should not break existing installations.
Summary
This PR improves the MiBoxer FUT089Z converter and fixes several open issues and limitations:
MiBoxer FUT089Z (RGB+CCT Remote)devices can't be used individually #6274)Features & fixes in detail
Implement features from the user extension in the converter
Previously, the device required installation of a user addon (https://github.com/Koenkk/zigbee2mqtt-user-extensions/tree/main/unstable/miboxer-fut089z) for some functionalities. That user extension is not working with recent Zigbee2MQTT versions (Koenkk/zigbee2mqtt-user-extensions#7 and Koenkk/zigbee2mqtt-user-extensions#14). This PR implements the functionalities of the user addon directly in the converter as user-configurable options, not changing the default behavior. This removes the need to install an additional addon, and basically resolves the issues. It should also resolve #8926, because the features should also work out-of-the-box with other white-label devices.
on,off, etc.. While in principle it is possible to distiguish buttons via group IDs, this is very unusual to do and differs from other similar devices. With the zone-specific actions enabled, the converter appends a suffix to each action (_zone_1to_zone_8, where "zone" is the term that is used in the user manual of the remote control), thus mimicking the behavior of other devices with different endpoints per button pair more closely.Enable use of multiple FUT089Z devices
During configuration, each
zone(on/off button) is assigned to a Zigbee group (101-108). These groups are fixes, so if multiple FUT089Z devices are on the same network, they all control the same groups and devices.This PR introduces configuration options (and the corresponding functionality) which let the user define a different group for any button. This fixes #6274
Fix ability to send messages to the device
As with most battery-powered device, this remote has its Rx turned off most of the time and is only able to receive commands after it sent a command itself (e.g. after a button press). Therefore messages to the device must be queued long enough. This is ensured by the
quirkCheckinInterval(21600)(i.e. wait for up to 6 hours until the device checks in again - the observed reporting interval of this device is 4 hours). This change is required to reliably modify the device configuration after initial configuration, e.g. to change group IDs.What's still not working
The remote seems to decide internally whether it wants to send a hue/saturation change or a color temperature request. Most of the times (e.g. after pressing one of the on/off buttons), it sends hue/saturation. After the 'W' button is pressed, it sends color temperature. I have not found a way yet to force the remote to a fixed behavior for each zone.
Next steps