Fibaro components

[pbalogh77]

Description:

Adds cover, light, sensor and switch support to the Fibaro component

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:

• 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.

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.

[amelchio]

Just a note, it is probably better to create individual PRs for each of the platforms. That way smaller parts can get approved and merged faster without a single person having to read, understand and approve all of it.

That said, I think you should keep this PR now as it is not huge and review has already started.

[pbalogh77]

Thanks Anders, I understand. My thining process was that it might be less work per PR for a reviewer, but overall, it'll take more effort to review it split into 4 PRs. I felt that at this total lines it might be more efficient to go in PR, knowing full well, that this might be discouraging some reviewers, but hoping to reduce the total effort needed. In the future I'll try to cut it into even smaller pieces.

[pbalogh77]

Ooops, clicked the wrong button when commenting :-( and I accidentally closed it...

[amelchio]

Looks mostly good.

The thresholds in the light platform seem strange and complicate things. Is there some hardware reason that these are needed?

[andre-richter]

Hi @pbalogh77,

I am using quite a lot of the Fibaro roller shutters and switches with HA, but I am still quite uneducated about HA source code.
Could you explain to me what your PR will change with regards to the status quo? I think I see blind tilt support. Also refactoring to some new HA code base?

Thanks a lot for your efforts!

Andre

[pbalogh77]

Hi @pbalogh77,

I am using quite a lot of the Fibaro roller shutters and switches with HA, but I am still quite uneducated about HA source code.
Could you explain to me what your PR will change with regards to the status quo? I think I see blind tilt support. Also refactoring to some new HA code base?

Thanks a lot for your efforts!

Andre

Hi Andre,

It adds support for Fibaro Home Center hubs, so instead of connecting the Z-wave devices to your HA with a Z-wave stick, you can now use the Fibaro hub and integrate that. The reason for this is that while HA is great, Fibaro HC2 is rock solid and has some features specific to it. I also believe that HA is best at integrating hubs, e.g. not taking over the responsibility of everything, just combining functionality on a higher level. Also, this way I can have the fibaro app as a fall-back if HA stops or crashes to still get into my home :-) In this way, I think HA can be used as a alternative UI for Fibaro hub users too.

Cheers,
Peter

[andre-richter]

Hi @pbalogh77,
I am using quite a lot of the Fibaro roller shutters and switches with HA, but I am still quite uneducated about HA source code.
Could you explain to me what your PR will change with regards to the status quo? I think I see blind tilt support. Also refactoring to some new HA code base?
Thanks a lot for your efforts!
Andre

Hi Andre,

It adds support for Fibaro Home Center hubs, so instead of connecting the Z-wave devices to your HA with a Z-wave stick, you can now use the Fibaro hub and integrate that. The reason for this is that while HA is great, Fibaro HC2 is rock solid and has some features specific to it. I also believe that HA is best at integrating hubs, e.g. not taking over the responsibility of everything, just combining functionality on a higher level. Also, this way I can have the fibaro app as a fall-back if HA stops or crashes to still get into my home :-) In this way, I think HA can be used as a alternative UI for Fibaro hub users too.

Cheers,
Peter

Ah, understand! I am using HA without the Fibaro home center so far, and it works quite well. I will keep this in mind though.

Thanks!

[amelchio]

Let's merge this (when the build passes) so the new Fibaro component is complete when it gets released. @pbalogh77 has promised in chat to add documentation soon.

[MartinHjelmare]

This could block threads in the thread pool. That's not allowed. A non blocking acquire could work. What are we trying to protect?

[pbalogh77]

The issue I'm trying to solve is that while we're still executing the turn_on command, another thread is receiving notifications from the fibaro hub and processing them, e.g. there can be calls to the update function. Which can mess up the data a bit and cause some havoc. This is especially troubling in the case of a turned off colored light, which has to issue two consecutive rest api calls to the fibaro hub, both of them resulting one or multiple status updates from the fibaro hub. Since neither function has infinite loops and only of them has actual IO, I don't see how it could lock up a thread permanently, but I'm very open to other ideas of solving this race condition.

[amelchio]

The race is real, I had the same issue with LIFX. I am not sure how to best solve it for a threaded platform. As is, I guess it could get ugly if the hub gets unavailable.

[balloob]

So this should become async_turn_on and Fibaro needs to maintain an async lock. We can't solve this on the Home Assistant level as we don't know exactly how the resources need to be treated that need locking (is it per device, per hub etc).

[amelchio]

I’ll do a judgement call and merge this so it makes the beta along with the remaining Fibaro news.

I am confident that @pbalogh77 is willing to address the concern that Martin raised in a separate PR, in time for the final release.

[balloob]

Good call 👍

[balloob]

I am stoked. I think that Fibaro has done a great job building a stable Z-Wave platform, with support for their hub, we will be accessible to a new group of people.

[northhacks]

will there be support for the thermostats in the near future?

[MartinHjelmare]

If you want to suggest an enhancement please open a feature request in the Feature Requests section of our community forum.

Merged PRs should not be used for enhancement discussion.

Thanks!