Battery Level always showing as 100%

[stefan-schweiger]

I just noticed that the exposed battery level is always 100% (or 200 as the cluster value since it's expressed in 0.5 steps as a uint8). For example in Zigbee2MQTT I see this for my the current device (a Ikea door sensor) state:

{
    "ac_status": false,
    "battery": 81,
    "battery_defect": false,
    "battery_low": false,
    "contact": true,
    "linkquality": 188,
    "restore_reports": false,
    "supervision_reports": false,
    "tamper": false,
    "test": false,
    "trouble": false,
    "update": {
        "installed_version": 16777241,
        "latest_version": 16777241,
        "state": "idle"
    }
}

But in Matterbridge the following value is shown (which of course is showing up as 100% for example in Home Assistant):

From quickly looking through the code I can't find anything obviously false with your calculation here:

https://github.com/Luligu/matterbridge-zigbee2mqtt/blob/fca046a26dd5f4b9e8eac95a69ac234b7a5ed84f/src/entity.ts#L544

[stefan-schweiger]

One other thing I just noticed for another device which exposes voltage I see that the value in Matterbridge is actually half of what it is in Zigbee2MQTT even though the conversion you are doing should not be changing the value:

https://github.com/Luligu/matterbridge-zigbee2mqtt/blob/fca046a26dd5f4b9e8eac95a69ac234b7a5ed84f/src/entity.ts#L549

Is there maybe another conversion happening in matter.js or Matterbridge itself (and at some point it just gets capped to the max value)?

[stefan-schweiger]

Maybe this conversion?

https://github.com/Luligu/matterbridge/blob/e9b5a46f2822a51aa43241ff253952f7d582b671/src/matterbridgeDevice.ts#L2412

https://github.com/Luligu/matterbridge/blob/e9b5a46f2822a51aa43241ff253952f7d582b671/src/matterbridgeDevice.ts#L2453

Not sure why voltage then would be half since I don't see a similar thing for battery voltage. But maybe there is another problem since my voltage is 3000 and the default value is 1500 (= half of 3000), so maybe the voltage is not handled at all.

[Luligu]

Hi, for the batter level: /**

• This attribute shall indicate the estimated percentage of battery charge remaining until the battery
• will no longer be able to provide power to the Node. Values are expressed in half percent units, ranging
• from 0 to 200. E.g. a value of 48 is equivalent to 24%. A value of NULL shall indicate the Node is
• currently unable to assess the value.
• @see {@link MatterSpecification.v11.Core} § 11.7.6.13 */ So matterbridge do correctly multiply the percentage by 2. The controller is wrong to show the value, I will check other controllers ... just to be sure.

[stefan-schweiger]

@Luligu I think you by accident multiple by 2 twice (once in matterbridge-zigbee and once in matterbridge), and since you cap the value at 200 it will always show as 100%. Probably if the battery is below 25% values below 100% would show up.

[Luligu]

I have this that shows in this way

I don't understand what you mean ?

[Luligu]

They match They match too

Keep in mind that what you see in the state in z2m can be a situation of moths ago... z2m doesn't publish it again unless you enable send state on start-up and restart...

So I can just suppose that either your data have not been sent or HA shows not correctly the battery.

[stefan-schweiger]

I have 100% for every device in Matterbridge/HA:

But in Zigbee2MQTT they are sensible:

[stefan-schweiger]

Keep in mind that what you see in the state in z2m can be a situation of moths ago... z2m doesn't publish it again unless you enable send state on start-up and restart...

Can you go into more detail what this means? I see a few config options which might fit, but the other zigbee2mqtt integrations I have been using until now where fine with the default config, so I'm a bit unsure why it wouldn't work

[Luligu]

State in z2m is like photo of last settings registered maybe in the last year. Doesn't mean that those values are sent-published. This option decide what happens with state

If all is enabled you can try to restart z2m and it should send the state again. Then check the matterbridge log to see the values update go through ... like Update endpoint.

Is possible that HA doesn't show correctly the values. Apple does as you saw.

[Luligu]

I made the same test... I guess HA doesn't divide by 2... Enable the dynamic example plugin and pair with HA ... there all devices have different kind of batteries and level so you can check what HA does...

[stefan-schweiger]

I have all of those options enabled (which is the default) and restarted zigbee2mqtt but nothing changed.

Just to be clear HA is only reflecting what it gets from Matterbridge. All values in Matterbridge are actually 200 for me.

[Luligu]

The data are not sent then... Try with example plugin... are virtual devices... eeasier to debug issues with controllers

[stefan-schweiger]

The devices from matterbridge-example-dynamic-platform all show up with correct battery values

[Luligu]

Then z2m is not sending values... In the gui Logs put the name of your device in the search box and let it run the whole night... then check if it has updates...

[Luligu]

Hi, in HA you can ask to reinterview device on the aggregator. Then HA reload all attributes, battery included.

[stefan-schweiger]

Hi, in HA you can ask to reinterview device on the aggregator. Then HA reload all attributes, battery included.

Maybe lets leave HA out of the picture, as far as I can tell the values are just reflecting what Matterbridge provides and they update correctly.

Then z2m is not sending values... In the gui Logs put the name of your device in the search box and let it run the whole night... then check if it has updates...

After letting it sit all night I have the correct battery values. Then I tried to restart Matterbridge and everything went back to 200. I have now also tired to enable device_options: { retain: true } in zigbee2MQTT so the broker always keeps the last state of the device (not sure if there is any downsides to this besides storage though), but seems like Matterbridge also does not pick up those retained messages on startup.

[Luligu]

Hi, the retain has no effect on this. It is just useful for the bridge messages that are retained so you can know the z2m status even if z2m is stopped. If you want to update Matter attributes without waiting the battery devices to connect and publish, you can simply leave Matterbridge running and restart z2m (providing you have the option to send state on start activated).