Home Assistant version
2026.7.2
Glowrium integration version
0.1.1
Device model
G8 (device-info pkey is Glowrium-C064, version:2)
Bluetooth connection
ESPHome Bluetooth Proxy
What happened?
The device clock is only ever written inside async_activate(), which runs when 0x14 reads False, so in practice once at first pairing. Nothing re-syncs it afterwards.
Reading KEY_TIME (0x05) off one of my lamps today, 2026-07-25, gives:
07ea 02 01 0f 0e 2c -> 2026-02-01 15:14:44
Correct time of day, but the date is nearly six months stale. Both Schedule and Circadian modes run off that clock, so anything date-dependent in them is operating on the wrong date. A user cannot see this, since the clock is not surfaced as an entity, and cannot correct it short of a factory reset to force the activation path again.
Two related things in the same area:
DST_ON hardcodes a 3600 second offset (0100000e10), while switch.py only reads byte 0 when reporting state, so whatever offset the device reports is discarded on write. A region with a 30 minute DST offset would get an hour.
_encode_device_time() sends dt_util.now(), which is local wall clock and therefore already DST shifted. If the device then applies its own offset from 0x35, that is a double shift. I have not been able to confirm which convention the firmware expects, and nothing in the code or docs states it, so a user enabling the DST switch may or may not be doing the right thing.
Possible approaches, though this is a design call so I have not sent a PR for it:
- Re-send the clock on every connect. Simplest, self-healing after a power cut, at the cost of a write per connection.
- Re-sync on a schedule, daily or similar, alongside the existing reconnect timer.
- Add a "Sync time" button next to the existing "Sync location" button, which is explicit but leaves anyone who never presses it where they are now.
Resolving the DST convention first would be worth doing either way, since re-syncing the wrong convention more often is worse than rarely. Happy to implement whichever you prefer.
Relevant log output
(no error is logged - the clock is simply never rewritten after activation,
so there is nothing to capture. The value above was read from the device.)
Checklist
Home Assistant version
2026.7.2
Glowrium integration version
0.1.1
Device model
G8 (device-info
pkeyisGlowrium-C064,version:2)Bluetooth connection
ESPHome Bluetooth Proxy
What happened?
The device clock is only ever written inside
async_activate(), which runs when0x14readsFalse, so in practice once at first pairing. Nothing re-syncs it afterwards.Reading
KEY_TIME(0x05) off one of my lamps today, 2026-07-25, gives:Correct time of day, but the date is nearly six months stale. Both Schedule and Circadian modes run off that clock, so anything date-dependent in them is operating on the wrong date. A user cannot see this, since the clock is not surfaced as an entity, and cannot correct it short of a factory reset to force the activation path again.
Two related things in the same area:
DST_ONhardcodes a 3600 second offset (0100000e10), whileswitch.pyonly reads byte 0 when reporting state, so whatever offset the device reports is discarded on write. A region with a 30 minute DST offset would get an hour._encode_device_time()sendsdt_util.now(), which is local wall clock and therefore already DST shifted. If the device then applies its own offset from0x35, that is a double shift. I have not been able to confirm which convention the firmware expects, and nothing in the code or docs states it, so a user enabling the DST switch may or may not be doing the right thing.Possible approaches, though this is a design call so I have not sent a PR for it:
Resolving the DST convention first would be worth doing either way, since re-syncing the wrong convention more often is worse than rarely. Happy to implement whichever you prefer.
Relevant log output
(no error is logged - the clock is simply never rewritten after activation, so there is nothing to capture. The value above was read from the device.)Checklist