where can i see this ZHA map? i did not know such exist so i can see the mesh network.
also, where can i see this kind of map for zwave?
OK…after searching, i see this map is an add-on. trying out now.
after more searching, i see this map is already built into the latest HA. lol
in my zha map, i see this:
in actuality, i have 7 devices as seen here:
are there supposed to be lines linking them together? I am guessing 2 of the zigbee devices dropped out and need to be added back in, OR they are not reporting recently?
Here show what map should look like, connections between devices. However, in second picture, note the Sonoff eWeLink temperature sensor has none, and yet is reporting fine.
What version of Home Assistant are you on?
Well in theory we are on same version. However, I don’t run the HA OS whole thing like you have. I just have a docker image of I think what yours calls the ‘core’ running on a old mac mini running Ubuntu 20. That should not make a difference as I believe they build all configs from same core code.
I hate to offer this, but wonder of you should delete all ZHA devices, reset them, remove ZHA from HA config and start again with just Sonoff Zigbee Tasmota Hub (I think is better route than TI CC chip) and add one single Aqara Weather sensor. And just let it sit for several hour. See if you get connections ZHA and reading from battery, temp, humidity and pressure on regular basis. If so, move forward one at a time. If not, then stay at this point and debug until one sensor is solid.
Also just checking, you have done the Tasmota thing to your Sonoff Zigbee Hub, correct?
An alternative with the TI CC chip is go the Zigbee2MQTT route, if nothing in ZHA works…
ok. i am trying the sonoff bridge today now. it has been flashed with Tasmota. the hub sits directly in the middle of all the sensors in the house.
this is the map i see today. still no lines drawn. the closest sensor is about 13 feet away too
I don’t understand why you are not seeing the links between devices. One, way out there thing that I thought about, any chance that the graphics card on the computer you are running this on is not able to draw the lines for some reason? As I said way out there…
Another thing that caught my eye, my coordinator has a ‘manufacture name’ value, yours does not. That does not seem good. See picture below.
Maybe if you set the logging level to debug for your zigbee stuff, you might see a message or two that might offer something. Have a look now before you change the level to debug and see what you see. A example of some of my ‘normal’ zigbee related error show in picture below. In the course of ‘ok/correct’ operation, zigbee seems to log some errors. With debug, you will get a LOT of stuff, so be ready. I usually peruse the home-assistant.log with a text editor out side of HA, that you can turn off word wrap, and scroll and search a little easier. Below are the log sections I have used. Change ‘info’ to ‘debug’ in each, this is in configuration.yaml , in example below the only log I have set at voluminous ‘debug’ level is the over the air firmware system ‘zigpy.ota’ entry:
logger:
default: warning
logs:
asyncio: info
homeassistant.core: info
# nabu casa and google home stuff
hass_nabucasa: warning
snitun: warning
homeassistant.components.cloud: warning
homeassistant.components.cloud.iot: warning
# zha zigbee stuff
# https://github.com/zigpy
homeassistant.components.zha: warning
bellows: warning
bellows.zigbee.application: warning
bellows.ezsp: warning
zigpy: warning
zigpy.ota: debug
zhaquirks: warning
Hummm, here is something else I just spotted in your diagram. What is the device in the circle, see picture below. It has a network number of zero, I don’t think this is cool. The only device with a network number of zero is the coordinator. So you have two devices with the same network number, and maybe worse than that the common number is the coordinators number. This network number is a ‘shorter’ unique number that the coordinator assigns to each device as they added to the network. I think makes data packets smaller and routing faster. But I am pretty sure they must be unique. If you can ‘remove’ this device in ZHA and ‘reset’ it using it reset button. You might yank the battery for a test period. You might need to restart you whole zigbee network, if this is the problems. I would power cycle the sonoff zigbee bridge as part of restart just to be complete.
example of my network numbers:
Also, see this post I made in another discussion on ZHA. This is a handy table of you zha network that you can add to a lovelace page, it is another view of the info that is showing in the network graph page of ZHA. The github page where you can download it is in the post. I’m not sure if you can install it via the HACS way, I am kind of a .yaml editing person so I don’t use many of the GUI tools for lovelace, see if you can get it install, I find it a useful view into zha:
welp, my zigbee down again. it lasted 19 days this time, since i was last here. im not going to use the usb stick. just sonoff bridge since it seems more robust.
everything was working fine until devices started to become unavailable 1 by 1. now nothing as seen here:
i do see lines now but not much to do since they are all offline as see above:
Bummer! Not sure what best path is for you. I am still in laboratory mode with ZHA and Sonoff Zigbee bridge. However, base on my limited experience and input for folk on these forums, when I have the right opportunity I am going to move to a Zigbee2MQTT lab with Texas Instruments CC2652 based coordinator. Bummer, because it seems like the Silicon Labs EFR32 was a good base for coordinator of the future… but does not enough dev’s with experience and time to make this solid.
i think it’s best to start from scratch with just 1 zigbee device at a time as you suggested. so i deleted ZHA and add it back…BUT when adding back, it auto add my old devices back. what’s the trick to start from scratch? i searched but did not find any
I would make sure the zigbee.db file is gone after you delete the zigbee integration. This file is located in my HA config directory, same place as my configuration.yaml file. I believe I have read that some folks recommend forcing a new PAN ID number before you add the integration back in. This is a new network number that the coordinator uses when adding new devices. But here is the problem, I am not sure that this is fully implemented as yet, it is not in the main HA documentation (at link below) I believe the entry that you put in configuration.yaml is, I have not tried changing the PAN ID, so I am guessing here that this will work, if it does, you should see the PAN ID you speifiec in the home-assistant.log after you restart Home Assistant, example below:
https://www.home-assistant.io/integrations/zha/#defining-zigbee-channel-to-use
https://github.com/zigpy/zigpy/pull/388
zha:
zigpy_config:
network:
update_id: 1
pan_id: 0x1234
2021-01-25 09:04:00 INFO (MainThread) [bellows.zigbee.application] Node type: EmberNodeType.COORDINATOR, Network parameters: EmberNetworkParameters(extendedPanId=cc:cc:cc:cc:e3:ab:00:78, panId=0x3498, radioTxPower=20, radioChannel=11, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)
I am facing a similar issue with a sonoff DS01 magnetic contact. It becomes unavailable after 6 hours of inactivity no matter the state. I am using CC2531 as my coordinator. If the sensor is triggered though it reports the correct state. This means if the window remains open for more than 6 hours the sensor become unavailable but if I close the window it comes bat to life and reports to be closed.
So it has to do how often the sensors report their state or are requested to report their state. I really don’t know how we can fix that or if it is possible to fix that.
In my case I tried to fix that by creating a boolean helper and two automations to store the last value of the issued contact.
Then I made two other automations when the sensor becomes unavailable to set its state according to the boolean helper. to set the state I used the Python:set_state service.( that by the way is extremely helpful. Check the forum for more info regarding python scripting and Python:set_state)
So I most of the times have the correct state.
i give up. i just go with all zwave and nodeMCU. surprisingly my zigbee devices were rock solid with SmartThings so i know i must have goofed somewhere with HA
1 Like
Did you ever find a solution to why it becomes unavailable after 6 hours of inactivity? I have approx ten DS01 units and two of them show this exact issue. One comes back ‘online’ if you open or close the window, but the other one stays unavailable and needs to be added back to the integration to fix again.
I am really sorry for the late response. I haven’t checked the forum for a while.
Although I haven’t checked, the state of my sensor is always correct after i have used the Python:set_state service. for the sensor that remains unresponsive I don’t know how to resolve this.
For the record I turned to Xiaomi Mi Window and Door Sensor. They are much more reliable and after 3 months of operation the still work with the initial batteries.On the sonoffs I have replaced them twice in the same period.
Perhaps too late for many, but nevertheless I’ll post my outcome troubleshooting one of the Sonoff DS01 connection issues I had.
Check the clip that holds the battery for it to be too wide, so the clip doesn’t connect correctly to the + and the - side. Just gently press the clip without the battery in it.
When the clip is adjusted correctly, a red led will be lit on the bottom side of the PCB for each time the DS01 is in state closed or open.
I hope this may help others troubleshooting their Sonoff DS01.
/m4v3r1ck