Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added component named switcher_kis switcher water heater integration. #22325

Merged

Conversation

@TomerFi
Copy link
Contributor

commented Mar 23, 2019

Description:

Integration for controlling the Switcher Water Heater device (https://www.switcher.co.il/).

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#8480

Example entry for configuration.yaml (if applicable):

# Mandatory only configuration:
switcher_kis:
  phone_id: 'xxxx'
  device_id: 'xxxxxx'
  device_password: 'xxxxxxxx'

# Full configuration:
switcher_kis:
  phone_id: 'xxxx'
  device_id: 'xxxxxx'
  device_password: 'xxxxxxxx'
  name: 'my_boiler'
  include_schedule_sensors: true
  schedules_scan_interval:
    minutes: 5

# Defaults:
# name = 'boiler'
# include_sensors = false
# schedules_scan_interval = {'mintues': 5}

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • 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.

@ghost ghost added the in progress label Mar 23, 2019

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 23, 2019

This PR is replacing the previous PR #20830

@awarecan

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

@tsvi

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

I tried using it as a custom component and it fails as follows:

2019-03-26 01:48:42 ERROR (MainThread) [custom_components.switcher_kis] failed to get queue
Traceback (most recent call last):
  File "/config/custom_components/switcher_kis/__init__.py", line 225, in async_setup
    v2bridge.queue.get(), timeout=5.0, loop=hass.loop)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
@tsvi

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

@awarecan Technically it should fit the water heater component, but it has no input or info about the temperature. The only difference between this and a regular switch is the fact that it abides by Israeli electrical regulations that water heaters must disconnect both phase and neutral for safety reasons.

Besides that it's a regular wifi switch (think tasmoto) which has some scheduling component.

@tsvi

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

It could maybe used as part of a template water heater if a water temperature sensor is added. Like the template climate component.

@Kane610
Copy link
Contributor

left a comment

This is way to big for an initial PR, strip it down to just the basic sensor please

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

This is way to big for an initial PR, strip it down to just the basic sensor please

@Kane610 As I stated earlier, This PR is replacing the previous PR #20830 .
I'm sorry, but I think @andrewsayre should review this PR, as he is already familiar with this component and the new PR was actually opened by his suggestion.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

Why not use water_heater entity component?

@awarecan Although the Switcher device is meant to control a water heater,
It has none of the properties, states or services of the "normal water heater".
It's basically just a switch with the ability to set schedules and time limits.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

I tried using it as a custom component and it fails as follows:

@tsvi What version of HA are you trying this on?

I've been running it constantly as a regular component from the time I was done writing it on my development environment.
I'm running version 0.91.0.dev0.

@tsvi

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

I tried using it as a custom component and it fails as follows:

@tsvi What version of HA are you trying this on?

I've been running it constantly as a regular component from the time I was done writing it on my development environment.
I'm running version 0.91.0.dev0.

0.90.1

By the way the old version does work, maybe not written correctly, but it does work.

@Kane610

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

@TomerFi breaking this down will simplify review and getting it finished. It is a good practice to follow.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

@tsvi
That means the component isn't getting the udp packet from your device within 5 seconds. The device sends the packet every 4 seconds.
Either the supplied device information is wrong and the component can't identify the device sending the message. I remember seeing somewhere that some people add to run the script that fetches the information from the device a couple of times just to get the phone_id correct.
If that's not the case, then maybe there's something in the network preventing the message from arriving. Maybe a different segment, or something else is listening on the same port (maybe you have both component versions running simultaneously? )

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

@TomerFi breaking this down will simplify review and getting it finished. It is a good practice to follow.

@Kane610 You are definitely right, that is a very good practice.

But in this case, if you can please have a look at the previous PR #20830 ,
You'll see there has been a lot of work, time and effort put into this component from both me, as the author, and @andrewsayre as the reviewer who went through every single line of code, and as you said, that's a big component.
I think stripping it down at this stage is redundant.

@andrewsayre

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

@TomerFi I think what you're finding is that our community members want this broken down so they can help review it. This is in the development check-list, afterall. I don't think any time was wasted by the previous review or work performed as it was an incremental move forward. A more thorough review was not performed due to the size of the original PR. I still think it should be broken down. The suggesting of opening a new PR was because the code changed significantly and we wanted to clear the clutter of the previous comments--not that the size was OK.

Keep in mind that our reviewers are all volunteers... I won't have a solid 2-3-hour block to go through this PR until this weekend, and there's no guarantee I'll get to it. If you're willing to wait until I, or someone else, has that kind of time, then keep the PR as it is. Otherwise if you can break it down, you'll open more doors for people who have smaller chuncks of time to review. :)

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

@andrewsayre
I understand, as I always say, I really appreciate yours and everyone else's hard work as well.
I know it's a volunteering job, I'm volunteering here too, we are all in the same boat here...

I didn't try to rush you or anything, I just did as you asked, you specifically wrote that when I'll open the new PR you'll assigned yourself as a reviewer.
So I opened the new PR and that's it, I haven't even approached you in any way since, and I wasn't planning to.
The only reason I tagged you and got you involved in the conversation is because @Kane610 was assigned as a reviewer and I've noticed that you haven't yet. I wasn't aware rather or not you started any reviewing or not.

@andrewsayre @Kane610
I appreciate all of your hard work, I really do.
Although, I have to say, it doesn't quite feel mutual and I'm starting to think this project isn't going to see the finish line.

First of all, I don't think this component is as big a you say it is, but I am the one who wrote its so I'm biased hehe. ;-)

@andrewsayre I think, since you already know this component and reviewed it when it was a bigger, you'll find it better, smaller and more well-written then before.

Second of all, as I stated in the previous PR, this component has been a long time in the making, it has a two working custom components ancestors in use by everyone who wants to integrate HA with Switcher.

I've been neglecting the previous versions and focusing all of my efforts on this component as a better and more reliable solution for a long time.
Trimming it down to a switch or a sensor means it will have less capabilities then the previous custom components and I can't actually expect anyone to use it, so I guess it will become redundant.

Now I feel like I'm doing all I can here to make this project of mine end, and this components launched, but maybe I'm just wasting my time and it's not going to happen.

Please tell me if you're not going to review it (on your own schedule, I've never rushed you or anything) and you think this PR is too big...
I'll simply close this PR, store this project away and maybe I'll revisit it in the future (although I'm not feeling very motivated right now).

I can't say I'll be happy with this decision, I have put a lot of work, time and effort into this project and it does not feels good having to kill it because it's "too big".

But... I'll live, it's okay.
I really appreciate your hard work anyway and I hope we'll get to collaborate on future projects.

If you see my point, and willing to respect my hard work as much as I respect yours, please review it on your own schedule, I'm here if you need me, but there is no rush from my side what so ever.

BTW @andrewsayre , you said the suggestion to open a new PR purpose was in order to:

clear the clutter of the previous comments

In this pace of the conversation, we might have to do it again... ;-)

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

BTW
To trim the component down to a switch...
All we need to do is actually comment out lines 255-266 in __init__.py and totally ignore the sensor.py file, and that's it, the component is "just a switch".
The two platforms work almost independently, the sensor platform just needs the ip address retrieved by the switch platform, other then that, they don't even know about each other.

Trimming down the component to "just a sensor" will require redundant changes to the configuration schema because I'll need to get the ip address from the user, which means that when we eventually integrate the switch platform it will be a breaking change.

My point is, if this component is too big for one reviewer, instead of trimming it and deleting a lot of the work I've already done (twice)...
Maybe just split it between two reviewers:
One can ignore lines 255-266 in __init__.py and totally ignore the sensor.py file,
The other one can focus on those lines and the sensor.py file and presume we have the ip address.

It's of course just a suggestion, I hope I haven't offended anyone, that wasn't my intention at all.
But I think if you look at this component as two separate platforms, you'll see it isn't as big as it seems.

I know that if we can work together, you guys will review it and on the other end I'll be here providing all the required information and working through all of your change requests...
I know that if were able to do this together, this PR will be done with shortly.

@rohankapoorcom
Copy link
Member

left a comment

I haven't had time to do a full review, but here's what I have after a first pass off the switch and init.

homeassistant/components/switcher_kis/__init__.py Outdated Show resolved Hide resolved
homeassistant/components/switcher_kis/__init__.py Outdated Show resolved Hide resolved
homeassistant/components/switcher_kis/__init__.py Outdated Show resolved Hide resolved
homeassistant/components/switcher_kis/__init__.py Outdated Show resolved Hide resolved
homeassistant/components/switcher_kis/services.yaml Outdated Show resolved Hide resolved
homeassistant/components/switcher_kis/switch.py Outdated Show resolved Hide resolved
@Kane610

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2019

For the context of PR size and coverage I'd like to paste this quote here:

You can argue that it is not black and white but a multi-hundred line PR is probably not the place to do it. Working on the code for days makes you know it well so you think that it is not as complex as it really is.

Sure it takes work but there is big value in reworking code changes into smaller steps. You will find and fix issues (not just bugs) to make the result easier to review. This saves review time and improves the code.

Smaller PRs can be reviewed by different people so that will also speed up things, even if there is some overlap. Furthermore, keeping it small helps with fatigue so reviewers will catch more things.

If Andrew is already in it and accepts the task that's fine. I am ramping up my review effort with home assistant, but that is not all I want to spend an evening doing. The work needs a reasonable size and in this case is just too much.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 31, 2019

@rohankapoorcom
Thank you very much for your review, I appreciate you taking the time to do so.
I'll go over all the change requests as soon as I can.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 31, 2019

@Kane610
I'm not sure where is this quote from, but I totally understand and agree with it.
I just want to emphasize one part of it:

it is not black and white

That was my point to begin with.
Although, reading back, I might have failed making it and I'm sorry about that.

Both you and Andrew are right, not only is trimming the component down is the best practice, but it's also per the development guidelines and checklists.

But... it's not all black and white.

In this case, removing the switch platform will make any future update a breaking change and I don't think removing the sensor platform will make the component that much smaller.
The sensor platform is quite small and the "complex" part is actually the component itself and switch platform because of its push behavior.

Nevertheless, if deleting the sensor platform is the "deal breaker" for either yours or Andrew's review, I would be happy deleting it and reinserting it in a later push or pr, but again... I'm not sure that's the right move here, but I will do it if needed to.

But that's besides the point, I totally understand you not having the time to review the component.
I'm aware that reviewing takes time and we're all volunteering and can't always spare the time.
I really appreciate your initial review and help.
Thank you.

@Kane610

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

I don't see why breaking it up would yield a breaking change. I've contributed additions and rewrites to the deconz component for over a year without any breaking change. And since this is the initial PR, you can definitely design to avoid that situation.

You should really look from the other side of things than what you can remove to get this accepted; what is the smallest integration you can do that will provide some benefit for the owners of switcher_kis devices starting to use your component.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2019

@Kane610
I appreciate your input, and I agree with you,
I can trim down a platform to make the component get accepted.
And as you said, I can design it in a way that would make the re-integration of the trimmed down platform smooth and easy.
That's actually what I suggested to do in my previous comment.

If you can please spare a couple of minutes, I would like to go over the component's flow, maybe we can understand each other better afterwards.

  • The component collects the following inputs from the user's configuration:

    • phone_id (Mandatory String for identifying and communicating with the device).
    • device_id (Mandatory String for identifying and communicating with the device).
    • device_password (Mandatory String for identifying and communicating with the device).
    • name (Optional String name of the device, default value is boiler).
    • include_schedule_sensors (Optional Boolean indicting whether or not the component should create the schedule sensors, default value is false).
    • schedules_scan_interval (Optional Timedelta for updating the schedule sensors, default value is 5 minutes, not relevant if include_schedule_sensors is false.
  • The component then takes the phone_id, device_id and device_password and creates a local udp connection to to the device.

  • The device will push its details and current state to the component (the details includes the ip address of the device):

    • When the initial message is received from the device, the component will call the switch platform for the creation of the switch entity, and when it is discovered successfully, the component will registers the following services:
      • turn_on_15_minutes: for turning on the device with the designated timer of 15 minutes.
      • turn_on_30_minutes: for turning on the device with the designated timer of 30 minutes.
      • turn_on_45_minutes: for turning on the device with the designated timer of 45 minutes.
      • turn_on_60_minutes: for turning on the device with the designated timer of 1 hour.
      • set_auto_off: for configuring the device's on state time limit.
      • update_device_name: for configuring the device's name.
    • For the next messages received from the device, the component will update the already created switch entity. That of course makes the switch entity's iot class Local Push.

My suggestion was to stop here and trim the rest for the acceptance of the component, the reasons for my suggestion will be provided later in this comment.

  • The component then evaluates the value of the include_schedule_sensors configuration value, if its set to false (as its default), the component is done. If its value is set to true:
    • The component then sends a tcp request for getting the schedules data from the device using the mandatory phone_id, device_id and device_password configuration values, combined with the retrieved ip address.
    • When (and if) successful, the component will create the sensor platform with the retrieved schedules data (and the configuration values combined with the ip address), the sensor platform will then:
      • Create 8 sensor entities representing the 8 schedule slots on the device.
      • Set interval retrieval of the schedules data from the device with the async_track_time_interval tool and the schedules_scan_interval configuration value (with default value of 5 minutes). That of course makes the sensors platform's iot class Local Pull.
      • Registers the following services:
        • create_schedule: for configuring an unused schedule slot.
        • delete_schedule: for deleting an existing configured schedule slot.
        • disable_schedule: for disabling an existing enabled configured schedule slot.
        • enable_schedule: for enabling an existing disabled configured schedule slot.
        • update_schedules: for manually retrieving the schedules data from the device (when the user doesn't want to wait for the interval update).

I would like to emphasize a couple of points, that were the reasons for me suggesting to trim the sensor platform and not the switch platform as you suggested:

  • The switch platform is being pushed with updates by the component itself which handles the device connection, I didn't see any point of writing the same code for both the component and switch platform, and seeing that the initial message being successful is a mandatory phase for the creation of the switch entity, I decided to keep the connection management at the component's level.
    On the other end, the sensor platform pulls its own updates in a more loose nature, therefor it handles its own connection.
    Which means the trimming down the switch platform will require a lot of code modification for re-integrating it in a later time which will make the next PR more error prone, but trimming down the sensor platform will require only some code modifications, which is always the preferred path.

  • The pulling of the sensor platform data is basically sending a tcp message and analyzing the response, the thing is, the process needs the ip address of the device which is retrieved with the initial pull of data for the creation of the switch entity.
    Which means that trimming down the switch platform will require modification to the configuration schema because we now need the user to supply the device's ip address.
    The user will have to set a static ip for device (assuming he knows how to do that) and supply it as a new mandatory configuration value, this will no longer be necessary after re-integrating the switch platform and will break the component, I remember reading that extra not familiar values are not allowed in configuration yaml of HA (please correct me if I'm mistaken), If I'm right, re-integrating the switch platform which means canceling the new mandatory configuration value (ip_address) will be a Breaking Change.
    On the other end, trimming down the sensor platform basically means, deleting the already optional configuration values (include_schedule_sensors, schedules_scan_interval), deleting the last part of the component (the part that calls for the sensor platform) and getting rid of the sensor.py file. Maybe delete a couple of unneeded constants, but nothing to big. Re-integrating the the sensor platform after trimming it down will have no effect on the already running component.

  • My third reason for suggesting the trimming of the sensor platform and not the switch platform is actually less technical the the previous two, this is actually just my point of view, and in no way a "deal breaker" of any sort...
    The thing is, the device we're talking about is a water heater, the basic functionality we need to provide our users is the ability to turn on or off the device, everything else, including the schedule control (the sensor platform) is as very nice-to-have functionality, but the bottom line it's just nice-to-have.
    Creating a component for integrating the with water heater but only allowing the integration of the schedules and not the state, doesn't feels right, even if it's for a limited time only.

As I see it, trimming down the switch platform, actually means creating a very different component and eventually overriding it with this one.
I hope we can see eye-to-eye on this one and either keep the component as-is or trim down the sensor platform only.

Thank you for your time,
I'm looking forward for your response.

@Kane610

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2019

Great to see that we are coming to an understanding here.

I don't think I specifically said to remove switch. Regardless of that the goal here is to simplify the PR so whichever you seem better to start with is good 👍🏻. The services should be kept out as well. See it like this; adding extra PRs after the initial one will go a lot quicker to integrate. So a real minimum viable product and build from there. Both Andrew and tsvi seems to be on top of this as well and they're both experienced with the integration process so with their support this should go well.

@TomerFi TomerFi force-pushed the TomerFi:switcher-boiler-integration-new branch from e29f515 to c18e742 Apr 13, 2019

mypy.ini Outdated Show resolved Hide resolved
@andrewsayre
Copy link
Member

left a comment

We made it!! Yeah! Can be merged after the reversion of mypi.ini, updating the PR example config, and build passes.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 14, 2019

@andrewsayre

We made it!! Yeah! Can be merged after the reversion of mypi.ini, updating the PR example config, and build passes.

I can honestly say I'm excited!
:-)

@Kane610

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

Great work!

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2019

@Kane610

Great work!

That has a lot to do with you guys reviewing and helping me out.
Especially @andrewsayre that has been very patient with me for more then two month now.

Thank you all, I really appreciate all of your help!
:-)

@tsvi

tsvi approved these changes Apr 15, 2019

@rohankapoorcom
Copy link
Member

left a comment

Great work! Thanks for working with us through the PR process.

@TomerFi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2019

Great work! Thanks for working with us through the PR process.

@rohankapoorcom
Thank you and everyone else for all the help provided through this process.
:-)

@andrewsayre
Copy link
Member

left a comment

One more thing to fix in the new commits. Tip: Don't continue making changes after the PR is approved unless asked in the approval. This kept the PR open longer (and missed the 0.92 beta cut) and the items changed could have gone in a new PR as it didn't affect functionality.

@codecov

This comment has been minimized.

Copy link

commented Apr 19, 2019

Codecov Report

Merging #22325 into dev will decrease coverage by <.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev   #22325      +/-   ##
==========================================
- Coverage   93.95%   93.95%   -0.01%     
==========================================
  Files         452      452              
  Lines       36845    36845              
==========================================
- Hits        34617    34616       -1     
- Misses       2228     2229       +1
Impacted Files Coverage Δ
homeassistant/components/uk_transport/sensor.py 93.43% <0%> (-0.73%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0a0975b...e26245e. Read the comment docs.

@andrewsayre andrewsayre merged commit 9d8d8af into home-assistant:dev Apr 19, 2019

13 checks passed

build Workflow: build
Details
ci/circleci: pre-install-all-requirements Your tests passed on CircleCI!
Details
ci/circleci: pre-test 3.5.5 Your tests passed on CircleCI!
Details
ci/circleci: pre-test 3.6 Your tests passed on CircleCI!
Details
ci/circleci: pre-test 3.7 Your tests passed on CircleCI!
Details
ci/circleci: pylint Your tests passed on CircleCI!
Details
ci/circleci: static-check Your tests passed on CircleCI!
Details
ci/circleci: test 3.5.5 Your tests passed on CircleCI!
Details
ci/circleci: test 3.6 Your tests passed on CircleCI!
Details
ci/circleci: test 3.7 Your tests passed on CircleCI!
Details
cla-bot Everyone involved has signed the CLA
codecov/patch Coverage not affected when comparing 0a0975b...e26245e
Details
codecov/project 93.95% (target 90%)
Details
"""On homeassistant stop, gracefully stop the bridge if running."""
await v2bridge.stop()

hass.async_add_job(hass.bus.async_listen_once(

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Apr 19, 2019

Member

We shouldn't use hass.async_add_job anymore. It's legacy.

Why do we need to add a job for this at all?

This comment has been minimized.

Copy link
@TomerFi

TomerFi Apr 26, 2019

Author Contributor

@MartinHjelmare
Much appreciated!
I addressed this and the other issues you referenced in a new PR I'm currently working on.
I'll notify you once I'll create the new pull request.

Thank you very much.
:-)

This comment has been minimized.

Copy link
@TomerFi

TomerFi Apr 27, 2019

Author Contributor

The new PR is here.
Besides resolving all the change requests from this PR, it also adds a couple of services and update the requirement version.
:-)

}

hass.async_create_task(async_load_platform(
hass, SWITCH_DOMAIN, DOMAIN, None, config))

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Apr 19, 2019

Member

Pass en emtpy dict as discovery_info, ie fourth argument.

async_add_entities: Callable,
discovery_info: Dict) -> None:
"""Set up the switcher platform for the switch component."""
assert DOMAIN in hass.data

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Apr 19, 2019

Member

Instead check if discovery_info is None and return if so.

device_data = await wait_for(
v2bridge.queue.get(), timeout=5.0, loop=hass.loop)
except (Asyncio_TimeoutError, RuntimeError):
_LOGGER.exception("failed to get response from device")

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Apr 19, 2019

Member

We start logging messages with capital letter.

mxworm added a commit to mxworm/home-assistant that referenced this pull request Apr 21, 2019

Merge branch 'dev' into current
* dev:
  Upgrade pyotp to 2.2.7 (home-assistant#23274)
  Upgrade xmltodict to 0.12.0 (home-assistant#23277)
  Add ctags file to .gitignore (home-assistant#23279)
  Bump zigpy and zigpy-xbee (home-assistant#23275)
  Bump zigpy-deconz (home-assistant#23270)
  Update pyheos and log service errors in HEOS integration (home-assistant#23222)
  Updated frontend to 20190419.0
  Return 0 instead of None (home-assistant#23261)
  Drop unnecessary block_till_done (home-assistant#23256)
  Drop unnecessary block_till_done, improve tests for MQTT Cover tests (home-assistant#23255)
  Drop unnecessary block_till_done for MQTT tests (home-assistant#23254)
  Drop unnecessary block_till_done for MQTT fan tests (home-assistant#23253)
  Added component named switcher_kis switcher water heater integration. (home-assistant#22325)
  Add missing services.yaml file for hue (home-assistant#23217)
  Drop unnecessary block_till_done, improve tests (home-assistant#23252)
  Drop unnecessary block_till_done (home-assistant#23251)
  Ask users for a pin when interacting with locks/garage doors (home-assistant#23223)
  Drop unnecessary block_till_done (home-assistant#23250)
  Drop unnecessary block_till_done, improve tests (home-assistant#23249)
  Drop unnecessary block_till_done, improve tests (home-assistant#23248)
@TomerFi TomerFi referenced this pull request Apr 27, 2019
7 of 9 tasks complete
@balloob balloob referenced this pull request May 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.