Battery level 0% in Home application[Bug] about homebridge-z2m HOT 22 CLOSED

I'm currently working on a new version of the plugin, which should solve these kind of nuances between devices, by using the information provided by zigbee2mqtt (a new API was added recently to get this kind of information).
I try to put updates on this in #18

As for this particular issue, it can be solved by extending the implementation of the BatteryServiceWrapper in platformAccessory.ts.
However, this code will all be replaced in the version I'm working on, so I personally would rather spent time on the new version than patching the "old" code.

from homebridge-z2m.

I see! Thanks for your quick reply. So, basically you just say I should wait for the new release without changing anything myself.

Then I have another question: will the new release be just a simple update with
npm i -g homebridge-z2m@latest?

Will there be any compatibility issues or can't you tell yet?

Thanks in advance.

from homebridge-z2m.

Once it is released, it should be able to update it that way.

In terms of compatibility issues, so far I think it will be possible to keep the configuration side of things the same.
Next to that the plugin will probably "remove" all accessories created by the previous version and recreate them (if they are not ignored by the configuration of course).
For a lot of devices, I think this won't be an issue, since the unique identifier will still be based on the IEEE address of the actual device, so I don't expect any configuration to be lost there.
For some services the name might slightly change (especially devices that have multiple endpoints, i.e. a relay/dimmer module with multiple channels), which might lead to the user having to reassign these to the correct rooms and automations.
Unfortunately there isn't a whole lot I can do about that (except for adding a lot of exceptions to the code, to work around this, but I'd rather not do that).

As mentioned in the README, the plugin still is a work in progress, so changes are to be expected.
I do think that this will be a one time thing, because I don't expect the plugins mechanism to change yet another time.

from homebridge-z2m.

Ok, thanks for your response! It is all clear for me. I think it's a great plugin and therefore I am very happy to be able to use it.

Do you have an expectation on when you will update your code on github?

from homebridge-z2m.

Most of the work I do on the new version is on the z2m-exposes branch.
My goal is still to have some kind of release before the end of the year, so people can start trying it out and I can gather feedback.

from homebridge-z2m.

That's great news!!! I will then also try to do some testing with it.

I think it will also be good for the zigbee2mqtt platform then to do some testing with sensors which are not listed yet. I have some sensors I work with which I can also test. Will you also be adding other types of sensors or not?

from homebridge-z2m.

Eventually I will, but I'm first focusing on the stuff that is supported in the latest release of the plugin.

If you have specific devices you would like to see support for, don't hesitate to open up an issue requesting it.
That way I know way I can take it into consideration when starting to expand the list of supported devices.

from homebridge-z2m.

@jos149 I wrote the battery service support for the new version today and I figured I would have a look if this would solve this issue for your sensor.

Unfortunately, if I look at the fromZigbee converters, I can't seem to find one that uses battery_level instead of battery.
Also looking at the device mapping used by zigbee2mqtt, I can't seem to find a Heiman smoke sensor that does this.
Can you maybe tell me the exact model number?

from homebridge-z2m.

It is the Heiman HS1SA which is indicated here as it reports battery but if I look in my Zigbee log it reports the battery level as battery_level. So, I guess that should also be the reason why it reports 0% in my Home app right? Tonight (I am (also?) Dutch) I will update to the newest version of your plugin to see if anything changed. I guess I am able to update to the newest version with the command I mentioned previously?

Sorry if I was not clear to you or I did get something wrong from what you said. I am a mechanical engineer so no expert in this subject, it is just a hobby haha.

from homebridge-z2m.

I did not yet publish a new version, so nothing to try out just yet.

I'll double check the code of zigbee-herdsman-converters for this particular sensor.

from homebridge-z2m.

I had another look, but all the code for the sensor you mention also indicates that it is using battery and not battery_level.
Can you maybe share your MQTT status message from the zigbee2mqtt/[FRIENDLY_NAME] topic for this sensor?

Which version of zigbee2mqtt are you using exactly?

from homebridge-z2m.

Dec 14 20:44:35 homebridge npm[475]: Zigbee2MQTT:info 2020-12-14 20:44:35: MQTT publish: topic 'zigbee2mqtt/Smoke sensor', payload '{"ac_status":false,"battery":100,"battery_low":false,"enrolled":false,"linkq

My mistake, I now see that it is battery, However, I am almost sure it reported different before. Anyway, what would then be the reason I cannot see a percentage?

from homebridge-z2m.

It might be that it had not been reported before. Once you've seen this message I would expect that it shows up.

If it doesn't, maybe it has to do with the space in the friendly name of the sensor (I've never tested it with spaces in the name).

from homebridge-z2m.

I tried but without success.

I did however get a message from zigbee2mqtt which said: no converter available for 'smoke' and it did the same message for 'battery'.

I don't know if this helps...but it might

from homebridge-z2m.

Sorry, @jos149, I forgot to reply to your message.

I think the log messages you are referring to aren't relevant and caused by the way the current version of the plugin constructs the message to the zigbee2mqtt/FRIENDLY_NAME/get topic. The future version of the plugin will probably no longer trigger these messages, although these messages don't do any harm.

Have you tried to run Homebridge in debug mode (-D)?
Maybe those logs will help more to figure out what's going on.

from homebridge-z2m.

Hey, I have not yet been able to access my network with my homebridge server. So have not been able to run this in debug mode. I will reply again when I have done this.

Changing the friendly name didn't do anything for the battery status like I mentioned. Do you have any other tips on how I could resolve this? Isn't it weird my smoke sensor reports a battery level in the zigbee2mqtt log but it does not report it through homebridge?

from homebridge-z2m.

[zigbee2mqtt] Publish to 'zigbee2mqtt/0x000d...../get': '{"battery":0,"smoke":0}'

So, when starting homebridge I get this line in the initialization. It says battery 0, however, in the zigbee2mqtt I get the correct status. Is this useful information for you?

And btw, do the sensors get saved in the cachedAccessories file from homebridge? Or how does this work?

Another thing I noticed was that everytime restarting my homebridge server one smoke sensor is always high (it detects smoke). However, this is not true. I have to trigger it once for the notification to disappear. Any clue?

from homebridge-z2m.

[zigbee2mqtt] Publish to 'zigbee2mqtt/0x000d...../get': '{"battery":0,"smoke":0}'

So, when starting homebridge I get this line in the initialization. It says battery 0, however, in the zigbee2mqtt I get the correct status. Is this useful information for you?

This is the plugin trying to request data from zigbee2mqtt.
However, since it is a battery powered product, this will probably have no effect.
I reckon you are running v0.0.10 of this plugin?

And btw, do the sensors get saved in the cachedAccessories file from homebridge? Or how does this work?

Yes.

Another thing I noticed was that everytime restarting my homebridge server one smoke sensor is always high (it detects smoke). However, this is not true. I have to trigger it once for the notification to disappear. Any clue?

I don't have this particular smoke detector, but one from Xiaomi. I've never experienced this behavior with this sensor nor with my CO/gas sensors or water leak sensors. Maybe there's a difference in the configuration of zigbee2mqtt that can cause this.

from homebridge-z2m.

This is the plugin trying to request data from zigbee2mqtt.
However, since it is a battery powered product, this will probably have no effect.
I reckon you are running v0.0.10 of this plugin?

I don't understand what you are saying here. In the homebridge command it sends a 'get' request to the sensor and the received values are 0 and 0 for battery and smoke. This is how I at least read it. When I am just manually start zigbee2mqtt and read the received data I get something like battery = 80. So, my point is: I thought I had some useful information for you to work with because I found it strange that your plugin tries to 'get' values from the sensor and receives a 0 while the zigbee2mqtt gets a different value.

I don't have this particular smoke detector, but one from Xiaomi. I've never experienced this behavior with this sensor nor with my CO/gas sensors or water leak sensors. Maybe there's a difference in the configuration of zigbee2mqtt that can cause this.

Somehow, after remaining 'true/high' for a while it has disappeared today. I will look at the log again.

from homebridge-z2m.

In the homebridge command it sends a 'get' request to the sensor and the received values are 0 and 0 for battery and smoke. This is how I at least read it.

No, this is literally the message being send (published) to MQTT by the Homebridge plugin. It's not a message from zigbee2mqtt. For more information, I'd recommend to check the docs of zigbee2mqtt about the different MQTT topics/messages.

from homebridge-z2m.

@jos149 In case you are already running zigbee2mqtt v1.17.0 (or newer), I would suggest to give the latest release on the next channel a try.

See the docs on installation for more information.

from homebridge-z2m.

Closing this issue due to inactivity.

from homebridge-z2m.