I wanted to set up some home automation based on my phone connecting to wifi, but parsing dhcpd's lease file didn't seem cloud native enough, so I implemented this. Surprisingly, it actually works, is concurrency safe (you can legitimately run two of them on the same network, and you'll not corrupt the etcd state. I mean, I pity the clients that have to deal with that network, but eh), and um, is almost useful.
I would not recommend anyone use this for anything other than entertainment.
> I would not recommend anyone use this for anything other than entertainment.
For what it's worth, we used a similar setup at a previous huge employer, but using powerdns with a custom backend adapter that hit a zookeeper cluster, serving a tiny subset of our DNS records (with really short TTLs so that changing ZK resulted in prompt DNS changes). We used this for Real Work, and it worked really well.
Shall write it today. Don't know how useful it'll be to people. Plan is to turn on door/hallway (Hue) lights when my phone's mac address shows up after having been gone for 15 mins (I have a low lease duration, which gives better granularity). Then poll a (Hue) motion sensor on the stairs to know when the lights can be turned off.
Shall also have to do some stuff to correlate brightness with time of day.
If it is for executing some script on successful connection of any device to wifi (and thus an IP is assigned), with dhcpd, it can be achieved with the following config:
subnet 192.168.1.0 netmask 255.255.255.0 {
on commit {
set ip = binary-to-ascii (10, 8, ".", leased-address);
execute ("/usr/local/bin/on-device-connect", "commit", ip);
}
}
I have setup exactly this to automate stuff unlocking the door in my office (in the morning, whenever some one arrives and phone connects to wifi).
More seriously, part of the reason I did the project was to see if I could have things react to the dhcp server, and not have the dhcpserver run things for me. No good reason, other than wanting all the components in my home network to run in their own VMs, and so having everything talking via etcd is convenient.
That said, if I didn't have copious amounts of free time, I definitely should have done that.
I wish someone would make a production ready and resilient version of this as it looks really nice - having all your config in a standard key-value store makes management so much easier.
Interestingly enough, you don't need anything like this if you want HA-DHCP. The DHCP protocol actually allows you to have multiple DHCP servers answer the same request, and if they do it in the same way, then it won't cause any flip-flops. This usually works best when all the IP's are mapped to mac addresses statically, and usually you have a multi-master DHCP setup sharing a VIP for example.
14 comments
[ 3.1 ms ] story [ 34.4 ms ] threadI would not recommend anyone use this for anything other than entertainment.
> I would not recommend anyone use this for anything other than entertainment.
For what it's worth, we used a similar setup at a previous huge employer, but using powerdns with a custom backend adapter that hit a zookeeper cluster, serving a tiny subset of our DNS records (with really short TTLs so that changing ZK resulted in prompt DNS changes). We used this for Real Work, and it worked really well.
So I think your approach is probably fine.
Shall also have to do some stuff to correlate brightness with time of day.
Hate to disappoint you, but I have to try this together with NFQUEUE to power a distributed computing cluster.
I will even use the lease information to implement a host-side firewall, BCP-38 style!
maniacal laughter
My original source: http://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-...
Edit: Fix code formatting.
This is the lock that Im using: http://www.ebay.com/itm/12V-Electromagnetic-Door-Locks-Magne... . Its electromagnetic and not a turn lock.
And the actuator that I built to control the lock is something like this: https://www.tindie.com/products/Armtronix/wifi-esp8266-solid...
The callback script in the dhcp server pushes an event to a mqtt broker on dhcp commit event.
And all of these orchestrated by home-assistant.io, on top of which, we have also mobile and voice (alexa) integration too.
More seriously, part of the reason I did the project was to see if I could have things react to the dhcp server, and not have the dhcpserver run things for me. No good reason, other than wanting all the components in my home network to run in their own VMs, and so having everything talking via etcd is convenient.
That said, if I didn't have copious amounts of free time, I definitely should have done that.
[1]: https://www.isc.org/kea/
Happy hacking!