Roadmap

[furyfire]

I must say I really enjoy your project. Beautiful work.

I made a little list of ideas and suggests that I think would be a welcome addition.
Please notice that I don't use the HomieServer but instead modified your lib to allow for better usage with my own MQTT server.
My wishes will therefor be a little biased :)
If you wish to keep homie-esp8266 and homie-server linked I would most likely still main a personal fork that keeps homie more "generic"

ToDo:

A proper webinterface for setting SSID and password during config mode is needed for less technical users (Hosted on the device)
Let the developer decide if the HomieServer is configurable or fixed.
There should be an interface for adding extra settings during config mode.
Hooks for clearing user settings when device drops into config mode.
SSL and Authentication for MQTT connection (optional of course)
Device should also report a "devicetype" that indicates what kind of firmware it runs. So you can have "temperaturesensor-1.0.0", "weatherstation-1.2.0"
Device should not report itself as "/devices/[devicename]/" but instead report itself as [prefix]/[devicetype]/[chipid]/$devicename to avoid collision between devices set with same name and allow shared MQTT servers
The framework should not include the ArduinoJson lib or the PubSubClient lib. The compiler should include the latest version. (Not sure how intrusive your changes to the MQTT lib has been)
Implement a few standard MQTT callbacks for debugging of remote devices (Read FS filesystem, EEPROM, Pin status, Wifi parameters)
Offline buffering/caching of data using a database, emdb on github looks interresting.
Make homieserver optional, provide documentation, helper functions and code example that shows how to interface with a HomieServer, but make it optional to use.

In the future I hope to see Homie as being the default solution for starting any project on the ESP8266. Include Homie.h configure the Homie instance and write code as you would for any Arduino.
Behind the curtains Homie ensures:

• The device is easy to configure for an end user
• The device can be recovered/reconfigured by the press of a button.
• That it is registered on the server so you know when it's active
• That you are able to communicate/debug/update no mater where the device is deployed
• That in the simplest form nothing is required beyond a free, paid or self hosted MQTT server
• Dead simple design concepts for anyone wanting to develop a server/client/interface with homie-server being the reference implementation

I can help on the embedded code
Any other ideas plans concepts floating around?

[marvinroger]

Thanks for that. This is complete! And I appreciate your compliments. Alright, point by point:

If you wish to keep homie-esp8266 and homie-server linked I would most likely still main a personal fork that keeps homie more "generic"

This is something I've had a lot of feedback on. The initial goal was to create an all-in-one "package" with the client and the server. But I understand ESP8266 devs are hacker and want to cook their own solution in a less tied way. So I want to go in that direction, starting with #7: you will be able to provide your own custom ports for the MQTT/OTA ports.

A proper webinterface for setting SSID and password during config mode is needed for less technical users (Hosted on the device)

Well, there is already an hosted or downloadable Web config available. Hosting it on the device is what I wanted at first. But there are two problems: clean UIs are today kind of heavy-sized, and I am afraid the ESP might not handle it. A simple form would work great, but I want something a bit more user-friendly. The second problem is the user would not only have to upload the firmware, but also the SPIFFS image. This is another step that might be repulsive for the user as this is not a standard Arduino thing.

Let the developer decide if the HomieServer is configurable or fixed.

Fixed by #7

There should be an interface for adding extra settings during config mode.

I am not sure what you mean. You already have access to the EEPROM for your custom settings if you want to. You'd want a function for custom settings that would be exposed on the config UI, that would accept a new parameter in the JSON, and that would be stored on the EEPROM?

Hooks for clearing user settings when device drops into config mode.

You have setResetFunction that accepts a function to be called to clear custom settings when the device is resetted.

SSL and Authentication for MQTT connection (optional of course)

This is a must have, but SSL is not stable enough on Arduino for ESP, so this will have to wait.

Device should also report a "devicetype" that indicates what kind of firmware it runs. So you can have "temperaturesensor-1.0.0", "weatherstation-1.2.0"

I agree with the $devicetype, but it would not be of the form temperaturesensor-1.0.0. The version would be stripped here as there is already a $version property. I would prefer to name it $firmware though.

Device should not report itself as "/devices/[devicename]/" but instead report itself as [prefix]/[devicetype]/[chipid]/$devicename to avoid collision between devices set with same name and allow shared MQTT servers

Why not simply devices/[chipId]/ with a $name property? Sounds cleaner.

The framework should not include the ArduinoJson lib or the PubSubClient lib. The compiler should include the latest version. (Not sure how intrusive your changes to the MQTT lib has been)

PubSubClient had to be modified to accept the input callback to be a method of a class. I can't submit a PR to the original project as Arduino for the ESP8266 and the standard Arduino don't have the same standard libraries and in our case this is a problem. So, we need to embed one libraries, why not embedding three? I know this is not clean but there is no way to declare dependencies for now, and asking the user to download three libraries seems too complicated.

Implement a few standard MQTT callbacks for debugging of remote devices (Read FS filesystem, EEPROM, Pin status, Wifi parameters)
Offline buffering/caching of data using a database, emdb on github looks interresting.

I am sorry I don't understand this one. Could you explain it more-in-depth?

provide documentation, helper functions and code example that shows how to interface with a HomieServer, but make it optional to use.

When the whole thing is stable yes, this will be needed!

[furyfire]

Yeah. I realized now my local version was not up to date with your latest edits.
Lot of the stuff I mentioned has already been implemented.
You make a good point on the web interface.... Maybe that is the best way so far.

And in regards with the settings during config mode that is exactly what I meant. A way for the user to set API keys, some hardware specific settings. Basically anything that doesn't lay itself out to be set from the MQTT server.

I would like to see the devices/ prefix to be configurable via a define if youre hosting on a shared server (great for testing)

With the predefined MQTT callbacks I mean something along the lines of /devices/[chipid]/memory/read where you send a start and a range. And the homie will respond with the data from that memory address. Basically a few low-level calls for debugging, fixing eeprom config, adding a SPIFFS file etc.

Offline buffering I'm refering to a way for the device to buffer data when the network is unavaible and delivering them to thhe server when connection is reestablished. I realize this might be out of the scope of Homie but its natural for homie to handle this when homie transparently handles the MQTT communication abstracting the details away.

I'll be checking out homie again tomorrow

[marvinroger]

Alright, I've added $fwname and $name to the Homie spec. The base topic for Homie devices is now devices / device ID, the device ID being generated based on the chips IDs. So there is no risk of conflict anymore (there is, 1/4 294 967 296, but this should be okay I think!). 592f58e implements it.

Check out the new setFirmware replacing setVersion.

---

Remaining:

• Implement $signal property (done 5cfcd8e)
• Interface for adding extra settings
  This will probably require SPIFFS, this will be way easier to deal with JSON than EEPROM
• SSL and Authentication for MQTT (done 9733c0d)
• Provide documentation

I am not in favor of predefined MQTT callbacks as you name it, at least not for now.

About the configurable devices/, I might implement it but it would not follow the Homie spec and this could lead to divergence. This would really be for debugging only.

Offline buffering is definitely out of the scope of Homie. At least for now, once again. ;)

[marvinroger]

I just implemented auth for MQTT, if you have time to test, I would be glad to have some feedback on it. The new config API is documented in the README. SSL is also implemented.

[furyfire]

I still use the stable version of Esp8266/Arduino. First tests of SSL caused a panic and reboot.
Authentication works. I will test again once 2.1.0 is released.

[marvinroger]

SSL is not really stable for now, even with the latest staging version. I hope the team working on the Arduino for ESP8266 will sort things out, if even doable.

Thanks for the feedback!

[marvinroger]

I have started to write the docs : https://github.com/marvinroger/homie-esp8266/wiki
It's more of a guide for now, but it will get better over time, the ultimate goal being to have nothing on the README except a quick description, the sample sketch and a link to the Wiki.

[marvinroger]

Docs are complete!

[marvinroger]

Closing as everything was implemented, except extra settings, so a new issue has been filled.