Homie 3.0

[timpur]

Open to any one.

Like to discuss what you think homie 3.0 will be, new feature, more tools, ext. What would you like to see.

Some of my thoughts.

• Under to hood (core changed).
  • New event bus.
  • New task manager.
  • Possibly a add-on aritecture. So you can enable and disable parts of homie core as you need them.
• Conform to Homie 3.0 (TBA)
• Add-ons
  • Battery management
  • Node types
• Compatibility with esp32???(not sure about this yet)

Let's talk.

Your ideas

Core

• Streamline the usage of JSON
• Task Management
  • For Node loops (property attribute $interval convention#53)

Add-ons

• Battery (readbattery level, sleep intervals etc)
• Debugging (Push debug output over internet, accept external commands etc)
• FileSystem (Push/Pull files to the SPIFFS over MQTT)
• Webserver in normal mode (For advanced user configuration)
• Other IoT protocols implementations (Philips Hue, Alexa, Google Iot, ThingSpeak)

Node Manager (lib of nodes)

• Note Types: Switch, Dimmer, etc.
• Util Nodes HeartBeat, ConfigMode, etc.

[furyfire]

Streamline the usage of JSON. Currently the $properties topic is comma seperated, but the $implementation/config topic is JSON. I don't care which one it is. I just want it to be streamlined.

Task management is a big plus. Some sort of repository of nodes which you can easily pull from and quickly modify. (Read X sensor on pin Y every Z seconds)

Core addons sounds great if the implementation can be kept clean
Add on ideas

• Battery (readbattery level, sleep intervals etc)
• Debugging (Push debug output over internet, accept external commands etc)
• FileSystem (Push/Pull files to the SPIFFS over MQTT)
• Webserver in normal mode (For advanced user configuration)
• Other IoT protocols implementations (Philips Hue, Alexa, Google Iot, ThingSpeak)

I know these things could be implemented as nodes. I just feel like they would belong better as "add-on" modules that provide offical functionality in line with the Homie protocol.

[hamishfagg]

Is SSL support a possibility for this?

[timpur]

@furyfire love it. Thank you for your comment. Yes I think we might use json more and your right we should pick a standard format for these things.

@IVData see #458 ( it's coming )

[euphi]

Regarding Add-Ons/Nodes:

I think most addons will be somehow a HomieNode. So, most work for addons will be to establish a add-on database and an offiicial process how to add the addons there.

For some cases a extension of the Homie API to support "Add-Ons" will be necessary, e.g. access to write "device properties" for the Battery add-on or more level of property information, e.g. for the FileSystem.

Regarding Debug: I have a LoggerNode that could be a good starting point for a debug add-on. Until now, it is not directly used by Homie, but it will be easy to adapt, especially if there would be a specific way to set a debug-functions inside homie.
(Or just subclass the Node also from Serial).

[timpur]

@euphi good points, im trying to get in touch with @marvinroger to discus and architecture of these ideas. Might start designing how this might all work. Will start uploading docs and milestone plan soon and a task list and we can all contribute to this next major version.

also found this #87

also keep looking at the main message as ill be updating it as you guys add things

[tripflex]

Yeah I agree a collection of addons would be amazing. I had to scour the internet and GitHub to find any custom nodes I could, and I actually did find a good few of them. Plus it wouldn't be that difficult to write some basic nodes either, and I wouldn't mind sharing mine as well.

Here's some of the nodes I found on GitHub:
https://github.com/yves-ledermann/homie-esp8266-supplements/tree/master/src/Nodes
https://github.com/luebbe/homie-node-collection/tree/master/src

[bertmelis]

When (if?) going that direction maybe create An organization github-account to manage all the contributors/maintainers/...

[timpur]

@tripflex @bertmelis Sounds good 👍

[timpur]

Question to all.

Homie Internal Node for sensors and controls.

Should homie use nodes or a node for internal things like the stats (wifi signal ...) and other control points like reset and restart and any other we add? Call it homie-internals Node ?? This would allow for auto discovery of all the internal sensors and controls. Also means as more are added over time, they can just be auto discovered, which is what we want for our Home Automation software.

This should only be done to sensors and controls, not everything in the internals make sense to move to a node.

Thoughts.

[amayii0]

Not using Homie heavily at the moment, as a noob I'm wondering what are possible use cases for internals.

Speaking about OO code, I'd keep private what should me only mine and public what is for everyone.
Internals looks like private, as such not accessible as-is. Could that be actually through some kind of getters setters?
For stuff having clear use cases, exposing that just like any other node looks pretty sane.

[timpur]

I just was just thinking, did we want to use a node for device sensors and controls (Part of homie) which are built-in? This would mean these sensors are discoverable and not assumed to be part of any spec....

Currently Internal sensors and controls (Part of homie) are assumed part of a spec and not discoverable....

??

[ingoogni]

$stats/... yes, probably also $online, they are not meta-data but measurement values.

[timpur]

Yeah for $stats and other measurement values. Not sure about the $online ($online will change with new convention)

[ingoogni]

Forgot to look at the redesign branch, from that I would add $state, it is not meta-data per se.

(In my simple Homie-applications I publish the state of the state-machine on a node)

[euphi]

The reason why $online changed, is to know for sure when all "discovery data" has been sent.

So it is not a measurement value, but important part of the homie convention.

Edit by @timpur: deleted duplicate comment.

[timpur]

Please have a quick look at #473

[flozsc]

I absolutely like the idea about additions for battery-powered sensors. Especially an integrated option for deep sleep would be great.

[timpur]

Yes I think adons will be a nice adition. And it might allow us to create a homie core version which is platform dependant and maybe add-ons can be shared for many platforms like esp8266 and esp32 ....

[hexxter]

From my point of view the support for ESP32 is importent and the addon and more lib of nodes is not necessary. The ESP32 is on the same price level and so much more equipment what for many IOT things required is.

[edilcn]

Hmm, what you guys think of developing homie 3.0 in a RTOS framework? The system could be ported more easily than a bare-metal. Just a thought hehe

[timpur]

@PauMito, i like the idea, but i think its more important that we stick to arduino framework for the users sake ...

I believe the Arduino framework isn't built on the OS SDK, which means we'll have to choose...

[edilcn]

Uhmmm...
So, I was doing some research about the compatibility of the Arduino Framework and FreeRTOS.
I've found this projects:

• https://create.arduino.cc/projecthub/feilipu/using-freertos-multi-tasking-in-arduino-ebc3cc

• https://exploreembedded.com/wiki/Setting_Up_FreeRTOS_on_Arduino

• http://esp-idf.readthedocs.io/en/latest/get-started/windows-setup.html (toolchain)

• https://www.espressif.com/en/media_overview/news/espressifs-esp32-support-amazon-freertos

[timpur]

Sorry, those are for arm and the esp32, there is no way to use Arduino and rtos for esp8266

[bodiroga]

Hi @timpur!

Is there any homie-esp8266 branch that is compatible with the Homie 3.0.0 convention? I'm not talking about the homie-esp8266 3.0 library version, I just need the current library features but compatible with Homie 3.0 convention.

Thanks for your hard work and best regards,

Aitor

[bodiroga]

Hi again @timpur!

I have created a branch in my own fork repository and I have adapted the library to comply to the latest Homie 3.0.0 version. I have done this for my own personal use, but I will be more than happy to make a PR and contribute back to the amazing work that you and @marvinroger have done! Here you have a link to my repository branch:

https://github.com/bodiroga/homie-esp8266/tree/develop-v3

Do you want me to make a PR against the 'develop' branch of the repository?

Many thanks again for all your help and best regards,

Aitor

[MajorTwip]

Hi @bodiroga
Thank you for your work. Works fine with the Openhab 2.4 Snapshot-MQTT binding (saw you there too).

MT

[marvinroger]

Hi @bodiroga
Please, open a PR. I’ll take a look and merge. :)

[bodiroga]

Hi @marvinroger!

Reading more carefully the Homie 3.0 specification, I have realized that my implementation of Node Arrays is wrong 😞 The array definition has changed significantly, so I need to adapt the library first before submitting the PR. Let's see if the changes are easy, because my C++ skills are very basic 👍

Best regards,

Aitor

[bodiroga]

It's me again @marvinroger 😉

Is it true that in the Homie 3.0 version the Node is what can be an array, whereas in the 2.0.1 version it was a property field? The array definition is the worst explained thing in Homie, I should open an issue in the convention repository to improve the documentation (https://homieiot.github.io/spec-core-latest/#arrays). Argh, and the callback mechanism for the settable attribute must be changed also. Step by step.

Let's start clarifying if the _range attribute and isRange() method should be moved from the Property class to the HomieNode class 👍

[marvinroger]

@bodiroga it is true. It just felt more natural to have node arrays, rather than properties arrays. 😉

[igrowing]

@timpur Having homie-internals (or any other name for the node) to discover other Homie-powered devices in the network could be useful.

In addition, few useful features:

• Homie location detection - Detect where Homie is to assist with weather/time/DST acquisition.
• Time acquisition from NTP + DST enabling.
• Interrupt to certain change in ADC (rise, fall, change).
• Having configuration option for 2nd AP (Failback AP) like in Easy-ESP and Tasmota.
• Ability to expand config.json with additional settings from the code. For example, write down to config.json a property if changed from default value. Then restore the value after each reboot.