Implementation guideline for client/controller developer about convention-website HOT 15 CLOSED

Do you think we need to write this guideline before releasing the v3?

from convention-website.

From @ThomDietrich on November 7, 2017 12:11

No. Would be useful but it doesn't influence the convention. Can be v3.0.1 ;)

from convention-website.

From @timpur on May 2, 2018 10:18

@ThomDietrich I'm happy to write up draft from my experience of implementing the discovery process and I hope @davidgraeff can help me with that and ofcause anyone else who want to contribute.

from convention-website.

From @timpur on May 2, 2018 12:42

homieiot/convention#93 (comment)

It is absolutely not about the semantic of an input or output. It is just about controllers knowing of all available inputs and ouputs and their data types (int, bool, string, etc).

Just to calcify @davidgraeff, this would have nothing to do with the spec, but more as help on how to use the spec if a dev wants it. It will help future people like you and me know where to start to discover all the homie devices :P as the title says: a guideline

from convention-website.

From @ThomDietrich on May 2, 2018 13:19

Exactly. The guideline will help developers on both sides (controller and client/device) implement MQTT communication in compliance with the Homie convention.

As I wrote before I believe a simple item list would be enough. The simpler the better.

from convention-website.

From @ingoogni on May 2, 2018 14:41

I'm getting utterly confused by this opening and closing and moving of discussion. Can't we have a decent mailinglist or even Gitter (meh) for discussing things. This is worse than USENET 30y ago.

@davidgraeff thanks for "It is just about controllers knowing of all available inputs and ouputs and their data types (int, bool, string, etc" that clarifies somewhat.
What does homie does not do yet? What is not possible yet? Does it need programming? Is it a matter of standardising certain types of topics? Is there an MQTT auto-discovery convention? Would that be useful? Who should adapt?

(I don't use it as everything I build is made to fit and "hardwired" (even in software) yet still interested)

from convention-website.

From @ThomDietrich on May 2, 2018 14:56

This is the way how issue ticket systems work for thousands to millions of projects on all kinds of platforms. They normally work quite well as long as people don't mix issues and discuss one single topic in one single issue.

Is it a matter of standardising certain types of topics? Is there an MQTT auto-discovery convention?

I'm confused. This IS the purpose of Homie :)

from convention-website.

From @davidgraeff on May 2, 2018 17:27

@ingoogni The spec is definitely not written for someone that has never seen MQTT before or has never thought about M2M communication. It does its best to introduce to the topic though and I would say it does a good job. All your questions are actually answered explicitly or implicit.

There is only one point, that I had to made up while implementing the controller side. And that is the response time. The MQTT broker does acknowledge a subscription, but it does not tell if there's any value for the given topic. I have decided to wait a maximum of 200ms for a value to arrive and otherwise assume there is none. The entire tree discovery has a time limit of 1500ms in my implementation.

from convention-website.

From @fermuch on May 2, 2018 17:51

There is only one point, that I had to made up while implementing the controller side. And that is the response time. The MQTT broker does acknowledge a subscription, but it does not tell if there's any value for the given topic. I have decided to wait a maximum of 200ms for a value to arrive and otherwise assume there is none. The entire tree discovery has a time limit of 1500ms in my implementation.

Does this need to be standarized, or is it different for every project? On my implementation I wait until every device is $state = ready, then wait 500ms for all pending messages to arrive, to assume a full discovery.

from convention-website.

From @davidgraeff on May 2, 2018 18:36

A recommended time could be added for implementors. The connection can't be influenced of course. Sometimes it just takes longer.

from convention-website.

From @timpur on May 6, 2018 10:50

Also, should we be defining which discovery attributes need to be published first and in order? eg $homie first then $node then $properties, then all the rest? (As order of how i see discovery done)

This would help most when a new device is added to the network, ensuring that a clean discovery is made?

@davidgraeff i was hoping to work with you to define how to discover a homie device, would be nice to get another opinion on they they precise as the best way, because there more than one...

from convention-website.

From @davidgraeff on May 6, 2018 10:58

Hm. The order of published topics doesn't matter actually if everything happens within 200ms (e.g. the timeout of an attribute). There are even two contradicting scenarios:

The device is already known

Every node and property is retained. We expect the worst case: The device has a whole set of new nodes and some old nodes removed. --> It would be less confusing for the controller if first device, then nodes, then properties are published.

The device is new to the network

It would be less confusing for the controller if first properties, then nodes, then the device is published. As soon as the device/$homie topic appears, the controller starts to parse all the (already available) sub topics.

from convention-website.

From @davidgraeff on October 29, 2018 7:16

I would say this does not belong to the spec repository, but to the website. Any disagreements?

I suggest adding implementation notes here: https://github.com/homieiot/convention-website/tree/master/docs/Implementations somewhere.

from convention-website.

It’s not part of the convention, indeed. 👍

from convention-website.

From @davidgraeff on October 29, 2018 7:54

@marvinroger Could you use https://github-issue-mover.appspot.com/ or similar to move this Issue to the webpage repo?

from convention-website.