If I’m the one to create the Binding, I would use UDP/multicast. This way we can create a custom contract (for autodiscovery) between OH and other future devices (ESP or not)
But why is auto-discovery really needed?
Just create your items using the MQTT binding with the topics you have created in your ESP8266 and you are done.
Because not everyone uses MQTT. Hence, we have 300 Bindings available.
For what? If for autodiscovery, sounds like standard approach. But I assume this is only the beginning of such new binding development.
I think @Revestroke wants to have the autodiscovery for his devices which would add dedicated things with appropriate channels for each of them.
Because it is more convenient than editing text files? No need to access OH machine directly. No need to know the right syntax for each file.
I don’t think anything exists currently but a binding of some sort would likely be a good option.
Seems lots of users are handling client devices via MQTT connections which is fine although it does appear we are all rebuilding the same or similar solution each time.
Just saw @rlkoshak post here: Mozilla Web of Things
Haven’t looked at it beyond a 10 minute glance but it could be the foundation of something more standard and structured for all to easily reuse. But as said it’s early days and you’d have to do the ground work for most of it yourself but if you had the interested in doing something along those lines anyway then why not do it inline with a standard that will hopefully get adopted overtime. It also has likely done a lot of the architectural thinking for you as well.
-I have coded Esp8266 chips by providing ssid and password for my WiFi network, thereby declaring mqtt server IP that is of Raspberry Pi as Openhab installed.
-The respective Esp8266 right now are hardcoded with the same network and they are communicating with openhab nicely.
-Issue: I want to use this smart home system in another place where network differs. Now here comes the need for Smart Things… Not everytime I can code the Esp8266 chips by changing ssid and pwd. So need to discover by coding in such h a way that they can be used as smart things and then detected by openhab server automatically either by any binding or by adding in things file.
-Samsung smart things and sonoffs are like that… One can just power them up and can set to different networks, as the server auto detects them. I am interested to do the same with Esp8266 and Openhab.
So you need something else I think. You need AP mode for your ESPs and some protocol to send your network settings using HTTP. This is how sonoffs work and I guess other WIFI devices as well.
You can look at tasmota sorce code how this is achieved. Basically by long pressing a button the device switches WIFI to AP mode with own private network and starts an HTTP server. Then you connect to that network and send to the server your network settings (SSID, password). After that the device changes the WIFI to client mode and connects to your network. That’s it. If you have properly configured OH server everything should work fine after that.
Wouldn’t something like a homie binding - which would support autodiscovery of esp devices.
If your main problem is that you don’t want to code the ESP if you need to change the WiFi setting, maybe that could help:
Its made for ESP32 but maybe it will work with ESP8266 as well.
This comes with a web interface where you can set WiFi and MQTT Broker settings.
When you change the location, just reset it 5 times and the ESP will automatically create an Access point where you can change the network settings again.
Exactly, and if you’re not too concerned about using MQTT, but more about configuring without having to upload new code if you move it, I would definitely check Homie library 
It allows you to just have to focus on the logic of the sensors programming. All the configuration is done by a JSON file pushed externally.
Basically at first start your ESP8266 boots in configuration mode, creating an Access Point. Connecting to this access point gets you to a web interface where you have to put your wifi credentials, mqtt broker location, and every custom settings you enabled. Then it reboots in normal mode. The code is very independant of your local configuration
And it also supports OTA so you can update firmware remotely…
This is a very modular solution, but no autodiscovery though 
Imo you would need to implement a custom binding if you really want it.
I have just done a similar thing and yes it needs to be a binding with the eclipse tutorial covering what you need to do to create a discovery service in your binding.
The way I did it was use mqtt and use retained messages, then when the discovery service connects to the broker it gets a full list of all your devices as topic:payload format you then need to write code to take that info and anncoince to openhab u have found a new device.
The learning curve is high at the start but once learnt it is very easy.
All of my ESP8266-based devices use mDNS/SSDP to announce themselves on the network. That makes them show up in Windows in the Network Devices (which means you can double-click on them to get to their web pages), and also makes it super trivial to write an OpenHAB binding to find them.
Its definitely the best route to go to for simple management. If I deploy new devices, they just show up, if they change IPs, they just pick up the new IP, etc…
There’s tons of examples of using SSDP on the ESP8266. And the ESH/OpenHab2 docs have samples for bindings to use SSDP.
That’s exactly what I said above. Braodcasting using UDP is easy but still, you’d have to manually do it in openHab. If we can come up with a protocol, we can have this done automatically by openHab. The thing is we need to create a contract between the devices and OH so that devices will broadcast it’s device type and OH would know what to do, which methods to retrieve states, and how to update states. Doing it this way, it would be easy to autodiscovery stuff much like how the zwave binding work.
Your basically describing UPnP.
A generic UPnP plugin would do that if your hardware exposed it. It’s how most media controllers work, Sonos, all the Vera home automation devices, etc…
is there some progress in here ? i’m using the espurna firmware on my esp8266 devices. i would love the idea that i switch them on the gets visible in inbox and expose there channels…
could someone point me in the right direction ? at the moment i use the rest api, by using mqtt, i havent until now, would the be visible in inbox and all that stuff of automatic item linking ?
I’ve got a binding that isn’t really in any shape to commit to OH yet that I use for most of my ESP8266-based systems in my house (around 20 of them).
They basically use mDNS for autodiscovery, and a standard JSON payload (easier than full UPnP) that tells the caller what the available services (and therefore, channels) are.
Its on my list to get back to at some point, as I make an upgrade pass through the firmware on all these devices. I’m hoping to get a combination of an Arduino library and OH2 binding that handles bidirectional services and autodiscovery. (The reason the stuff I have is not sufficiently generic to commit to OH is that they use a combination of HTTP, raw TCP, and UDP interfaces, and its too convoluted and use-case specific at the moment.)
That said, you can do a lot of it right out of the box – if you set up an mDNS discovery endpoint on the ESP8266, you can set a specific hostname to get advertised, and you can use those hostnames in the TCP/UDP binding (with the caveat that the TCP binding is a festering pile right now, and has memory leaks).
Basically, if you expose your device’s hame as “mydevice-{chipId}” or something, where chipId is the ESP’s internal ID, you’ll have a fixed hostname you can use in a TCP channel, so you can do something like:
String MonoPrice "MonoPrice Amp [%s]" (MonoPriceGroup) { tcp=">[monoprice-13997243.local:1001:]" }
That’s taken from a set of items I use for controlling a whole-house audio amp. The ESP’s hostname is “monoprice-13997243.local”, and OpenHab can connect to it just fine. Its not really auto-discovery, but at least the address is stable even if I don’t use static IPs. Basically the device shows up as {hostname}.local
I started some project recently, just to reduce number of modifications after each configuration change on ESP device or in home network. I may not be the easiest solution on the earth but it works for me, so maybe it will work for you 
Take a look at https://github.com/adrb/mqradar
Would you have link to how to setup mDNS? - I am struggling with the same issue and do not want fixed ip for my mqtt broker.