DIY DynDNS With ESP8266 And Dweets

You’re on a home router, and your IP address keeps changing. Instead of paying a little bit extra for a static IP address (and becoming a grownup member of the Internet) there are many services that let you push your current IP out to the rest of the world dynamically. But most of them involve paying money or spending time reading advertisements. Who has either money or time?!

[Alberto Ricci Bitti] cobbled together a few free services and an ESP8266 module to make a device that occasionally pushes its external IP address out to a web-based “dweet” service. The skinny: an ESP8266 gets its external IP address from and pushes it by “dweet” to a web-based data store. Freeboard reads the “dweet” and posts the resulting link in a nice format.

Every part of this short chain of software services could be replaced easily enough with anything else. We cobbled together our own similar solution, literally in the previous century, back when we were on dialup. But [Alberto R B]’s solution is quick and easy, and uses no fewer than three (3!) cloud services ending in .io. Add an ESP8266 to the WiFi network that you’d like to expose, and you’re done.

38 thoughts on “DIY DynDNS With ESP8266 And Dweets

    1. You should look into that, I thought so as well. Turns out that for many providers the business plans are cheaper due to not bundling often useless crap like wifi hotspots, extra TV, online streaming and other garbage onto their plans. I was Originally paying 49.95EUR for a 150/15. Now I’m paying 53EUR for 180/30, and the far higher upload speed is worth the 3EUR just by itself.

      1. My closed down ISP router is only able to link to paid services as a build in feature. While his way of doing it is free (well, at the cost of an esp8266 and some power).

      1. Prevents ‘unintentionally’ backdoored devices from exposing themselves with uPnP. Though why anyone would leave uPnP running on a firewalled router in a secure environment is beyond me.

    1. Get a cheap domain name. I use NameCheap on mine, and for something like $10/yr for a .info site, I have my own domain that’s not going to be blocked anywhere. And Namecheap has a dynamic DNS service of their own that’s compatible with most home routers, several desktop and CLI apps, and a url/http based api if you have to write your own scripts.

      You can also use it as an ALIAS I think on your domain name’s DNS records, and point that towards your dyndns subdomain. Just make sure you set the TTL to something fairly low (say minutes or a few hours), or it might not refresh fast enough.

      1. As it was, I just got a very cheap static IP vps, pointed my domain DNS at that and proxy through to my home servers. Dyndns, dtdns and another I don’t recall were all blocked.

        And alas it is a thing. Seems to be down to some crappy McAfee corporate firewalling. It also blocks anything it thinks is a parked domain. All for our own good, no doubt!

  1. I don’t get this at all. What’s the point of getting the IP of the IoT device and then trying to pull data from it when you can simply push the data from the IoT device without even knowing the boundary IP address.

    If you try to pull data from the IoT then you have a hole lot of config to do on the IoT side of the boundary IP anyway. By default most firewalls will block this and HTTP requests are probably redirected to a web configuration panel for the boundary router/modem/whatever it is. So you have to make exceptions to the firewall rules or NAT or DMZ.

    1. The idea is that you are behind a router, and are running a ssh server (or whatever server) there. Now your home ip address changes every day and you are at the office and want to ssh to home. How do you reach home if you don’t know it’s ip? Well, by also using this device.
      I don’t know why you won’t run something similar on that ssh server machine, but need a separate device for it. But at least if you use this it’s free. My home router has this feature too, but it can only link with services that cost money.

      Also the article compares this with dyndns, but this is not the same. Dyndns offers you a domain name ( for example, or if you pay more, which it changes the dns records of. He does not have the domain linked to his home address. He can not do `ssh`. He has to open the webpage to find his ip, and then do `ssh`

      1. Yes, but these net based services are for IoT devices.

        Doing it this way just makes everything more complex. Now you have to run DNS queries to find the server that will provide the devices boundary IP and then get that server to pull the data and push it to another server. All of this is dependent on many other factors like fire wall configs.

        Why not just push the data from the device with an outbound connection and be done with it. This will work 99% of the time as the default config on the devices is set to accommodate it and no DNS requests are needed and you don’t need to know the boundary IP.

    1. The good trick for that is to use a cheap/lightweight VPS somewhere and use it as a reverse SSH portal.

      You can use SSH with a reverse port to attach from your internal network to the VPS, then hit the VPS from outside and SSH in. Only worth it if you have more resources from within your home network than you can use on the VPS (such as a large data store or huge compute resources).

      1. I’m with the Oliver on this. “Dweet” for “device tweet” is just dumb. I’m sure it will catch on, but still annoying.

        “ooo my frige just dweeted at me that it’s 40.1F inside!”, or “hold on just got a dweet from my coffee maker, gotta go get my coffee”.

  2. Not really DIY since you still need the dweet service. The DIY bit here is the client end and it appears that you also still need to query someone else as to what your external IP is.

    1. Roll your own “Dweet” style service. It never ceases to amaze me that hipsters are getting rich off of non-novel ideas that are realized by slapping together some buggy node.js app on a VPS container and giving it an annoying name.

  3. Another way is to leverage AWS route53 and the ability to generate AWS credentials with access to only very specific services (in this case, the ability to update route53 records). Then, write a script (or use something like pfsense that has this built in) to periodically check your world-facing IP and update the route53 record if necessary. Assuming you don’t get a lot of traffic, route53 will be like 51 cents a month — still an external service, but I’d rate AWS as less likely to disappear than some random other IoT-service-of-the-week

  4. a bit offtopic but if you’re using something a bit more powerful like a pi, you can setup a tor hidden service which bypasses firewalls, does not need any router configuration. You can even set up a key that makes that service look inexistent to anyone but you. Unfortunatly the documentation around the web on this is not so good, but it’s actually not that hard also.

    1. That triggered my OLAF (Obvious Late April Fool) alert just now.
      Also, does this guy work for Bug Labs? If so, he could (ab)use their servers directly instead of using both their .io services, but I suspect he’s not doing that because he works at the advertising department and desperately needs a way to promote this “dweet” thing and its associated “free”board which is not free (well, it’s free if you don’t mind having your dashboards viewed by strangers).

  5. Don’t assume you have a PC or a Pi running on the site. All I have in my storage place is a pair of crappy-crappy, old-old IP cameras (ddns-less, not upgradable) and this is a viable alternative to buying new ones.

  6. So, i suppose it has it’s usefulness in this ‘dweet’ ecosystem, but freedns can give you a wget/curl link that you could just use with the get command on the esp8266. You would not even need to ipify anything, the server on freedns’ end pulls your ip from the http server’s log.

    1. This sounds great in theory and in theory, if you set you DNS Zone timing correctly it should work like a charm.

      The problem is that most DNS caches don’t adhere to authoritative DNS Zone timing parameters so the whole thing falls apart.

      If you have cPanel then you have a domain and hosting so your off doing it with a PUSH request from the IoT device and cache the data on the server.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.