OpenEPaperLink
Camera entities show corruption most of the time
Describe the bug
I have several tags that are used in drawcustom automations and the tags themselves are working great, but the camera preview in Home Assistant is showing corruption instead of the actual image, and if I click on it I see nothing:
Access Point is running firmware 2.75, Home Assistant integration is 1.0
«Known Issues
G5 Encoded Images that are fetched from the AP are not decoded correctly yet»
I see there's a decode_g5 method checked in but not being used. Is it functional? Is the work involved to detect the encoding of what's returned from the AP?
I see there's a decode_g5 method checked in but not being used. Is it functional?
the decode_g5 method is not working, i tried porting the g5 decoding algorithm from the js/c implementation from the main repo but did not have time to finish it, so it is still on my local machine.
Is the work involved to detect the encoding of what's returned from the AP?
# Possibly decode G5 data
if len(data) >= 0 and tag_type.g5_compression and int(tag_type.g5_compression) > 0:
# Read G5 header
if len(data) <6:
print("[decode_esl_raw] Not enough data for G5 header.")
return None
header_size = data[0]
bufw = (data[2] << 8) | data[1] # little-endian
bufh = (data[4] << 8) | data[3]
format_indicator = data[5]
# Go ahead with decoding g5...
https://gist.github.com/g4bri3lDev/eede4c28fc0e351edd1d69e1b22a6b98
Is this fully functional or your work in progress?
Is this fully functional or your work in progress?
it's still work in progress (not throwing errors anymore)
Forgot to mention I worked on this over the weekend but was not able to finish: this g5 encoding is tough!
I checkpointed my work here: https://github.com/jterrace/open_epaper_link_homeassistant/tree/g5
- I took your g5 gist and created a g5 module in the repository.
- Found and fixed a bug related to mutable byte arrays.
- Added a sample g5 encoded image along with the expected decoded image.
- Added a test case using the test images.
- Converted all the printfs to logging statements
Unfortunately, the decoder is failing on the second line of the image. I ran out of time to work on it if anyone wants to pick up where I left off. Otherwise, I'll get back to it when I have time again, maybe this weekend.
Made a little progress today, updated my branch. The decoder was failing because I wasn't stripping out the header. It at least doesn't crash and produces an image now, but the result is garbled.
I’ve only recently started seeing this (Solum 2.9” tags). Sometimes they are ok, but most of the time it’s just random noise like the first image above. Can’t work out why sometimes it fails but not others. I thought it was when there’s red in the image but an experiment just disproved that.
It was all working fine until a recent update.
Any news on this one? I'm still seeing garbled camera images for my tags most of the time, although sometimes it's fine. I've tried to work out what causes them to sometimes work and sometimes not, but I can't seem to spot a common link.
The actual tags are fine, it's just the content in HA that's broken.
Just after I posted that one of them started working again for a few minutes. Perhaps it was watching this issue page ;-)
I've noticed a couple of times since this update where the physical tag updates but the HA content image doesn't.
Although if I reload the integration then it shows the correct image. Very odd.
Before reloading the image shown in any dashboards, and the image shown if I go to the device info page of the tag are both out of date and don’t reflect what’s shown on the physical tag.
But like I said, if I simply reload the integration then it all magically goes right.
Happy to help with any debugging if you need me to.
@PaulOckenden this is happening, because unless dry-run is set to true the image is always fetched from the AP now when reports xfer complete is being sent over the web socket for that tag. That means the tag has successfully updated its content, but sometimes the image on the AP filesystem is still the "old" one.