text:
Failed to check config(restart) from Lovelace UI due to missing stream support

Home Assistant release with the issue:
101.2

Last working Home Assistant release (if known):
101.1
Operating environment (Hass.io/Docker/Windows/etc.):
pyenv on Debian

Integration:

Description of problem:
Checking configuration from UI getting error: Component error: camera - Requirements for stream not found: ['av==6.1.2'].
Starting directly from environment works with no issues.
I'm not using streams (no configuration for stream in configuration.yaml). Using just still_image for camera setting!
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
camera:
 - platform: generic
   still_image_url: http://cam1/Streaming/channels/1/picture
   name: Cam1

Traceback (if applicable):

Additional information:

Hi, thanks for creating this issue, I'm 90% sure I'm getting the same issue as you. I am using the 'mjpeg' camera platform, but am getting the same looking error when I check my config. Here's the error message I'm getting:
INFO:homeassistant.util.package:Attempting install of av==6.1.2
ERROR:homeassistant.util.package:Unable to install package av==6.1.2: Failed building wheel for av Command "/srv/homeassistant/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-q0rc_ab4/av/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-micvu_bm/install-record.txt --single-version-externally-managed --compile --install-headers /srv/homeassistant/include/site/python3.7/av" failed with error code 1 in /tmp/pip-install-q0rc_ab4/av/
Failed config

Here's the YAML for my camera:
camera:
  - platform: mjpeg
    name: "Small Cam"
    still_image_url: http://192.168.1.132:8080/stream/snapshot.jpeg?delay_s=0
    mjpeg_url: http://192.168.1.132:8080/stream/video.mjpeg

For now, as a (bad) fix/workaround, I've taken the camera out of my config, as I need to be able to use the config checker.

I fixed it by building required ffmpeg from source.
But this does not mean we can close this issue, problem with config checker is there.

Just an FYI - This issue also is present when using the configuration checker under Windows when using a similar camera config as listed above.

I fixed it by building required ffmpeg from source.

Quite the workaround, I ended up adding using NodeRED to automate the config checker, and it removed my camera.yaml package before config check, and replaces it afterwards, and my camera is now working in HA again.
I just need to make sure I now have no YAML errors in my camera.yaml package as it is now no longer checked by the config checker.

I've done a little digging and I think it's this pull request that is causing this issue:
https://github.com/home-assistant/home-assistant/pull/28453
It was added in 0.101.2
I've managed to patch the camera component for 0.101.3 and config check now passes and my camera is working again.
No need to building build ffmpeg from source :)
I'll see if I can make a pull request in order to fix this bug/issue.

Can anyone with this issue help me out, did upgrading to 0.101.3 fix this issue for anyone?
Or are you still getting config check errors in 0.101.3? Thanks

just manually apply the fix; https://github.com/DeviousPenguin/home-assistant/commit/f6653bb3884fd7ee7f5fd692b41ed982be9740ee

It's still happening on 0.102.1

you try these? https://www.home-assistant.io/integrations/stream#troubleshooting
sudo apt-get install -y python-dev pkg-config libavformat-dev libavcodec-dev libavdevice-dev libavutil-dev libswscale-dev libavresample-dev libavfilter-dev

This is likely the same issue as this:    https://github.com/home-assistant/home-assistant/issues/26711#issuecomment-557830472

From our thread

cd /home/pi/
sudo apt-get install libomxil-bellagio-dev –y
git clone https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg
sudo ./configure --enable-gpl --enable-nonfree --enable-mmal --enable-omx --enable-omx-rpi --disable-static --enable-shared --disable-doc
sudo make -j4
sudo make install
sudo reboot

Not sure how to fix the error when running under Windows.

I can confirm that DeviousPenguin's fix works.  Hopefully there is a pull request for it and will make it in the next update.  In the meantime, you can manually make the update here:
https://github.com/DeviousPenguin/home-assistant/commit/f6653bb3884fd7ee7f5fd692b41ed982be9740ee

I can confirm that DeviousPenguin's fix works. Hopefully there is a pull request for it and will make it in the next update. In the meantime, you can manually make the update here:
DeviousPenguin@f6653bb

That nice to know if works for you on Windows, but I'm afraid my pull request was denied as my fix  breaks things for people using the streaming component:
https://github.com/home-assistant/home-assistant/pull/28610

Removing stream from after_dependencies fixes it for you, however breaks the camera integration for anyone who wants to use it with stream !

I'll look into seeing if a better fix is possible, I may have to add a 2nd camera component, each one with different dependencies, that way the fix may work for both people who are and are not using the streaming component.

authors: DeviousPenguin MarkHofmann11 jurgenweber ofalvai rds76 webtop


text:
Issues getting info from BME280 sensor with luftdaten integration

Home Assistant release with the issue:
0.103.5
Last working Home Assistant release (if known):
This is my first haas installation
Operating environment (Hass.io/Docker/Windows/etc.):
virtualenv on debian testing running as a systemd container
Integration:
https://www.home-assistant.io/integrations/luftdaten/
Description of problem:
Data from BME280 sensor is not pulled by haas.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
N/A

Traceback (if applicable):
Jan 02 18:06:42 haas hass[24603]: 2020-01-02 18:06:42 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform luftdaten
Jan 02 18:06:42 haas hass[24603]: Traceback (most recent call last):
Jan 02 18:06:42 haas hass[24603]:   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform
Jan 02 18:06:42 haas hass[24603]:     await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
Jan 02 18:06:42 haas hass[24603]:   File "/usr/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
Jan 02 18:06:42 haas hass[24603]:     return fut.result()
Jan 02 18:06:42 haas hass[24603]:   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/luftdaten/sensor.py", line 38, in async_setup_entry
Jan 02 18:06:42 haas hass[24603]:     name, icon, unit = SENSORS[sensor_type]
Jan 02 18:06:42 haas hass[24603]: KeyError: 'pressure_at_sealevel'

Additional information:

See comments of #27493
Fixed with #30317

Fixed by the above mentioned PR.

source: gharchive/issue

authors: ReneNulschDE skibbipl springstan

repo: home-assistant/home-assistant

license_type: permissive

license_source: github-api


text:
TP-Link HS200 switch not appearing after upgrade to 0.31.1

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
**Home Assistant release (hass --version):0.31.1
Python release (python3 --version): Python 3.4.2
Component/platform: tplink switch
Description of problem:  I have my tplink switch set up with a static ip and the following configuration.
switch:

platform: tplink
host: 192.168.4.90
name: Laundry Room Light

And after the upgrade to 0.31.1 it is not showing up in the interface and automation is no longer working.
Expected:
Problem-relevant configuration.yaml entries and steps to reproduce:

Traceback (if applicable):

Additional info:

Issue is with the pyHS100 package, I have opened an issue with them with a possible resolution.

Thank you @smaggard, would be great if you can link the issue

Moved to https://github.com/GadgetReactor/pyHS100/issues/4

I just did, also I have a branch ready for upload on the project in question, just waiting on approval from them.

On Oct 25, 2016, at 3:45 PM, Johann Kellerman notifications@github.com wrote:
Thank you @smaggard https://github.com/smaggard, would be great if you can link the issue
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/4045#issuecomment-256170464, or mute the thread https://github.com/notifications/unsubscribe-auth/AV_aD62lZAdnxp29DH0_bygRtj2RnG2Pks5q3mp5gaJpZM4KgMga.

This issue was resolved, please close it.

Actually, this is still not working.

It was pulled in during the last dependency upgrade, which was reverted because it had issues, sorry.

authors: kellerza linodavid mweinelt smaggard


text:
Scripts no longer working in 0.51 (and 0.51.1)

Home Assistant release (hass --version):
Home Assistant 0.51.1 on Hass.io (RPi 3)
Python release (python3 --version):
N/A
Component/platform:
script
Description of problem:

Scripts can no longer be triggered. The log says: Unable to find service script/turn_on or Unable to find service script/play_woop_woop
script domain is gone in Developer Tools > Services

Expected:
Everything (scripts, executing script via an automation's actions) should be working as in 0.50.
Problem-relevant configuration.yaml entries and steps to reproduce:
Example automation:
- alias: Test script
  id: test_script
  trigger:
    platform: state
    entity_id:
      - device_tracker.something
      - device_tracker.someone
    to: 'home'
  action:
    service: script.play_woop_woop

and also:
[...]
  action:
    service: script.turn_on
    entity_id: script.play_woop_woop

Additional info:
The error log is saying (since the upgrade):
2017-08-13 19:37:46 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.6/asyncio/tasks.py", line 181, in _step
    result = coro.throw(exc)
  File "/usr/lib/python3.6/site-packages/homeassistant/setup.py", line 61, in async_setup_component
    return (yield from task)
  File "/usr/lib/python3.6/asyncio/futures.py", line 331, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.6/asyncio/tasks.py", line 244, in _wakeup
    future.result()
  File "/usr/lib/python3.6/asyncio/futures.py", line 244, in result
    raise self._exception
  File "/usr/lib/python3.6/asyncio/tasks.py", line 179, in _step
    result = coro.send(None)
  File "/usr/lib/python3.6/site-packages/homeassistant/setup.py", line 160, in _async_setup_component
    conf_util.async_process_component_config(hass, config, domain)
  File "/usr/lib/python3.6/site-packages/homeassistant/config.py", line 571, in async_process_component_config
    config = component.CONFIG_SCHEMA(config)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 538, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 315, in validate_mapping
    cval = cvalue(key_path, value)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 538, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 315, in validate_mapping
    cval = cvalue(key_path, value)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 538, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 315, in validate_mapping
    cval = cvalue(key_path, value)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/voluptuous/validators.py", line 262, in __call__
    v = schema(v)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 575, in validate_sequence
    cval = validate(index_path, value)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/voluptuous/validators.py", line 224, in __call__
    return schema(v)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/voluptuous/validators.py", line 262, in __call__
    v = schema(v)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 221, in __call__
    return self._compiled([], data)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 538, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 315, in validate_mapping
    cval = cvalue(key_path, value)
  File "/usr/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
    return schema(data)
  File "/usr/lib/python3.6/site-packages/homeassistant/helpers/config_validation.py", line 222, in service
    if valid_entity_id(value):
  File "/usr/lib/python3.6/site-packages/homeassistant/core.py", line 65, in valid_entity_id
    return ENTITY_ID_PATTERN.match(entity_id) is not None
TypeError: expected string or bytes-like object

Oh, dang!! I just noticed a typo I made in my scripts.yaml (and the configuration check didn't detect it). Scripts are back. :+1:


text:
[SMALL PATCH] Sql sensor

Description:
Just reopening #12142 to address small fix

@dgomes make sure to use new branches for your PRs.

source: gharchive/pull-request

authors: balloob dgomes


text:
Broadlink

Description:
Change back to the pypi version of the library and to the latest version.
I have only tested this with one of the switches, and no sensors
Checklist:

[ ] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

Ok to merge when conflicts resolved.

MP1 support broken after this PR

authors: Danielhiversen balloob vicfergar


text:
_send_packet() improvement

Description
This enhancement allows you to specify the number of times a packet should be sent and the delay between one send and another. Useful for controlling TV volume.
Example entry for configuration.yaml:
script:
    enhanced_send_packet:
        sequence:
            - service: switch.broadlink_send_packet_192_168_0_100
              data:
                  packet: 'JgAaAB8bHxs8Gx8bHxseHB4cHjk6HR4cHhweAA0FAAAAAAAAAAAAAAAAAAA=='
                  repeat: 5
                  delay: 0.2

The above script will send the packet 5 times with a 0.2s delay between one send and another. I'm currently using this enhancement to control the volume of my TV with a slider.
This is my first pull request and I didn't have time to learn about the process of documentation yet, so I apologize for not providing one. Peace.

Hi @felipediel,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

This PR seems to have gone stale. Closing it.

authors: balloob felipediel homeassistant


text:
Upgrade boto3 to 1.9.16

Description: Update boto3 to 1.9.16
Related issue (if applicable): fixes #17094
Example entry for configuration.yaml (if applicable):
notify:
  - name: NOTIFIER_NAME
    platform: aws_sqs
    aws_access_key_id: AWS_ACCESS_KEY_ID
    aws_secret_access_key: AWS_SECRET_ACCESS_KEY
    region_name: 'us-east-1'

Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

Hi @guyk-yahoo,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

I signed the CLA for 5 times already... :(

Hi @guyk-yahoo,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

Still not working... stupid CLA... :/

Hi @guyk-yahoo,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

Your commit is attributed to @guyk-yahoo and you have commited as @GuyKh

@balloob
Just did it through @guyk-yahoo (other computer).
Still no go.

Yay!! It worked....

authors: GuyKh balloob guyk-yahoo homeassistant


text:
end snips dialogue

Description:
This change will explicitly end the snips dialogue, otherwise the session will be open till timed out. With this change snips will be able to start new dialogues faster after in a row.
snips reference: https://snips.gitbook.io/documentation/ressources/messages-reference#end-session
Related issue (if applicable): fixes #
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

@tschmidty69 can you weigh in on the implications of this PR.  Will it prevent multi-turn dialogs?

Sorry for the delay looking at this. The problem would be that you are ending the session even if HA is not handling the intent. For example I only have some of my intents handled by HA, the rest are handled by other programs listening for the mqtt that HA is not aware of. But I see what you are trying to do in that we are only sending the endSession if there is a plain text response. when we should end all session we are handling. I can see some bizarre cases where people are perhaps having two different things responding to an intent but there are other/better ways to do that (trigger additional actions from HA).

authors: djbulsink tschmidty69 uchagani


text:
Mock storage in sync tests

Description:
This is an attempt to mock storage in synchronous tests to see if this speeds up the test suite.

1 failed test so it didn't pass tests, but also didn't see any significant speed boost. Closing it.


text:
GeoNet NZ Volcanic Alert Level sensor

Breaking Change:

Description:
This is a new integration that fetches information about volcanos in New Zealand from a feed provided by GeoNet NZ.
A sensor is created for each volcano in the feed (and within the defined radius). The sensor state is the current volcanic alert level which is a value from 0-5. Each sensor has additional attributes such as the volcano's coordinates, distance to home, volcanic activity, hazards and the last update date.
The preferred way to set up this integration is through the UI where you can define the radius around the HA instance to include volcanos from.
I decided to create sensors instead of geolocation entities for this feed integration because the location of the volcanos does not change, and the most important information of each entity is not the distance, but the volcanic alert level.
Related issue (if applicable): n/a
Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#10464
Example entry for configuration.yaml (if applicable):
geonetnz_volcano:

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[x] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

Doco added

Just rebased to 0.101.0.dev0

Just rebased to 0.102.0.dev0 to resolve merge conflict

Just rebased again, and bumped the version of the integration library to make it compatible with Python 3.8.


text:
[device_tracker] Don't clear GPS coordinates when no GPS reported.

Description:
Take two? (#4851) (#4848)
If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass

gps_updated could use some formatting on the frontend. Shows up like this for me: 2016-12-11T18:21:32.164847+00:00

@sterling because that's the str representation of a datetime object, it's out of scope for this PR and I can't see it changing anytime soon.

Can someone explain to me what we are trying to achieve here? I see https://github.com/home-assistant/home-assistant/issues/4841 but I also know that's by design 👍  A router sees a device at home, so it marks the device as at home. The UI does not show devices that are home so even adding gps coordinates is not going to help.
Router trackers work differently than trackers that push their state to Home Assistant (ie GPSLogger). When a router tracks a device, it is based on seen events and when a device has not been seen for X time (configurable) it will be marked as not_home. You know what disables that check? If a device is managed by a tracker that pushes state. (and thus uses gps/location_name)
So by faking that the router is adding gps coordinates, you're actually breaking a lot of stuff. I also don't like the whole merging states, it's dirty. The router detecting a device is given way more accuracy to the state then any previously reported GPS coordinates would, this is because most GPS reporting apps are based on geofencing, which only triggers every 500 meters or so.
So if we want to keep GPS coordinates on a device, the router should add the home coordinates and no gps_accuracy (as we have none). However, the stale check should also be updated to work with gps coordinates being always set.

Background; The intention for the PR is to keep coordinates around for things like the Google Maps camera recipe. Currently when the tile is visible it will point to the middle of nowhere when home due to the fact that the router is wiping the GPS coordinates.
Could you explain what you mean by 'merging of states' ?

With merging I mean that we are going to attach the GPS coordinates from a previous report by the GPS logger to a new report by the AsusWRT router.
We know the location of the AsusWRT router so if we want to attach GPS coordinates, we should attach the home coordinates for highest accuracy.

I see what you mean, I perceived it as a state update - but I understand what you mean by you end up with stale attributes after an update.
As mentioned previously, what would be the best way to track if the device is stale when we're attaching coordinates?

I think we should add another instance variable to keep track if the GPS coordinates were auto filled in because the user was home.
(note that a device tracker that pushes states like owntracks can actually set our state to 'home' so we cannot not use that as an indicator)

@balloob I think we got it working with the gps_updated attribute, but so like the idea of filling the home coords more, then we know it is correct.
Maybe we should kill gps_updated completely and rather create an attribute check_stale that we set when we auto fill coords, since even with filled gps attributes, we need to consider stale for these types of trackers. Coords should also only be auto-filled when location is None.
Another way is to set accuracy to 'home' or 100% when auto filled, bit might cause automation issues if we deviate from a value (meters currently if I'm not mistaken)

Yes we should not mess with the type. Another instance variable can work or
use a source_type. So if it a router, we know to check for stale
On Mon, Dec 12, 2016, 05:18 Johann Kellerman notifications@github.com
wrote:

@balloob https://github.com/balloob I think we got it working with the
gps_updated attribute, but so like the idea of filling the home coords
more, then we know it is correct.
Maybe we should kill gps_updated completely and rather create an
attribute check_stale that we set when we auto fill coords, since even
with filled gps attributes, we need to consider stale for these types of
trackers. Coords should also only be auto-filled when location is None.
Another way is to set accuracy to 'home' or 100% when auto filled, bit
might cause automation issues if we deviate from a value (meters currently
if I'm not mistaken)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/4852#issuecomment-266428730,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYJ2uZenon8iBWNwXl0HxXCBfAssy2qks5rHUmNgaJpZM4LJ-3u
.

👍 Lets go for source_type which we can set to: GPS, Router or Location, according to the see params passed in. This will also display nicely as an attribute in the frontend

How would gps and location be different?
Routers can easily be updated to pass in home GPS and source_type here. We can default to source_type=gps for other calls ?

That sounds good, seems simple to add it as a param to async_see.
The only reason I mentioned "Location" was this but must honestly say I havent worked with a tracker that passes in location, maybe router and gps is enough

Don't forget to include some tests.

@kellerza think I got all your comments, I'm having a bit of trouble structuring this test :( I'm not sure if my failures are related to incorrect test structure or my changes to device_tracker.

@lwis you have 3 failures and only introduced 1 new test.
Almost seems that the test data (probably known_devices) are not cleaned up properly - since you have 2 test's data in this failure.
Another approach could be to first return from your new test (so its always successful) and then make the existing one's work. If the remaining 2 are clean its definitely not cleaning up properly.

Happy days @lwis, it passes! Only minor style comments in the tests

Hi! Sorry to post in a closed PR, but are there any plans to add more source_types? I just activated bluetooth tracking yesterday and I was really surprised to see the detected devices show up with source_type 'gps'. I could write a PR for that if it's ok?

authors: balloob kellerza lwis richrd sterling


text:
refactor(project): use husky

What does this PR do?
It adds husky in order to manage the repository hooks installation and execution.
The PR also:

Renames the hooks files.
Removes the installation script.
Checks if yarn is installed before calling it from the hooks; if is not present, it will use npm.

How should it be tested manually?
Before installing the branch, remove the old hooks:
rm ./.git/hooks/pre-commit && ./.git/hooks/post-merge

Then install the branch (dependencies) and test the hooks:
# It should call the 'lint' and 'test' scripts
./.git/hooks/pre-commit
# It should try to install dependencies
./.git/hooks/post-merge

Pull Request Test Coverage Report for Build 146

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 144:
0.0%

Covered Lines:
355

Relevant Lines:
355

💛  - Coveralls

Pull Request Test Coverage Report for Build 146

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 144:
0.0%

Covered Lines:
355

Relevant Lines:
355

💛  - Coveralls

license: MIT