Fix issue with 'async_request_refresh'

[tdragon]

No description provided.

[TheStork239]

I think FMI have recently changed the OAAS sea level query so that it now returns two types of sea level measurements, with the parameters in the query being called ‘SeaLevel’ (as it was before) but also now a new ‘SeaLevelN2000’ measurement. So I think that a “starts with SeaLevel” type of parsing line might cause unintended results as it would presumably pick up both of the measurement types from the data?

[TheStork239]

Hi again @tdragon,
One way would be to just add an 'else if' to skip over the entries that are in fact for the new 'SeaLevelN2000' parameter, something along the lines of the below:

for n in range(len(root_mareo)):
    try:
        if root_mareo[n][0][2].text == 'SeaLevel':
            tuple_to_add = (root_mareo[n][0][1].text, root_mareo[n][0][3].text)
            sealevel_tuple_list.append(tuple_to_add)
        elif root_mareo[n][0][2].text == 'SeaLevelN2000':
            pass
        else:
            _LOGGER.debug("Sealevel forecast record mismatch - aborting query!")
            break
    except:
        _LOGGER.debug(f"Sealevel forecast records not in expected format for index - {n} of locstring - {loc_string}")

[tdragon]

Good point. I am not really interested in the SeaLevel, but seen an error in the log and quickly fixed it.
I've updated my fix, I think it is safe to ignore everything unexpected. What do you think?

[TheStork239]

Thanks. I think a potential issue with your amended fix is that it will flood the log with “unsupported record” lines. The FMI sea level data fetch brings in half hourly forecast data for two days ahead, and for each time point it now has both a ‘SeaLevel’ and ‘SeaLevelN2000’ entry. So every time the sensor updates, you would see nearly a hundred log lines on unsupported records.

I think the parsing over the forecast would best work if it followed the below logic:

1. If it finds a ‘SeaLevel’ entry, it adds the tuple. (This works in current code already).
2. If it finds a ‘SeaLevelN2000’ entry, it skips it without creating a tuple. These ‘SeaLevelN2000’ entries are now part of what the FMI mareograph data fetch query returns, but it is expected and probably do not need to be reflected in the logs.
3. If it finds some other entry than either ‘SeaLevel’ or ‘SeaLevelN2000’ then something has gone wrong with the data fetch and that should be highlighted in the logs.

That way it would only create a log entry if something unexpected came up when parsing the data.

[tdragon]

Ok, I added a skipping of the ‘SeaLevelN2000' without logging.

[anand-p-r]

Thanks for changing this!