🛰 International Space Station announcement when it is about to be overhead (and visible!)

Notifies you when the International Space Station (ISS) is going to be overhead next for your location (and will be high enough to be visible)

Gives you a forecast of the next viewable arrival of the International Space Station (valid until January 2031)

How does it work?

It checks an RSS feed for your location to check for upcoming arrival times for the ISS.

There’s an ISS card for Lovelace and you can set notifications on your mobile phone and Google / Nest smart speaker. Notifications are set to be 10 minutes before the ISS is overhead and when it is overhead.

The notification will tell you from what direction and angle above the horizon the ISS will arrive, how long it will be visible and it what direction and angle above the horizon it will disappear.

You can adjust the degrees above the horizon for getting notifications, from 0° to 50°. NASA’s Spot the Station website suggests making the minimum rising angle of 40° above the horizon, but this depends on how much open sky you can see from your location.

Data is pulled from an RSS feed for your location, which you can get from https://spotthestation.nasa.gov/

For example, in Melbourne Australia where I am, the URL is Melbourne, Victoria, Australia | Sighting Opportunity | Spot The Station | NASA

On that page, get the RSS feed URL and enter that into the Feedparser node in the top left.

In my example, the RSS feed is https://spotthestation.nasa.gov/sightings/indexrss.cfm?country=Australia&region=Victoria&city=Melbourne


Needs “node-red-node-feedparser” and “node-red-contrib-string” added to the palette in Node RED. In Node Red, go to the menu, select Manage Palette and search for both of these nodes then install. You will need to add this if you don’t have it installed on Node RED already. Details on these are at:

You will also need to add the YAML to your existing Home Assistant YAML files. This are all listed in the yaml files that are part of this project.


Look in the comments for spots where you could add some additional checks to stop announcements when people are asleep or if who are home aren’t interested in the ISS.


Listen to the example at home_assistant_node_red_iss/iss_overhead_in_10_minutes_announcement.mp3 at main · enzymes/home_assistant_node_red_iss · GitHub

At our house, I have a sub-flow that checks to see if announcements on the speaker are allowed.

For example, if it is overnight, no announcements.

If I’ve set a “do not disturb” mode, then again no announcements.


If only certain people are interested in the ISS announcements on the speaker, you could add a check here to see if they are home.

If they are home, there’s an announcement.

If they aren’t home, there’s silence.


Get it from GitHub - enzymes/home_assistant_node_red_iss: Notifies you when the International Space Station (ISS) is going to be overhead next for your location


Quick note of thanks for sharing this project. Really enjoyed getting my head around the setup and the nodered flow is impressive. Looking forward to tweaking the automations so I’m notified at the right times.

1 Like

Thought I’d capture a few updates so others know where key changes are required:

  1. Timezones in Nodered Date/Time Formatter - 3 nodes to update. Use this wiki page for the valid regions to use: List of tz database time zones - Wikipedia
  2. Update the location names in the Lovelace card titles.
  3. Review the automations for notifications in Nodered. I ended up removing these from Nodered and maintaining them in HA instead. I reused the scripts which were provided. Just needs the notify service entity to be updated.

Still tweaking so might come back and update.

1 Like

Very interesting, but for people do not use node-red?

Hi Maurizio,

It needs Node Red to run, all of the data is processed through it :slightly_smiling_face:

Also not currently a Note-RED user here, although I may become one in order to use this, especially now that the offical ISS integration has stopped working due to the removal of the Open Notify API it uses.

I am wondering if the same can be acheived using the Feedreader integration. Does anyone have any experience in using this and whether this could be used to convert this to run natively in Home Assistant?

Hi Rob,

I chose to use Node Red as I didn’t think this was possible using just the scripts and automations in Home Assistant.

You could read in the data using feedreader and using a series of templating, but that’s too complicated for me.

Node Red does require some learning to get the hang of, and every time I have an idea for something, I inevitably have to do a lot of Googling, but I tend to get a result in the end – even if it takes me a couple of weeks or more tinkering here and there.


@enzymes Thanks for your reply. I got this working with Node-RED doing the parsing of the the feed using your flows, but have created some helpers and template sensors to allow me to do notifications using the regular automations in Home Assistant. I’m also using a couple of rest sensors to get position to show on the map and People in Space and templating to get the crew onboard the ISS from that.

As I haven’t used Node-RED before and prefer to write code in general, I’m going to attempt to rewrite the feedparsing part at some point using Feedreader and templating, as I don’t need Node-RED for anything other than this.

I must say that using this solution as it stands (with my current slight modifiication for notifications) is way better than the no-longer functioning ISS Above Horizon sensor that was provided by the built in integration, so thank you for all your work on the Node-RED flows. What I have already is great thanks to you making this public. I’d just like to get the remainder out of Node-RED now. :slightly_smiling_face:

1 Like

@robertwigley Are you getting all this information through NodeRed or are you using any other feeds from the ISS integration? If it is all in NodeRed, are you able to share the flows? I currently have NodeRed for the notification and sighting details, but am using two Rest calls to gather the location and people in space details.

@black No, I’m only using Node-RED to get the sightings. I’m doing everything else with two rest sensors, and a few helpers, template sensors and automations. I don’t use Node-RED. I’ve actually just started looking at how to rewrite getting the sightings so I can remove Node-RED from this completely. So far I’ve got the feeds in using Feedparser. The Feedreader integration is no good for this purpose.

Raw sensor data in Developer Tools:

Displayed in a List Card:

sensor: section in configuration.yaml

- platform: rest
  name: International Space Station Location
  icon: mdi:space-station
  resource: http://api.open-notify.org/iss-now.json
  value_template: "{{ value_json.iss_position.latitude }},{{ value_json.iss_position.longitude }}"
  json_attributes_path: "$.iss_position"
    - latitude
    - longitude
    seconds: 30
# People in Space
- platform: rest
  name: People in Space
  icon: mdi:account-group
  resource: http://api.open-notify.org/astros.json
  value_template: "{{ value_json.number }}"
    - people
# Spot the Station Glasgow
- platform: feedparser
  name: Spot the Station Glasgow
  feed_url: https://spotthestation.nasa.gov/sightings/xml_files/United_Kingdom_Scotland_Glasgow.xml
    hours: 12
    - published
    - summary

template: section in configuration.yaml:

    # ISS Crew
    - name: ISS Crew
      icon: mdi:account-supervisor-circle-outline
      state: "{{ state_attr('sensor.people_in_space', 'people') | regex_findall(find='ISS', ignorecase=false) | count }}"

    # ISS Sighting binary sensor
    - name: ISS Sighting
      icon: mdi:space-station
      state: >-
        {%- set var_date_now = now().strftime('%d/%m/%Y') -%}
        {%- set var_time_now = now().strftime('%H:%M') -%}
        {%- set var_date_iss_next_sighting = as_timestamp(states('sensor.iss_next_sighting_timestamp')) | timestamp_custom('%d/%m/%Y') -%}
        {%- set var_time_iss_next_sighting = as_timestamp(states('sensor.iss_next_sighting_timestamp')) | timestamp_custom('%H:%M') -%}
        {%- if (var_date_now == var_date_iss_next_sighting) and (var_time_now == var_time_iss_next_sighting) -%}
        {%- else -%}
        {%- endif -%}
      delay_off: >-
        {% set var_mins = states('sensor.iss_visible') | int - 1 %}
        00:{{ '{:02}'.format(var_mins) }}:00
    # ISS Approaching binary sensor
    - name: ISS Approaching
      icon: mdi:earth
      state: >-
        {%- set var_date_now = now().strftime('%d/%m/%Y') -%}
        {%- set var_time_now = now().strftime('%H:%M') -%}
        {%- set var_date_iss_next_sighting = as_timestamp(states('sensor.iss_next_sighting_timestamp')) | timestamp_custom('%d/%m/%Y') -%}
        {%- set var_time_iss_next_sighting = (as_timestamp(states('sensor.iss_next_sighting_timestamp')) - 600) | timestamp_custom('%H:%M') -%}
        {%- if (var_date_now == var_date_iss_next_sighting) and (var_time_now == var_time_iss_next_sighting) -%}
        {%- else -%}
        {%- endif -%}
      delay_off: 00:09:00

This output without the need to have Node-RED in use equals GREAT integration.

1 Like

If anyone can lend a hand with creating the template sensors that separate the dictionary and lists from the feed, that would be appreciated. I’m struggling to separate them using jinja ATM.

1 Like

So I think you could actually get feedparser to work but you’d have to change up the logic. The problem with feedparser currently is that it just pops out events when items are added to the RSS feed. Which isn’t interesting under the current logic because those are in the future and the current logic treats the feed like a calendar, trying to find the event in the middle closest to “right now”.

But alternatively, what if we just made a calendar? The google calendar integration comes with a google.create_event service. So if we made a dedicated calendar for this then we could use feedparser and use each event to create a calendar event on that dedicated calendar. And then the automation is trivial - use a calendar trigger.

Unfortunately google calendar is kind of required for the google.create_event service. The caldav integration does not come with this service and there is no local calendar option atm. If the google piece really bothers you then some other options would be:

  1. Write the events to a file as they come in from feedparser and then use a command_line sensor to read that data back into a sensor for use in automations
  2. Call a script or use a rest/shell command to effectively roll your own “create event” service that can talk to a local calendar service you’ve deployed which you can communicate with over caldav. Call it per feedparser event and then use the calendar trigger.
  3. Make a bunch of input_datetime helpers. When a feedparser event comes in that meets your criteria set one that is currently in the past to the date and time of the new event. Trigger your auotmation anytime the current date/time equals one of those helpers

The problem with simply reading the feed in HA is its XML. There really is no good way to handle XML in pure HA automation I’m aware of, either in Jinja or on the command line. Better to instead stash the events somewhere as feedparser hands them to us parsed.

Node-RED is fun and very useful, but takes a bit of fiddling with and researching to get it to work. I like what you’ve done and your panel on Home Assistant looks great :+1:

Hopefully, someone will find this useful.

I tried to do this in Home Assistant but kept having issues with the amount of data returned and processing it. I’m still a bit of a noob with Home Assistant…

I wrote a script that can run in Google Apps Script which fetches the RSS feed from Spot the Station and adds it to my Google Calendar. I then use the Google Calendar integration in Home Assistant to trigger automations based on this.

I have a separate setup to display the NEXT Spot the Station event using a Home Assistant sensor.

This is a very similar script but instead of returning all upcoming events data, it just returns the next event’s data:

I use both of these and force the sensor to update after every event that ends in the calendar, allowing the sensor data to always show the next upcoming event data.

1 Like