ZXT-600 should update mode when changing setpoint

[ronisaacson]

OH 3.4.3. I have a ZXT-600 IR blaster and it works great with my mini split AC. One issue though:

If the mode is Off and you adjust either the heat or cool setpoint, the unit will turn on and accept that setting. But the thermostat_mode channel doesn't update, so now the AC is on but the mode still says that it's off. The same thing seems to happen if the mode is either heat or cool and you change the opposite setpoint.

I think the correct behavior is to update the mode automatically when changing either setpoint.

[apella12]

It would be helpful to have a Debug log of the scenarios that you describe.

For clarity (I'm not sure I understand exactly);
A) if mode is off

1. and the cool setpoint changed, the device switches to cool mode
2. or the heat setpoint is changed, the device switches to heat mode

B) if mode is Heat and the cool setpoint changed, the device switches to cool mode

C) if mode is cool and the heat setpoint is changed, the device switches to heat mode

If yes the device is switching modes based on what setpoint is changed. That is unusual and possibly device specific. On my zwave thermostat I can change either setpoints without the mode being changed.

[ronisaacson]

Yup that's right. I have a Fujitsu mini split using code 1029, and if I change either the heating or cooling setpoint, the mode on the unit will automatically switch to the mode of whatever setpoint I changed, no matter what it was before.

The Fujitsu IR codes, like most mini-splits with digital remotes, are complete messages with the full state (rather than specific actions). So there's something reading the setpoint change and applying the mode change automatically. I suspect it's the ZXT-600 doing this and not the Fujitsu itself but I have no way to prove it.

[apella12]

I would suggest a rule to send a mode change after a setpoint change (if the current mode is not already on the setpoint mode)

The developer will have the final word, but there would be at least two hurdles to overcome "binding-wise". First the ZW debug logs would need to show a mode change message to act on. Second, the ZW protocol has specific rules on command classes and unsolicited messages and the mechanics of the binding are aligned with these rules. Sending a mode change message from an OH rule will overcome either hurdle.