BAC-006AZB Support - Help needed to creating a new external definition

[nygma2004]

I have a Beca BAC-006AZB thermostat, which is very similar to some of the models already supported. It is recognized as BAC-003, but I wanted to find tune the definition in two different ways:

• The BAC-003 definition sends a current_cooling_setpoint and also current_heating_setpoint which is confusing as the device does not have two different setpoints based on the mode.
• I worked with the modbus version of these thermostats and it is possible to get the state of the relay / valve (e.g. heating is currently on or off) and that was missing from the definition.

I created a new external definition, set the log level to debug, and at the same time found this issue: #24389. I took mode of Bart's settings and copied into the external definition:

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const modernExtend = require('zigbee-herdsman-converters/lib/modernExtend');
const e = exposes.presets;
const ea = exposes.access;
const tuya = require('zigbee-herdsman-converters/lib/tuya');

const definition = {
    // Since a lot of Tuya devices use the same modelID, but use different datapoints
    // it's necessary to provide a fingerprint instead of a zigbeeModel
    fingerprint: [
        {
            // The model ID from: Device with modelID 'TS0601' is not supported
            // You may need to add \u0000 at the end of the name in some cases
            modelID: 'TS0601',
            // The manufacturer name from: Device with modelID 'TS0601' is not supported.
            manufacturerName: '_TZE204_dzuqwsyg',
        },
    ],
    model: 'TS0601_new',
    vendor: 'Tuya',
    description: 'BAC-006AZB 2 pipe thermostat',
    fromZigbee: [tuya.fz.datapoints],
    toZigbee: [tuya.tz.datapoints],
    onEvent: tuya.onEventSetTime, // Add this if you are getting no converter for 'commandMcuSyncTime'
    configure: tuya.configureMagicPacket,
        exposes: [
            e.child_lock(),
            e.binary('state', ea.STATE_SET, 'ON', 'OFF').withDescription('Turn the thermostat ON/OFF'),
            e.enum('operation_mode', ea.STATE_SET, ['manual','program','holiday','temp man']).withDescription('Thermostat current operational mode'),
            e.binary('backlight', ea.STATE_SET, 'ON', 'OFF').withDescription('Turn the backlight ON/OFF'),
            e.numeric('backlight_brightness').withUnit('%').withValueMax(99).withValueMin(4).withDescription('Backlight brightness in standby mode'),
            exposes.climate()
                .withLocalTemperature(ea.STATE)
                .withRunningState(['idle', 'heat'], ea.STATE)
                .withSetpoint('current_heating_setpoint', 10, 35, 0.5, ea.STATE_SET)
                .withLocalTemperatureCalibration(-9, 9, 1, ea.STATE_SET)
                        .withPreset(['hold', 'program']),
                ...tuya.exposes.scheduleAllDays(ea.STATE_SET, 'HH:MM/C HH:MM/C HH:MM/C HH:MM/C'),
            e.deadzone_temperature().withValueMin(0).withValueMax(5).withValueStep(1),
            e.binary('window_open_detection', ea.STATE_SET, 'ON', 'OFF').withDescription('Turn the Window Open Detection ON/OFF'),
            e.binary('eco_mode', ea.STATE_SET, 'ON', 'OFF').withDescription('ECO mode ON/OFF'),
            e.eco_temperature().withDescription('ECO Heating energy-saving temperature').withValueMin(15).withValueMax(30),
                e.temperature_sensor_select(['IN', 'AL', 'OU']),
            e.max_temperature().withValueMin(15).withValueMax(45).withValueStep(1),
            e.min_temperature().withValueMin(5).withValueMax(15).withValueStep(1),
            ],
    meta: {
        tuyaDatapoints: [
            [1, 'state', tuya.valueConverter.onOff],
            [2, 'operation_mode', tuya.valueConverterBasic.lookup({'manual': tuya.enum(0), 'program': tuya.enum(1),'holiday': tuya.enum(2), 'temp man': tuya.enum(3)})],
            [4, 'eco_mode', tuya.valueConverter.onOff],
            [16, 'current_heating_setpoint', tuya.valueConverter.raw],
            [19, 'max_temperature', tuya.valueConverter.divideBy10],
            [24, 'local_temperature', tuya.valueConverter.divideBy10],
            [26, 'min_temperature', tuya.valueConverter.divideBy10],
            [27, 'local_temperature_calibration', tuya.valueConverter.localTemperatureCalibration],
            [36, 'running_state', tuya.valueConverter.raw],
            [40, 'child_lock', tuya.valueConverter.lockUnlock],
            [101, 'unknown_0-99', tuya.valueConverter.raw],
            [106, 'schedule_sunday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [107, 'schedule_saturday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [108, 'schedule_friday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [109, 'schedule_thursday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [110, 'schedule_wednesday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [111, 'schedule_tuesday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [112, 'schedule_monday', tuya.valueConverter.thermostatScheduleDayMultiDP],
            [113, 'preset', tuya.valueConverterBasic.lookup({'hold': tuya.enum(0), 'program': tuya.enum(1) })],
            [114, 'backlight', tuya.valueConverter.onOff],
            [115, 'backlight_brightness', tuya.valueConverter.raw],
        ],
    },
    extend: [
        // A preferred new way of extending functionality.
    ],
};

module.exports = definition;

Now I can see my new device under the new name, so I know the system is picking up the new definition.

Question 1:
And even though this definition only have current_hearing_setpoint defined, but in MQTT I am still getting this:

{
   "child_lock":"UNLOCK",
   "current_cooling_setpoint":29,
   "current_heating_setpoint":35,
   "deadzone_temperature":1,
   "fan_mode":"auto",
   "linkquality":255,
   "local_temperature":29,
   "local_temperature_calibration":0,
   "operation_mode":"holiday",
   "preset":"manual",
   "schedule":"06:00/20 11:30/21 13:30/22 17:30/23 06:00/24 12:00/23 14:30/22 17:30/21 06:00/19 12:30/20 14:30/21 18:30/20",
   "state":"ON",
   "system_mode":"fan_only",
   "system_mode_device":"fan_only"
}

I don't understand where the current_cooling_setpoint comes from? Why is it being sent?

Question 2:
The above definition is missing some of the features supported my thermostat, which was working fine as BAC-003. Is it possible to see the definition of any of the device which is already supported? So I can copy and paste some of its settings to my definition?

Question 3:
I am not seeing anything in the debug log what is stated in the documentation. Or is it because the external definition already has the exposes and tuyaDatapoints defined, so the raw details are not included in the debug log any more?

[robvanoostenrijk]

@nygma2004,

You should be able to change back to BAC-003 as it looks to be the proper definition of your device.

I added cooling_setpoint_temperature to try and resolve Matterbridge integration, but obviously it had unintended side effects.

I've provided a writeup of the incoming changes here:
#25718 (comment)

If you are able to test this locally as well, it would generate valuable feedback support.

[nygma2004]

@robvanoostenrijk Thanks a lot for these comments. I am processing the data in Node-Red, so I can implement some logic to look both the cooling and heating setpoint and combine it into a single value for our use.
I don't have the devices any more (moved to the final location to test the zigbee network), but should have a chance to get them back and do some more testing. Also I am not yet upgraded to 2.x and a bit afraid of the migration so I may not have the latest version either.
But any work that is done with BAC-002-AZLB (on the linked topic) should be applicable for me as well. If I understand it correctly, the number (002 or 003) is a physical version of the device, but the internal workings are identical.

[robvanoostenrijk]

Both BAC-002-AZLB and BAC-003 will again only expose current_heating_setpoint only.
The activity heat or cool will be indicated by the system_mode.

Correct about the device types. I have 1x BAC-002-AZLB (TS0601 / _TZE200_dzuqwsyg) and 2x BAC-003 (TS0601 / _TZE204_dzuqwsyg), both are identical in behaviour, including the exposed datapoints.

I'll do some additional checking on the service menu settings of each as well and double-confirm there are no differences.

[nygma2004]

Fantastic. I just need to understand how these changes will be available for me? I am not sure how I can track in which release these changes will be included in. I assume these will be in the 2.x release? I am on 1.39.0 at the moment.

[robvanoostenrijk]

2.x, 1.x is no longer in active development. However you could choose to backport the code to an external converter instead if your requirement is to stay on 1.39.0 longer.