Predicted values

[physje]

RWS also has sensors in its API that predict values ​​up to 24 hours in advance (if you request them, you'll receive up to 288 time-value combinations). These sensors are currently disabled by default because they aren't actually measurements.

Because this could be useful information, I'm considering creating a sensor for this.
@leondeklerk has added a sensor for high and low tides. This is a very good solution for tides, as they clearly have peaks.
But there are also sensors (think flow rate, for example) that don't change as quickly.

What would be good sensors for forecasting?
Minimum or maximum values ​​for the next 24 hours?
And what if there are no real minimum or maximum values, just a steady increase of decrease?
Or something else?

[leondeklerk]

I think there are currently 3 types of predicted categories: water height (tide), wave height, flow rate. For those three categories I have collected some info as well as my thoughts.

I think some inspiration can be taken from the forecast.solar integration. Which does solar power predictions for your solar panels.
In general, it has two types of sensors:

• Sensors that indicate a value of power/energy
  • E.g. expected generated solar power for the next hour is 4 KWh
• Sensors that indicate a time of power/energy
  • E.g. the peak power for today occurs at 12:30

So they separate time from data values, which this integration combines into one sensor.

So based on this I think you could add:

• [min / max] [water height / wave height / flow rate] for [this hour / next hour / next 12 hours / today / tomorrow ]
  • The time of the min / max point is an attribute like it is now for the measured values, or it can be a separate sensor

Maybe it can also include the entire list of values (up to 24h) as a future [water level / wave height / flow rate] sensor so if needed someone can create a local helper. This way they can create sensors like "I want max of the next 6 hours", as I would expect people having different preferences with regard to what time frame they need. Though I am not sure if home assistant really supports this well, where you define future values.

I think this would be the basis for all categories with future values, then if there are multiple process types available for a grootheid, I think it could be calculated for both types.

Tide

Tide is a bit special because it has two predicted values associated with it, processtype "verwachting" for forecasted weather based water levels, and "berekend" for calculated water based levels based on the sun and moon.
I think the second type is actually calculated in advance for the entire year, so it could have more than 288 values.

Grootheid: WATHTE
Processtypes: verwachting, berekend

In addition, this is the only type of data that has min/max values for high/low tide. So in addition to time frames above (min/max next hour/day) I would personally expect at least next low and next high tide sensors, for the at least the verwachting type as that one is the most accurate representation of real world values.

For the "berekend" process type there is a "groepering" available "GETETBRKD2" which already pre-calculates the high/low tides given a time range. For "verwachting" this is not available so it needs a filter + peak detection algorithm (see my latest implementation on my fork).

Some other possible sensors related to tide that could be interesting:

• Last high/low tide
• highest / lowest tide next 24h

Flow rate

Future flow rate values do not seem available for at least a sizable part of the flow rate measurement locations. But I have found somewhere it is (e.g. maastricht.sintpieter)

Grootheid: Q
Processtypes: verwachting

It seems for process type "meting" there is a WaardeBewerkingsMethode available with code "GEM24H" which is the average. So based on that it could be interesting to have an average value for this category as well, for tides I don't think an average makes sense.

Wave height

Similar to flow rate, when using the website, I can only find a few locations which actually have wave height with future values. One of such locations is westereems.oost

Grootheid: Hm0
ProcessTypes: verwachting

I think, similar to flow rate, you could calculate an average. For the process type "meeting" there are other subtypes available like Gem. hoogte van hoogste 1/50 deel v.d. golven (H1/50) but I am not even sure what exactly this means or how you calculate it, so it seems too complicated for normal use 😅.

Remarks

There is also wind, but I haven't really checked it. It seems there are future values available as well (https://waterinfo.rws.nl/publiek/wind/Hoek-van-Holland%28HOEK%29/details). This adds another dimension to the data as there is also direction.

Other than next high / low tide I have no personal use for any of the other data, but I tried to think of what people could be interested in.

[pieterwasalreadytaken]

I'm currently trying to get the tide data via a RESTful integration, but so far not the best results.

Personally, I also only need tide data. (Although I would like the actual data points instead of only the extremes)

To answer your question: I think 48 hours in advance can be beneficial as well. With 24 hours you don't even have 2 full cycles.
Or make it configurable, you do need to define a period with timestamps anyway.

If there are no min/max values, I think the default of RWS is a predicted data point every 10 mins, which seems reasonable.

[physje]

Based on the code of @leondeklerk the component now includes tide-sensors.
It's not well tested, so I released it as beta-release.

[leondeklerk]

I'll see if I can test it this weekend!

[leondeklerk]

So I did some tests and found the following things (all for heinenoord.goidschalxoord)

• The sensor for normal current water height is not enabled by default
• The prediction sensor have double process types

- There is also another non tide sensors for the predicted "astronomisch" value, but I am not sure what it tracks. It has a "preditect peak time" but it is in the past

The tide sensors themselves work great so far!

[physje]

Released a new beta-version, v3.0.5

The sensor for normal current water height is not enabled by default

The prediction sensor have double process types

Should both be solved now

It has a "preditect peak time" but it is in the past

Haven't digged deep into that, but that's probably because also data from the past is fetched (ranging from -10 to -360 minutes). I think the peak was in that part.

I'm still looking for a good way to connect the array of predicted/calculated values ​​to the sensor. An attribute with a dictionary with the time as the key and the value as value seems the most logical, but Home Assistant won't accept that.
Currently, it's two separate lists: one with the times and one with the values. I'm not entirely satisfied with it yet, so if anyone has a good solution (one that also makes it easy to use these values ​​with a script or something similar), please let me know.

[leondeklerk]

Yes, both are fixed on my side as well.

As for the complex data, with the following changes to sensor.py:

I end up with this in HA:

So it seems that an array of objects works as expected? I'm not sure what issue you were running into?

[physje]

I'm not sure what issue you were running into?

You can indeed generate a list this way, which I've already managed. But to find the maximum or minimum, you have to iterate through the entire list and retrieve the values.

{% set forecast = state_attr('sensor.vlissingen_waterhoogte_astronomisch', 'Forecast') %}
{% for x in forecast: %}
  {% set value = x['Value'] | float %}
  {% set key = x['Time'] %}
  {{ key }} {{ value }}
{% endfor %}

It would be better if it were a dictionary with the time as the key and the value as the value. Then you could use build-in Python functions in a script to find the maximum and minimum values ​​of the prediction, for example.

When I try to do that, I get stuck every time.

[Noveste]

Firt of all, great work with this addon! Just found this discussion when searching how to get the predicted data from waterinfo into HA. Let me give some input on the comment from @leondeklerk "what people could be interested in":

People that do water activities like kayaking, surfing, boating, supping, kiteboarding (hopefully always) check different forecasts before going out since it will impact their activities. A forecast is therefore needed and various apps and websites provide this information. An example is: Windfinder but also the waterinfo website can be used ofcourse.

Getting the forecasts into HA (wind directions, wind speed, wind gusts, water flow direction, water flow speed, high/low tide time, wave height) would open up so many possibilities instead of manually checking the forecast.