[GH-ISSUE #459] Chroma29 eat batteries in 2-3 days #2492

New Issue

@skiphansen commented on GitHub (Apr 26, 2025):

Did you have to restore the SN on the tags when programmed them ? If so did you put in the actual SN from the label?

The reason I ask is that the first digit after the letter indicates a hardware difference and if it's wrong (a 0 instead of a 1 or versa versa) that could be the problem.

I'll double check the current consumption when I get a chance. I have a couple of Chroma29s that have lasted several months, but that's with weather updates ever 3 hours.

Increasing the update interval from 10 minutes to 1 hour couldn't hurt.

@skiphansen commented on GitHub (Apr 26, 2025): Did you have to restore the SN on the tags when programmed them ? If so did you put in the actual SN from the label? The reason I ask is that the first digit after the letter indicates a hardware difference and if it's wrong (a 0 instead of a 1 or versa versa) that could be the problem. I'll double check the current consumption when I get a chance. I have a couple of Chroma29s that have lasted several months, but that's with weather updates ever 3 hours. Increasing the update interval from 10 minutes to 1 hour couldn't hurt.

sascha_hemi commented

@skiphansen commented on GitHub (Apr 26, 2025):

I just tested a JA1xxxxxxxB tag with FW 10 and it seems fine. If you have a good current meter you should measure about 1.2 microamps while it is idle between updates.

I'll test a JA0xxxxxxxB next.

The JA0xxxxxxxB version also looks ok, I measure about 1.7 microamps while it is idle between updates.

The JA1 version includes a FET that disconnects the power to the EPD while it isn't being accessed, the JA0 version does not have this FET which is why the idle current is higher.

@skiphansen commented on GitHub (Apr 26, 2025): I just tested a JA1xxxxxxxB tag with FW 10 and it seems fine. If you have a good current meter you should measure about 1.2 microamps while it is idle between updates. I'll test a JA0xxxxxxxB next. The JA0xxxxxxxB version also looks ok, I measure about 1.7 microamps while it is idle between updates. The JA1 version includes a FET that disconnects the power to the EPD while it isn't being accessed, the JA0 version does not have this FET which is why the idle current is higher.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Apr 26, 2025):

Thank you.

I looked all up and the serial numbers on the web interface and the EPD are identical for all (also for the ones with repaired SN). The only thing that is different is that the EPD end with a B in the SN and on web it shows an X instead.

For now I wait for the arrival of the new batteries because I found some dead batteries and some with undervoltage in my two 100pcs batches. I don't trust them.

Measurements JA1 (if I read them correctly):

about 5mA for startup
about 7mA while going to "wait for data"
up to 20mA while getting data from the AP
about 1 microamps while in standby.

Just for fun I put the voltmeter on the batteries while they are inside the EPD and the voltage fluctuates greatly while the EPD is starting, communicating and downloading (between 3.05V and 2.2V). So I really think my batteries are trash xD
This would also explain why tags often freeze. Probably the chip get stuck because of the voltage drops.

@DunklerPhoenix commented on GitHub (Apr 26, 2025): Thank you. I looked all up and the serial numbers on the web interface and the EPD are identical for all (also for the ones with repaired SN). The only thing that is different is that the EPD end with a B in the SN and on web it shows an X instead. For now I wait for the arrival of the new batteries because I found some dead batteries and some with undervoltage in my two 100pcs batches. I don't trust them. Measurements JA1 (if I read them correctly): - about 5mA for startup - about 7mA while going to "wait for data" - up to 20mA while getting data from the AP - about 1 microamps while in standby. ![Image](https://github.com/user-attachments/assets/5bb1c722-b5ff-4e61-9c6d-dbe093d277a5) ![Image](https://github.com/user-attachments/assets/68a991f9-90b1-43c1-be0f-bbbae732f3a4) Just for fun I put the voltmeter on the batteries while they are inside the EPD and the voltage fluctuates greatly while the EPD is starting, communicating and downloading (between 3.05V and 2.2V). So I really think my batteries are trash xD This would also explain why tags often freeze. Probably the chip get stuck because of the voltage drops.

sascha_hemi commented

@skiphansen commented on GitHub (Apr 26, 2025):

Let us know if your next batch of batteries fixes the issue or not.

I bought bunch of Tags (not Chroma29s) that had CR2450s which seemed to be ok so I've been using them in my Chroma29s (I'm cheap!). I haven't been keeping close track, but the tags have run for at least several months with the weather forecast content type updating every 3 hours.

Every Chroma29 that I've bought had VERY dead CR2450s ... like in absolutely ZERO volts.

The batteries in all of the Chroma74s I bought were at least usable. Of course they might be a lot NEWER.

@skiphansen commented on GitHub (Apr 26, 2025): Let us know if your next batch of batteries fixes the issue or not. I bought bunch of Tags (not Chroma29s) that had CR2450s which seemed to be ok so I've been using them in my Chroma29s (I'm cheap!). I haven't been keeping close track, but the tags have run for at least several months with the weather forecast content type updating every 3 hours. Every Chroma29 that I've bought had VERY dead CR2450s ... like in absolutely ZERO volts. The batteries in all of the Chroma74s I bought were at least usable. Of course they might be a lot NEWER.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 11, 2025):

sooo lil update

new batteries, nearly same problem.
after 1.5 weeks they are empty. what I saw was that the tags redraw pretty often even if nothing changed.

my accesspoint was some days (06.05.-10.05.) offline because I needed the usb port for my 3D printer.
Normaly in my understanding the tag should go in an absolut deep sleep without ap

I will change the battery again and let it run with active AP and will report back with better graphs from Home Assistant (battery voltage,check ins, etc etc)

@DunklerPhoenix commented on GitHub (May 11, 2025): sooo lil update new batteries, nearly same problem. after 1.5 weeks they are empty. what I saw was that the tags redraw pretty often even if nothing changed. my accesspoint was some days (06.05.-10.05.) offline because I needed the usb port for my 3D printer. Normaly in my understanding the tag should go in an absolut deep sleep without ap I will change the battery again and let it run with active AP and will report back with better graphs from Home Assistant (battery voltage,check ins, etc etc) ![Image](https://github.com/user-attachments/assets/309584b8-dac5-4da6-99f5-a8aec57dc751) ![Image](https://github.com/user-attachments/assets/9388650d-582d-432b-b38d-9a029f324d08)

sascha_hemi commented

@skiphansen commented on GitHub (May 12, 2025):

They should definitely NOT update the screen if there's no change.

What content is the tag showing? If it's an HA automation you might try something simple like the current weather generated by the AP and see if that makes a difference.

The serial port logging on the tag's serial port should tell us more.

If there's no AP the tag should eventually go into deep sleep mode, but it takes quite a while. I don't know off the top of my head, but it's days. That behavior is not well tested.

@skiphansen commented on GitHub (May 12, 2025): They should definitely NOT update the screen if there's no change. What content is the tag showing? If it's an HA automation you might try something simple like the current weather generated by the AP and see if that makes a difference. The serial port logging on the tag's serial port should tell us more. If there's no AP the tag should eventually go into deep sleep mode, but it takes quite a while. I don't know off the top of my head, but it's days. That behavior is not well tested.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 12, 2025):

it depends. this HA Tag os showing my Home Status my other tests (without HA) used the hours counter

I need to look further in the part with the serial logging. because I dont have much material here. will report back

Edit: The redraw refreshed the image, because the date and time in the lower right corner was old

Edit2: logging is active with current weather 1h. will report when battery is dead again

@DunklerPhoenix commented on GitHub (May 12, 2025): it depends. this HA Tag os showing my Home Status my other tests (without HA) used the hours counter I need to look further in the part with the serial logging. because I dont have much material here. will report back Edit: The redraw refreshed the image, because the date and time in the lower right corner was old Edit2: logging is active with current weather 1h. will report when battery is dead again

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 12, 2025):

Is it normal that it conacts the AP so often or does the 40s sleep mean something else?
(sry for the early stupid question. seeing the serial lpg is pretty interesting :3)

edit: found it i think https://github.com/OpenEPaperLink/OpenEPaperLink/wiki/Tag-protocol-timing

openepaperlink.log

Settings

@DunklerPhoenix commented on GitHub (May 12, 2025): Is it normal that it conacts the AP so often or does the 40s sleep mean something else? (sry for the early stupid question. seeing the serial lpg is pretty interesting :3) edit: found it i think https://github.com/OpenEPaperLink/OpenEPaperLink/wiki/Tag-protocol-timing [openepaperlink.log](https://github.com/user-attachments/files/20173726/openepaperlink.log) Settings ![Image](https://github.com/user-attachments/assets/5d736aa3-dd9c-498d-a9d0-a69b93b6c2a6)

sascha_hemi commented

@skiphansen commented on GitHub (May 12, 2025):

It IS if you are watching the WEB page from a browser and "Shorten latency during config" is set to yes.

I can attest that checking in every 40 seconds will kill a set of batteries in about a week.

However your screen shot shows that you have "Shorten latency during config" set to no so it shouldn't been doing that.

Try rebooting your AP and then check of the setting is still no.

The good news (I guess) is that it's not updating the screen every 40 seconds.

Skip

@skiphansen commented on GitHub (May 12, 2025): It **IS** if you are watching the WEB page from a browser and "Shorten latency during config" is set to yes. I can attest that checking in every 40 seconds will kill a set of batteries in about a week. However your screen shot shows that you have "Shorten latency during config" set to no so it shouldn't been doing that. Try rebooting your AP and then check of the setting is still no. The good news (I guess) is that it's not updating the screen every 40 seconds. Skip

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 13, 2025):

moved down to other post, because no markdown

@DunklerPhoenix commented on GitHub (May 13, 2025): *moved down to other post, because no markdown*

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 14, 2025):

(markdown of other post was broken)

I rebooted it and cleared my browser cache. It still shows no :)
I disabled it weeks ago because I use the Home Assistant Integration and you recommended it in your Wiki.
I let it run some time and report with new log back.
(Sent from Phone. See edit for serial log from now)

14.05. 22:36 CET+2 openepaperlink.log

13.05. 23:20 CET+2 AP reboot (stuck "offline")
14.05. 11:33 CET+2 Force reload because of incomplete draw ( yeah the tag is not the best)

14.05. 11:35 CET+2 You can see that it checks in far before expected (expected counts down from 10min)

@DunklerPhoenix commented on GitHub (May 14, 2025): (markdown of other post was broken) I rebooted it and cleared my browser cache. It still shows no :) I disabled it weeks ago because I use the Home Assistant Integration and you recommended it in your Wiki. I let it run some time and report with new log back. (Sent from Phone. See edit for serial log from now) 14.05. 22:36 CET+2 [openepaperlink.log](https://github.com/user-attachments/files/20214020/openepaperlink.log) 13.05. 23:20 CET+2 AP reboot (stuck "offline") 14.05. 11:33 CET+2 Force reload because of incomplete draw ( yeah the tag is not the best) ![Image](https://github.com/user-attachments/assets/0bcc3ab9-1615-4360-8c3b-728febf15da9) 14.05. 11:35 CET+2 You can see that it checks in far before expected (expected counts down from 10min) ![Image](https://github.com/user-attachments/assets/75303135-8326-4264-a0f3-550d6014c38c)

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 14, 2025):

I can attest that checking in every 40 seconds will kill a set of batteries in about a week.

It really looks like the sleep mechsnism has a problem. It uses often 40000ms but also 60000ms, 600000ms and 540000ms and this in quite random order 😵‍💫

(see updated link in last post)

@DunklerPhoenix commented on GitHub (May 14, 2025): > I can attest that checking in every 40 seconds will kill a set of batteries in about a week. It really looks like the sleep mechsnism has a problem. It uses often 40000ms but also 60000ms, 600000ms and 540000ms and this in quite random order 😵‍💫 (see updated link in last post)

sascha_hemi commented

chroma29_full_0013_459_debug.zip

@skiphansen commented on GitHub (May 14, 2025):

I've added some additional logging to help figure out what's happening. Please give this version a try.

BTW: Here's my test tag so far, the content is just the current date. I'm still waiting for the first sleep to expire.

chroma29 OEPL v0013-DEBUG, compiled May 14 2025 06:56:04
SN JA00013753
BattV Boot 3372, now 3368, Tx 0, update 0
Temp 21 C
RSSI 0, LQI 0
MAC 4467090000013753
Sleeping for 400 ms
Loaded settings:
  Scan After Timeout 0
  fixedChannel 0
  batLowVoltage 2600
  enableFastBoot 0
  Last ch 203
  min Check In Time 40
Normal boot
BattV Boot 3372, now 3368, Tx 0, update 0
Updating display
BattV Boot 3372, now 3368, Tx 0, update 3356
Update complete
Sleeping for 10000 ms
AP on 203
BattV Boot 3372, now 3364, Tx 3360, update 3356
Updating display
BattV Boot 3372, now 3368, Tx 3360, update 3356
Update complete
Saved settings:
  Scan After Timeout 0
  fixedChannel 0
  batLowVoltage 2600
  enableFastBoot 0
  Last ch 203
  min Check In Time 40
Sleeping for 5000 ms
BattV Boot 3372, now 3368, Tx 3360, update 3356
Temp 22 C
RSSI -53, LQI 196
No update
nextCheckInFromAP 47
getNextSleep: 40 40
Sleeping for 2820000 ms

@skiphansen commented on GitHub (May 14, 2025): I've added some additional logging to help figure out what's happening. Please give this version a try. [chroma29_full_0013_459_debug.zip](https://github.com/user-attachments/files/20208948/chroma29_full_0013_459_debug.zip) BTW: Here's my test tag so far, the content is just the current date. I'm still waiting for the first sleep to expire. ``` chroma29 OEPL v0013-DEBUG, compiled May 14 2025 06:56:04 SN JA00013753 BattV Boot 3372, now 3368, Tx 0, update 0 Temp 21 C RSSI 0, LQI 0 MAC 4467090000013753 Sleeping for 400 ms Loaded settings: Scan After Timeout 0 fixedChannel 0 batLowVoltage 2600 enableFastBoot 0 Last ch 203 min Check In Time 40 Normal boot BattV Boot 3372, now 3368, Tx 0, update 0 Updating display BattV Boot 3372, now 3368, Tx 0, update 3356 Update complete Sleeping for 10000 ms AP on 203 BattV Boot 3372, now 3364, Tx 3360, update 3356 Updating display BattV Boot 3372, now 3368, Tx 3360, update 3356 Update complete Saved settings: Scan After Timeout 0 fixedChannel 0 batLowVoltage 2600 enableFastBoot 0 Last ch 203 min Check In Time 40 Sleeping for 5000 ms BattV Boot 3372, now 3368, Tx 3360, update 3356 Temp 22 C RSSI -53, LQI 196 No update nextCheckInFromAP 47 getNextSleep: 40 40 Sleeping for 2820000 ms ```

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 15, 2025):

16.05. 22:39 CET+2 (no more update)

openepaperlink13.log

@DunklerPhoenix commented on GitHub (May 15, 2025): 16.05. 22:39 CET+2 (no more update) [openepaperlink13.log](https://github.com/user-attachments/files/20258981/openepaperlink13.log)

sascha_hemi commented

@skiphansen commented on GitHub (May 15, 2025):

Here's the problem:

[2025-05-14 23:37:47.304] nextCheckInFromAP 10
[2025-05-14 23:37:47.305] getNextSleep: 45 45
[2025-05-14 23:37:47.309] Sleeping for 600000 ms
[2025-05-14 23:47:47.394] No update
[2025-05-14 23:47:47.394] nextCheckInFromAP 0
[2025-05-14 23:47:47.397] getNextSleep: 45 45
[2025-05-14 23:47:47.398] getNextSleep: 45 45
[2025-05-14 23:47:47.403] Sleeping for 45000 ms
[2025-05-14 23:48:32.533] No update
[2025-05-14 23:48:32.534] nextCheckInFromAP 0
[2025-05-14 23:48:32.537] getNextSleep: 45 45
[2025-05-14 23:48:32.538] getNextSleep: 45 45
[2025-05-14 23:48:32.543] Sleeping for 45000 ms
[2025-05-14 23:49:17.654] No update

The AP told the tag to sleep for 10 minutes @ 23:37:47.304 which is correct based on your configuration.
The tag then sleep from 23:37:47.309 to 23:47:47.394 which is correct.
Then the AP didn't provide a sleep time with the next AvailDataInfo packet.

struct AvailDataInfo {
    uint8_t checksum;
    uint64_t dataVer;  // MD5 of potential traffic
    uint32_t dataSize;
    uint8_t dataType;
    uint8_t dataTypeArgument;  // extra specification or instruction for the tag (LUT to be used for drawing image)
    uint16_t nextCheckIn;      // when should the tag check-in again? Measured in minutes
} __packed;

This caused the tag to use its internal power savings algorithm to calculate the sleep time and the result was 45 seconds.
From 23:48:32.534 to 23:57:19.134 the tag polled the AP every 45 seconds or so and the AP kept relying with zero for nextCheckIn.

At 23:57:19.134 the AP started to tell the tag to sleep for 10 minutes again.

At 00:36:59.696 the first new screen update became available.

This appears to be a AP bug to me.

What was the content type for this tag during this test?

If it wasn't a simple AP generated image please rerun the test with the current weather content with updates set once an hour.

There were changes to the update scheduling code in the 2.81 release that I am not familiar with, perhaps @nlimper can give us his take when he's back home from his trip.

The applicable tag code fragment is here for review.

@skiphansen commented on GitHub (May 15, 2025): Here's the problem: ``` [2025-05-14 23:37:47.304] nextCheckInFromAP 10 [2025-05-14 23:37:47.305] getNextSleep: 45 45 [2025-05-14 23:37:47.309] Sleeping for 600000 ms [2025-05-14 23:47:47.394] No update [2025-05-14 23:47:47.394] nextCheckInFromAP 0 [2025-05-14 23:47:47.397] getNextSleep: 45 45 [2025-05-14 23:47:47.398] getNextSleep: 45 45 [2025-05-14 23:47:47.403] Sleeping for 45000 ms [2025-05-14 23:48:32.533] No update [2025-05-14 23:48:32.534] nextCheckInFromAP 0 [2025-05-14 23:48:32.537] getNextSleep: 45 45 [2025-05-14 23:48:32.538] getNextSleep: 45 45 [2025-05-14 23:48:32.543] Sleeping for 45000 ms [2025-05-14 23:49:17.654] No update ``` The AP told the tag to sleep for 10 minutes @ 23:37:47.304 which is correct based on your configuration. The tag then sleep from 23:37:47.309 to 23:47:47.394 which is correct. Then the AP didn't provide a sleep time with the next AvailDataInfo packet. ```c struct AvailDataInfo { uint8_t checksum; uint64_t dataVer; // MD5 of potential traffic uint32_t dataSize; uint8_t dataType; uint8_t dataTypeArgument; // extra specification or instruction for the tag (LUT to be used for drawing image) uint16_t nextCheckIn; // when should the tag check-in again? Measured in minutes } __packed; ``` This caused the tag to use its internal power savings algorithm to calculate the sleep time and the result was 45 seconds. From 23:48:32.534 to 23:57:19.134 the tag polled the AP every 45 seconds or so and the AP kept relying with zero for nextCheckIn. At 23:57:19.134 the AP started to tell the tag to sleep for 10 minutes again. At 00:36:59.696 the first new screen update became available. This appears to be a AP bug to me. What was the content type for this tag during this test? If it wasn't a simple AP generated image please rerun the test with the current weather content with updates set once an hour. There were changes to the update scheduling code in the 2.81 release that I am not familiar with, perhaps @nlimper can give us his take when he's back home from his trip. The applicable tag code fragment is [here]( https://github.com/skiphansen/Tag_FW_Chroma/blob/1a2e2d15c3e805e634af6add0324f04b54cb3afb/Chroma_Tag_FW/OEPL/main.c#L140-L164) for review.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 15, 2025):

Evil AP xD but an AP bug would be great. I dont want to reflash all tags :3

The tag is already set to current weather one hour for all the serial logs.

PS Is it possible to support your work with money?

@DunklerPhoenix commented on GitHub (May 15, 2025): Evil AP xD but an AP bug would be great. I dont want to reflash all tags :3 The tag is already set to current weather one hour for all the serial logs. PS Is it possible to support your work with money?

sascha_hemi commented

@nlimper commented on GitHub (May 15, 2025):

As seen from the AP-side, this is all by design.
The OEPL protocol defaults to checkins around 40 seconds, on which a tag is supposed to last for 5 years on a set of batteries. At least, for the Solum tags. On the Chroma tags, in theory it should be possible too, as the original protocol of the manufacturer will do something similar.

For extra savings on top of that, there is the TTL parameter, to tell the AP that you don't expect to send a new image for x seconds. The AP lets the tag sleep for that amount of time (or shorter, as stated by the 'max sleep' setting in the config). After the TTL expires (that is, after the 'next update' time, as shown in the web interface), a new image is expected to be generated in any moment, so from then on, the AP lets the tag sleep at a default 40 second time. It's not wise to let the tag sleep for a long timespan again, as it would make the system very unresponsive.

For the build in content, this is working smoothly. But if you use HA to send images, and want to use the least amount of checkins, it's important to use the TTL parameter when you send the image, calculated as the time that you're actually plan to send the next image.

@nlimper commented on GitHub (May 15, 2025): As seen from the AP-side, this is all by design. The OEPL protocol defaults to checkins around 40 seconds, on which a tag is supposed to last for 5 years on a set of batteries. At least, for the Solum tags. On the Chroma tags, in theory it should be possible too, as the original protocol of the manufacturer will do something similar. For extra savings on top of that, there is the TTL parameter, to tell the AP that you don't expect to send a new image for x seconds. The AP lets the tag sleep for that amount of time (or shorter, as stated by the 'max sleep' setting in the config). After the TTL expires (that is, after the 'next update' time, as shown in the web interface), a new image is expected to be generated in any moment, so from then on, the AP lets the tag sleep at a default 40 second time. It's not wise to let the tag sleep for a long timespan again, as it would make the system very unresponsive. For the build in content, this is working smoothly. But if you use HA to send images, and want to use the least amount of checkins, it's important to use the TTL parameter when you send the image, calculated as the time that you're actually plan to send the next image.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 15, 2025):

what O.o 5 years? I would be happy if they last 3 months

@DunklerPhoenix commented on GitHub (May 15, 2025): what O.o 5 years? I would be happy if they last 3 months

sascha_hemi commented

@skiphansen commented on GitHub (May 15, 2025):

least, for the Solum tags. On the Chroma tags, in theory it should be possible too, as the original protocol of the manufacturer will do something similar.

One very significant difference is that factory protocol for the Chroma tags is that the AP polls the tags for data. It basically transmits constantly and the tags wake up periodically to LISTEN so they do NOT transmit periodically. It takes significantly less current to receive than it does to transmit.

I don't want to engage you in a deep technical discussion while you're out enjoying nature! Are you back from your trip?

@skiphansen commented on GitHub (May 15, 2025): > least, for the Solum tags. On the Chroma tags, in theory it should be possible too, as the original protocol of the manufacturer will do something similar. One very significant difference is that factory protocol for the Chroma tags is that the AP polls the tags for data. It basically transmits constantly and the tags wake up periodically to **LISTEN** so they do **NOT** transmit periodically. It takes **significantly** less current to receive than it does to transmit. I don't want to engage you in a deep technical discussion while you're out enjoying nature! Are you back from your trip?

sascha_hemi commented

@skiphansen commented on GitHub (May 15, 2025):

PS Is it possible to support your work with money?

Thanks for asking!

This is just a retirement hobby for me, using the results of my efforts (and helping me make it better) is all the thanks I need.

@skiphansen commented on GitHub (May 15, 2025): > PS Is it possible to support your work with money? Thanks for asking! This is just a retirement hobby for me, using the results of my efforts (and helping me make it better) is all the thanks I need.

sascha_hemi commented

@nlimper commented on GitHub (May 15, 2025):

One very significant difference is that factory protocol for the Chroma tags is that the AP polls the tags for data. It basically transmits constantly and the tags wake up periodically to LISTEN so they do NOT transmit periodically. It takes significantly less current to receive than it does to transmit.

Aha! I didn't know that.
So, using the current OEPL protocol, the Chroma tags can never be made as energy efficient as the Solum tags. :-(
Probably the best thing to do, is to increase the default checkin time in the tag firmware, maybe to even something like 5 minutes (in that case, a simple addition to the AP will make sure it doesn't show the tag as timed out). They will be a lot less responsive, but at least the batteries will last. Or, do you have other ideas on saving power?

btw: yes, I'm back home! :-)

@nlimper commented on GitHub (May 15, 2025): > One very significant difference is that factory protocol for the Chroma tags is that the AP polls the tags for data. It basically transmits constantly and the tags wake up periodically to **LISTEN** so they do **NOT** transmit periodically. It takes **significantly** less current to receive than it does to transmit. Aha! I didn't know that. So, using the current OEPL protocol, the Chroma tags can never be made as energy efficient as the Solum tags. :-( Probably the best thing to do, is to increase the default checkin time in the tag firmware, maybe to even something like 5 minutes (in that case, a simple addition to the AP will make sure it doesn't show the tag as timed out). They will be a lot less responsive, but at least the batteries will last. Or, do you have other ideas on saving power? btw: yes, I'm back home! :-)

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 15, 2025):

Damn… wouldnt it be possible to mimic the behavior of the original firmware just for the information that a new update is available and let the rest like it is now? So that the initial registration works like now, but the ap just broadcasts for eg the serial number of a tag when an update is available and the tag is just listening for his own serial number and then starts to update like it would do with the OEPL protocol?

Sry I dont know much about such communcations. So I dont know how difficult it is to create such a hybrid and if it is even useful. The communication itself uses another base (subghz) than the other tags. So they shouldnt interfere with the other tags if they communicate a bit different

@DunklerPhoenix commented on GitHub (May 15, 2025): Damn… wouldnt it be possible to mimic the behavior of the original firmware just for the information that a new update is available and let the rest like it is now? So that the initial registration works like now, but the ap just broadcasts for eg the serial number of a tag when an update is available and the tag is just listening for his own serial number and then starts to update like it would do with the OEPL protocol? Sry I dont know much about such communcations. So I dont know how difficult it is to create such a hybrid and if it is even useful. The communication itself uses another base (subghz) than the other tags. So they shouldnt interfere with the other tags if they communicate a bit different

sascha_hemi commented

@nlimper commented on GitHub (May 15, 2025):

the ap just broadcasts for eg the serial number of a tag when an update is available and the tag is just listening for his own serial number and then starts to update like it would do with the OEPL protocol?

It's much more complicated than you think. You can not just have the tag listening continuously, as even just listening already takes a lot of energy. So you would need some synchronised listening, with all risks on mis-timings etc, because the tags don't have stable timings.

@nlimper commented on GitHub (May 15, 2025): > the ap just broadcasts for eg the serial number of a tag when an update is available and the tag is just listening for his own serial number and then starts to update like it would do with the OEPL protocol? It's *much* more complicated than you think. You can not just have the tag listening continuously, as even just listening already takes a lot of energy. So you would need some synchronised listening, with all risks on mis-timings etc, because the tags don't have stable timings.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 15, 2025):

Yeh that was what I meant with I dont know anything about.
I had in my head:
AP always repeatly transmit a package whitch has just the information with tags to update. Eg each tag gets in the beginning an internal id and the AP just sends something like [1,5,6,7] (tags with internal id 1,5,6,7 have an update).

Sometimes a tag awakes after a hardcoded time and listens shortly for this and if it hear his id it beginns to communicate normaly.

AP transmit every 5ms permanent, Tag wake up listens for 25ms (pseudotimes)
If no catch. Sleep and try again later.

That was just my limited simple thinking to this ^^‘
more ‚hit and miss‘ instead of clean synchronized communication

@DunklerPhoenix commented on GitHub (May 15, 2025): Yeh that was what I meant with I dont know anything about. I had in my head: AP always repeatly transmit a package whitch has just the information with tags to update. Eg each tag gets in the beginning an internal id and the AP just sends something like [1,5,6,7] (tags with internal id 1,5,6,7 have an update). Sometimes a tag awakes after a hardcoded time and listens shortly for this and if it hear his id it beginns to communicate normaly. AP transmit every 5ms permanent, Tag wake up listens for 25ms (pseudotimes) If no catch. Sleep and try again later. That was just my limited simple thinking to this ^^‘ more ‚hit and miss‘ instead of clean synchronized communication

sascha_hemi commented

@skiphansen commented on GitHub (May 16, 2025):

Aha! I didn't know that. So, using the current OEPL protocol, the Chroma tags can never be made as energy efficient as the Solum tags. :-( Probably the best thing to do, is to increase the default checkin time in the tag firmware, maybe to even something like 5 minutes (in that case, a simple addition to the AP will make sure it doesn't show the tag as timed out). They will be a lot less responsive, but at least the batteries will last. Or, do you have other ideas on saving power?

Just as a test I can certainly make a one off version for DunkerPhoenix prevents the tag from waking up every 40 seconds just to see if it fixes the problem for him. I'll do that first thing tomorrow.

My feeling is that normally the tags haven't been checking in every 40 seconds, that's certainly not what I've seen.

I updated to 2.81 when you released it and I've been running it since then with a couple of Chroma29s here and I haven't changed any batteries yet.

I'm personally saw > 3 months with Chroma42s and weather forecasts every 3 hours with 2.75.

3 months was just how long I ran them at our summer place before we hid out of the rest of the year. After 3 months the batteries still tested like new.

I did kill a set of batteries in a week with checkins every 40 seconds because I had left my PC parked on the AP page while testing with the Shorten latency configuration option enabled.

btw: yes, I'm back home! :-)

Welcome home!

@skiphansen commented on GitHub (May 16, 2025): > Aha! I didn't know that. So, using the current OEPL protocol, the Chroma tags can never be made as energy efficient as the Solum tags. :-( Probably the best thing to do, is to increase the default checkin time in the tag firmware, maybe to even something like 5 minutes (in that case, a simple addition to the AP will make sure it doesn't show the tag as timed out). They will be a lot less responsive, but at least the batteries will last. Or, do you have other ideas on saving power? Just as a test I can certainly make a one off version for DunkerPhoenix prevents the tag from waking up every 40 seconds just to see if it fixes the problem for him. I'll do that first thing tomorrow. My feeling is that normally the tags haven't been checking in every 40 seconds, that's certainly not what I've seen. I updated to 2.81 when you released it and I've been running it since then with a couple of Chroma29s here and I haven't changed any batteries yet. I'm personally saw > 3 months with Chroma42s and weather forecasts every 3 hours with 2.75. 3 months was just how long I ran them at our summer place before we hid out of the rest of the year. After 3 months the batteries still tested like new. I did kill a set of batteries in a week with checkins every 40 seconds because I had left my PC parked on the AP page while testing with the Shorten latency configuration option enabled. > btw: yes, I'm back home! :-) Welcome home!

sascha_hemi commented

@skiphansen commented on GitHub (May 16, 2025):

Here's a new version to try: chroma29_full_0013_459_debug1.zip

Changes:

When the AP replies with zero for nextCheckIn it will be replaced with 10 (minutes).

@skiphansen commented on GitHub (May 16, 2025): Here's a new version to try: [chroma29_full_0013_459_debug1.zip](https://github.com/user-attachments/files/20245173/chroma29_full_0013_459_debug1.zip) Changes: 1. When the AP replies with zero for nextCheckIn it will be replaced with 10 (minutes).

sascha_hemi commented

@skiphansen commented on GitHub (May 16, 2025):

@nlimper I still think that there's something odd happening on the AP side.

For example my test tag has been off since Wednesday and I just flashed it with the above firmware and started it up again.
The AP shows:

so Thursday and Friday were rendered at midnight as expected, but the AP is still relying
No update.

It seems to me that since two updates are available it should be downloading them.

I'll keep logging until it updates, here's the log so far:

sh_5_16_25.log

I'm going to study the scheduling code in the AP when I get time to get a better understanding.

@skiphansen commented on GitHub (May 16, 2025): @nlimper I still think that there's something odd happening on the AP side. For example my test tag has been off since Wednesday and I just flashed it with the above firmware and started it up again. The AP shows: ![Image](https://github.com/user-attachments/assets/e8f65ac9-c963-4720-845d-d1900dacf229) ![Image](https://github.com/user-attachments/assets/58ad3a22-0a0e-475b-8248-08e7a3ea051f) so Thursday and Friday were rendered at midnight as expected, but the AP is still relying No update. It seems to me that since two updates are available it should be downloading them. I'll keep logging until it updates, here's the log so far: [sh_5_16_25.log](https://github.com/user-attachments/files/20247438/sh_5_16_25.log) I'm going to study the scheduling code in the AP when I get time to get a better understanding.

sascha_hemi commented

@nlimper commented on GitHub (May 16, 2025):

That can happen if the S3 and C6 get out of sync: the S3 told the C6 that there is an update available, but the C6 has since then reset for some reason, so it doesn't tell the tag that there is an update. Right click the tag and delete the pending image, and then force update to generate a new image.

@nlimper commented on GitHub (May 16, 2025): That can happen if the S3 and C6 get out of sync: the S3 told the C6 that there is an update available, but the C6 has since then reset for some reason, so it doesn't tell the tag that there is an update. Right click the tag and delete the pending image, and then force update to generate a new image.

sascha_hemi commented

@skiphansen commented on GitHub (May 16, 2025):

Yes, that fixed it, the tag updated to the most recently generated image. Now to figure out why the C6 reset!

However the older images weren't deleted. Should we ever had more than one pending image for a particular tag?
I have nightly reboots disabled just to check stability, to we rely on the reboot to clean up old images?

@skiphansen commented on GitHub (May 16, 2025): Yes, that fixed it, the tag updated to the most recently generated image. Now to figure out why the C6 reset! However the older images weren't deleted. Should we ever had more than one pending image for a particular tag? I have nightly reboots disabled just to check stability, to we rely on the reboot to clean up old images?

sascha_hemi commented

@nlimper commented on GitHub (May 16, 2025):

Clean up takes place on the 'transfer complete' signal, and at restart. I guess 'delete pending image' option doesn't remove it from the flash.
I'm sure there are thousands of little improvements that can be made, but please for now lets focus on the original problem. :-)

@nlimper commented on GitHub (May 16, 2025): Clean up takes place on the 'transfer complete' signal, and at restart. I guess 'delete pending image' option doesn't remove it from the flash. I'm sure there are thousands of little improvements that can be made, but please for now lets focus on the original problem. :-)

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 16, 2025):

20.05. 22:35 CET+2 (updates ended)

openepaperlink13.1.log

It froze on first boot

[2025-05-16 22:53:42.646] Sleeping for 10000 ms
[2025-05-16 22:53:52.680] No saved channel
[2025-05-16 23:05:13.819]   <- manual reboot

It is good that the "nextCheckInFromAP 0" still is 40s on blk fail

[2025-05-16 23:07:16.486] blk failed validation!
[2025-05-16 23:07:16.487] nextCheckInFromAP 0
[2025-05-16 23:07:16.491] getNextSleep: 40 40
[2025-05-16 23:07:16.495] getNextSleep: 40 40
[2025-05-16 23:07:16.495] Sleeping for 40000 ms

@DunklerPhoenix commented on GitHub (May 16, 2025): 20.05. 22:35 CET+2 (updates ended) [openepaperlink13.1.log](https://github.com/user-attachments/files/20355082/openepaperlink13.1.log) It froze on first boot ``` [2025-05-16 22:53:42.646] Sleeping for 10000 ms [2025-05-16 22:53:52.680] No saved channel [2025-05-16 23:05:13.819] <- manual reboot ``` It is good that the "nextCheckInFromAP 0" still is 40s on blk fail ``` [2025-05-16 23:07:16.486] blk failed validation! [2025-05-16 23:07:16.487] nextCheckInFromAP 0 [2025-05-16 23:07:16.491] getNextSleep: 40 40 [2025-05-16 23:07:16.495] getNextSleep: 40 40 [2025-05-16 23:07:16.495] Sleeping for 40000 ms ```

sascha_hemi commented

@skiphansen commented on GitHub (May 17, 2025):

17.05. 00:49 CET+2 (gets updated now and then)

openepaperlink13.1.log

It froze on first boot

There's probably the known issue with the first sleep at power up. I was never able to find it. It's very difficult to repoduce.

[2025-05-16 22:53:42.646] Sleeping for 10000 ms
[2025-05-16 22:53:52.680] No saved channel
[2025-05-16 23:05:13.819]   <- manual reboot
It is good that the "nextCheckInFromAP 0" still is 40s on blk fail

Right, nextCheckInFromAP is only overridden when the AP replies "no update" with nextCheckInFromAP of zero,
in other cases the nextCheckInFromAP is used as is.

Fingers crossed...

@skiphansen commented on GitHub (May 17, 2025): > 17.05. 00:49 CET+2 (gets updated now and then) > > [openepaperlink13.1.log](https://github.com/user-attachments/files/20259819/openepaperlink13.1.log) > > It froze on first boot There's probably the [known issue](https://github.com/OpenEPaperLink/Tag_FW_Chroma/issues/2) with the first sleep at power up. I was never able to find it. It's very difficult to repoduce. > > ``` > [2025-05-16 22:53:42.646] Sleeping for 10000 ms > [2025-05-16 22:53:52.680] No saved channel > [2025-05-16 23:05:13.819] <- manual reboot > ``` > > It is good that the "nextCheckInFromAP 0" still is 40s on blk fail Right, nextCheckInFromAP is only overridden when the AP replies "no update" with nextCheckInFromAP of zero, in other cases the nextCheckInFromAP is used as is. Fingers crossed...

sascha_hemi commented

@skiphansen commented on GitHub (May 17, 2025):

I think the C6 reset issue IS the causing this issue.

I configured the content for my test tag as current weather with 30 minute updates and ran it all day. It appears that the C6 reset twice which caused an update to be lost which invoked my kludge which forced a 10 minute sleep.

9:27:02.452: Drawing image in slot 0
9:49:13.859: Drawing image in slot 1
10:19:26.840: Drawing image in slot 2
10:49:38.302: Drawing image in slot 3
11:19:51.322: Drawing image in slot 0
11:50:02.723: Drawing image in slot 1
12:19:15.694: Drawing image in slot 2
12:49:28.694: Drawing image in slot 3
13:19:41.666: Drawing image in slot 0
13:49:54.707: Drawing image in slot 1
14:19:03.119: Forced nextCheckInFromAP to 10 minutes
14:29:03.206: Forced nextCheckInFromAP to 10 minutes
14:39:03.284: Forced nextCheckInFromAP to 10 minutes
14:49:07.910: Drawing image in slot 2
15:12:20.896: Drawing image in slot 3
15:42:33.915: Drawing image in slot 0
16:12:46.868: Drawing image in slot 1
16:41:55.350: Forced nextCheckInFromAP to 10 minutes
16:51:55.438: Forced nextCheckInFromAP to 10 minutes
17:01:55.474: Forced nextCheckInFromAP to 10 minutes
17:12:00.118: Drawing image in slot 2
17:35:13.134: Drawing image in slot 3
18:05:26.155: Drawing image in slot 0
18:35:39.159: Drawing image in slot 1

So normally the tag sleeps until the next update is available, but without the kludge the tag polls the AP every 40 seconds until a new update is available when the AP replies w/o an update with a nextCheckin of 0.

I'll add AP logging to my test and see what I can find.

Here's the full log for the record: 5_16_25.log

@skiphansen commented on GitHub (May 17, 2025): I think the C6 reset issue **IS** the causing this issue. I configured the content for my test tag as current weather with 30 minute updates and ran it all day. It appears that the C6 reset twice which caused an update to be lost which invoked my kludge which forced a 10 minute sleep. ``` 9:27:02.452: Drawing image in slot 0 9:49:13.859: Drawing image in slot 1 10:19:26.840: Drawing image in slot 2 10:49:38.302: Drawing image in slot 3 11:19:51.322: Drawing image in slot 0 11:50:02.723: Drawing image in slot 1 12:19:15.694: Drawing image in slot 2 12:49:28.694: Drawing image in slot 3 13:19:41.666: Drawing image in slot 0 13:49:54.707: Drawing image in slot 1 14:19:03.119: Forced nextCheckInFromAP to 10 minutes 14:29:03.206: Forced nextCheckInFromAP to 10 minutes 14:39:03.284: Forced nextCheckInFromAP to 10 minutes 14:49:07.910: Drawing image in slot 2 15:12:20.896: Drawing image in slot 3 15:42:33.915: Drawing image in slot 0 16:12:46.868: Drawing image in slot 1 16:41:55.350: Forced nextCheckInFromAP to 10 minutes 16:51:55.438: Forced nextCheckInFromAP to 10 minutes 17:01:55.474: Forced nextCheckInFromAP to 10 minutes 17:12:00.118: Drawing image in slot 2 17:35:13.134: Drawing image in slot 3 18:05:26.155: Drawing image in slot 0 18:35:39.159: Drawing image in slot 1 ``` So normally the tag sleeps until the next update is available, but without the kludge the tag polls the AP every 40 seconds until a new update is available when the AP replies w/o an update with a nextCheckin of 0. I'll add AP logging to my test and see what I can find. Here's the full log for the record: [5_16_25.log](https://github.com/user-attachments/files/20265593/5_16_25.log)

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 19, 2025):

Could this also be the cause of display updates with the old content instead of the new?
Example my Home/Away tag:

Tag is on AWAY
I come home
HA recognize me
AP get Update auf HOME
Tag refreshes but still shows AWAY afterwards (with old timestamp in lower right corner)
AP thinks Tag shows HOME

@DunklerPhoenix commented on GitHub (May 19, 2025): Could this also be the cause of display updates with the old content instead of the new? Example my Home/Away tag: 1. Tag is on AWAY 2. I come home 3. HA recognize me 4. AP get Update auf HOME 5. Tag refreshes but still shows AWAY afterwards (with old timestamp in lower right corner) 6. AP thinks Tag shows HOME

sascha_hemi commented

@skiphansen commented on GitHub (May 19, 2025):

I don't know much about HA, but I won't think so. The preview on the AP normally updates after the tag updates the image and acknowledges the transfer.

@skiphansen commented on GitHub (May 19, 2025): I don't know much about HA, but I won't think so. The preview on the AP normally updates after the tag updates the image and acknowledges the transfer.

sascha_hemi commented

@skiphansen commented on GitHub (May 20, 2025):

@nlimper It doesn't look like the C6 is resetting.

The problem appears to be that occasionally updates are not generated, but expectedNextCheckin is advanced anyway.

I haven't been able to trace down the cause of this yet.

My latest logs are attached if you want to take a look.

The MAC of my test tag is 4467090000013753. The problem starts @ 7:15:14 after a successful update. Since the content type is current weather with 30 minute updates the next update should be around 7:45, but the update isn't generated.

The AP code is the current master as Sunday of plus debug logging. The code is committed here: https://github.com/skiphansen/OpenEPaperLink/tree/debug_issue_459

Ap log: 5_20_25_ap.log

Tag log: 5_20_25_tag.log

@skiphansen commented on GitHub (May 20, 2025): @nlimper It doesn't look like the C6 is resetting. The problem appears to be that occasionally updates are not generated, but expectedNextCheckin is advanced anyway. I haven't been able to trace down the cause of this yet. My latest logs are attached if you want to take a look. The MAC of my test tag is 4467090000013753. The problem starts @ 7:15:14 after a successful update. Since the content type is current weather with 30 minute updates the next update should be around 7:45, but the update isn't generated. The AP code is the current master as Sunday of plus debug logging. The code is committed here: https://github.com/skiphansen/OpenEPaperLink/tree/debug_issue_459 Ap log: [5_20_25_ap.log](https://github.com/user-attachments/files/20350836/5_20_25_ap.log) Tag log: [5_20_25_tag.log](https://github.com/user-attachments/files/20350837/5_20_25_tag.log)

sascha_hemi commented

@skiphansen commented on GitHub (May 21, 2025):

I've verified that the AP occasionally miscalculates expectedNextCheckin which causes the tag to poll the AP frequently rather than sleeping until an update is available.

I'll create a new ticket to track the AP issue.

The impact of this on battery life is directly related to the amount of time this unnecessary polling lasts.

This issue is not specific to the Chroma29 firmware, this issue should effect all tags in that some battery capacity is wasted.
If the wasted battery capacity is noticeable or not is an open question.

@DunklerPhoenix I'm still interested in knowing if the debug firmware resolves your problem w/o an AP change.

I'd suggest putting in a new set of batteries on one of your TAGs and then running an endurance test with your intended use case.

Do NOT leave a serial port or programmer connected during the test. These connections can effect the true battery drain.

@skiphansen commented on GitHub (May 21, 2025): I've verified that the AP occasionally miscalculates expectedNextCheckin which causes the tag to poll the AP frequently rather than sleeping until an update is available. I'll create a new ticket to track the AP issue. The impact of this on battery life is directly related to the amount of time this unnecessary polling lasts. This issue is not specific to the Chroma29 firmware, this issue should effect all tags in that some battery capacity is wasted. If the wasted battery capacity is noticeable or not is an open question. @DunklerPhoenix I'm still interested in knowing if the debug firmware resolves your problem w/o an AP change. I'd suggest putting in a new set of batteries on one of your TAGs and then running an endurance test with your intended use case. Do **NOT** leave a serial port or programmer connected during the test. These connections can effect the true battery drain.

sascha_hemi commented

@nlimper commented on GitHub (May 22, 2025):

The problem appears to be that occasionally updates are not generated, but expectedNextCheckin is advanced anyway.

The MAC of my test tag is 4467090000013753. The problem starts @ 7:15:14 after a successful update. Since the content type is current weather with 30 minute updates the next update should be around 7:45, but the update isn't generated.

At 7:13 everything runs according to plan: a new image is generated, the tag picks up the new image, and the nextupdate is set to 07:43:57 and the tag is set to sleep for 28 minutes.

But then, At 7:43, a new image should be generated, but for some reason expectedNextCheckin was set to 8:11, which is too far ahead in the feature so the generating of the image is delayed until 5 minutes before 8:11 (to prevent an image to be generated with data that is outdated when it finally gets displayed).

I don't know yet why/how expectedNextCheckin is set to 8:11. I will investigate.

@nlimper commented on GitHub (May 22, 2025): > The problem appears to be that occasionally updates are not generated, but expectedNextCheckin is advanced anyway. > The MAC of my test tag is 4467090000013753. The problem starts @ 7:15:14 after a successful update. Since the content type is current weather with 30 minute updates the next update should be around 7:45, but the update isn't generated. At 7:13 everything runs according to plan: a new image is generated, the tag picks up the new image, and the nextupdate is set to 07:43:57 and the tag is set to sleep for 28 minutes. But then, At 7:43, a new image should be generated, but for some reason expectedNextCheckin was set to 8:11, which is too far ahead in the feature so the generating of the image is delayed until 5 minutes before 8:11 (to prevent an image to be generated with data that is outdated when it finally gets displayed). I don't know yet why/how expectedNextCheckin is set to 8:11. I will investigate.

sascha_hemi commented

@skiphansen commented on GitHub (May 22, 2025):

Thanks Nic. I have found the cause of the issue, but not a cure. I'll create a new ticket with the details tomorrow.

@skiphansen commented on GitHub (May 22, 2025): Thanks Nic. I have found the cause of the issue, but not a cure. I'll create a new ticket with the details tomorrow.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 22, 2025):

@DunklerPhoenix I'm still interested in knowing if the debug firmware resolves your problem w/o an AP change.

I'd suggest putting in a new set of batteries on one of your TAGs and then running an endurance test with your intended use case.

Do NOT leave a serial port or programmer connected during the test. These connections can effect the true battery drain.

Sooo the test is set up.

Tags:
1x - the original tag that is already running some time with disconnected serial
3x - Home Assistant provided updates (home/away) *
3x - hourly count up provided by AP *

All with debug firmware v0013-1
All without serial connection
* with fresh batteries of the same lot

@DunklerPhoenix commented on GitHub (May 22, 2025): > [@DunklerPhoenix](https://github.com/DunklerPhoenix) I'm still interested in knowing if the debug firmware resolves your problem w/o an AP change. > > I'd suggest putting in a new set of batteries on one of your TAGs and then running an endurance test with your intended use case. > > Do **NOT** leave a serial port or programmer connected during the test. These connections can effect the true battery drain. Sooo the test is set up. Tags: 1x - the original tag that is already running some time with disconnected serial 3x - Home Assistant provided updates (home/away) * 3x - hourly count up provided by AP * All with debug firmware v0013-1 All without serial connection \* with fresh batteries of the same lot

sascha_hemi commented

chroma29_ota_0013_459_debug1.zip

@skiphansen commented on GitHub (May 22, 2025):

Wow, I didn't expect you to flash 7 tags with the debug firmware! I hope you have a jig at least.

Here's an OTA version in case you decide to add more tags to your test. Sorry I didn't provide it initially!

Believe me when I tell you I know that a PIA opening and updating tags is!

@skiphansen commented on GitHub (May 22, 2025): Wow, I didn't expect you to flash 7 tags with the debug firmware! I hope you have a jig at least. Here's an OTA version in case you decide to add more tags to your test. Sorry I didn't provide it initially! Believe me when I tell you I know that a PIA opening and updating tags is! [chroma29_ota_0013_459_debug1.zip](https://github.com/user-attachments/files/20394206/chroma29_ota_0013_459_debug1.zip)

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 22, 2025):

nope
by hand like all others xD
thank you for the ota. i'll use it for the other 10 that are active atm

Edit 24.05.:
1.
Tag with debug firmware (running since 14.may) is now in a reboot loop (2400mv)
I hope it is because of the debugger. otherwise maybe the most of my tags are really dead. The only opion I have then are the ble tag from aliexpress xD
2.
One of the 3 Tags counting hours freezed 8 h ago
He contacts to the AP, but does not update the image

funny detail: it is not the tag that froze here. the ap does not generate a new image for that tag O.o

@DunklerPhoenix commented on GitHub (May 22, 2025): nope by hand like all others xD thank you for the ota. i'll use it for the other 10 that are active atm Edit 24.05.: 1. Tag with debug firmware (running since 14.may) is now in a reboot loop (2400mv) I hope it is because of the debugger. otherwise maybe the most of my tags are really dead. The only opion I have then are the ble tag from aliexpress xD 2. One of the 3 Tags counting hours freezed 8 h ago He contacts to the AP, but does not update the image ![Image](https://github.com/user-attachments/assets/7d401667-e61d-4699-808a-69e4a300ea01) ![Image](https://github.com/user-attachments/assets/7be74337-9a5d-4abe-83a7-2dae160ab2dc) funny detail: it is not the tag that froze here. the ap does not generate a new image for that tag O.o ![Image](https://github.com/user-attachments/assets/5d57d9af-8ac8-4727-a2ae-0067d2a725c7)

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 30, 2025):

The tags that count hours are mostly dead now. Last image: 200h

1x - the original tag that is already running some time with disconnected serial - dead
3x - Home Assistant provided updates (home/away) * - all alive
3x - hourly count up provided by AP * - 2 of 3 dead

the tags with the 600+ hours are the old firmware.
so maybe the most tags are really just trash :/

@DunklerPhoenix commented on GitHub (May 30, 2025): The tags that count hours are mostly dead now. Last image: 200h 1x - the original tag that is already running some time with disconnected serial - dead 3x - Home Assistant provided updates (home/away) * - all alive 3x - hourly count up provided by AP * - 2 of 3 dead the tags with the 600+ hours are the old firmware. so maybe the most tags are really just trash :/ ![Image](https://github.com/user-attachments/assets/2a3f7402-0b35-4852-b5c3-445d9403a33a) ![Image](https://github.com/user-attachments/assets/c5823f76-c7fa-4364-98ca-87308ad473a9)

sascha_hemi commented

@skiphansen commented on GitHub (May 30, 2025):

Thanks for all of the effort you've put into this and the feedback!!!

I'll do some measurements and do some calculations and see how may hours it should last in theory.

The manufacture's spec for battery life of the Chroma29 is 5 years with 3 updates per day.
Assuming updates use most of the battery that would still be 7 1/2 months with hourly updates.

Of course the factory protocol didn't require the tag to transmit as often as the OEPL protocol so there's that.

BTW it's better not to edit comments days later ... edits don't send notifications to people watching this issue, but new comments do.

@skiphansen commented on GitHub (May 30, 2025): Thanks for all of the effort you've put into this and the feedback!!! I'll do some measurements and do some calculations and see how may hours it should last in theory. The manufacture's spec for battery life of the Chroma29 is 5 years with 3 updates per day. Assuming updates use most of the battery that would still be 7 1/2 months with hourly updates. Of course the factory protocol didn't require the tag to transmit as often as the OEPL protocol so there's that. BTW it's better not to edit comments days later ... edits don't send notifications to people watching this issue, but new comments do.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (May 30, 2025):

thank you
I know. The edits were made on purpose to prevent that many emails.

If you want I can send you as much of my tags as you like via post, if you need them.

@DunklerPhoenix commented on GitHub (May 30, 2025): thank you I know. The edits were made on purpose to prevent that many emails. If you want I can send you as much of my tags as you like via post, if you need them.

sascha_hemi commented

@skiphansen commented on GitHub (May 30, 2025):

Thanks for the offer, but I'm good. I bought the same quantity from the same guy and have lots that I've never programmed.
I'm am interest in any other SubGhz tags that I don't have if you (or any lurkers) happen by any.

@skiphansen commented on GitHub (May 30, 2025): Thanks for the offer, but I'm good. I bought the same quantity from the same guy and have lots that I've never programmed. I'm am interest in any other SubGhz tags that I don't have if you (or any lurkers) happen by any.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jun 22, 2025):

Update: I let all tags (75+) running updates of the current hour. Only 4 Tags are still running and are over 1200h+. The batteries are still pretty full and they don't use the debug software with the minimum time.

SOOOOO all other Tags of that lot are broken and only this 4 are usable. Maybe I didn't have any luck with it or I can't recommend buying them from that ebay seller.

Edit: The 4 working one are JA100XXXXXB Tags and not the old version

@DunklerPhoenix commented on GitHub (Jun 22, 2025): Update: I let all tags (75+) running updates of the current hour. Only 4 Tags are still running and are over 1200h+. The batteries are still pretty full and they don't use the debug software with the minimum time. SOOOOO all other Tags of that lot are broken and only this 4 are usable. Maybe I didn't have any luck with it or I can't recommend buying them from that ebay seller. Edit: The 4 working one are JA100XXXXXB Tags and not the old version

sascha_hemi commented

@skiphansen commented on GitHub (Jun 30, 2025):

Update: I let all tags (75+) running updates of the current hour. Only 4 Tags are still running and are over 1200h+. The batteries are still pretty full and they don't use the debug software with the minimum time.

SOOOOO all other Tags of that lot are broken and only this 4 are usable. Maybe I didn't have any luck with it or I can't recommend buying them from that ebay seller.

Edit: The 4 working one are JA100XXXXXB Tags and not the old version

Are there any JA100XXXXXB tags in the "broken" batch?

I find it hard to believe the tags are actually "broken", there's just not much to go wrong which would only effect battery life.

A more likely answer Is that the firmware isn't going into the low power sleep mode quite correctly and minor differences between boards are begin magnified.

If you haven't tossed them you I'd like a couple examples of the tags that preformed the poorest in your testing.

Please DM me for my address.

@skiphansen commented on GitHub (Jun 30, 2025): > Update: I let all tags (75+) running updates of the current hour. Only 4 Tags are still running and are over 1200h+. The batteries are still pretty full and they don't use the debug software with the minimum time. > > SOOOOO all other Tags of that lot are broken and only this 4 are usable. Maybe I didn't have any luck with it or I can't recommend buying them from that ebay seller. > > Edit: The 4 working one are JA100XXXXXB Tags and not the old version Are there any JA100XXXXXB tags in the "broken" batch? I find it hard to believe the tags are actually "broken", there's just not much to go wrong which would only effect battery life. A more likely answer Is that the firmware isn't going into the low power sleep mode quite correctly and minor differences between boards are begin magnified. If you haven't tossed them you I'd like a couple examples of the tags that preformed the poorest in your testing. Please DM me for my address.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 2, 2025):

I have 4 addional JA1. They hold between 200 to 900h before they are dead.
The JA0 tags only come to max 250h before they die.

I don't throw them away. Even if they don't work on battery I can still use them on another power source.

EDIT: found a dm possibility... author email via git clone for the win.

@DunklerPhoenix commented on GitHub (Jul 2, 2025): I have 4 addional JA1. They hold between 200 to 900h before they are dead. The JA0 tags only come to max 250h before they die. I don't throw them away. Even if they don't work on battery I can still use them on another power source. EDIT: found a dm possibility... author email via git clone for the win.

sascha_hemi commented

@skiphansen commented on GitHub (Jul 16, 2025):

There's a problem alright! Your JA003xxxxxB tag measures 2.93 milliamps in sleep mode.

My development Chroma29 S/N JA000xxxxxB measures 1.5 microamps in sleep mode.

None of my Chroma29s that I bought ordinally got from the same vendor included any
JA003xxxxxB tags, they were all either JA000xxxxxB or JA100xxxxxB.

So my current guess is that there are hardware difference between JA000xxxxxB
and JA003xxxxxB that I'm not accounting for in the code.

Unfortunately I see that there are also JA001xxxxxB and JA004xxxxxB Chroma29s exist.

Isn't reverse engineering fun?!?

I'll take some tags apart and see if I can figure out the differences.

Thanks again for helping the project! From the packing material you use
I can tell you spend some money on batteries!

@skiphansen commented on GitHub (Jul 16, 2025): There's a problem alright! Your JA003xxxxxB tag measures 2.93 milliamps in sleep mode. My development Chroma29 S/N JA000xxxxxB measures 1.5 microamps in sleep mode. None of my Chroma29s that I bought ordinally got from the same vendor included any JA003xxxxxB tags, they were all either JA000xxxxxB or JA100xxxxxB. So my current guess is that there are hardware difference between JA000xxxxxB and JA003xxxxxB that I'm not accounting for in the code. Unfortunately I see that there are also JA001xxxxxB and JA004xxxxxB Chroma29s exist. Isn't reverse engineering fun?!? I'll take some tags apart and see if I can figure out the differences. Thanks again for helping the project! From the packing material you use I can tell you spend some money on batteries!

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 16, 2025):

thank you for the hard work!
Yes I still have a package with 300 batteries left :D
I already used about 200-300 hahaha

@DunklerPhoenix commented on GitHub (Jul 16, 2025): thank you for the hard work! Yes I still have a package with 300 batteries left :D I already used about 200-300 hahaha

sascha_hemi commented

@skiphansen commented on GitHub (Jul 16, 2025):

It looks like an easy fix!

The pcb on JA003xxxxxB boards matches the one used on JA1xxxxxxxB board so I just need to modify the code that parses the SN to determine which of the two power saving configurations to use.

I should have a new image for you to test in the next couple of days.

@skiphansen commented on GitHub (Jul 16, 2025): It looks like an easy fix! The pcb on JA003xxxxxB boards matches the one used on JA1xxxxxxxB board so I just need to modify the code that parses the SN to determine which of the two power saving configurations to use. I should have a new image for you to test in the next couple of days.

sascha_hemi commented

@skiphansen commented on GitHub (Jul 17, 2025):

Give this one a try.

On the tag that showed 20 hours the sleep current dropped from 2.93 milliamps to 1.12 microamps.

chroma29_ota_0015.zip

BTW the sleep current on the JA1xxxxxxxB tag you sent me that showed 371 hours looked fine with v0010.
Did it die or did you send it to me as a example of one of your "good" tags.

@skiphansen commented on GitHub (Jul 17, 2025): Give this one a try. On the tag that showed 20 hours the sleep current dropped from 2.93 milliamps to 1.12 microamps. [chroma29_ota_0015.zip](https://github.com/user-attachments/files/21301554/chroma29_ota_0015.zip) BTW the sleep current on the JA1xxxxxxxB tag you sent me that showed 371 hours looked fine with v0010. Did it die or did you send it to me as a example of one of your "good" tags.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 17, 2025):

okay will try.
the JA1 was one that died early, but that was because of a bad battery batch.
I sent it so you have a sample of different tags out of my batch

@DunklerPhoenix commented on GitHub (Jul 17, 2025): okay will try. the JA1 was one that died early, but that was because of a bad battery batch. I sent it so you have a sample of different tags out of my batch

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 18, 2025):

JA0008XXXXX 3,144V
JA0016XXXXX 3,184V
JA0020XXXXX 3,180V
JA0036XXXXX 3,120V
JA1001XXXXX 3,208V
JA1002XXXXX 3,204V

All with FW21 0x15 on channel 104.
Now counting hours with max sleep 300. (I need 300s for the other tags that are in production use at the moment)

@DunklerPhoenix commented on GitHub (Jul 18, 2025): JA0008XXXXX 3,144V JA0016XXXXX 3,184V JA0020XXXXX 3,180V JA0036XXXXX 3,120V JA1001XXXXX 3,208V JA1002XXXXX 3,204V All with FW21 0x15 on channel 104. Now counting hours with max sleep 300. (I need 300s for the other tags that are in production use at the moment)

sascha_hemi commented

@skiphansen commented on GitHub (Jul 19, 2025):

I've updated several more tags and all are looking good.

I've updated the master repo with v0015 so you can use the auto update option to update tags in the future.

I've recent installed Home Assistant and hope to get the OEPL integration running today. Once it's up I'll start an endurance
test on the old 20 hour tag and see how it does. I'm really looking forward to having some long term battery voltage charts.

BTW: make sure to shorten latency during config to prevent the tags from waking up every 40 seconds.

Fingers crossed...

@skiphansen commented on GitHub (Jul 19, 2025): I've updated several more tags and all are looking good. I've updated the master repo with v0015 so you can use the auto update option to update tags in the future. I've recent installed Home Assistant and hope to get the OEPL integration running today. Once it's up I'll start an endurance test on the old 20 hour tag and see how it does. I'm really looking forward to having some long term battery voltage charts. BTW: make sure to [shorten latency during config](https://github.com/OpenEPaperLink/Home_Assistant_Integration?tab=readme-ov-file#-battery-optimization) to prevent the tags from waking up every 40 seconds. Fingers crossed...

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 19, 2025):

the option is always on no :)
the only tag that is a bit strange is the
JA0008XXXXX 3,144V -> 2,902V

The voltage drop is a bit much, but I still let it run for the moment
The others are still over 3,1V

@DunklerPhoenix commented on GitHub (Jul 19, 2025): the option is always on no :) the only tag that is a bit strange is the JA0008XXXXX 3,144V -> 2,902V The voltage drop is a bit much, but I still let it run for the moment The others are still over 3,1V

sascha_hemi commented

@skiphansen commented on GitHub (Jul 19, 2025):

One of my tags that's been running for months on used batteries is currently @ 2.304 but seems to be running 100% reliably.

My HA automation is up and running ... impressive!

@skiphansen commented on GitHub (Jul 19, 2025): One of my tags that's been running for months on used batteries is currently @ 2.304 but seems to be running 100% reliably. My HA automation is up and running ... impressive!

sascha_hemi commented

@skiphansen commented on GitHub (Jul 20, 2025):

Looking good!

@skiphansen commented on GitHub (Jul 20, 2025): Looking good! <img width="238" height="217" alt="Image" src="https://github.com/user-attachments/assets/416309c0-88ca-4ea1-9d76-fa13e27c6d67" /> <img width="1146" height="397" alt="Image" src="https://github.com/user-attachments/assets/a60de7f0-2d98-4e05-ba8a-5f90dac816bc" />

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 20, 2025):

totally forgot I can look at the graph from HA xD

Here is the curve from the "strange" JA0008 Tag

The graphs of the other tags look completly different
here as an example the JA0020

@DunklerPhoenix commented on GitHub (Jul 20, 2025): totally forgot I can look at the graph from HA xD Here is the curve from the "strange" JA0008 Tag <img width="1440" height="3040" alt="Image" src="https://github.com/user-attachments/assets/5682989e-d969-486e-b1d3-199854abe128" /> The graphs of the other tags look completly different here as an example the JA0020 <img width="1440" height="3040" alt="Image" src="https://github.com/user-attachments/assets/022abaa4-bb7e-483a-95da-6e9455c315cd" />

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 20, 2025):

nevermind... if i throw them side by side they look quite similar
maybe the battery had a problem at start or it measures the voltage wrong

@DunklerPhoenix commented on GitHub (Jul 20, 2025): nevermind... if i throw them side by side they look quite similar maybe the battery had a problem at start or it measures the voltage wrong <img width="1440" height="3040" alt="Image" src="https://github.com/user-attachments/assets/84d1f7c3-42a3-47b8-b7f7-75b0a506fc12" />

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 29, 2025):

JA0008XXXXX 3,144V -> dead in 260h
Restart with new batteries -> 3,12V

(view is till dead. no new battery yet)

@DunklerPhoenix commented on GitHub (Jul 29, 2025): JA0008XXXXX 3,144V -> dead in 260h Restart with new batteries -> 3,12V (view is till dead. no new battery yet) <img width="3099" height="943" alt="Image" src="https://github.com/user-attachments/assets/56c6b264-9507-48e2-bda8-730480cf5810" />

sascha_hemi commented

@skiphansen commented on GitHub (Jul 29, 2025):

The big drop on 21 Juli looks suspicious, any idea what caused that?

My test using your old 20 hour tag is still looking good. I started the test with a fresh set of year old tenergy CR2450 batteries.

@skiphansen commented on GitHub (Jul 29, 2025): The big drop on 21 Juli looks suspicious, any idea what caused that? My test using your old 20 hour tag is still looking good. I started the test with a fresh set of year old tenergy CR2450 batteries. <img width="261" height="257" alt="Image" src="https://github.com/user-attachments/assets/1c472772-1518-4898-9f58-2f5d92cb0be7" /> <img width="1468" height="396" alt="Image" src="https://github.com/user-attachments/assets/006b7930-7d0d-4cfc-888c-bcfb792d1ec3" />

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 29, 2025):

nice to hear.
nope I dont know whats happened there. I didn't touch the tag in that time, but we will see in the second round if I can repeat it :3

@DunklerPhoenix commented on GitHub (Jul 29, 2025): nice to hear. nope I dont know whats happened there. I didn't touch the tag in that time, but we will see in the second round if I can repeat it :3

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jul 30, 2025):

Off-Topic Update

JA0036XXXXX 3,120V This one froze 50 hours ago.
It's still communicating with OEL, but OEL doesn't seem to update it anymore.

Somehow (idk why) it switched from hour counting to remote content.
It was integrated into HA some weeks ago. So maybe the HA integration did something strange.

@DunklerPhoenix commented on GitHub (Jul 30, 2025): Off-Topic Update JA0036XXXXX 3,120V This one froze 50 hours ago. It's still communicating with OEL, but OEL doesn't seem to update it anymore. --- Somehow (idk why) it switched from hour counting to remote content. It was integrated into HA some weeks ago. So maybe the HA integration did something strange. <img width="2341" height="563" alt="Image" src="https://github.com/user-attachments/assets/8adc6dd2-a71b-46d6-b9f1-36f8ac2dba69" />

sascha_hemi commented

@skiphansen commented on GitHub (Jul 30, 2025):

Off-Topic Update

JA0036XXXXX 3,120V This one froze 50 hours ago. It's still communicating with OEL, but OEL doesn't seem to update it anymore.

Somehow (idk why) it switched from hour counting to remote content. It was integrated into HA some weeks ago. So maybe the HA integration did something strange.

Sorry I have no idea, but I'm 99.9% sure it's not related to the tag's firmware.

@skiphansen commented on GitHub (Jul 30, 2025): > Off-Topic Update > > JA0036XXXXX 3,120V This one froze 50 hours ago. It's still communicating with OEL, but OEL doesn't seem to update it anymore. > > Somehow (idk why) it switched from hour counting to remote content. It was integrated into HA some weeks ago. So maybe the HA integration did something strange. > > <img alt="Image" width="2000" height="563" src="https://private-user-images.githubusercontent.com/1261305/472540220-8adc6dd2-a71b-46d6-b9f1-36f8ac2dba69.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTM5MDg3MTIsIm5iZiI6MTc1MzkwODQxMiwicGF0aCI6Ii8xMjYxMzA1LzQ3MjU0MDIyMC04YWRjNmRkMi1hNzFiLTQ2ZDYtYjlmMS0zNmY4YWMyZGJhNjkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDczMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA3MzBUMjA0NjUyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MzJjZmYyMmRlYTJlZjI4ZTdkMTY5ZDc0ZDgyNzUwMzEzZmIyZTc2MzlmMTYzZDkyZmYxNTU5MjgwMzIxYjlmZCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.3xO08__ForFS18IowTwBy0rthcv5YJ0ziuwIp93bmTE"> Sorry I have no idea, but I'm 99.9% sure it's not related to the tag's firmware.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Aug 9, 2025):

JA0008XXXXX (restarted 2 weeks ago 3,12V) -> 2,32V
Still working, but reporting low battery
Hours count 267
(other testtags 530h+ and still over 3,0V+)

It seems that this one still has a problem. If its empty I will open it and post images of the board here.
There is again a strange voltage drop in the chart like on the first cycle (https://github.com/OpenEPaperLink/OpenEPaperLink/issues/459#issuecomment-3131764426). (nobody touched it)

The Check-Ins are in the same interval as the other tags. So I think its again a different sleep mode.

@DunklerPhoenix commented on GitHub (Aug 9, 2025): JA0008XXXXX (restarted 2 weeks ago 3,12V) -> 2,32V Still working, but reporting low battery Hours count 267 (other testtags 530h+ and still over 3,0V+) It seems that this one still has a problem. If its empty I will open it and post images of the board here. There is again a strange voltage drop in the chart like on the first cycle (https://github.com/OpenEPaperLink/OpenEPaperLink/issues/459#issuecomment-3131764426). (nobody touched it) The Check-Ins are in the same interval as the other tags. So I think its again a different sleep mode. <img width="3105" height="1073" alt="Image" src="https://github.com/user-attachments/assets/54d7d5dd-baa2-4e7b-9a14-ea490d47ad82" />

sascha_hemi commented

@skiphansen commented on GitHub (Aug 9, 2025):

My test just hit 500 updates and 3.076v.

I can believe one tag with an actual problem, but not most of them.

It will be interesting to see what you find. Does the display itself look ok?

I doubt it's a sleep issue this time or it would just be a much sharper and faster drop.

My guess is that the processor looped w/o sleeping for some reason a few times.

The smaller dips after the big drop are interesting as well.

@skiphansen commented on GitHub (Aug 9, 2025): My test just hit 500 updates and 3.076v. <img width="275" height="245" alt="Image" src="https://github.com/user-attachments/assets/43fe0dd2-680d-496e-b53d-a29a18f21b39" /> I can believe one tag with an actual problem, but not most of them. It will be interesting to see what you find. Does the display itself look ok? I doubt it's a sleep issue this time or it would just be a much sharper and faster drop. My guess is that the processor looped w/o sleeping for some reason a few times. The smaller dips after the big drop are interesting as well.

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Aug 9, 2025):

you are right. this little spikes are also on the old graph.
you can see fine white lines on the display.

(batteries outside the tag both 2.79v without load)

edit: after putting bats back

@DunklerPhoenix commented on GitHub (Aug 9, 2025): you are right. this little spikes are also on the old graph. you can see fine white lines on the display. (batteries outside the tag both 2.79v without load) ![Image](https://github.com/user-attachments/assets/b2a922a3-ab0f-4211-87a4-aceb4485b3ea) ![Image](https://github.com/user-attachments/assets/cd6d2640-d10e-4155-b010-8b4c5fd045df) ![Image](https://github.com/user-attachments/assets/04b53dfe-7fc1-4cba-8215-44e4dea73622) ![Image](https://github.com/user-attachments/assets/41a46430-8a61-468f-8183-a8b10c8d071a) ![Image](https://github.com/user-attachments/assets/9f7e9597-2a60-4368-9725-5aab3861e768) edit: after putting bats back ![Image](https://github.com/user-attachments/assets/3c77b1af-859c-44a8-943f-0e5177c0ecbd)

sascha_hemi commented

@skiphansen commented on GitHub (Aug 9, 2025):

I have a few displays that look like that. I'll bet several of the line drivers in the display itself have failed or there are shorts on the drive line somewhere. Even if the battery life was ok I'd consider that display as unusable.

Interestingly enough one of the displays I have that looks like that was apparently unused ... at least it had some kind of test screen on it, not blank and not something clearly from a store.

@skiphansen commented on GitHub (Aug 9, 2025): I have a few displays that look like that. I'll bet several of the line drivers in the display itself have failed or there are shorts on the drive line somewhere. Even if the battery life was ok I'd consider that display as unusable. Interestingly enough one of the displays I have that looks like that was apparently unused ... at least it had some kind of test screen on it, not blank and not something clearly from a store.

sascha_hemi commented

@skiphansen commented on GitHub (Aug 31, 2025):

My test has broken the 1000 hour threshold and the battery voltage is still above 3 volts.

I'm closing this issue as fixed.

@skiphansen commented on GitHub (Aug 31, 2025): <img width="242" height="235" alt="Image" src="https://github.com/user-attachments/assets/022b5b69-50a5-4dbf-b3d1-8ebf9b757b6a" /> My test has broken the 1000 hour threshold and the battery voltage is still above 3 volts. I'm closing this issue as fixed.

sascha_hemi commented

@skiphansen commented on GitHub (Nov 9, 2025):

Still going strong!

@skiphansen commented on GitHub (Nov 9, 2025): Still going strong! <img width="256" height="255" alt="Image" src="https://github.com/user-attachments/assets/c79c6c74-7a73-4ef0-b5f9-35e7b6fbb2f1" />

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Nov 9, 2025):

same here. :3

@DunklerPhoenix commented on GitHub (Nov 9, 2025): same here. :3

sascha_hemi commented

@DunklerPhoenix commented on GitHub (Jan 20, 2026):

4470h 🎉

@DunklerPhoenix commented on GitHub (Jan 20, 2026): 4470h 🎉

sascha_hemi commented