search

homieiot / homie-esp8266

💡 ESP8266 framework for Homie, a lightweight MQTT convention for the IoT
http://homieiot.github.io/homie-esp8266
MIT License
1.36k stars 307 forks source link

Homie 3.0 #467

Open timpur opened 6 years ago

timpur commented 6 years ago

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.

Let's talk.

Your ideas

Core

Node Manager (lib of nodes)

furyfire commented 6 years ago

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

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 commented 6 years ago

Is SSL support a possibility for this?

timpur commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

timpur commented 6 years ago

@tripflex @bertmelis Sounds good 👍

timpur commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

timpur commented 6 years ago

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

ingoogni commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Please have a quick look at #473

flozsc commented 6 years ago

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

timpur commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

timpur commented 6 years ago

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

bodiroga commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

MT

marvinroger commented 6 years ago

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

bodiroga commented 6 years ago

Hi @marvinroger!

Reading more carefully the Homie 3.0 specification, I have realized that my implementation of Node Arrays is wrong :disappointed: 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 :+1:

Best regards,

Aitor

bodiroga commented 6 years ago

It's me again @marvinroger :wink:

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 :+1:

marvinroger commented 6 years ago

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

igrowing commented 6 years ago

@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: