Use api.forecast.solar host in API calls

[anikrooz]

Rather than using the looked-up IP address for API calls, use 'api.forecast.solar' so that certificate for https call matches.

For context, I'm getting the error:
Config entry 'Preesall' for forecast_solar integration not ready yet: 0, message='Attempt to decode JSON with unexpected mimetype: text/html', url=URL('https://148.251.178.234/estimate/53.xxx/-2.xxx/36/30/4.0?time=iso8601&damping=0.0&inverter=4.0'); Retrying in background

This is due to my firewall seeing that the certificate presented by the API server at 148.251.178.234 is for pv-log.net and has expired. Sending the correct host header ("api.forecast.solar") gets the correct certificate and will not fall foul of any certificate inspection firewalls.

[frenck]

Did they solve the original issue that is in #5? And if so, this PR needs to clean up that whole workaround (not just the hostname change).

[anikrooz]

Ah I see. Makes sense now why it's making the API call by IP address.
No it looks like IPv6 is still not working...

wget -6 https://api.forecast.solar/estimate/51.15/10.45/37/0/10
--2022-08-04 08:08:58--  https://api.forecast.solar/estimate/51.15/10.45/37/0/10
Resolving api.forecast.solar (api.forecast.solar)... 2a01:4f8:211:55d::2
Connecting to api.forecast.solar (api.forecast.solar)|2a01:4f8:211:55d::2|:443... failed: Connection refused.

Looks like either the cert needs fixing, the IPv6 DNS entry needs removing, or IPv6 access needs fixed. Or both!

[frenck]

Yup... :(

Unfortunately, this is an upstream issue.

[klaasnicolaas]

According to Knut's info, the problem with the IPv6 is now solved? 🤷🏻‍♂️ If any of us could confirm that, we could remove the workaround.

[klaasnicolaas]

For now this pull request has been marked as a draft, until it is really clear that the workaround is no longer needed and can be removed completely.

[frenck]

I've just tested the API from an IPv6 endpoint, it seems to work correctly now.

curl -v -6 https://api.forecast.solar/estimate/51.15/10.45/37/0/10

*   Trying 2a01:4f8:211:55d::2:443...
* TCP_NODELAY set
* Connected to api.forecast.solar (2a01:4f8:211:55d::2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=api.forecast.solar
*  start date: Mar  8 02:39:27 2023 GMT
*  expire date: Jun  6 02:39:26 2023 GMT
*  subjectAltName: host "api.forecast.solar" matched cert's "api.forecast.solar"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x56325fe4b8f0)
> GET /estimate/51.15/10.45/37/0/10 HTTP/2
> Host: api.forecast.solar
> user-agent: curl/7.68.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx
< date: Mon, 24 Apr 2023 15:59:14 GMT
< content-type: application/json; charset=utf-8
< access-control-allow-origin: *
< x-pid: 1j187q41
< x-version: v6.1.0.1402
< x-ratelimit-period: 3600
< x-ratelimit-limit: 12
< x-ratelimit-remaining: 8
< x-response-time: 13 ms
<
{"result":{"watts":{"2023-04-24 06:04:42":0,"2023-04-24 06:15:00"
...

[klaasnicolaas]

Does the IPv6 still work properly? Is it time to remove the workaround?

[frenck]

I think so, yes 👍