probot-home-assistant[bot]
commented
4 years ago zha documentation zha source (message by IssueLinks)
Closed HydrelioxGitHub closed 3 years ago
probot-home-assistant[bot]
commented
4 years ago zha documentation zha source (message by IssueLinks)
probot-home-assistant[bot]
commented
4 years ago Hey there @dmulcahey, @adminiuga, mind taking a look at this issue as its been labeled with a integration (zha) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)
Adminiuga
commented
4 years ago 
HydrelioxGitHub
commented
4 years ago I'm using a Texas Instruments cc2531 with flashed firmware. Works well with zigbee2mqtt. I will try to re add Zha integration and post log as soon as I can.
Adminiuga
commented
4 years ago I think someone else was reporting similar issues when using CC2531. Remove device from the UI, enable debug logging, re-pair the device. Post logs here.
Variour
commented
4 years ago I have the same problem, this is the output when pairing the OSRAM Smart+ Plug.
logger:
default: info
logs:
homeassistant.core: debug
homeassistant.components.zha: debug
bellows.zigbee.application: debug
bellows.ezsp: debug
zigpy: debug
zigpy_cc: debug
zigpy_deconz.zigbee.application: debug
zigpy_deconz.api: debug
zigpy_xbee.zigbee.application: debug
zigpy_xbee.api: debug
zigpy_zigate: debugit does look like something in zigpy-cc
These
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] waiting for dataConfirm
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.AREQ subsystem=Subsystem.AF command_id=128 data=b'\x00\x03\xe8' length=3 fcs=44>
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 24}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 1, 'transid': 140}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 156}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 158}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 172}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 174}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 176}
+{'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] <-- AREQ AF dataConfirm tsn: None {'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.zigbee.application] message ignored: dataConfirm
2020-05-17 17:28:39 DEBUG (MainThread) [zigpy_cc.api] res AREQ AF dataConfirm tsn: None {'status': 0, 'endpoint': 3, 'transid': 232}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.zigbee.application] request (0x7acd, 260, 0, 3, 3, 233, b'\x00\xe9\x00\x04\x00', True, False)
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] --> SREQ AF dataRequest tsn: 233 {'dstaddr': 31437, 'destendpoint': 3, 'srcendpoint': 3, 'clusterid': 0, 'transid': 234, 'options': 0, 'radius': 30, 'len': 5, 'data': b'\x00\xe9\x00\x04\x00'}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\x0f$\x01\xcdz\x03\x03\x00\x00\xea\x00\x1e\x05\x00\xe9\x00\x04\x00\x81'
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.SRSP subsystem=Subsystem.AF command_id=1 data=b'\x00' length=1 fcs=100>
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] <-- SRSP AF dataRequest tsn: None {'status': 0}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] waiting for dataConfirm
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.AREQ subsystem=Subsystem.AF command_id=128 data=b'\x00\x03\xea' length=3 fcs=46>
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 24}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 1, 'transid': 140}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 156}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 158}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 172}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 174}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 176}
+{'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] <-- AREQ AF dataConfirm tsn: None {'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.zigbee.application] message ignored: dataConfirm
2020-05-17 17:28:44 DEBUG (MainThread) [zigpy_cc.api] res AREQ AF dataConfirm tsn: None {'status': 0, 'endpoint': 3, 'transid': 234}
2020-05-17 17:28:49 INFO (MainThread) [homeassistant.components.esphome] Can't connect to ESPHome API for espcam01.local: Error resolving IP address: [Errno -2] Name does not resolve
2020-05-17 17:28:49 INFO (MainThread) [homeassistant.components.esphome] Trying to reconnect in 60 seconds
2020-05-17 17:28:49 DEBUG (MainThread) [zigpy_cc.zigbee.application] request (0x7acd, 260, 0, 3, 3, 235, b'\x00\xeb\x00\x05\x00', True, False)
2020-05-17 17:28:49 DEBUG (MainThread) [zigpy_cc.api] --> SREQ AF dataRequest tsn: 235 {'dstaddr': 31437, 'destendpoint': 3, 'srcendpoint': 3, 'clusterid': 0, 'transid': 236, 'options': 0, 'radius': 30, 'len': 5, 'data': b'\x00\xeb\x00\x05\x00'}
2020-05-17 17:28:49 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\x0f$\x01\xcdz\x03\x03\x00\x00\xec\x00\x1e\x05\x00\xeb\x00\x05\x00\x84'
2020-05-17 17:28:49 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.SRSP subsystem=Subsystem.AF command_id=1 data=b'\x00' length=1 fcs=100>
2020-05-17 17:28:49 DEBUG (MainThread) [zigpy_cc.api] <-- SRSP AF dataRequest tsn: None {'status': 0}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.AREQ subsystem=Subsystem.AF command_id=128 data=b'\x00\x03\xec' length=3 fcs=40>
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 24}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 1, 'transid': 140}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 156}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 158}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 172}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 174}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] payload missmatch
-{'endpoint': 11, 'transid': 176}
+{'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] <-- AREQ AF dataConfirm tsn: None {'status': 0, 'endpoint': 3, 'transid': 236}
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.zigbee.application] message ignored: dataConfirm
2020-05-17 17:28:50 DEBUG (MainThread) [zigpy_cc.api] waiting for dataConfirmDon't look good and we did not get Manufacturer and Model
2020-05-17 17:29:00 DEBUG (MainThread) [zigpy.endpoint] [0x7acd:3] Manufacturer: None
2020-05-17 17:29:00 DEBUG (MainThread) [zigpy.endpoint] [0x7acd:3] Model: None@sanyatuning can you take a look at this one? Let me know if you would like to move this issue to zigpy-cc repo for visibility
pveras
commented
4 years ago @Adminiuga, @sanyatuning was any progress made on this? I have OSRAM Smart+ lights that present similar issues but they work fine on zigbee2mqtt. Let me know if you would like any debug info to help solve this
Adminiuga
commented
4 years ago You could try alternative implementation of znp protocol via https://github.com/zha-ng/zha-custom-radios Take backups. After installing custom radios, edit .storage/core.config_entries and change radio_type to znp (needs checking)
Variour
commented
4 years ago I have tried it with zha-custom-radios and zigpy-znp, which is linked as a replacement for zha-custom-radios.
My core.config_entries entry looks like this
{
"connection_class": "local_push",
"data": {
"device": {
"path": "/dev/ttyACM0"
},
"radio_type": "znp"
},
"domain": "zha",
"entry_id": "86bebfc8d292426ba81f6272bedf676c",
"options": {},
"source": "user",
"system_options": {
"disable_new_entities": false
},
"title": "/dev/ttyACM0",
"unique_id": null,
"version": 2
}With both I get
Logger: homeassistant.config_entries
Source: components/zha/core/gateway.py:146
First occurred: 23:34:57 (1 occurrences)
Last logged: 23:34:57
Error setting up entry /dev/ttyACM0 for zha
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 219, in async_setup
result = await component.async_setup_entry( # type: ignore
File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 100, in async_setup_entry
await zha_gateway.async_initialize()
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 146, in async_initialize
self.application_controller = await app_controller_cls.new(
File "/usr/local/lib/python3.8/site-packages/zigpy/application.py", line 65, in new
await app.startup(auto_form)
File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 384, in startup
await self.form_network()
File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 553, in form_network
await self.update_network(
File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 490, in update_network
await self._znp.request(
File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 324, in request
raise CommandNotRecognized(
zigpy_znp.exceptions.CommandNotRecognized: Fatal request error RPCError.CommandNotRecognized.Rsp(ErrorCode=<ErrorCode.InvalidSubsystem: 1>, RequestHeader=CommandHeader(id=0x08, subsystem=Subsystem.APPConfig, type=CommandType.SREQ)) in response to AppConfig.BDBSetChannel.Req(IsPrimary=<Bool.true: 1>, Channel=<Channels.CHANNEL_25|CHANNEL_20|CHANNEL_15: 34635776>)Edit: The problem is probably that I am not running Z-Stack 3.0.1, but 1.2 on my CC2531.
makuser
commented
4 years ago I have tried it with zha-custom-radios and zigpy-znp, which is linked as a replacement for zha-custom-radios.
The problem is probably that I am not running Z-Stack 3.0.1, but 1.2 on my CC2531.
Same here, I also switched to zigpy-znp using the custom_component, upgraded my CC2531 to 3.0.1 again, reset the NVRAM and I was finally able to read the proper MODEL_INFO.
I am now waiting for my custom quirk to be merged: https://github.com/zigpy/zha-device-handlers/pull/491
Just for the record; using the CC2531 both with Z-Stack 3.0.1 (20190425) as well as 1.2 (20190608) using the ti_cc radio type did not work for me, at the moment I only have some Osram Smart+ bulbs to test though. I was able to add the bulbs, but they are not recognized properly, actually their signature is partially even correct (only the model info was missing), but for some reason it still used the zha profile to talk to a bulb that clearly identified itself using the zll profile, so I was not able to control it at all.
Great that it all works, it's my first time using the zha component, I only used zigbee2mqtt before.
TheJulianJES
commented
3 years ago As far as I understand, this issue should be fixed by using zigpy-znp instead of zigpy-cc. A "migration guide" for users still experiencing this issue can be found here: https://github.com/zigpy/zigpy-znp#home-assistant (I think this issue can be closed)
pixelspark
commented
3 years ago As far as I understand, this issue should be fixed by using zigpy-znp instead of zigpy-cc. A "migration guide" for users still experiencing this issue can be found here: https://github.com/zigpy/zigpy-znp#home-assistant (I think this issue can be closed)
I am actually using zigpy-znp (I followed the linked guide earlier).
In my case, the Smart+ plugs are recognized, but it seems sometimes their state becomes out of sync (i.e. automations will not change the state of the plug because HA thinks the plug is already in the desired state - manually toggling on/off however still works). When I manually toggle the switch using the button, this does not sync to HA either.
I am seeing a few logs related to the device (0xF351 below) which seem to indicate mostly normal operation (other devices are using the plug as router looks like. Some fragments:
2020-12-12 14:56:23 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0xF351, Relays=[])
2020-12-12 14:56:23 INFO (MainThread) [zigpy_znp.zigbee.application] TC device join: ZDO.TCDevInd.Callback(SrcNwk=0x3142, SrcIEEE=00:17:88:01:08:72:8e:0e, ParentNwk=0xF351)
2020-12-12 15:06:19 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0x2ADF, Relays=[0xF351])
2020-12-12 15:07:03 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0xF351, Relays=[])
2020-12-12 15:17:28 WARNING (MainThread) [zigpy_znp.zigbee.application] Failed to send request AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0xF351), DstEndpoint=3, DstPanId=0x0000, SrcEndpoint=1, ClusterId=0, TSN=40, Options=<TransmitOptions.RouteDiscovery|APSAck: 48>, Radius=30, Data=b'\x00\x28\x00\x04\x00'): Status.MAC_NO_ACK
2020-12-14 10:17:29 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0x8DF3, Relays=[0xF351])
2020-12-14 10:19:51 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0x8DF3, Relays=[0xF351])
2020-12-14 10:19:51 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0x8DF3, Relays=[0xF351])
2020-12-14 10:20:22 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device relays: ZDO.SrcRtgInd.Callback(DstAddr=0xF351, Relays=[])
2020-12-07 17:40:29 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.osram_outlet_1_electrical_measurement is taking over 10 seconds
2020-12-07 17:40:35 INFO (MainThread) [buienradar.buienradar_json] Parse ws data: latitude: 52.07871146877499, longitude: 5.111322104930879
2020-12-07 17:40:37 WARNING (MainThread) [zigpy_znp.api] Received an unhandled command: AF.DataConfirm.Callback(Status=<Status.APS_NO_ACK: 183>, Endpoint=1, TSN=157)
2020-12-07 17:40:42 WARNING (MainThread) [zigpy_znp.api] Received an unhandled command: AF.DataConfirm.Callback(Status=<Status.APS_NO_ACK: 183>, Endpoint=1, TSN=158)
2020-12-07 17:41:07 WARNING (MainThread) [zigpy_znp.api] Received an unhandled command: AF.DataConfirm.Callback(Status=<Status.APS_NO_ACK: 183>, Endpoint=1, TSN=161)
2020-12-07 17:41:11 WARNING (MainThread) [zigpy_znp.api] Received an unhandled command: AF.DataConfirm.Callback(Status=<Status.APS_NO_ACK: 183>, Endpoint=1, TSN=162)
One minor other thing is that the device seems to report a 'power sensor' but it only shows erroneous data. Not sure if the device actually has such a sensor but in any case something isn't recognized properly.
If you want me to open a separate issue, let me know.
TheJulianJES
commented
3 years ago I've also got a couple of these OSRAM Smart+ plugs. The weird sensor happens because they send "ElectricalMeasurement", but they don't even have a current sensor. I guess a quirk could be added to https://github.com/zigpy/zha-device-handlers/ to not even add the entity to Hass, but for now I just disabled the entity in Home Assistant. (Also another note: the devices seems like it's not a great router. So if you have issues, always try to use another router (not any OSRAM/LEDVANCE device).)
Regarding the issue that your OSRAM plugs seem to loose some messages, I would just create another issue here. The logs are probably a good starting point.
Adminiuga
commented
3 years ago Just disable the entity for em sensor
pixelspark
commented
3 years ago I've also got a couple of these OSRAM Smart+ plugs. The weird sensor happens because they send "ElectricalMeasurement", but they don't even have a current sensor. I guess a quirk could be added to https://github.com/zigpy/zha-device-handlers/ to not even add the entity to Hass, but for now I just disabled the entity in Home Assistant. (Also another note: the devices seems like it's not a great router. So if you have issues, always try to use another router (not any OSRAM/LEDVANCE device).)
Regarding the issue that your OSRAM plugs seem to loose some messages, I would just create another issue here. The logs are probably a good starting point.
Will do. Not seeing any routing issues yet. Reading all this it seems like the best solution is just to get rid of the plugs altogether. Will nevertheless open a separate issue for the syncing problem.
Thanks all, this is probably the only small issue I have encountered with ZHA/HA so far. Really grateful for everyone's effort.
github-actions[bot]
commented
3 years ago There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
The problem
I've tried to link my Osram Smart + plug to HA using the ZHA integration. A device is added but as "unk model" and "unk manufacturer". There is a switch in lovelace but it's not working at all. I've checked on https://zigbee.blakadder.com/zha.html if this device is supported (I don't know if it's a good reference...). The reference of the Osram plug is AB3257001NJ in blakadder.
Environment
Problem-relevant
configuration.yamlTraceback/Error logs
Additional information
This plug works correctly using zigbee2mqtt.