New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic expose #9929
Comments
You can you use different zigbee models based on selected mode. Then you can create different device definitions based on model name. They're few zigbee led controllers, which are doing in this way. |
Thank you @nurikk , I think that would be a acceptable way to handle it. Can you point me a reference of a led controller doing it like that? Thank you Br, |
I can't point to exact implementation, but your converter should look like this: const baseDefinition = {
vendor: 'LiXee',
description: 'Lixee ZLinky',
fromZigbee: [haMeterIdentificationFZ, seMeteringFZ, haElectricalMeasurementFZ],
toZigbee: [],
configure: async (device, coordinatorEndpoint, logger) => {
const SW1_ENDPOINT = 1;
const endpoint = device.getEndpoint(SW1_ENDPOINT);
// ZLinky don't emit divisor and multiplier
endpoint.saveClusterAttributeKeyValue('haElectricalMeasurement', { acCurrentDivisor: 1, acCurrentMultiplier: 1 });
endpoint.saveClusterAttributeKeyValue('seMetering', { divisor: 1, multiplier: 1 });
for(let reportable of dataReportable){
logger.debug(`ZLINKY_TIC: Start configure reporting for ${reportable.name} (${reportable.cluster}/${reportable.attribut}).`);
//await endpoint.read(reportable.cluster, [reportable.attribut]);
endpoint.configureReporting(reportable.cluster || reportable.clusterId,
[{
attribute: reportable.attribut || reportable.attributId,
minimumReportInterval: 1,
maximumReportInterval: repInterval.MINUTES_5,
reportableChange: 1,
}]).then(() => {
logger.debug(`ZLINKY_TIC: ${reportable.name} (${reportable.cluster}/${reportable.attribut}) report successfully configured.`);
}).catch(e => { // Bug on firmware v1.0.0 (2021 11 01) -> Some attributs reportable cannot be configured
logger.warning(`ZLINKY_TIC: Failed to configure reporting for ${reportable.name} (${reportable.cluster}/${reportable.attribut}). Adding in polling attributs list.`)
dataNonReportable.push(reportable);
});
}
},
options: [exposes.options.measurement_poll_interval()],
onEvent: async (type, data, device, options) => {
const endpoint = device.getEndpoint(1);
if (type === 'stop') {
clearInterval(globalStore.getValue(device, 'interval'));
globalStore.clearValue(device, 'interval');
} else if (!globalStore.hasValue(device, 'interval')) {
// periodic scan for non-reportable attributs
const seconds = options && options.measurement_poll_interval ? options.measurement_poll_interval : 120;
await poll(endpoint);
const interval = setInterval(async () => {
try {
await poll(endpoint);
} catch (error) {/* Do nothing*/ }
}, seconds * 1000);
globalStore.putValue(device, 'interval', interval);
}
},
endpoint: (dev) => {
return {
'haElectricalMeasurement': 1, 'seMetering': 1, 'haMeterIdentification': 1
}
}
}
// here you export array
module.exports = [
{
zigbeeModel: ['ZLinky_TIC_mode1'],
exposes: [indexEnergy(), ...exposesData],
extends: baseDefinition,
// you can create even custom configure method for every mode
},
{
zigbeeModel: ['ZLinky_TIC_mode2'],
exposes: [indexEnergy(), ...anotherExposesData],
extends: baseDefinition,
},
//continue
]; |
ok, thanks. It is clear for me what sou say. But when the final user will pair the device, how it will be able to decide which to use? The converters that I saw in the repo have some differences (like model, or last chars of manufacter, etc.) which makes possible to create fingerprints when paired. Here we are talking about the exactly same device. Sorry, I'm not familiar with the framework/APIs of Z2M Br |
I'm interested too. Dynamic exposes would be interesting for one of my devices also. |
What I've tried to do is define Also I've tried the idea of @nurikk , but device is not recognized because there is no match based on Br, |
I think i have found a solution to our problem.
Haven't tried yet. But I will tonight. I think this will work. |
I have tried jet. For my device it works like this:
This is the same device but with different configurations. Hope will help you to. |
Hi, Thank you @Danit2 for sharing your code. In your example, you use fingerprint aproach by endpoints, right? In that case, it means that your device expose different endpoints based on his mode/status? |
Yes my device can have different modes. You can use them also. |
ok, thank you for clarifying it. In my side the device doesn't have any mode. It just expose all attributes (some are reportable and some others you had to read them). So maybe if I can't control dynamically what is exposed to Z2M, maybe I could try to restrict what is sent to MQTT (Koenkk/zigbee-herdsman-converters#3468) In any case, your aproach doesn't seems applicable to my case. Thank you in any case :) |
Is your feature request related to a problem? Please describe
Zlinky is a small zigbee device that can be connected to a electrical Linky box and expose different parameters. However, the same Linky device can have multiple configurations:
Those combinations makes useless expose all elements to the user, because most of them will be null or the max value of the data type.
Ex (using integration https://gist.github.com/ralmn/02de46e193bf111062f15be07d3e9bd2):
In this case, all data shown here is useless because my Linky is in mode Historique and monophase and the data shown above is for people with mode Standard and triphase
Describe the solution you'd like
exposes
definition of the converter that could be adapted dynamically or during the init withoptions
Describe alternatives you've considered
Currently the only way right now is disabling in the code the elements you don't want.
Additional context
Zlinky Integration: https://gist.github.com/ralmn/02de46e193bf111062f15be07d3e9bd2
Zlinky doc: https://github.com/fairecasoimeme/Zlinky_TIC
The text was updated successfully, but these errors were encountered: