This component will set up the following platforms.
| Platform | Description |
|---|---|
binary_sensor |
Show something True or False. |
This is a Home Assistant driver for the D-Link DCH-S150 motion detector, which is no longer supported by D-Link. This component does what it can to smack the device into shape -- including the ability to set the backoff time (how long it ignores additional motion detections), the ability to set the Home Assistant polling time (upgrade from prior components), the ability to fix the time zone settings (important now that D-Link's URLs are no longer any good), the ability to tweak sensitivity, and various other improvements.
- Using the tool of choice open the directory (folder) for your HA configuration (where you find
configuration.yaml). - If you do not have a
custom_componentsdirectory (folder) there, you need to create it. - In the
custom_componentsdirectory (folder) create a new folder calleddchs150_motion. - Download all the files from the
custom_components/dchs150_motion/directory (folder) in this repository. - Place the files you downloaded in the new directory (folder) you created.
- Restart Home Assistant
- In the HA UI go to "Configuration" -> "Integrations" click "+" and search for "DLink"
Using your HA configuration directory (folder) as a starting point you should now also have this:
custom_components/dchs150_motion/translations/en.json
custom_components/dchs150_motion/translations/fr.json
custom_components/dchs150_motion/translations/nb.json
custom_components/dchs150_motion/__init__.py
custom_components/dchs150_motion/api.py
custom_components/dchs150_motion/binary_sensor.py
custom_components/dchs150_motion/config_flow.py
custom_components/dchs150_motion/const.py
custom_components/dchs150_motion/dch_wifi.py
custom_components/dchs150_motion/entity.py
custom_components/dchs150_motion/hass_integration.py
custom_components/dchs150_motion/manifest.json
custom_components/dchs150_motion/strings.json
You can do a lot of additional configuration by clicking "Configuration" in the device setup. Some of this is even more than you could do in the initial phone app!
NOTE: Pushing these parameters has only been tested a bit on my devices -- no guarantees it won't screw up your device somehow. But given that these devices are close to dead, anyhow, why not experiment!
Here are some parameters you can tinker with:
| Parameter | Description |
|---|---|
Update Interval |
Sets the polling frequency from HASS. You can set this to any number; it's in seconds (fractional seconds appear to work). Note that the smaller the number, the more network traffic, and the more server load -- but the faster the responsiveness. |
Device Wait |
Otherwise known as "backoff". This is how long the device ignores additional motion, before detecting a "new" motion. By default, this was set to 30 seconds in the device - you probably noticed that it would ignore your motion. If you're trying to get a motion sensor that keeps triggered when you keep moving (this is, I think, the normal case), then set this down low, like 1-2 seconds. Just the ability to bump this down made the device so much better for me! |
Sensitivity |
I'm not sure exactly how this works, but you can tweak it to see how it goes . . . |
Disable Detector |
It's a setting, so I included it . . . but why bother? |
Nickname |
I don't know that this is useful, but it can be set. NOTE: I couldn't get the HNAP command SetDeviceSettings to work, so I couldn't reset the basic device name, which is what would be really useful. If you know the parameters to that command, please let me know! |
Description |
Another one that may not be useful . . . but you can set it on the device . . . |
NTP server |
The device really needs to get to a good NTP server, or it won't work. By default it goes to ntp1.dlink.com. That DNS entry was offline for a while, but recently (2023-03-30) has been repointed to time2.google.com. I default this to time.google.com. |
| Time zone stuff | You should set this all appropriately for your location. |
If for some reason you have a DCH-S150 that you never configured, or if you have to factory-reset your device (hopefully not because you were futzing with parameters with this component!), then you can check out my script here
-
You can probably ignore the rest of the project it’s in. I initially cloned bmork’s cool DCS-8000LH defogger (i.e., cloud remover) project, and started tinkering with that, until I remembered that I’d never been successful setting up my devices using Bluetooth from my phone – so I never got the BTLE stuff to work – and, frankly, you don’t need to.
-
You need to connect your wifi to the access point the device advertises. Afterwards, it’ll probably show up at IP 192.168.0.60. Make sure you can access that cleanly before anything else (you can go try logging in at that IP - won’t accomplish much, but proves you can get there). I do all this from a Linux box - that's probably the easiest way.
-
In theory, this code supports both password-protected wi-fi and open wi-fi. I wrote all the code to work with a password, and debugged it through to the point that the D-Link device was accepting my requests without error, but not connecting to my network . . . and then I finally remembered that I had to set up a whole separate 2.4Ghz open network (filtered by MAC address) for these devices, as they didn’t like connecting to my main network. SO . . . if your network is password protected, this may or may not work for you.
If you want to contribute to this please read the Contribution guidelines
This project was generated from @oncleben31's Home Assistant Custom Component Cookiecutter template.
Code template was mainly taken from @Ludeeus's integration_blueprint template
Couldn't say enough good things about @postlund's original D-Link HNAP integration, which formed the initial base for the HNAP communications!
Some additional work added from @openhab's D-Link implementation
Double-checked against @iobroker-community-adapters D-Link implementation
You can find HNAP documentation (a bit old) here, which was useful for probing the device.
For deconstructing what might be happening in the firmware, take a look at @0xdead8ead's copy of the DIR-865 firmware or @jhbsz's copy of the DIR-850L_A1 firmware -- this was helpful in guessing parameters in general for the D-Link HNAP implementation.
In terms of understanding the authentication handshake, check out the Embedded Lab Vienna for IoT & Security (ELVIS)'s HNAPown for a good discussion of brute forcing the embedded HTTP server.