I suspect the function "is_ISS_above" is returning true when it's not above

[r-jordan]

Hi!

The function is_ISS_above has been returning True during more than 1 hour and it is impossible because the durations are less than 1000 seconds. Otherway it's returning False when it should return True.

Are you sure the following implementation of the is_ISS_above function is correct?

        test = self.pass_times(latitude, longitude, altitude, 2)
        # 2 results where asked so if API return only 1, that mean ISS is
        # above the location
        return len(test) is 1

I've searched the API documentation and it doesn't say anything about returning only 1 pass time would mean that the ISS is above. A correct implementation would be to look if the current time is between risetime and risetime+duration of the first element of the response.

Have good holidays!

[Moonbase59]

Indeed, something seems to be flakey here, and many people in the Home Assistant forum complain about wrong visibility states. In addition, I sometimes see the risetime "jump" when the visibility goes true (using Home Assistant Core 0.112.4, which in turn uses pyiss).

I wonder if response[0] in iss-pass.json will still hold the current rise while it’s happening (i.e., within its duration). Have to investigate further, I think. Guess I’ll set up some direct REST sensors to open-notify and see what happens.

Since we’re watching the ISS here, it might also be a good idea to reduce the number of people in space to number of people on the ISS by checking craft="ISS".

[HydrelioxGitHub]

Hello,
I've not updated this project for years. Feel free to submit PR !

[Moonbase59]

Hey, thanks for a prompt response! I’d love this to be fixed here (so others can benefit), and will do some testing and let you know my findings (or actually try to make a PR …).

[Moonbase59]

First findings:

• It seems that the open-notify.org API endpoint /iss-pass.json is forcibly cached or only updated every one hour. Sending Cache-Control: headers doesn’t change that behaviour.

  Thus, the next risetime shown in response[0] may be in the past for quite some time. I’m unsure how the time for the next update is chosen, hopefully not within the duration of a visible ISS.

• That said, it seems reasonably safe to check response[0] to see if now() is between risetime and risetime + duration and set "visible" from that.

• I couldn’t yet produce the situation where 2 results were requested but only 1 returned.

• I wonder how sensibly the cache expiry times are chosen, or if we should append some cache-defeating variable to the GET, like the current timestamp. Then again, I don’t like overstressing other people’s (free!) APIs.

Guess I’ll watch this for a few more days to see where the pitfalls might be.

[Moonbase59]

Just had the situation where the ISS was visible from 20:14:10–20:24:28, and the update came in at 20:15:29.
The API really only returns one new response in this case, containing risetime and duration for the next rise, effectively invalidating above assumptions.

{
  "message": "success", 
  "request": {
    "altitude": 514.0, 
    "datetime": 1595268929, 
    "latitude": xx.xxxxxx, 
    "longitude": xx.xxxxxx, 
    "passes": 2
  }, 
  "response": [
    {
      "duration": 647, 
      "risetime": 1595280452
    }
  ]
}

Since for some reason we only get a changed JSON response once an hour, this explains why "visible" isn’t shown at the correct times, and the ISS might already be over another part of the world.

Now to find who does the aggressive cacheing – Home Assistant, open-notify.org, or some part in between.

Further thinking & testing …

[Moonbase59]

Seems the open-notify.org API has its quirks, too: While the ISS is visible (and only one response given), this response is actually the next plus one risetime! And response[0] will jump back to the next risetime when 2 results are given again. One needs to be aware when displaying this.

Need some more experimentation regarding the caching: The only way I could show an approximately valid "visible" indication was to poll the REST API every minute, adding a timestamp &ts=xxxxx to the GET.
Will probably write a little Python tomorrow, using pyiss, to find if it’s Home Assistant after all.

In order not to overrun open-notify’s API, I wonder if it might be wise to store next risetime and duration somewhere, and only request new data from their API when now() > risetime + duration (or when these are invalid because we didn’t yet request a value). Without this, a typical 1-minute granularity would mean calling their API 1440 times per day.

[HydrelioxGitHub]

Thanks for your time and your work on this issue !

[Moonbase59]

It may take a little time, though, I’m currently overwhelmed with other work.

[HydrelioxGitHub]

This issue is open for two years, so I think it's ok even if it takes a couple of month.

[viktak]

Hi there!
I also noticed the issue with the ISS component in Home Assistant - That's how I ended up here.

@Moonbase59 I don't see any caching anywhere: Anyt time I refresh the public API endpoint (http://api.open-notify.org/iss-now.json), I see new values, even if I do it in quick succession. something like this:

{"iss_position": {"latitude": "22.4381", "longitude": "-63.6948"}, "message": "success", "timestamp": 1618656038}

This tells me that there is no caching on their side.

Also, if I use the example commands from this component, I see the same effect:

Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyiss
>>> station = pyiss.ISS()
>>> print(station.current_location())
{'latitude': '13.0246', 'longitude': '-71.4123'}
>>> print(station.current_location())
{'latitude': '13.2240', 'longitude': '-71.2598'}
>>> print(station.current_location())
{'latitude': '13.3237', 'longitude': '-71.1835'}
>>> print(station.current_location())
{'latitude': '13.4482', 'longitude': '-71.0880'}
>>> print(station.current_location())
{'latitude': '13.5230', 'longitude': '-71.0306'}
>>> print(station.current_location())
{'latitude': '13.6226', 'longitude': '-70.9540'}
>>> print(station.current_location())
{'latitude': '13.6724', 'longitude': '-70.9157'}
>>> print(station.current_location())
{'latitude': '13.7222', 'longitude': '-70.8774'}
>>> print(station.current_location())
{'latitude': '13.7720', 'longitude': '-70.8390'}
>>> print(station.current_location())
{'latitude': '13.8218', 'longitude': '-70.8007'}
>>> print(station.current_location())
{'latitude': '16.9167', 'longitude': '-68.3639'}
>>> print(station.current_location())
{'latitude': '17.1136', 'longitude': '-68.2051'}
>>> print(station.current_location())
{'latitude': '17.2858', 'longitude': '-68.0658'}
>>> print(station.current_location())
{'latitude': '22.5100', 'longitude': '-63.6305'}
>>>

Is it possible, that the public API endpoint dropped caching since last July?

Furthermore, the print(station.is_ISS_above(lat,lon)) seems to be working too:

>>>
>>>
>>> print(station.current_location())
{'latitude': '44.8171', 'longitude': '-33.1774'}
>>>
>>>
>>> print(station.is_ISS_above(44.8171,-33.1774))
True
>>>

So I would say this component is working just fine. However, my problem in Home Assistant remains still: I get the notifications and the wrong time, not when the ISS is above me.

[viktak]

I have done some more experiments and I got more weird results. Just now I issued the following commands, one after the other with a second or so delay:

>>> print(station.current_location())
{'latitude': '-26.3721', 'longitude': '-48.6489'}
>>> print(station.is_ISS_above(51,89))
True
>>> print(station.is_ISS_above(51,88))
False
>>> print(station.is_ISS_above(51,89))
True
>>>

I don't seem to understand how this is possible...

[viktak]

... and after a long time, this morning, I got a correct result:

From the API endpoint:

{"timestamp": 1618812623, "message": "success", "iss_position": {"longitude": "22.7532", "latitude": "43.5016"}}

From the command line:

>>> print(station.current_location())
{'longitude': '17.8375', 'latitude': '41.0015'}
>>> print(station.is_ISS_above(37,23))
True
>>>

Bonus: Home Assistant also reported it correctly!

I'm just worried, it is a coincidence...