Newby question for which I didn’t find a “real” solution here. Hope it’s ok to introduce my system and some of my ideas:
I started HA on a RPi 4b recently and integrated my PV system, added some ZB sensors and a few actors, created automations, alarms etc. which was appealingly easy.
I chose a ZB coordinator that seemed to be trusted by many (Sonoff which now shows as CC2652 from TI ???) and Sonoff S60ZBTPF plugs, sensors range from “noname” to Sonoff and Heimann, actors are Sonoff TRVZB and ZBMINIR2. The idea was to get an idea of the various makes and their quality.
Things started quite promising and I took the first exit from the integrations page: ZHA. Simple config and devices where recognized easily.
Issues that showed up soon:
after each and every HA update most (but not all) sensors get lost and have to be re-integrated by resetting them where ever they are.
Routers are always online but the “map view” doesn’t show links for some. Plugs and valves are online and controllable (like on/off).
Some sensors that are online after the reload show correct values, some don’t.
I don’t see any “class” related issue. Sometimes security devices (smoke and water sensors) are ok after the upgrade whilst simple open/close sensors are not. Sometimes it’s the other way round.
I tried everything I found here and at the ZB site. From updates to downgrades, flashing and zha tools and spooky stuff. Nothing really helps. The coordinator is placed at the very best possible place (no interference etc.).
Once I get every bit back online after resetting and re-adding there is still one router (another Sonoff plug) that is fully functional but shown without a link in the map!
Sensors are shown online and are functional (incl. automations triggered by them) to some point.
Sorry no clue what to do next. Any help is really welcome!
BTW there are more issues that seem to be bounbd to the underlying ZB issues::
door open sensors trigger false alarms e.g. after restarting HA. Looks like even a delay of 5 minutes is not enough to get the automation reliably. My scenario looks e.g. like this “forgot to close garage door → trigger an alarm after 5 minutes → return home to close the garage door”
electric floor heating thermostat (TS0601 TZE284_rlytpmij), none of the solutions here really works as required… floor temp is “frozen”, basicalyy I can only switch it on and off… my plan was to store overproduction PV power in the concrete/tiles in some rooms…
climate group helper for the TRVZBs… is really complex. And yet I don’t understand how to easily create and modify a schedule with different temps.
Likely caused by how you set up the automations that trigger the notifications. Can you paste the automation as preformatted yaml? use the </> button to format the yaml.
as mentioned I placed all devices as good and as close as possible. Distances and number of obstacles/wall between the routers are less than what would be a “must be possible” under normal circumstances. The coordinator (LAN uplink only, no WiFi) is reasonably isolated (next electronic device @4m, next AP @6m, PPi in a closed al case, USB2 ext. cable etc. etc.) from interfering signals and centered in the building and it’s sourroundings.
I guess that’s why most routers don’t feel the need to build a mesh when their strongest link is the coordinator?
There are, like probably everywhere, 2,4GHz WiFi networks around but that is nothing I could influence.
My ZB network is on channel 25. My internal 2.4 WiFi is on 1.
I don’t get a mesh build up at all. And the shown router that is working but doesn’t have a link in the map is in the middle of two others. One indoor wall, one wooden wall to the other and max. dist. <10m.
I could use outdoor 2,4GHz HPE Aruba APs instead the USB dongle. Maybe that’s a better and more stable hardware…
Regarding automations: here is a very simple one that sometimes works as expected and sometimes “sticks” in that way that it alarms the mobile several times or stays there. Interestingly when you check the sensor state it always responds instantenously and correct…
alias: Gartenhaus-Tuer-links
description: ""
triggers:
- trigger: state
entity_id:
- binary_sensor.tur
for:
hours: 0
minutes: 10
seconds: 0
conditions: []
actions:
- action: notify.mobile_app_handi
metadata: {}
data:
message: "Gartenhaus linke Tür noch immer auf. "
title: Gartenhaus-Tuer
mode: single
triggers:
- trigger: state
entity_id:
- binary_sensor.tur
from: "off"
to: "on"
or just to "on"
Seems your current automation triggers on every state change (from unavailable to off for example).
As for the Zigbee issues, most issues are solved by either adding routers strategically (smart sockets are a good example) or by placing the coordinator more central. In your case more routers would probably not hurt. I don’t think you will get any better experience by switching from ZHA to Z2M.
copy. sound absolutely like what I missed (knowledgewise) added from off to on. Will report how that worked.
Regarding “more routers”:
what is a reasonable distance between them (as mentioned within 10m and one wall in between they do not form a mesh!) and how could I measure the current bandwith etc.?
Is their any way to manually influence the mesh build up?
New idea with some (imo) smart advantages:
I could use my HPE Aruba (AP) network. Those networks APs are placed for 5GHz WiFi coverage in the outdoor and indoor area. Their controller offers an option to act as ZB coordinator.
BUT how can I use that in HA? ZB2MQTT (which would help with the electric floor heating thermostat probably) I think.
Yet I have only found the dropdown menu for selecting the coordinator and that offers local usb devices only… So there must be a place to add at some kind of “IP reachable” coordinator…
It’s a difficult question to answer - every network differs from another basically. For comparison my network stretches over 3 stories and two separate buildings, I have around 60 router devices and 40 battery ones. Best bet is probably to place a few and see how that works before you know if you need more or not.
I’ve not tried HPE Zigbee coordinator functionality in APs (I didn’t even know they offered that support). There is support for coordinators over ethernet in both ZHA and Z2M, here is an example: Zigbee2MQTT / ZHA Sett... | SMLIGHT Manuals
I think for my following setting this is really a lot of code:
Workdays (sample for just one group):
from 6:00 till 8:00, from 11:00 till 13:00 and from 17:00 till 22:00 set temp 21°
slots in between set temp 18°
during neight time (22:01 till 05:59) set temp 16°
Weekends:
similar scheme with different slots.
As far as I can see I have to define at least three slots each day and add temp to every slot separately.
To give you an idea what might make it easier (and how I use it currently): AVM (now called Fitz) does it with their DECT thermostats basically by giving you two temps (eco and comfort e.g.) to set. You only select one (e.g. comfort) and “draw” the slots. All others slots will be set to eco.
Maybe you know that solution too?
Thank you for your input!
I can confirm it. Just received the some information (proprietary solution, neither standard ZB coordinator nor MQTT) from Aruba too. Didn’t spend extra money on them. I simply do use those very robust outdoor APs including their beacons anyway and recently found the IoT configuration section which offers ZigBee support (and a lot of settings/options).
Yes, unfortunately setting up the schedules is a bit of a hassle.
The Climate Group Helper just supports the core schedule integration.
You can also create your schedules via YAML, which is probably faster than using the UI.
I edit the ‘.storage/schedule’ file directly and then restart immediately.
But that’s probably more of a hack than a practical solution.
Servus Björn, copy that. Will see if I can live with that. For now I struggle with ZB. It’s just “no good” after every HA Core update most sensors got lost. After resetting and readding the sensors work but are not shown with interconnects in the map. Same with one of five plugs… I honestly doubt that it is something cuased by “not enough routers” if there are 3 in one room and the coordinator is less than 10 meters away. Maybe this whole ZHA thing is not, at least for me, good enough. And there are others here with similar issues…
You might be surprised… my Zigbee mesh wasn’t really stable until I had about 20 router devices. Even sensors in the same room as the coordinator (< 4m) weren’t always stable and they ran through batteries. And, that’s in a typical American home with wood-framed walls covered in drywall… if your home has thicker, more radio-opaque construction, the number of routers required can be substantially higher.
From what I’ve seen on this forum over the years I’ve been here, many of the “others here with similar issues” are having those issues because they expect a Zigbee network to act like WiFi. They want the benefit of small, battery-powered sensors that don’t need new batteries every month, but they don’t understand that what makes that possible is a dense mesh of routers that provides multiple paths from any sensor back to the coordinator. Or, they have a bunch of routing lightbulbs, but they don’t understand that putting those bulbs behind a physical switch means that the mesh will need to reorganize every time those switches power or de-power the bulbs.
Dear Digeridrew, thank you for the explanation. I was aware of the technical drawbacks of low power devices. I use ULE-DECT/HAN-FUN too and they simply don’t have that problems. I have a ZB and a DECT-ULE window open sensor in the same room, same distance to the coordinator respectively DECT-Gateway, same (german style) walls and ceilings in between. Those sensors are similar battery efficient (app. 2 years for 2x AAA). My aim was to find out how efficient Zigbee can be. It’s pricepoint was definitely attractive but if it requires such a large number of routers is really relative. Well and no I didn’t place a router behind a light switch ;-).
Maybe you can explain why the network allways fails after a core update of HA? It does not fail after a reload of HA or a reboot of the OS. That’s one aspect I don’t understand. The network is there an the ZB data is on the coordinator but HA can’t connect???
I changed my ZB from ZHA to Z2MQTT and now, without any change regarding the hardware it works fine, builds the mesh and all sensor are only right away.
As I expected and can now see visualized it was not an issue related to the sheer number of routers or the quality of my walls
The last thing I struggle now is my first thermostat group with its schedule can’t be manually overridden anymore.
I updated all the entities (didn’t “convert” anything from ZHA to Z2MQTT) and now I can set the HVAC mode to e.g. off but it’s just not accepting it.
my ZHA issue was, as I assumed, obviously not a hardware issue or some kind of “not enough” hardware. I switched to MQTT and that’s it. Automatically built mesh link, direct links AND all my devices are fully supported now. Especially the electric floor heating thermostats that never did when using ZHA.
Checked all kinds of restarts and updates, reenabled my 2,4GHZ WiFi, relocated the coordinator to a less ideal position. Disconnected/relocated one router (plug), hard rebooted/powercycled the RPi, AOK…
I’m new to HA and I looked around (e.g. in climate.py where the service is registered) but couldn’t find exactly what you meant.
Maybe you can guide me to or even through a troubleshooting procedure?
How can/should I debug this issue?
How do I know/see a service in HA?
…
