Closed davidgraeff closed 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).
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.
@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".
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.
@davidgraeff wdyt, should this be discussed in the controller developer guidelines?
Also, did you miss my comment?
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?
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?
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.
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.
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.
@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 😄❤️
@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.
@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?
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.