Apostrophes in Weather Alert info

[neilswann80]

Apostrophes in Weather Alert info cause an issue, displayig as: â€tm

See example below:

[orontee]

Thank you for reporting!

Can you attach the /mnt/ext1/system/state/taranis.json file? It contains the application model serialized in JSON. It will help to reproduce and analyze the problem.

[neilswann80]

Thank you for reporting!

Can you attach the /mnt/ext1/system/state/taranis.json file? It contains the application model serialized in JSON. It will help to reproduce and analyze the problem.

I'm not getting any weather alerts currently, so will the JSON still help? I've had the screenshot saved for a while.

[orontee]

Don't worry, I'll try to reproduce by myself.

[orontee]

Tested with various Unicode characters in alert description (writing the characters directly in the taranis.json file) and it's ok; The following text was rendered as expected:

It's an apostrophe, it’s a right single quotation mark, it‘s a left single quotation mark! À aussi en français accentuons le débat.

One can thus expect that the content of the state file is wrongly encoded when the problem happens. Can come from a wrong deserialization of the OpenWeather API response or a wrong encoding while writing the state file.

[orontee]

I failed to reproduce up to now. Please post the location and taranis.json file if the problem appears once again.

[neilswann80]

It's happening for today's weather alert for Bistol, GB.

taranis.json

Also the last line of the alert is partly cut-off (I've noticed this on the last couple of alerts):

[orontee]

Great! Reproduced on my device. I'll investigate after work. Thank you!

[orontee]

From the logs I read the URL requested.

Then I checked that the response headers says that the encoding used is UTF-8 but the payload is wrongly encoded since terminal support UTF-8 and display of response payload is wrong:

matthias@peitho:~ $ curl --verbose --output payload_with_wrong_accents.json "https://api.openweathermap.org/data/3.0/onecall?lon=-2.5973&lat=51.453802199999998&units=metric&exclude=minutely&lang=fr&appid=4620ad6f20069b66bc36b1e88ceb4541" 2>&1 | grep -E charset
< Content-Type: application/json; charset=utf-8
matthias@peitho:~ $ cat payload_with_wrong_accents.json | grep --only-matching -E "It.*easy"
It’s easy
matthias@peitho:~ $ echo -e '\xe2\x82\xac'   # Print euro sign to check whether terminal supports UTF-8 encoding
€

Requesting a specific charset is a no-op:

curl --verbose -H "Accept-Charset: iso8859-1" --output payload_with_wrong_accents.json "https://api.openweathermap.org/data/3.0/onecall?lon=-2.5973&lat=51.453802199999998&units=metric&exclude=minutely&lang=fr&appid=4620ad6f20069b66bc36b1e88ceb4541" 2>&1 | grep -iE charset
> Accept-Charset: iso8859-1
< Content-Type: application/json; charset=utf-8

And finally, on OpenWeather website itself:

Conclusion: Not a Taranis bug! More an OpenWeather API or Met Office bug.

[neilswann80]

Although not a Taranis issue then, would it be worth adding a workaround to substitute "â€tm" for an apostrophe anyway?

And what about the last line of the alert being cut off? Does that need raising as a separate issue?

Thanks.

[orontee]

Although not a Taranis issue then, would it be worth adding a workaround to substitute "â€tm" for an apostrophe anyway?

My point of view is that we'd better first send a bug report upstream (OpenWeather API) and see whether they work on it or not. Open for discussion.

And what about the last line of the alert being cut off? Does that need raising as a separate issue?

Good catch! There's a bug in the computation of the content height of alert description; It's not possible to scroll to read full content... Tracked with #100.