Thanks for reporting this. I don't have any devices that sleep but you are correct, Battery+ should restore its state.

The new beta 2.3.12 now has this change, if you are able to validate I'll close this issue.

Feedback from #1843 suggests this isn't fixed unfortunately.
Sorry, there is just something odd about the Shelly Door/Window sensor that's not getting it identified as a having a battery.
There's little I can do about this without having one to test myself so having to close this as unfixable.

Hi,

The point is that those entities should be restored entity in order to work correctly.

Thank you for considering the code change.

The latest beta does change them to restored entities but doesn't seem to have an effect.
It was a worthwhile change and may help with others but doesn't seem to fix the Shelly sensor.

Will better investigate as soon as ai have the time for this task

@andrew-codechimp is this problem fixed? I have a similar experience with all of my Shelly TRVs. When they are awake and I add them to HA Battery Notes everything is working as expected. After some time all Battery+ Sensors get unavailable. There is no chance to get them back working except to delete the device and read it. Shall I open another new issue?

I made these entities restore entities so thought they were fixed but if you are running the latest version then that appears not to made a difference.

Unfortunately I don't have any of these devices to be able to test this further so I don't have a way to fix this for these devices.

@andrew-codechimp thanks for the info, even if that is of course a great pity. ;)

I will reopen this issue just as a reminder to myself if I ever get a device to test or more inspiration.

Hi @andrew-codechimp, is there anything I/we can do to help?

Hi @andrew-codechimp, is there anything I/we can do to help?

Thanks but I think I'll have to read through the Shelly BLE code to see if there's anything odd there I need to handle.
I have some BLE devices myself (Xiaomi plant sensors) that do come back so it's not all BLE devices that have the issue.

Okay, well let me/us know if that changes. Happy to help. Actually it’s also not just BLE. I have them on wifi, but same issue 😉

Okay, well let me/us know if that changes. Happy to help. Actually it’s also not just BLE. I have them on wifi, but same issue 😉

Good to know, I'll expand my scope to the whole Shelly integration then.

Just to give some extra info, I have the same issue with my Shelly TRV (WIFI connected).
But also with my Shelly Button (Also WIFI connected).

https://www.shelly.com/products/shelly-button1-white

All other battery devices seem to work.

If you need any info let me know.

Hi again,

since weeks, all my battery devices are working fine; with the only exception of the one above:

At each restart it goes unavailable for logon time, more than 10 minutes, then magically it comes back online.

Can you review the code or at least add some more debugging ?
Thank you in advance,

Simone

P.S:> I have an automation that list all unavailable entities after 5 minutes of each reboot. This is the way I noticed ;-)

Can you delete the battery note for that device and add it again, I don't think it's tracking that battery properly. If the battery is showing 52% so should Battery+
Is there anything else in Diagnostics for that device?

Can you delete the battery note for that device and add it again, I don't think it's tracking that battery properly. If the battery is showing 52% so should Battery+ Is there anything else in Diagnostics for that device?

It does if:

• I delete and recreate the device in battery note

or

• If I wait a lot of time after restart

Or if I reload battery note for that specific device:

@nicx , @confucius78, @Woutch can you config that a reload of the device from Battery Note solves the issue for you as well ?

That's strange, it's like the integration is not broadcasting its initial setting of the value.
Do you have more than one Shelly Motion 2 (SHMOS-02) and are the others working ok?

That's strange, it's like the integration is not broadcasting its initial setting of the value.

Can we add a few debug lines to better understand what happens (and why) ?

Do you have more than one Shelly Motion 2 (SHMOS-02) and are the others working ok?

Nope, is the only one of this kind.

I'll have a look at the code and see what I can add but I don't think it does too much from memory. If it receives a numeric value from the listener it will set it.