Closed stickpin closed 1 year ago
Hey there @dmulcahey, @adminiuga, @puddly, mind taking a look at this issue as it has been labeled with an integration (zha
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
zha documentation zha source (message by IssueLinks)
Welcome to ZHA sadly you was not being converted from deCONZ (Joke) :-))).
The first error i also is getting for some device then starting ZHA and its trying sending commands to device that is not being online then the system is not having the Zigbee network up and its not critical but i have not digging way the system is trying sending those commands to this devices that i think is not do (perhaps is bad stored attributes in the Zigbe.db ?).
Also theCouldn't get list of groups
is ZHA trying reading ZLL group from the device that is not having one (it can the light is having ZLL profile and is one ZB3 light. Is the light firmware updated ?).
The second i have also seen and some other user have reporting it.
Its normally happening then one device is rejoining the system and like using one short address (NWK) that is being used of one device and one router is complaining its occupied.
Good behaving Zigbee device shall leave and rejoining if one NWK conflict so the IKEA light is doing it OK.
One think can being interference that is making the device leaving or interrupting the mesh network but im not 100% sure way is happening with some devices some time.
The interesting is not the device that is complaining (the TS011F an IKEA light) its the other device that is not identified 0x0ed1 (ec:1b:bd:ff:fe:d0:78:c7
) do you knowing the model and brand of that device ??
Also you is having device that is joining but have not left the network that is little strange. Can you looking id its some sleeping end devices that is not OK initiated ?
It can being devices that is not doing pulling if its parent OK and is rejoining after sleeping to long but interesting see witch devices it is.
Hi @MattWestb,
Thanks for the detailed answer. :) The "ec:1b:bd:ff:fe:d0:78:c7" device is IKEA TRADFRI on/off switch. All my devices are up-to-date with the latest firmware, in case they are available. To be completely honest I am a bit disappointed with the current EFR32MG21 stability. I guess it's more related to software(firmware) than to hardware but still. Maybe it's only my experience but after Z2M with CC2652RB Dongle, my Zigbee network is behaving very strangely.
I've started rollback this morning to Z2M with CC2652RB. I guess it's still too early for EFR32MG21. I will keep this dongle for labs and will wait for a better time. :)
All coordinators is working little different and running different code (the Zigbee stack on the chip) and also different settings for the mesh network. You is having one large network and you is see more problems then one user with 2 lights and 5 Aqara sensors for shore.
The "re joining" devices is very likely not one thing with the coordinator (then you have blocking the EZSP for having direct children) but is very likely one problem with its parent is not liking its child or the child is not liking its parent. One very common problem is OSRAM plugs that looks working very well in the network but is making very much problem for its children and also traffic between other routers is being distorted.
I recommending looking if some of the "re joiner" is having problem in Z2M with TI coordinator then they is connected to one router. I think you is finding radio interference or one or more bad routers in you network.
One very known issue that is not fixed in current TI firmware is nearly impossible having real Zigbee 3 end devices having the coordinator but is working very well if having one normal router as parent (Danfoss Ally TRV is falling in deep sleep and must being re powered) but i think its being fixed in the dev firmware.
In the end you shall doing what you like and what is best for your system !!
@MattWestb... just a few more things to add about ZHA in general. :) I think the integration is dramatically improved. UI and integration into the Home Assistant are very nicely done. Many device-specific options are now exposed in the UI. Even the painful Home Assistant restart, which restarts the Zigbee network as well, was recovering very fast.
But I was surprised that some of the issues that are being presented two years ago are still present today.
Not of those issues are present in Zigbee2MQTT.
These two are more like feature requests:
I am happy to help to debug those issues on ZHA including the initial ones with devices leaving and joining the network, but I am not sure about ZHA Developers' availability, as well as how many people are affected by the same issues as me, and I cannot keep my production network with those bugs for a long time.
FYI @dmulcahey, @Adminiuga, @puddly
When devices for some reason from time to time are not shown as part of the Zigbee Group
An issue was fixed regarding this over a year ago. No issues here and not sure with what devices you're experiencing this.
Meaning if I turn off Group with two bulbs, one may stay shown as on for 30 seconds or so.
Currently ZHA polls all group members after changing the group. Z2M (and the Hue integration) just assume the state. ZHA will also have this fixed in the next beta:
What happening with ZHA is that most of the time it will fail with a few of the bulbs to complete the full scene activation.
This is because HA scenes send individual commands. The same thing will happen if you set up an HA scene and use Z2M (some coordinators work better with such an "overload of messages" though). For example, I have a TI coordinator and a scene with 12 lights changing at once and it works quite well.
One thing that could solve this for everyone (weaker networks) would be to implement Zigbee scenes, as it would be enough to send one "reactivate scene 1" command to a whole Zigbee group (drastically reducing the amount of message). (It's already possible to use Zigbee scenes with scripts and service calls. A UI for this would be very nice of course.)
Try to set your color temperature to 3200K and see how different bulb manufacturers will behave. I guess there is something wrong with the translation for some vendors.
Other than the internal conversion from Kelvin to Mired that HA does (which can be ignored basically), there's no other conversions in that regard. I also don't think Z2M does any correction, but I might be wrong. Never noticed any issues for all of my different lights. (And even if Z2M corrected some color temps to different values for some lights, those corrections wouldn't work for Zigbee groups.)
ZHA is missing the Offset/Calibration option
I don't think this would/should be implemented into ZHA itself. I'd also like to see it as an option for all HA sensors though. For now, template sensors can be used.
OTA management is not available through UI
I think this is known and will be implemented at some point in time.
For my is Zigbee groups importing but many users is using HA groups that is sending unicast commands to all lights = bad. But im missing one GUI for making and changing Zigbee scenes :-((
Calibrating sensors i have make issues / request for but its not being made but now its possible making it very nice in ZHA / devices. Also OTA / device in GUI is on the way.
With the problem group status is not updated it can being that you have some lights that is not Zigbee complaint and is not reporting status changes like Philips HUE and need being pulled for getting the host system. ZHA can pulling device status but trying avoiding it then its not Zigbe complaint and its bad for the mesh networking.
In the end its about how mush user is helping with coding and testing in our community system and its 2 system in the top and its Z2M and ZHA and other have falling behind.
Most importing for one production system is it shall being realibol !!!
@TheJulianJES thanks a lot for the answer. Regarding "assume the state". Thanks a lot for your effort! :) I guess it was annoying not only me. :))
Regarding Scenes. Can you share an example, of how to use Zigbee Scenes in ZHA? I tried it yesterday in Z2M and it will definitely resolve my problem with scenes.
Maybe I will give it a try one more time.
Two more questions... I want to go with EFR32MG21 anyway, as "in theory" it will be easier to migrate to SkyConnect once I will be able to get my hands on it. Which firmware is recommended? I currently running the official one. But you can get ncp-uart-sw_v6.10.3_115200.gbl from here: https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle-NoSigned/EZSP
Also as settings, if I going to switch one again, I want to use those settings:
zha:
zigpy_config:
source_routing: true
network:
channel: 25
channels: [24, 25, 26]
ezsp_config:
CONFIG_MAX_END_DEVICE_CHILDREN: 0
CONFIG_APS_UNICAST_MESSAGE_COUNT: 64
CONFIG_SOURCE_ROUTE_TABLE_SIZE: 200
CONFIG_ROUTE_TABLE_SIZE: 16
CONFIG_ADDRESS_TABLE_SIZE: 32
CONFIG_PACKET_BUFFER_COUNT: 250
CONFIG_BINDING_TABLE_SIZE: 32
CONFIG_NEIGHBOR_TABLE_SIZE: 26
ota:
ikea_provider: true # Auto update Trådfri devices
ledvance_provider: true # Auto update LEDVANCE/OSRAM devices
salus_provider: true # Auto update SALUS/Computime devices
inovelli_provider: true # Auto update INOVELLI devices
otau_directory: /config/zigpy_ota # Utilize .ota files to update everything else
Any suggestions?
EZSP 6.7.8.0 (Sonoff 6.7.9.0) is the stable version and EZSP 6.10.3.0 is candidate and looks working well. EZSP 7.X is having some bugs and the latest shall working (7.2.0) but Sonoff have not released one EZSP version (and likely dont do then the dev have moving on).
Edit: If trying EZSP 7.X you is getting problem going back to 6.X and need flashing one NVM reset file for getting it working https://github.com/xsp1989/zigbeeFirmware/issues/28.
@MattWestb, i think the official firmware is actually v6.10.3.0 build 297 (ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl) from https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/NCP. My question was mostly if the official version is any different from the xsp1989 version.
The xsp1989 version is having patches for the hardware and shall working well. If i remember right Hi was saying "E" its using the same hardware settings in the firmware as the old ones. The itead is the new hardware but we have not getting any information from the devs of it only what xsp1989 have "leaked" https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/issues/10.
The bad thing is xsp1989 have moving on so we is not getting any support at all now :-((
I think both shall working OK but you can trying both but we have not getting feedback form users if some is working better then the other.
PS: Thanks for the link i was looking for the router firmware one user is using :-))
I received my SkyConnect a couple of days ago and migrated now everything to ZHA (once again). :) @MattWestb, @TheJulianJES, sorry for bothering again, but there is any chance you can share an example of how to use Zigbee Scenes through commands and scripts?
Note: Color XY/color temp attribute reports aren't parsed in ZHA (as the color_mode
attribute isn't reportable and HA would be unable to know what color mode the bulbs are in). Eventually, ZHA will poll the bulbs for their state but that can take a long time.
So you will see incorrect states in HA. The basic steps are still listed below:
Create a Zigbee group with the devices using the ZHA UI. Remember the group ID. In the example, I'll use 0x000a (hex) (or 10 in decimal).
Note: We cannot use the modern params
approach with issue_zigbee_group_command
, so we have to use args
.
You can find the commands when using the "Manage Zigbee device" -> clusters UI.
To create a new scene:
service: zha.issue_zigbee_group_command
data:
cluster_type: in
cluster_id: 5
group: 10 # group id
command: 0 # add new scene
args:
- 10 # group id
- 1 # scene id
- 10 # transition time (in 1/10th seconds)
- Scene1 # scene name
Then, set all devices to the states you want to store in the scene.
To store the current settings into the scene:
service: zha.issue_zigbee_group_command
data:
cluster_type: in
cluster_id: 5
group: 10 # group id
command: 4 # store state in scene
args:
- 10 # group id
- 1 # scene id
To recall the scene (again, this will not set the correct state in HA):
service: zha.issue_zigbee_group_command
data:
cluster_type: in
cluster_id: 5
group: 10 # group id
command: 5 # recall scene
args:
- 10 # group id
- 1 # scene id
- 10 # optional: override transition time (in 1/10th seconds)
@TheJulianJES thanks a lot! Works like a charm! Now I can live peacefully with ZHA. :)))
What i is missing is working scene add commands (data sets for all ZCL clusters) with all parameters so can adding advanced scenes for lights and not only storing scenes then its not flexible.
After experimenting a bit, there are a few things to add.
To remove a scene this payload can be used:
service: zha.issue_zigbee_group_command
data:
cluster_type: in
cluster_id: 5
group: 3 # group id
command: 2 # remove scene
args:
- 3 # group id
- 1 # scene id
I have 13 bulbs from different vendors that are involved in the scene, the transition time not acting the same for all bulbs, so the solution is to set the transition time to 0 during scene creation, for example:
service: zha.issue_zigbee_group_command
data:
cluster_type: in
cluster_id: 5
group: 3 # group id
command: 0 # add new scene
args:
- 3 # group id
- 1 # scene id
- 0 # transition time (in 0/10th seconds)
- Warm White # scene name
I've tried to set transition time at scene recall, but it was not working for me.
@TheJulianJES, @MattWestb maybe it is worth creating some Wiki page for everyone? I think this information is very useful for the whole HA community. If you can point me to where to create it, I will be happy to do it.
You are very welcome adding scene in the wiki https://github.com/zigpy/zigpy/wiki.
@MattWestb Thanks! I will do the page next week.
@TheJulianJES, @MattWestb I think I've found what is wrong with Kelvin's Temperature behavior. Well... it's very simple, TRADFRI bulb E27 CWS opal 600lm doesn't support it. :)
I've found two issues related to it: DeConz: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4140 Zigbee2MQTT: https://github.com/Koenkk/zigbee2mqtt/issues/4845
So the solution is to use some converter, for example, this one: https://www.luxalight.eu/en/cie-convertor to convert Kelvin to XY values.
OOO !! It was the first gen CWS that is not one true RGBW light. IKEA is using RGB LEDs also for simulating TC. IKEA Hub is setting the (default) TC-scenes with X Y and its looks working OK. But is nearly impossible making it nice with other commands. If converting TC to X Y shall working OK bit its little work to do.
Edit: The new CWS3 is having working CT in ZHA :-)).
As promised, I've created a wiki page explaining the Zigbee Scenes in ZHA: https://github.com/zigpy/zigpy/wiki/Zigbee-Scenes Feel free to correct, or rephrase me. :)
Sadly ZHA have not GUI for Zigbee scenes like de(F)CONZ that is adding then in HA GUI. I also missing add scene with unlimited datasets like blind %, CT, XY and so on for all device types. Z2M is doing it OK https://www.zigbee2mqtt.io/guide/usage/scenes.html#creating-a-scene.
The problem
Hi All,
I've migrated my 100+ devices Zigbee network to the new USB Dongle: Sonoff ZBDongle-E with EFR32MG21 chipset. As part of the migration, I've migrated from Zigbee2MQTT to the ZHA, as ZHA has official Silicon Labs support. In general, the network is stable but I have a few strange messages in the log that I cannot explain.
When I am restarting Home Assistant, I see in the log those messages:
During regular work, I see strange NWK conflicts and that devices leaving and joining back the network in the middle of nowhere for no reason.
The Sonoff ZBDongle-E running official firmware v6.10.3.0 build 297 (ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl)
My ZHA settings in the configuration.yaml are:
My network looks this way:
Any explanation for this behavior?
What version of Home Assistant Core has the issue?
2023.1.4
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
ZHA
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha/
Diagnostics information
config_entry-zha-fb17b05629f882f6722ee497150796b9.json.txt
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response