Update for sensor.opensky fails

brayStorm commented 4 years ago

The problem

"Update for sensor.opensky fails" The actual integration never updates, and doesn't seem to pull any information.

Environment

Home Assistant Core release with the issue: 0.118.2
Last working Home Assistant Core release (if known): None
Operating environment (OS/Container/Supervised/Core): Core
Integration causing this issue: opensky
Link to integration documentation on our website: https://www.home-assistant.io/integrations/opensky/

Problem-relevant `configuration.yaml`

sensor:
  - platform: opensky
    name: OpenSky
    radius: 5.0

Traceback/Error logs

Logger: homeassistant.helpers.entity
Source: components/opensky/sensor.py:135
First occurred: 4:34:35 PM (1 occurrences)
Last logged: 4:34:35 PM
Update for sensor.opensky fails

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 278, in async_update_ha_state
    await self.async_device_update()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 474, in async_device_update
    raise exc
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/opensky/sensor.py", line 135, in update
    states = self._session.get(OPENSKY_API_URL).json().get(ATTR_STATES)
  File "/usr/local/lib/python3.8/site-packages/requests/models.py", line 900, in json
    return complexjson.loads(self.text, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/simplejson/__init__.py", line 525, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python3.8/site-packages/simplejson/decoder.py", line 370, in decode
    obj, end = self.raw_decode(s)
  File "/usr/local/lib/python3.8/site-packages/simplejson/decoder.py", line 400, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Additional information

tux2000 commented 4 years ago

It is working with a similar configuration in my installation with 0.118.1 and with exactly this configuration on the dev branch (edf70e9f). The error message looks to me as if potentially the OpenSky API did not provide a proper json file. Could this have been a temporary problem? Is https://opensky-network.org/api/states/all accessible from the same network as home assistant is on?

brayStorm commented 4 years ago

Yes, [https://opensky-network.org/api/states/all]() opens just fine.

tux2000 commented 4 years ago

Mh, this is a tricky one then. I have currently an open pull request for a different way of handling the API calls to OpenSky (https://github.com/home-assistant/core/pull/43747) but I would not expect this to change your problem, @brayStorm ... Do you feel comfortable to put up your own development version of home assistant (https://developers.home-assistant.io/docs/development_index/) to test some more what the problem is? It would also help to know if other users have a similar problem to be able to narrow down the cause of it...

towerhand commented 4 years ago

I get this error sometimes but not too often. Not familiar with running dev but I'm willing to try if needed.

Getting a lot of this ones though: 2020-11-30 20:10:51 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.opensky is taking over 10 seconds

2020-11-30 20:10:53 WARNING (MainThread) [homeassistant.components.sensor] Updating opensky sensor took longer than the scheduled update interval 0:00:12

tux2000 commented 4 years ago

Thanke @towerhand for your information. Do you see any pattern in which situations you get the error message that @brayStorm is describing?

The second type of warning messages is exactly the issue I'm trying to fix with #43747 but this implies also that your home assistant got hold of the data while the problem @brayStorm is describing looks like as if the OpenSky data is not received or read correctly...

brayStorm commented 4 years ago

I'll give it a go later tonight and report back.

towerhand commented 4 years ago

I had this error 39 times in the last 12-14 hrs. I can check the timestamps when I get home in a few hours and see if there’s a pattern.

tux2000 commented 4 years ago

Ok, i added some logging to the code to provide more information on what is going wrong sometimes. I have put that code into a separate branch on my fork of the home assistant repository: https://github.com/tux2000/core/tree/pp-opensky-error/homeassistant/components/opensky

If you could put the files from that folder into a new folder called opensky within your custom_components folder. After a restart home assistant should use that code instead of the main one.

Adding debug logging for that component will give more verbose output. This can be activated from the configuartion.yaml like this:

logger:
  default: info
  logs:
    homeassistant.components.opensky: debug

towerhand commented 4 years ago

2020-12-03 00:02:11 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.opensky fails Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 278, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 474, in async_device_update raise exc File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/opensky/sensor.py", line 149, in update _LOGGER.debug(str(len(states)) + " flights parsed") TypeError: object of type 'NoneType' has no len()

tux2000 commented 4 years ago

Thanks for testing. This was another error I had fixed in one of the pull requests. To streamline development I now merged all previous changes into one branch to send in as one pull request later.

I now also managed to reproduce the initial error on my system and it seems to be caused by OpenSky Network sometimes replying with an status code 502 instead of data. So there is not too much to be done from home assistants side but retrying later. I modified the code to catch this situation and only throw an error when it doesn't get data in 10 attempts in a row. This should fix the problem for now.

The current code is in my repository under the same link as above. It would be amazing if you could test this.

towerhand commented 3 years ago

Getting this with the custom component from your repo. `Logger: homeassistant.helpers.entity Source: custom_components/opensky/sensor.py:235 First occurred: December 7, 2020, 11:55:34 PM (485 occurrences) Last logged: 3:32:35 AM

Update for sensor.opensky fails Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 278, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 474, in async_device_update raise exc File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/opensky/sensor.py", line 235, in update _LOGGER.debug(str(len(states)) + " flights parsed") TypeError: object of type 'NoneType' has no len() `

tux2000 commented 3 years ago

This should be fixed in the most recent commit

towerhand commented 3 years ago

The newer commits really helped, haven't gotten a single opensky error since updating it, great job and thanks for taking ownership of the integration.

brayStorm commented 3 years ago

Great work. Is it possible with OpenSky's api to query a window of time? Like how many flights have entered my defined area in the past day/week?

tux2000 commented 3 years ago

@brayStorm, in principal this data should be available at OpenSky but I dont see a good usecase for this historic data access in home assistant. In my opinion sensors in home assistant are all about current status of something. If you want to follow the development over time you can use the home assistant history:

towerhand commented 3 years ago

@brayStorm I'm using the Event Sensor custom integration (https://github.com/azogue/eventsensor) and these automations:

id: "flight_counter_increment" alias: Flight Counter Increment mode: queued initial_state: true trigger:
- platform: event event_type: opensky_entry action:
- service: counter.increment entity_id: counter.overhead_flights
id: "flight_counter_reset" alias: Flight Counter Reset initial_state: true trigger:
- platform: time at: "00:00:00" action:
- service: counter.reset entity_id: counter.overhead_flights

I have it set up to reset daily but you can tweak it as needed.

mariwing commented 3 years ago

Thank you for working on this and trying to take ownership! Since your PR was declined (which I think is a very strange and wrong descission. I totally understand that you don't want to rewrite an old component) - maybe you could publish this "version" on HACS instead?

tux2000 commented 3 years ago

Hej @mariwing. I can actually see the point with reducing the code complexity in the home assistant main repository. But i don't feel I have the time, energy and competence to set up a own project for an opensky API wrapper. So your suggestion to take the working code as it is over to HACS might actually be a better way to go. But even there I need to invest some time to understand how to set up things. So for now the code if available from my fork of the main repository but I would be happy for anybody taking the lead on making it more easily accessible to a wider audience.

frederickjh commented 3 years ago

@tux2000 Just a heads up. After upgrading to the security update releases (2021.1.3 or newer), your open sky in the `custom_components' directory is not working. Throwing errors like:

[homeassistant.components.sensor] opensky: Error on device update!

However other integrations are also having the same issue and more. I had one of my automations for a local switch with no cloud service fail with

[homeassistant.components.automation.heater_fan_on] Heater fan on: Error executing script. Unexpected error for call_service at pos 2: Cannot connect to host us-central1-hasskit-a81c7.cloudfunctions.net:443 ssl:default [Try again]

Reverting back to version 2021.1.2 and everything works.

mariwing commented 3 years ago

I am running 2021.1.4 and have no issues with neither the custom/forked opensky or any other integrations for that matter. I am not saying that your issue is not related to .4 but it apparently doesn't affect everyone.

frederickjh commented 3 years ago

@mariwing Are you a Nebacasa subscriber? I am not but I have to wonder if the domain my home assistant was trying to connect to was Nebacasa. The hasskit in the subdomain part makes me wonder that.

mariwing commented 3 years ago

Yes I am

tux2000 commented 3 years ago

@frederickjh thanks for the heads-up, and @mariwing for checking. In my setup with 2021.1.4 the current version from my repository is working. I am not using Nabucasa. But it might be good to see if others are running in the same problem. For now I will not do more changes on that component since it needs to refactored in one way or another to conform with home assistant main repo or HACS...

frederickjh commented 3 years ago

I just tried to update Home Assistant, in a Docker Container, and found that the DNS was not resolving, registry-1.docker.io . I use OpenDNS's DNS servers on my home network. I tried checking the DNS for that site in the OpenDNS cachechecker online. Everything looked normal. In the end I changed the DNS servers on the machine running Docker by adding the Google DNS servers above the DNS line for the home network. So before /etc/resolv.conf looked like this:

nameserver 127.0.0.53
options edns0
search local

After like this:

# Google DNS Servers if for some reason Open DNS is not working.
nameserver 8.8.8.8
nameserver 8.8.4.4

nameserver 127.0.0.53
options edns0
search local

With this change I was able to update the Home Assistant Docker container to version 2021.1.4 and I also noticed that all the sensors that were having a long time to reach an external host or were not reaching them, were now working. These were not working or not working all the time before changing this: Swiss Meteo, OpenSky, and USCIS. So I am now thinking my problem was a DNS resolution issue.

frederickjh commented 3 years ago

Note that the solution above means that DNS for devices on the local network will NOT be resolved as Google's DNS servers will consulted before the local DNS server on the LAN router.

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

mariwing commented 3 years ago

OpenSky still fails without applying the patch mentioned in this thread. The PR was declined since apparently it is more important to have a rewrite of the component than having a bug fix merged so we could have a working component shipped with Home Assistant.

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

home-assistant / core