Yoda-x/ha-zha-new

Any plans to submit changes from ha-zha-new and zigpy fork to upstream ZHA and zigpy?

Opened this issue · 10 comments

Hedda commented

@Yoda-x I was wondering if your long-term plan on maintaining your ha-zha-new / zha_new custom component as well as zigpy and bellows forks as completely separate projects from the official ZHA integration component in Home Assistant Core plus upstream zigpy and bellows projects or if you have plans to update/port and try to submit some or all of your code improvements/enhancements that are still relative to the upstream main branch of those projects for mainlining?

Also recommend to check out these related projects:

network map => https://github.com/zha-ng/zha-map
RSSI/LQI information => https://github.com/dmulcahey/zha-network-card
digraph visualization => https://github.com/dmulcahey/zha-network-visualization-card
zha-device-exporter => https://github.com/dmulcahey/zha-device-exporter

All those upstream projects have matured a lot over the last year or so and therefore I was personally really curious why the forks and why custom components? Why are not everyone today working towards mainlining this upstream in order to try improving those projects in the upstream main branches instead? That is, submit smaller patches for individual features, functions and or discussing larger refactoring ideas with the main developers of upstream ZHA and zigpy which I believe today are only @Adminiuga & @dmulcahey or?

@estevez-dev & @h3ndrik & @mikeybeck & @jamesyuip & @KLUSEK Was hoping that I could start a respectful open discussion about "reason why the ha-zha-new fork?" questions among all who contributed to Yoda-x's ha-zha-new project along with the upstream developers?

estevez-dev commented

I'm moved away from ha-zha-new to a default zha component as now it satisfies all my needs and support all my devices.

Hedda commented

Me too, but all improvements and enhancements in ha-zha-new and related forked dependencies has still not yet been back-ported and submitted as pull requests to the upstream ZHA in Home Assistant Core, zigpy/zigpy, zigpy/bellows, dmulcahey/zha-device-handlers, etc. which are now default for most ZHA and zigpy users, or have they?

My point is that every user of the default ZHA and zigpy should benefit if this all improvements and enhancements that are still relative was upstreamed, or at least tried to be upstreamed by @Yoda-x

  • 👍1
Yoda-x commented

Hi, sorry about the delayed answer.
What features are you missing?
My and the mainline version moved away over the time, so it would need some effort to port it.

  • 👍1
  • ❤️1
  • 🚀1
Hedda commented

Sorry I don't specifically know, I have't really used ha-zha-new myself, someone hinted at quirks here:

https://community.home-assistant.io/t/xiaomi-motion-sensor-with-zha-vs-zha-new/181215/5

Some other things I don't know but might are be upstream in mainline ZHA, zigpy & quirks yet are:

  • initial lightlink support to read out group id from remotes and controllers ?
  • additional device types for lights ?
  • add RSSI/LQI information in entity attributes ?
  • network map ?
    • digraph / zigbee2dot.py

@Yoda-x Any plans to continue developling on upstream ZHA, zigpy & quirks now it's active again?

Hedda commented

Also check out these related projected:

network map => https://github.com/zha-ng/zha-map
RSSI/LQI information => https://github.com/dmulcahey/zha-network-card
digraph visualization => https://github.com/dmulcahey/zha-network-visualization-card
zha-device-exporter => https://github.com/dmulcahey/zha-device-exporter

Adminiuga commented
  • initial lightlink support to read out group id from remotes and controllers ?

That's already in there, that's how ikea five button remotes work

  • additional device types for lights ?

What types are missing?

  • add RSSI/LQI information in entity attributes ?

This not gonna fly with HA Core, but there's https://github.com/dmulcahey/zha-network-card

  • network map ?digraph / zigbee2dot.py

Maybe at some point. There's zha-map and corresponding UI card, but ATM I don't feel the ROI worth the effort.

ahmadtawakol commented

Hi, sorry about the delayed answer.
What features are you missing?
My and the mainline version moved away over the time, so it would need some effort to port it.

My only problem with ZHA is how it handles the Aqara motion sensor’s timeout. Your implementation does it much better and gives me much more flexibility over my automations. This is something that I really want to see ported to ZHA.

ahmadtawakol commented

@Hedda So if I replace the sensor file in ZHA with the sensor file from Yoda-x then it will work?

Hedda commented

Sorry but I'm not sure what the Aqara motion sensor timeout issue is so I was just asking as a question.

Deviations can be handled via ZHA Device Handlers, but not sure if such sensor timeout is a deviation.

Suggest you open a new issue for discussion => https://github.com/zigpy/zha-device-handlers/issues