[GH-ISSUE #490] Corrupt camera entity pictures #3623

New Issue

sascha_hemi · 2026-03-20T23:07:25+01:00

sascha_hemi commented

2026-03-20 23:07:25 +01:00

Originally created by @emufan on GitHub (Aug 6, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/490

Describe the bug
I just updated to newest version of integration as well as to AP FW 2.81 and Tag FW 41 0x29

If I run now such an automation for devices, e.g.

      - action: open_epaper_link.drawcustom
        target:
          device_id:
            - a152781569ac5e7505baa098790c0af0
            - 3d2ca1c37f3314bd3cdc721168d1f6bf
        data:
          dry-run: false
          background: white
          rotate: 0
          payload:
            - type: text
              value: iX Batterie
              x: >-
                {% if states('binary_sensor.bmw_ix_weiss_ladezustand') == 'on'
                %}
                  165
                {% else %}
                  173
                {% endif %}
              "y": 48
              anchor: mm
              size: 28
              color: black

in generated the right image in the folder \config\www\open_epaper_link and send it to the tag.

BUT (never had that before the updates):

After the AP has sent it to the tag, the picture is deleted again in the folder.
If I have the camera entity on a dashboard or open it in more-info, the image is re-created but corrupt

Expected behavior
Have the last pictures still available for the camera entity.

Originally created by @emufan on GitHub (Aug 6, 2025). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/490 **Describe the bug** I just updated to newest version of integration as well as to AP FW 2.81 and Tag FW 41 0x29 If I run now such an automation for devices, e.g. ``` - action: open_epaper_link.drawcustom target: device_id: - a152781569ac5e7505baa098790c0af0 - 3d2ca1c37f3314bd3cdc721168d1f6bf data: dry-run: false background: white rotate: 0 payload: - type: text value: iX Batterie x: >- {% if states('binary_sensor.bmw_ix_weiss_ladezustand') == 'on' %} 165 {% else %} 173 {% endif %} "y": 48 anchor: mm size: 28 color: black ``` in generated the right image in the folder \config\www\open_epaper_link and send it to the tag. <img width="271" height="152" alt="Image" src="https://github.com/user-attachments/assets/ffb8ff13-5098-4d59-a6af-6bdebc512557" /> BUT (never had that before the updates): 1. After the AP has sent it to the tag, the picture is deleted again in the folder. 2. If I have the camera entity on a dashboard or open it in more-info, the image is re-created but corrupt <img width="155" height="160" alt="Image" src="https://github.com/user-attachments/assets/d27ce3ea-e525-434c-a90d-c1afcd2ab300" /> **Expected behavior** Have the last pictures still available for the camera entity.

sascha_hemi added the bug label 2026-03-20 23:07:25 +01:00

sascha_hemi closed this issue

2026-03-20 23:07:25 +01:00

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@emufan commented on GitHub (Aug 6, 2025):

Arg. Do not find this breaking change there (now only "G5 Encoded Images that are fetched from the AP are not decoded correctly yet" but I don't want to fetch them), that it is not possible anymore to use the camera-images on dashboards. If I would have know that, I would not have done the update.

So you say, it it because of the re-download/update from AP?

Then why do this? Just leave the images as generated from HA as in the versions before. Sure, if I would update on AP in parallel, they would be out of sync, but for those who are doing it in HA, they would still have the HA-picture.

Without deleting and calling from HA (?) the compression would not matter, wouldn't it?

@emufan commented on GitHub (Aug 6, 2025): Arg. Do not find this breaking change there (now only "G5 Encoded Images that are fetched from the AP are not decoded correctly yet" but I don't want to fetch them), that it is not possible anymore to use the camera-images on dashboards. If I would have know that, I would not have done the update. So you say, it it because of the re-download/update from AP? Then why do this? Just leave the images as generated from HA as in the versions before. Sure, if I would update on AP in parallel, they would be out of sync, but for those who are doing it in HA, they would still have the HA-picture. Without deleting and calling from HA (?) the compression would not matter, wouldn't it?

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@atc1441 commented on GitHub (Aug 6, 2025):

Hey again, I did delete that comment again as Im not sure if it still counts as for me the Compressed images do show correct in HA,
In theory you could edit out the deletion of the images in the HA plugin and see if it works out. You can remove those 2 lines https://github.com/OpenEPaperLink/Home_Assistant_Integration/blob/main/custom_components/open_epaper_link/camera.py#L363 via an text editor in your HA installation and reboot HA

@atc1441 commented on GitHub (Aug 6, 2025): Hey again, I did delete that comment again as Im not sure if it still counts as for me the Compressed images do show correct in HA, In theory you could edit out the deletion of the images in the HA plugin and see if it works out. You can remove those 2 lines https://github.com/OpenEPaperLink/Home_Assistant_Integration/blob/main/custom_components/open_epaper_link/camera.py#L363 via an text editor in your HA installation and reboot HA

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@emufan commented on GitHub (Aug 6, 2025):

Ah, great. Will try it. But this would only remove the delete, but not the catch from device, wouldn't it? Do you have a hint, where this is happening as well?

@emufan commented on GitHub (Aug 6, 2025): Ah, great. Will try it. But this would only remove the delete, but not the catch from device, wouldn't it? Do you have a hint, where this is happening as well?

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@svenove commented on GitHub (Aug 6, 2025):

It's also possible to deactivate compression - believe it's done by editing the tagtype-json on the AP. I don't recall the exact change, but I know I read it somewhere.

@svenove commented on GitHub (Aug 6, 2025): It's also possible to deactivate compression - believe it's done by editing the tagtype-json on the AP. I don't recall the exact change, but I know I read it somewhere.

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@atc1441 commented on GitHub (Aug 6, 2025):

Yeah you could change this number to like "99" https://github.com/OpenEPaperLink/OpenEPaperLink/blob/master/resources/tagtypes/04.json#L13
But then also the upload is not compressed anymore so I would not advice it but it will work. With that small screen its not that big of a deal as even uncompressed its just a small image

@atc1441 commented on GitHub (Aug 6, 2025): Yeah you could change this number to like "99" https://github.com/OpenEPaperLink/OpenEPaperLink/blob/master/resources/tagtypes/04.json#L13 But then also the upload is not compressed anymore so I would not advice it but it will work. With that small screen its not that big of a deal as even uncompressed its just a small image

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@emufan commented on GitHub (Aug 6, 2025):

Thanks to both of you. Don't know where 29 or 99 come from, but can test it.

But the approach in deleting the deletion (hint from above), but the request/update from AP as well (still searching for it, any tips) would be more what I would like.

@emufan commented on GitHub (Aug 6, 2025): Thanks to both of you. Don't know where 29 or 99 come from, but can test it. But the approach in deleting the deletion (hint from above), but the request/update from AP as well (still searching for it, any tips) would be more what I would like.

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@atc1441 commented on GitHub (Aug 6, 2025):

29 is the minimum version from which G5 Compression is supported and "99" would be a very high number to "disable" it

"but the request/update from AP" I dont understand what you mean by this

@atc1441 commented on GitHub (Aug 6, 2025): 29 is the minimum version from which G5 Compression is supported and "99" would be a very high number to "disable" it "but the request/update from AP" I dont understand what you mean by this

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@emufan commented on GitHub (Aug 6, 2025):

"but the request/update from AP" I dont understand what you mean by this

I understood, that https://github.com/OpenEPaperLink/Home_Assistant_Integration/blob/main/custom_components/open_epaper_link/camera.py#L363 is just deleting the (working) image from folder.

Clear cached image to force refresh on next request

But thought the problem is the step afterwards, the request of the compressed image from AP/tag if opening or using the camera entity. So I would think that I have to skip it as well, as the main problem.

Or is it that way, that If the picture is still in the folder, it is not requested from AP? Yes, then it would be enough to delete the deletion.

@emufan commented on GitHub (Aug 6, 2025): > "but the request/update from AP" I dont understand what you mean by this I understood, that https://github.com/OpenEPaperLink/Home_Assistant_Integration/blob/main/custom_components/open_epaper_link/camera.py#L363 is just deleting the (working) image from folder. > Clear cached image to force refresh on next request But thought the problem is the step afterwards, the request of the compressed image from AP/tag if opening or using the camera entity. So I would think that I have to skip it as well, as the main problem. Or is it that way, that If the picture is still in the folder, it is not requested from AP? Yes, then it would be enough to delete the deletion.

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@atc1441 commented on GitHub (Aug 6, 2025):

It will not request the image if it is exisiting!

Also the G5 Compression is still not supported so yes my first comment was still correct ^^ The displays I use are using ZLIB Compression which is implemented in the HA Integration https://github.com/OpenEPaperLink/Home_Assistant_Integration/blob/main/custom_components/open_epaper_link/image_decompressor.py#L111

@atc1441 commented on GitHub (Aug 6, 2025): It will not request the image if it is exisiting! Also the G5 Compression is still not supported so yes my first comment was still correct ^^ The displays I use are using ZLIB Compression which is implemented in the HA Integration https://github.com/OpenEPaperLink/Home_Assistant_Integration/blob/main/custom_components/open_epaper_link/image_decompressor.py#L111

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@emufan commented on GitHub (Aug 6, 2025):

Great. Will do it that way and delete my camera snapshot way, which I used currently, again for now. Thanks so much for your help and the background.

@emufan commented on GitHub (Aug 6, 2025): Great. Will do it that way and delete my camera snapshot way, which I used currently, again for now. Thanks so much for your help and the background.

sascha_hemi commented

2026-03-20 23:07:26 +01:00

@g4bri3lDev commented on GitHub (Sep 13, 2025):

With Release 2.0.0 of the Integration decoding of G5 images has now been implemented correctly so this issue should be fixed.

@g4bri3lDev commented on GitHub (Sep 13, 2025): With Release 2.0.0 of the Integration decoding of G5 images has now been implemented correctly so this issue should be fixed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#3623