Power cut recovery

I have found that mDNS can also assist here to make the devices no longer require a reserved DHCP entry.
I used to set up my devices such as my Xiaomi Gateway, and Sonoff modules with a fixed IP address which was accomplished by setting up DHCP IP reservations in my DHCP server.
Now instead I enabled mDNS support and advise OH of there mDNS address and use that for web access also so no need for them to await for DNS.

It does bring an interesting point up though. If for some reason a device such as a sonoff module powers up prior to the DHCP server being available even with mDNS configured it still needs an IPv4 addrwess (its what I still primarily use), as I do not want to go to setting static IP addresses on every sonoff and managing them, I am trying to move away more from manual address management and more towards zero config then the Sonoff will evbentually timeout and give itself an 169 address. So should I therefore also add a secondary address on the OH server in the 169 address subnet so that it can talk to these early devices?

Anyone have any thoughts on this, best practises?
I am off to do some research on the subject to see what others have come up with.



Does Sonoff implement APIPA? I thought that was only a Windows thing. A quick search for “tasmota apipa” didn’t really bring anything up.

APIPA is the protocol that assigns you a 168.254.x.x range IP address when there is no DHCP but I don’t think it is universally supported.

That could put a damper on your plans.

But if the devices do implement APIPA, then the device should periodically check for a DHCP server after getting assigned the 169 address and will switch to what the DHCP server gives out. So you really wouldn’t buy much I think by putting your OH server on the 169 subnet in addition to your regular subnet.

I don’t know what best practices are but I can say what I do which is the manual approach. I have about 20 IP addresses in my dynamic pool that gets handed out to new devices/guests. When I have a new device I log into the firewall (I use pfSense), bring up the table of leases, click the + button and give that mac address a host name which will update the local DNS, and static IP (all done from the form that pops up when I click the +). Then the next time the device joins the network it will get a “static” IP and I can access it by hostname, which is what I primarily do anyway. Depending on what the new device is or what I’m doing at the time I may reboot the device immediately or I might just wait until it happens naturally.

I have around 60 devices (some of which are gone and I should remove them at some point) but when I initially started doing this I had around 20 devices and growing the list is not all that much work. I usually only have to add a new static mapping a couple times a year now and it only takes a couple of minutes. I split up my address range into chunks for no other reason to make it easier to find devices in the list. If I were to do it over again, rather than using a single Class C subnet and breaking the 2-255 range into chunks I would set up something bigger and use the second octet to split the IP addresses. For example, instead of using X.X.1.120 to X.X.1.130 for computers and VMs I’d use X.X.2.X. I’ve found that I’ve made some of my “chunks” too small and others far to large that will result in some overlap or forcing me to clean up in the near future. Maybe I’ll do that anyway some day.

afaik APIPA is part of the DHCP client, but if tasmota does not receive an ip address through DHCP, it will reboot, so instead of using an APIPA address, it will try alternative ways for configuration (i.e. second WLAN SSID/Password, boot in AP-Mode…)

There is a great post in this thread on zeroconf, and describes Windows/MACs and Linux veraients.


To specifically address the sonoff issue.

Looking around the Tasmota forums I have put together this understanding which I will need to test.

The objective for me is to

REQ1. Have dynamic low maintenance connectivity.

This means I need to move away from the setting of static or reserved IP addresses. I cannot use DHCP scopes or other ‘fancy’ options either as the existing Google Wifi does not support them and I am not looking to change this mesh system just yet.

REQ2. The sonoff module should use a name rather than an IP address to discover the MQTT service.host.

REQ3. The sonoff module should be locatable using its name for web browser access, and not require the IP address to be known.

Objective/requirements defined, and constraints understood lets look at the sonoff module capabilities.

SOL1: The use of mDNS and careful initial configuration of the sonoff module using either precompiled binary with the correct options set OR using the console will meet this requirement.

SOL2: Run avahi-daemon on my Linux MQTT host and advertise the hostname, Then use of mqtthost.local name in the sonoff UI rather than setting a hard coded IP address. There is an issue around that said the modules were not resolving DNS for this parameter so this need testing.

SOL3: The WEBSERVICE should be advertised using mDNS by the modules configuration, this can be done using console options and once again there are some issues open around this space so it needs testing.

The behaviour of the DHCP client is down to the underlying arduino code base rather than tasmota.

Using the solutions below and also setting mDNS service to enable on all my sonoffs using ‘SetOption55 1’ command in the console. I also removed all the reserved addresses from my DHCP server and ensured the size of the lease range was increased to cope with all these new devices that would be using DHCP.

I have my linux based OH system advertising itself as openhab.local using the default avahi-daemon config as its hostname is set as openhab.
I then use ‘openhab.local’ as the MQTT hostname in the sonoff modules configuration and they discovery the Openhab server IP address dynamically.
I have not looked to see if the MQTT service could be advertised separately.

I use tasmota v6.5.0

I decided to use avahi for linux and pfsense and bonjour for windows 10.
I set up the sonoff modues with mDNS enabled and the hostname set to a defined naming scheme, in my case its XXSOY where XX is an abbreviation for the location SO indicates its a SonOff and the Y is a numerical instance number.
e.g. HOSO3 which is the third Sonoff in my Home Office.
The sonoffs are seen on the LAN using their mDNS name e.g. HOSO3.local
and putting the address http:…hoso3.local takes me the web service on the sonoff module. Note that I installed the avahi package on pfsense and configured it under services. I installed avahi-daemon on the linux boxes, and left their default config.
Now on my windows 10 client I initially could not resolve hoso3.local, this is because Microsoft have included their own mDNS service running on port 5353 and it doesn’t play nicely with others. So I followed the instructions here and added the registry entry, reinstalled bonjoir and all is well. I will look at other devices such as Android TV around the house and make sure I enable mDNS support where ever I can. It is still not 100% clear to me if win10 needed all the steps suggested above, but it is working for me.

There are also some good mDNS/Avahi/Bonjour/ZeroConf browsers available and I found them useful to use when testing, on windows I used the one found here.

So with everything working for normal cases, I will have ago at setting up my test environment to investigate the behaviour of the sonoff modules when no DHCP server is available.



1 Like

I have tested the arduino based tasmota sonoff modules DHCP client behaviour and found that it never uses the 169.254.x.x. address range.

Versions tested:

Program Version 6.5.0(sonoff)
Build Date & Time 2019-03-19T12:47:29
Core/SDK Version 2_4_2/2.2.1(cfd48f3)

It performs a around three DHCP discoveries and then waits around 180 to 200 seconds and does another three discoveries, rinse and repeat.

Therefore there is only two states to consider IP address is as provided (static or DHCP makes no difference). OR no IP address and the unit is unusable, this can only occur if the unit is DHCP enabled. There is a static IP state where the configured IP address is no longer aligned to the infrastructure and so is unable to contact anything or be contacted, this is a typicall transition scenario when the address range is changed.

By opting to NOT use static IP addresses on the sonoff I put a dependancy on DHCP server and DHCP addresses available to be allocated, in return I have less administration tasks. As that is my objective I am ok with that trade off.