Using this causes the frame to no longer sleep

[AlexCPU]

I found your integration as https://github.com/kmplngj/eink_canvas_home_assistant_component/ is using the underlying information to try and improve the "official" integration, but I'm having some issues.

Test environment details:

• 13.3" frames, all running firmware 1.8.29
• No dedicated Bluetooth hardware in home assistant, only ESPHome proxies running 2025.12.2
• Sound on so you can tell what it's doing
• running a ping to the devices IP to see if it's alive

Testing:

1. Set up frame in Bloomin8 Desktop app, connected to VLAN segregated from internet and LAN (has access to NTP - haven't seen any other packets dropped by firewall)
2. Control with the desktop app works fine, if I keep the app running, it seems to stay awake
3. Close the desktop app and the device sleeps at the appropriate time, I can also force it to sleep with a POST to /sleep as per the API.

Once it's asleep, it (obviously) stops responding to ping, and if I wake it up with either the button, or the desktop app, a few seconds later it responds to ping.

4. Whilst it's awake I can also control it with the official HA integration, which works fine (obviously the lack of wake is a huge issue to it!)
5. Once the device goes to sleep, I press your wake button for the first time. The device wakes correctly, however something isn't right.

Once it's been woken up by your button, it will not go back to sleep via any means (i.e. time delay, quick press of button, POST to /sleep), also, it's not responding to every ping, it's missing a couple every about every 5-10 seconds. The official integration seems to see the media player connecting and disconnecting every few seconds. It feels like it's stuck in a reboot loop as it wasn't woken up correctly.

6. Using the Bloomin8 desktop app to send the wake command (even in this kind of awake state) fixes the frame and it will stop doing whatever it is doing, and then go back to sleep properly.
7. Pushing your button wakes the frame again, and puts it into this odd state again.

[AlexCPU]

I've sussed it! I'll write a PR tomorrow, but basically, if you look at a snoop from the app, you need to send two messages, not one! The first is x01 then you have to follow it up with x00. My guess is the BLE chip is really dumb and is just holding a wake line, and we're just setting a GPIO pin, so you need to toggle it to wake it up, not just set it to 1.

[rymaz]

Was experiencing same behavior on 1.0.4. Updated to your fork (1.0.5) and can confirm behavior is now working as expected -- device falls back asleep after max_idle is hit. Also can run POST /sleep and works as expected as well.