Success! I'll try adding my door sensor and alarm and see if it works 
You probably can't even install the required packages for extroot, as the kernel modules are statically linked and will not match the exact kernel version. When using OpenWRT snapshots, you have to hurry to install any required modules on the same day, as they will be rebuilt for a different kernel on the next day.
But this device is not even in the snapshots yet, Pull Request #2998 is still pending.
So, you either have to build it yourself (including all the packages for extroot, Domoticz, openzwave) or wait for the pull request to be merged (so you could use the official snapshot builds).
This is actually really annoying, but that's just the way it is with OpenWRT and newly-added devices...
I understand, I'm quite happy that I can actually run OpenWRT on it, was thinking to just get rid of it as the cloud service for it is long gone. I'll probably start tinkering and building it myself with the required packages, thanks for the insight!
Is it actually? Amazing, I wouldn't have expected them to render those hubs useless this quick.
I've never even tried to sign up for the cloud service, but that explains why I found so many of these hubs on ebay quite cheap over the last years 
I stumbled on those devices when looking into Z-Wave (for the Danfoss heating thermostats, as the current eq-3 System I'm using is garbage, it often fails and would leave the heating on full power over the weekend etc.), but the Z-Wave UZB Dongle was (and is) quite expensive, not even speaking of the official Danfoss Control Hubs... So I found this device with the same hardware as the UZB dongle, but a lot cheaper, because people throw them out on ebay since they can not use it with the crappy D-Link cloud service (which imho only supports the 3 different Z-Wave devices offered by D-Link).
The first thought was, just cut the usb traces and solder a usb cable to use the Z-Wave Dongle with a Raspberry Pi 
But it turned out OpenWRT runs well on this device, also it has a great wifi range (also thought about using it for gluon / Freifunk).
Regarding Z-wave, there's basically the option to use Domoticz with openzwave, but that needs extroot for storage, or use it as a simple forwarder (e.g. USB over TCP? but that would be not much different to "cutting the traces", except it would consume even more power )
I'd be happy about any solution to actually use Z-Wave on this device, but for now even the openzwave package became too big (they included device pictures). Currently I'm hoping the pull request will make into v20, since it will be a lot easier to install extroot on an official release. Hope this still happens before the winter comes 
1 Like
Great hack idea right there! I couldn't make it work at all even while creating a new account, setting up their rubbish app and even contacting support and trying gazillion versions of the firmware.
Turns out they screwed the cloud service in some way and they won't even bother with it anymore as the unit is discontinued. So you can imagine having bought the entire package, door sensor, sound alarm and a security camera, but no functional cloud and app 
I ended up buying a Z-Wave USB stick (ouch costly) that I was running with a Pi4 and Home Assistant. Worked quite OK, but I wanted to free the Pi and use it on other projects hence why I'm researching in adding a bit of life to this crappy hub.
So you can imagine my surprise and excitemend on it even running OpenWRT
I will keep lurking here for any possible updates.
Since this device is now officially supported (at least in snapshots), I've cleaned up the wiki to remove most of the experimental stuff about creating factory images etc. 
@vasquez I was also successful to connect my Z-Wave devices to the hub, and - finally - turn this thing back into what it was meant to be 
Current progress of documentation:
https://openwrt.org/toh/d-link/d-link_dch-g020_a1#controlling_z-wave_devices_via_domoticz
Just need to figure out how to set device permissions for ttyACM0 on reboot... Since there is no udev in OpenWRT, this happens via hotplug.d, but it seems the scripts are called only after the domoticz daemon would start, so it cannot access the Z-Wave controller in the first attempt upon reboot 
1 Like
Guys, I'm doing something wrong, please help me.
I'm uploading to the hub this image: openwrt-ath79-generic-dlink_dch-g020-a1-squashfs-factory.bin
The upload works fine (using normal procedure or the recovery, same behavior) but after reboot I cannot find the Hub using ping (I've made a DHCP reservation for Hub's MAC Address).
What I'm doing wrong? Thanks
OpenWRT uses 192.168.1.1 as the default IP address after flashing, with DHCP enabled.
Both Ethernet ports are defined as LAN for this device, so it will not automatically connect to your network via WAN port either (besides this would only result in a NAT cascade for devices connected to the router).
So, before connecting it to your network, connect it directly to your computer and ssh into 192.168.1.1 to update network settings via uci (there is unfortunately no LuCI in snapshot images, so this needs to be done via ssh), I agree this can be quite annoying...
Should be something like
uci set network.lan.ipaddress='192.168.xx.yy'
uci set network.lan.dns='192.168.xx.zz'
uci set network.lan.gateway='192.168.xx.zz'
uci set dhcp.lan.ignore='1'
uci commit
/etc/init.d/network reload
xx.zz being your main router's ip, yy the DCH-G020 ip.
You should then be able to
opkg update
opkg install luci
Thanks @s_2,
The problem is that I cannot ping/SSH into 192.168.1.1 nor 192.168.0.60. The status led is solid green but I cannot ping the hub on none of the two ethernet ports.
Do you receive any ip address from the device via DHCP? Maybe try to set a static one for your computer first, e.g. 192.168.1.100.
Also, if there are other network interfaces using addresses from that range, try to disable these first (e.g. wifi); this is however mostly a problem on Linux machines rather than Windows.
Thanks @s_2, it looks like I wasn't patient enough: my laptop got an IP address in range 192.168.1.x in the end.
I was able to change the bridge IP address to fit into my home network and also I've managed to install luci package. I can browse hub's web interface without any issue.
Now, another problem: the image I've downloaded from your website is too old ( r13148) vs the latest available 19.07.5. You said in a previous message that the newer openwrt images/snapshots should work without any modification on this hub. I've tried to find the right .img for my hub but I got lost on so many releases variants. Can you please indicate what I'm supposed to download from here? https://downloads.openwrt.org/releases/19.07.5/targets/ath79/generic/
Thanks a lot for your time
v19.07.5 is actually older, it is just a bugfix release for the v19 branch. The DCH-G020 was added in May 2020, so it was not included in the v19 releases; even if the release date is more current, newly-added devices are usually not backported.
So there is currently no official image with LuCI, but until v20 is released you can use the latest snapshot image from:
https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-dlink_dch-g020-a1-squashfs-sysupgrade.bin
You can flash this from LuCI with the "keep settings" checkbox enabled. After flashing, you will need to opkg update && opkg install luci again via ssh, but this is not so much of a hassle anymore now since all your ip settings are kept, so it will be reachable from your network and have internet access to download packages.
The snapshots are rebuilt every night, this means any packages linked to a specific kernel version can only be installed on the same day... So, make sure to install everything else you need besides LuCI right away.
Hey, I just followed your guide and I got everything working except domoticz. It's not available in the daily snapshots anymore. I've tried installing it manualy but either I get an architecture mismatch error or the version I managed to install (domoticz_4.9700-3_mips_24kc.ipk) doesn't like Python3.7 that's installing alongside... any ideas?
Interesting, I had installed this back in August last year and it's been running since... now indeed the package has vanished from snapshots, so it seems there would be no way to even reproduce this setup.
The last commits in the packages feed regarding domoticz were about fixing build issues, adding support for Python 3.9 etc...
I guess I'll try building an image with the package later, and see if there's any useful error during the build.
Technically, it's not even possible to build a sysupgrade image for extroot, so even if building the package itself would work, you would have to install it manually... and as far as I recall, this has a lot of dependencies, you really don't want to install these manually... 
This is really annoying, sorry you can't use the device for now 
It seems the domoticz package is flagged as BROKEN, but you could enable building in menuconfig "Advanced configuration options (for developers)".
Apparently this was introduced by:
when the dependency minizip was set to @BROKEN
Unfortunately, the build fails already when trying to build libftdi, which is required by telldus-core, which is selected automatically by domoticz (to support some USB dongle called telldus) when the BROKEN flag is set...
I guess it could be expected to see some other things break as well, as soon as you enable build of broken things 
So, I have no clue how to proceed from here; I'm not exactly sure if the minizip dependency is actually the issue, i.e. whether to raise this issue within https://github.com/openwrt/packages/pull/15012
// edit: minizip itself builds fine when selected manually, also when manually removing the lines
depends on BROKEN and select PACKAGE_telldus-core
from ./tmp/.config-package.in it still breaks for the missing dependency libftdi, which cannot find libusb as a dependency, so it seems we have to figure out what's wrong with building libusb first...
// edit #2: it seems to be related to
Policy CMP0021 is not set: Fatal error on relative paths in
INCLUDE_DIRECTORIES target property. Run "cmake --help-policy CMP0021" for
policy details. Use the cmake_policy command to set the policy and
suppress this warning.
1 Like
Great find @s_2! I've just installed a fresh snapshot and I'm trying to install this older package hoping dependencies will resolve https://downloads.openwrt.org/releases/19.07.7/packages/mips_24kc/packages/domoticz_4.9700-3_mips_24kc.ipk but I'm getting an incompatible architecture error 
root@OpenWrt:~# opkg print-architecture
arch all 1
arch noarch 1
arch mips_24kc 10
root@OpenWrt:~# opkg install domoticz_4.9700-3_mips_24kc.ipk
Unknown package 'domoticz'.
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for domoticz found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package domoticz.
Do you remember what version of domoticz were you were running in August?
A bit further digging into the package's control.tar I get this:
Package: domoticz
Version: 4.9700-3
Depends: libc, boost, boost-date_time, boost-system, boost-thread, libcurl4, libmosquittopp, libopenssl1.1, libopenzwave, libsqlite3-0, libstdcpp6, zlib
Source: feeds/packages/utils/domoticz
SourceName: domoticz
License: GPL-3.0
LicenseFiles: License.txt
Section: utils
Require-User: domoticz=6144:domoticz=6144
Maintainer: Stijn Tintel <stijn@linux-ipv6.be>
Architecture: mips_24kc
Installed-Size: 9474046
Description: Domoticz is a Home Automation System that lets you monitor and configure various devices like: Lights, Switches, various sensors/meters like Temperature, Rain, Wind, UV, Electra, Gas, Water and much more. Notifications/Alerts can be sent to any mobile device.
The version info just says "2020.2", but according to uptime this must have been setup sometime in january rather than august I think after initial testing I still wanted to wait for a stable release of v21 for productive use, but then the weather became colder and I just set it up anyways using a snapshot 
It's probably easiest to just wait until someone fixes compiling for libusb; not sure how much can be achieved but just messing with the cmake_policy command here.
1 Like