No, it was displayed in hex, previously.
Take a look at my screenshots from a couple of days ago.
And, I just put the manually-added customization back in place…hex nwk addresses.
No, it was displayed in hex, previously.
Take a look at my screenshots from a couple of days ago.
And, I just put the manually-added customization back in place…hex nwk addresses.
Amazing! I still have the old visualization installed and this is what I see
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 submitted a feature request.
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…
Have a look here https://github.com/home-assistant/core/issues/44954#issuecomment-764797420
A lot of things can explain that you do not see the links …
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.’
I’m actually very early in my Zigbee journey so I’m gonna see what zigbee2mqtt looks like. I’ll also check the mapping and report back.
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???
Good hunting!
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…
Well, it seems the the linkage doesn’t appear in the Z2M map either, so I guess it is an Aqara problem after all…I do see LQI measures though.
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.
For OTA firmware update with ZHA look here OTA Image Types Firmware versions · dresden-elektronik/deconz-rest-plugin Wiki · GitHub
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 ? …
Good news. Interesting and I am sure frustrating to some level.
I have been reading the info in this post below by @Dueller . There is a custom component called ‘zha-map’ by one of the main contributors to ZHA @Adminiuga . I am still not really sure I understand what the purpose of this tool is, but in reading some of the issues around it and looking into the code, it appears it might do some ‘clean’ up on the zha network that perhaps currently is not done by the built in ZHA tools. Might be worth a read.