ha-zha-new icon indicating copy to clipboard operation
ha-zha-new copied to clipboard

Published 20 hours ago • verified publisher icon Yoda-x

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

Open Hedda opened this issue 4 years ago • 10 comments

@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?

  • Custom to core = https://github.com/Yoda-x/ha-zha-new => https://github.com/home-assistant/core
  • Quirks = https://github.com/Yoda-x/ha-zha-new => https://github.com/zigpy/zha-device-handlers
  • zigpy = https://github.com/Yoda-x/zigpy => https://github.com/zigpy/zigpy
  • bellows = https://github.com/Yoda-x/bellows => https://github.com/zigpy/bellows

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?

Hedda avatar Mar 10 '20 13:03 Hedda

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.

estevez-dev avatar Mar 12 '20 08:03 estevez-dev

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

Hedda avatar Mar 12 '20 12:03 Hedda

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.

Yoda-x avatar Apr 22 '20 14:04 Yoda-x

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 avatar Apr 22 '20 18:04 Hedda

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

Hedda avatar Apr 23 '20 09:04 Hedda

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

Adminiuga avatar Apr 23 '20 14:04 Adminiuga

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 avatar May 23 '20 07:05 ahmadtawakol

@ahmadtawakol Can device quirks like those not be handled via ZHA Device Handlers?

  • https://github.com/Yoda-x/ha-zha-new/tree/master/custom_components/device

to

  • https://github.com/zigpy/zha-device-handlers
    • https://github.com/zigpy/zha-device-handlers/tree/dev/zhaquirks/xiaomi/aqara

"lumi.sensor_motion.aq2" ?

Hedda avatar May 25 '20 09:05 Hedda

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

ahmadtawakol avatar May 25 '20 16:05 ahmadtawakol

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

Hedda avatar May 26 '20 11:05 Hedda