After removing the manually-installed zha-network-visualization-card, and moving to use ZHA Network Visualization, I noticed that the network address (nwk) showin in the device map ais now reported in decimal, rather than the traditional hexadecimal.
This is not consistant with the nwk format shown in the Lovelace card, which is reported in hex.
It would be nice if the nwk address value was reported with the same format in all places.
Is there a way to change the network address (nwk) in the device map to be shown in hex again?
The zha network visualization use the code developed for the custom:zha-network-visualization-card (now deprecated) and it has always displayed the NWK in decimal (just checked now)
The visualization now is included in HA core and as far as I know there no configuration options other than database_path and enable_quirks
I also notice that all your devices have a name in the top of the block like ‘Zigbee Bridge’ or ‘Temp4’ the I do not have? May be some alias name that you gave?
I also notice that all your devices have a name in the top of the block like ‘Zigbee Bridge’ or ‘Temp4’ the I do not have?
Interesting. Your lack device “friendly names” is a difference/detail and may help the developers figure out what is different between the two ZHA visualizations.
When a device gets added by ZHA, it gets automatically named something like Sonoff 14f559, which I’d never remember and thus would mean nothing to me.
I edit that “friendly name” for each Zigbee device so I can tell all the temperature sensors apart.
I’m also seeing this problem, but in my case it was after disconnecting my Conbee II stick and reconnecting it after two hours. One device (Aqara climate sensor) never displays a line even though it’s reporting data as usual. Re-pairing and re-naming does not help.
Was a Github issue opened on this? I think it’ll get more attention from the devs there.
I have a Sonoff SNZB-02 temperature end device that behaves similarly. It does not show any connection back to the coordinator and yet reports it’s data fine and continuous. It was originally ‘added VIA’ a Centralight RZHAC wall plug. I think the problem is that some interim devices may not report neighbors correctly. Especially occurs a lot with Aqara and Sonoff end devices. I’m not sure which device in the the relationship is ‘doing it wrong’, perhaps both. Pictures below show the Sonoff with no neighbor relationships being reported in ZHA. However, pictures also show a Aqara weather correctly reported as a neighbor. Both the Aqara and Sonoff devices seem to report ‘better’ when directly added to coordinator. I have yet to have one of my Aqara’s which are directly connected to the Sonoff Zigbee Tasmota’ed bridge not report a relationship. But maybe, from what I read, you are seeing this with your Conbee coordinator.
It’s a bit hard for me to tell what the dev’s focus in on for ZHA’s next releases. But, yes, you are correct, visibility needs to occur there. One problem I have, is has been difficult to collect good solid data to include in bug reports. A lot of moving parts in zigbee…
Thanks for chiming in @dproffer, yes it has been (re)-paired with Conbee II coordinator.
I have a Sonoff SNZB-02 temperature end device that behaves similarly. It does not show any connection back to the coordinator and yet reports it’s data fine and continuous. It was originally ‘added VIA’ a Centralight RZHAC wall plug. I think the problem is that some interim devices may not report neighbors correctly. Especially occurs a lot with Aqara and Sonoff end devices. I’m not sure which device in the the relationship is ‘doing it wrong’, perhaps both.
Thing is, I’m pretty sure I saw the link the very first time I paired the Aqara sensor with coordinator, so I’m not sure it’s an “Aqara issue” per-se.
Not really a promising sign when one of lead devs on the project uses a ‘shrug’ emoji
‘Adminiuga commented 24 days ago
But all the data in the map is based on what the devices are actually reporting. If the device are not reporting neighbours, then it won’t be present in the map 🤷 Can’t control what devices are reporting.’
Zigbee2MQTT is a solid stack, I ran it on a raspberry pi for over a year. I wanted to move off the rpi for HA server so I migrated my zigbee stuff to wifi as part of that. I’m poking around ZHA just mostly to see what is native to HA. Both Zigbee2MQTT and ZHA are solid and growing. Right now, based on my experience with both, I prefer that Zigbee2MQTT runs my devices thru MQTT, I am kind of a fan of MQTT in general. Also right now Zigbee2MQTT allows you to modify the functions of a zigbee device easier than ZHA, it still requires some coding work that is not basic. Both Zigbee2MQTT and ZHA are suffering the same pain in two important areas, 1st it seems like compatibility between zigbee devices is far from standard, I put zigbee in third place behind wifi and bluetooth for compatibility between devices from different vendors. And 2nd, firmware updates for Zigbee devices is at best tepid and I doubt it will ever be complete for either solution. For example, I doubt you will ever be able to update Phillips Hue devices firmware on either ZHA or Zigbee2MQTT. So if something important comes along for your Hue devices, you will still need to have a Hue hub and remove your device from ZHA or Zigbee2MQTT, pair it to Hue, do the firmware update, unpair from Hue, re pair with ZHA or Zigbee2MQTT… value in that???
That’s promising. I hope that Hue and more vendors make their firmware repositories available. BTW, on that front, it sure seems like it would be more secure to pull the firmware OTA images directly from source vendor web repositories. I’m am still trying to understand if the firmware OTA images have any authenticity wrapper or method around them…
Not to ruin your zigbee journey, but after some pretty extensive experimenting with zigbee (of more flavors that I will admit too ), wifi, and bluetooth. Bluetooth with the right collector device is the way to go for temperature and humidity sensing around the house in and out at low cost and high relibility.
Probably a ConBee problem in conjunction with Aqara see link I provided before (sorry long post!)
Why? Compatibility / Reliability?
I just started to experiment for my future house to be built. So I would be interested to know why you choose Bluetooth that seems just entering the world of IOT? Did you experiment with z-wave?
Did you try any on/off - dimmer modules in any of these technologies ? …