search

homieiot / convention

🏡 The Homie Convention: a lightweight MQTT convention for the IoT
https://homieiot.github.io/
Other
715 stars 60 forks source link

Remove timings paragraph. Rename behaviour to lifecycle. #155

Closed davidgraeff closed 5 years ago

davidgraeff commented 5 years ago

A controller need a way to figure out when to assume default values for optional topics.

Instead of relying on a timing, the $state attribute should be used. A next question would be if we allow topic changes ($nodes, $properties) while in $state=ready mode.

boc-tothefuture commented 5 years ago

How will this work when the controller reconnects? It may get the topics in any order and may take an arbitrary long duration to process them (depending on system load, number of topics, load on the broker, etc).

davidgraeff commented 5 years ago

Yeah I know. This only solves the situation for slow Homie peer devices. A second lifecycle / state-machine for the communication with the MQTT broker is required for a Homie controller. As long as the broker is keeping sending stuff, a controller can assume a working connection and otherwise a timeout for that connection is somehow required or implementation specific.

euphi commented 5 years ago

@boc-tothefuture The homie convention can't handle this case.

As a workaround, a newly subscribed client can send a not-retained message to the broker to a MQTT topic where it is subscribed to. Usually the broker will queue this message and send it after the old stored (retained) messages.

However, maybe the problem is not that relevant in practice: A controller that wants to learn the advertised devices / nodes and their properties, just can update its list "in realtime".

Thalhammer commented 5 years ago

How about building some kind of list of published topics the way we list nodes and properties? This way a controller would exactly know what to expect and when everything arrived. It also should be easy to implement on devices and controllers.

ThomDietrich commented 5 years ago

@davidgraeff wdyt, should this be discussed in the controller developer guidelines?

Also, did you miss my comment?

davidgraeff commented 5 years ago

Also, did you miss my comment?

No I didn't. We don't have such a section yet though. Do you aim for the website or the convention document itself?

ThomDietrich commented 5 years ago

I was refering to this comment https://github.com/homieiot/convention/pull/155#pullrequestreview-194413594

Please break one sentence per line

Regarding the guideline: All the more important that we capture the ideas for content of this section. This is where I am confused because you've opened and closed a few issues and now there is non open any more 😕 I also do not understand your question. Shouldn't the website repository be a place of presentation and style but all convention related information and knowledge belongs in the convention repository!? Come to think of it: Why are there two repositories to begin with?

davidgraeff commented 5 years ago

Why are there two repositories to begin with?

Because martin roger doesn't want to give me full access to this repo, but for a website deployment environment I required this. So we have two repos now ^^.

Shouldn't the website repository be a place of presentation

But also about implementation details, I think. The specification should be a clean specification only.

ThomDietrich commented 5 years ago

Things like this shouldn't hold us back. @marvinroger would you agree that active contributors should have the correct permissions to drive this project forward. Please consider entrusting one or two of the currently active developers. Jm2c 😉

Two repos problem aside: Everything related to the convention should be in the repository. Be it the main document, example implementations, FAQs or guidelines. All of those belong together and form the complete picture of the convention. If at all possible I'd strive to merge the two repositories.

euphi commented 5 years ago

Things like this shouldn't hold us back. @marvinroger would you agree that active contributors should have the correct permissions to drive this project forward. Please consider entrusting one or two of the currently active developers. Jm2c

@marvinroger gave me access to homie-esp8266 today, so I can help in progress V3 implementation for ESP8266.

@marvinroger: For ensuring project progress, I think it would be best to give some few people access to the homieiot organization (make them member), so they can control rights for the projects repos.

marvinroger commented 5 years ago

@davidgraeff @ThomDietrich @euphi @timpur alright, you now have full access to the homieiot organization.

@davidgraeff just to be clear, I never intended "not to give you full access to this repo". I am just overloaded with a lot of personal matters, and I don't have time to read GitHub, so I might have misunderstood a few things.

Finally, I apologize if I slowed you, and the different Homie projects, down. I am infinitely grateful to all of you who keep this project alive.

OSS love, if that's a thing 😄❤️

davidgraeff commented 5 years ago

@ThomDietrich I'd be fine with a merge of the homepage and convention repos. We can even build the website on on separate branch of this repo and remove the third homepage-build-result repo as well, if you like.

ThomDietrich commented 5 years ago

@marvinroger thank you! With this step we can now continue to push the success of the homie convention. Hope to see you again soon!

@davidgraeff my opinion is that this would be the best way forward. @euphi wdyt?