I have setup HA Core and deCONZ in Docker containers and this seems to be working really well.
My next step is to enable Alexa integration (Which I have working) but I don’t want to do this whilst deCONZ is running over HTTP.
My first question is whether anyone has attempted to add any security to deCONZ?
Having had a poke around it appears that the web server for deCONZ is embedded within their code rather than a separate thing I can add a certificate to which makes me think the only solution is to create my own docker image that includes an Nginx install to proxy requests and only expose this outside the container.
This should work fine for the web interface but I am not clear how HA interacts with deCONZ. I have a feeling this uses websockets and whilst they are running on port 443 I understand these are standard http websockets not WSS???
So I guess at this point I am reaching out to understand how the integration works and whether I might be able to tweak it (eg. could I change the ports without breaking anything, could HA cope with communicating over HTTPS?)
You could just isolate the container in which deCONZ is running in to be on the same internal docker network as HA. Though this could possible create other issues that would also have to be solved. And you would loss access to its GUI.
But why do you feel you need to secure it on you local network?
I am running the home automation containers on a macvlan network to segregate things along with a bunch of IoT devices so to some extent it is already isolated
I need GUI access to add new devices but I guess this can be added as and when needed.
I work in Cyber Security so I have unhealthy paranoia but it only takes one badly behaved IoT device for someone to gain access to your network and sending passwords around in clear text makes them pretty useless.
The other way of looking at this is if you are sending passwords, why wouldn’t you secure it?
In terms of HA connecting to deCONZ, is this over websockets ?
That is what I was looking at yes. The issue is making it so the reverse proxy can access deCONZ but nothing else (Hence why I was thinking about taking the deCONZ container and adding an Nginx reverse proxy in there and keeping everything inside that container.
Will check out the rest API as I suspect this will only cater for HTTP and there is nowhere to define trust for certificates.
Unfortunately i don’t think it is possible as the HA integration that communicates with the gateway have no setting for using HTTPS. and therefor putting in a reverse proxy in front of it will make it fail.
But i agree that this could be awesome to have. Hope you find a solution a please post it here if you do
Rather than deconstructing/reconstructing the deconz container, I’d go a different route and use zigbee2mqtt and secure both the webinterface (which is simply a nodejs app) and is easily able to be changed over to https with minimal effort and then set it up to use MQTTs. Then, in HA, enable the MQTT integration using the same MQTTs server.
The nice thing about this is that it is both secured and decoupled. Therefore, should you get a bad actor within your IoT network (which should really be on a firewalled, segmented VLAN for maximum security), there’s multiple layers of protection rather than trying to hack together a solution that is going to leave you unable to upgrade the deconz integration without a lot of work on your part.
How does that compare in terms of speed of update and reliability (Particularly with a Conbee II)? From what I have read it isn’t quite as stable as deCONZ and there is a noticable lag when turning on / off lights??
I did have a quick play with ZHA but that didn’t seem to play as nicely as deCONZ but haven’t tried Zigbee2MQTT yet
I want secure apps, the wife wants 100% uptime and responsiveness
Network is segregated and firewalled but currently deCONZ and HA are on the same VLAN as IoT devices hence why I would prefer them to be remotely secure (especially given that the web server for deCONZ either looks bespoke or old)
I actually just updated over the weekend from a ConbeeII to a CC2652p2 coordinator (https://www.tubeszb.com/product/cc2652p2-based-zigbee-to-ethernet-serial-coordinator/1). However, on my mesh, speed has never been an issue. My sensors and lights are on/off within 500-1500ms. Same for reliability. There have been instances where some Ikea devices tend to destroy a mesh (very well documented), so I have been steadily removing them and replacing them with better devices. All my other sensors, locks, lights and switches all respond nearly instantly.
Mostly when you hear someone say they have “noticeable lag when turning on/off lights” it is 99% due to them not having a well formed mesh. Zigbee requires a solid mesh with an appropriate amount of repeaters and routers, especially with a tiny device like the Conbee that is constrained by both CPU and RAM. With that said, if you plan your Zigbee mesh accordingly, your devices will respond pretty much instantaneously. The added overhead of MQTT might add a few ms to the response time. But, so long as you have a halfway decent internal network, you’ll never notice it.
As for reliability? I’ve been running z2m for a couple of months now and it’s never crashed on me or faltered out aside from some Ikea devices misbehaving and flooding the mesh with messages.
OT… My Zigbee mesh is currently 21 Ikea GU10 bulbs plus four or five Ikea switches / sensors… I must admit I hadn’t come across this issue but there again I have arrived at HA in an attempt to replace the Ikea hub which seems to not be that stable…
Are the problems with all the Ikea kit or just the switches / sensors?
The bulbs should work as routers yes?
Only in a ZLL only mesh should bulbs act as routers. Otherwise, no, bulbs should never route, especially in a busy mesh (50+ devices). It boils down to the fact that bulbs have a tiny amount of memory and often get switched off which leads to issues within the mesh, not to mention the fact that they can only repeat for a few (<5) child devices.
Yeah, the Ikea Gateway is pretty much a throw-away item. Up until about a year ago, people really only kept them around to perform OTA updates on Ikea devices. But now that nearly all the Zigbee coordinators can perform OTA updates on their own, there isn’t much need to keep them around.
If you are using ONLY Ikea and/or Hue devices, you’ll be fine with HA and any of the Zigbee controllers (ZHA, deconz, zigbee2mqtt) as you would be running an entire Zigbee3.0/ZLL profile mesh. If you start putting in other devices that are ZHA profile devices (anything from Sengled, Aeotec, and most other Zigbee manufacturers), that’s when you might start running into issues. ZHA and ZLL profiles can work together, but some manufacturers (namely Ikea and Hue) decided to forge their own path in the Zigbee spec and do some weird things with messaging between the two profiles that causes headaches.
but haven’t tried Zigbee2MQTT yet