Exactly. Because of autodiscovery. Another layer which again doesn’t cover every use case. rather providing support for limited number of scenarios, failed hard if anything unsupported happens.
I experienced it some time ago trying autodiscovery with Shelly devices. No chance if you want to do something special.
That’s why I prefer mqtt (without autodiscovery) setting entities manually. ONce data get there, I can do anything I want having full control over it. I can make light from switch. I can join 2 channels of RGB driver into CCT light etc. Try it with deconz or shelly integration.
It’s not I wouldn’t love the system which does those things for me automatically. but today all this ‘automatic’ configuration is very limited and unflexible. In regard of this any integration which tries to manage HA entities for you is just another layer which may decrease flexibility/reliability of the solution. The last sentence is not something specific to HA. It’s rather general rule in software engineering.
you solved. The point is the Integration should solve it. If it doesn’t, if it forces user to workaround - then this is what I’m talking about. And the result, see above what you said about mqtt autodiscovery
I just put two examples in previous post.
Sorry I will not share my experience with deconz/z2m. I have none. But I have experience with shelly devices. And every integration existing (shellyForHass, ShellyAutodiscoveryScript, new official Shelly integration) are way limited comparing to what you can do with mqtt manually. It’s not good thread to talk about details. I can report you all I know using PM if you wish
What I chose: z2m or deconz I don’t know. At the end I made both working. z2m has more steep learning curve. Deconz did a mess in HA entities on first try. So At this point I will try to get familiar with z2m since I believe mqtt provides better granularity and control over entities. Then will see.
You can’t expect everything to worl in wvery case without some workaround from time to time, but this has absolutely nothing to do whether you use MQTT or any other integration.
Anyway, let’s agree that we disagree,we just have different views and that’s fine.
So, it is becoming difficult to me to choose, my actual setup is:
Lights - atm I want to keep them on hue bridge (maybe move to diy hue emulator later)
A bunch of sensors, mainly from xiaomi (door sensors, buttons, temp/humidity, movement etc) currently on xiaomi bridge (that I want to get rid of)
I bought both a raspbee internal card and a CC2531 usb dongle from itead (4$) and now I want to make a new hass installation that integrates one of those zigbee controller
raspbee depends on deconz, and I don’t like the xserver gui dependency, but supports a lot of devices, the CC2531 has a limit of 20 devices, and I don’t have routers in my devices (all are battery operated, I could buy the ikea extender, but I don’t want to depend on this)
After reading this thread the Hass implementation of ZHA seems the way to go but I don’t understand if it still needs deconz software to use the raspbee card, and also if it needs a mqtt broker (which I would still install for shelly hardware) or not… I’m a little confused abvout this situation
Also after further readings seems that zigbee2mqtt works with conbee 2 now, but I don’t understand if it supports the old raspbee 1 module too
that would decouple zigbee controls from hass and also keeps be to reuse the mqtt broker
I tried to work on this, and, happy news, my raspbee I controller works fine with zigbee2mqtt
Good coverage of the house, easy setup, so, right now I’m happy with it
I also been able to reuse mqtt for shelly control
After reading the story about the CC2531 and Sonoff ZBBridge, I am puzzled by this as I was under the impression the SonOff ZBbridge (and their USB equivalent) was based on the CC2531.
Either way, the SonOff ZBBridge is good for a small installation, but I believe it is limited in the number of devices it can handle. Great for a beginner or someone just getting into it,
If you do end up with more ZigBee devices, like if you add a few Zigbee sensors (motion, temp etc) and door sensors and the like you may find your network outgrowing something like the SonOff ZBBridge. Just be aware that like Zwave, if you change the controller you are most likely up for repairing all devices and redoing all the entities.
I have been using Deconz lately and found that even devices that don’t show in PhosCon are often recognised as entities in Home Assistant. Some of the cheap motion and climate sensors that show up as 3A branding in the Deconz network map come to mind.
Okay, but I do know for a fact the SonOff USB is the CC2531, maybe the bridge is not.
That said, the SonOff ZBBridge only supports officially a mxaimum of 32 devices. (stock firmware, no hacking)
I am in a one bedroom apartment, and by the time I add fittings that have 2 globes per fittings, Sensors and motion detection all using Zigbee and a few plug sockets, I have exceeded that amount .
Actually I did read and the iTead official page says supports 32 sub devices (a sub device being a device that connects to the bridge).
I am not referring to tasmotizing the bridge. I refer to default firmware, which runs as its own hub which is a separate thing from the three hubs listed in this topic.
Unofficially it may support more, like the Hue Bridge supports unofficially more than Philips quote. I am talking official support. Once you go past that, you may have reliability issues.
Edit: I am not saying the SonOff devices are bad, I am just saying be aware of their limitations. It is easy to build up to a large number of devices even in a small area. Even the Hue official limit of 63 is easy to reach. ( I haven’t kept up with hue lately, this may have been changed in latest firmware)
Jeez, I mentioned I’d Tasmotized it in my original post and you then tried lecturing me about it being a limited beginner device based on not having flashed it and it was going to personally cause me problems if I expanded my network, so you were wrong on all counts there.
Again, if you bothered to do a bit of reading you’d know the ZBBridge is based on the EFR32 chipset which is far more powerful than the CC2531, so wrong again.
No one here is going to be running the ZBBridge as it comes out of the box so the stock limitations are of no relevance.
That is the official Zigbee standard, and inherent to most Zigbee coordinators. But Zigbee is a mesh network, and devices routed through a router do not count to that limit. Most mains powered Zigbee devices act as a router. If you have 32 sensors (temperature/humidity, motion sensors, door/window sensors) that counts for that limit. But if you add 10 Zigbee bulbs to the mix, and lets say 20 of your sensors connect through the bulbs, the coordinator will only see 22 directly connected devices (the 10 bulbs, and the 12 sensors not routed through the bulbs). That is why you want a strong mesh.
My learning:
-deconz weirdly needs his 40sec time to wake up in the morning (?? Everything stayed on but it’s like that). After that it’s responsive the rest of the day
Calling a deconz listening event in nodered brings system to a halt
Creating groups in deconz and calling that group instead of individual lights made a HUGE difference
It’s still sorcery to pair devices, my tip is to ask in parallel to change brightness of some lights around during the pairing. (Sounds like a grandmother tale but that works for me)
I feel I’m reaching the limits of everything as I feel more and more mini delays when sensors switch lights, but it’s still perfectly acceptable.
So i put my HA house take over on the backburner quite some time ago, when I encountered relentless problems with deCONZ not persisting all connections through restarts and shutdowns, which can happen a fair bit when setting up and fiddling with HA. I was consistently having the delete and pair switches, and then all automations related had to be fixed on top of that. I’m giving this a second go, and it looks like ZHA has matured some-what too, so if deCONZ haven’t uped their game which given its still a clumsy VPN setup, I doubt it. Also reading this: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Network-lost-and-configuration-restore-does-not-help and this “This method cannot be used for the Home-Assistant add-on and no current workaround is known. This also includes the button in Phoscon within the addon.” (soruce: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually) is not filling me with confidence!
You have to consider that they are cooperating with those responsible for the different container setups, neither the docker nor add-on are officially supported by the manufacturer but created by the community.
Yep! Although the whole point of docker and deconz having a REST api is to containerize and allow separation of concern, well at least I would have hoped .
So having updated everything and everything else just working, my switches never came back to life on the ZigBee network. So they get one more chance with deconz otherwise I’ll see what ZHA is like.
I’m also using deCONZ about 4 years now, and it works flawless with about 90 devices. Running as hassio addon keeps everything separated from HA core; when i upgrade HA lights / switches etc are still working. Also i have disabled automatic adding of devices, so i can first rename them in Phoscon followed by a reload of the integration afterwards.
I was using HA to activate lights based on motion sensors and switches, but the program evolved a lot the past years; now all rules are made within deCONZ instead of HA / AppDaemon.
Apologies for the late response. I live in Europe and I notice that a lot of generic brand of smart lights sold in para pharmacies, and some big local general stores (in holland: Hema, Action, Kruidvat) they all sell either their own brands or weird ones but they all have a
icon. So far I’ve been able to onboard all of them to the Smart Life app as a piece of cake. If you search on amazon for “tuya” you can find a lot of them.
.