Comments (21)
stefan-muc
commented on July 16, 2024
2
@euphi made the point more clear than me:
Even worse, if there is a incompatible change, but that does not affect you, with your proposal you are forced to change you subscribe without real need.
That's exactly the point: When the specification changes in a detail I don't even use, I don't want to update all my subscriptions (which could mean physically collecting some hardware and having to re-program it).
As far as I understand Homie, it's a semantic-hierarchical structure for MQTT messages. Everything not needed shall stay out of the path to have a short, grippy and permanent path to a device attribute. That's one big advantage of Homie which goes down the toilet when we add meta-information to the path.
Why only Homie-Version in path? Why not e.g timezone, timestamp charset and device status too? With the same argumentation as @traverseda we could also propose this. In the end we have a 100 level deep tree and a nearly unusable convention. No, I don't want to go that way.
Devices could use this feature to keep backwards compatibility with previous versions of the homie specification by publishing different data on different channels.
This argument is like "let's all IP devices send every packet in IPv4 and IPv6 simultaneously". No, there might be more starndards/versions, and the client decides which one he uses. Sending data redundantly doubles the load on the device, on the MQTT server and on every (subscribed) client. It even introduces bugs when redundant data isn't consistent. That's useless...
Let's compare Homie to other conventions/standard that use tree structures, e.g. HTML. Since decades it's <html><body> where the body is located at. It never has been <html><3><body>, and it now isn't <html><5><body> as we are on HTML 5, and it won't be <html><6><body> in the future as we might move to HTML 6 - even though there is XPath where I could "subscribe" to <html><*><body> and wouldn't have to adjust my code for a new version. And there are very good reasons for that - the same as for Homie.
One major advantage, if the subscriber support version 3 of the homie specification only, but the device support 3 and 4, the subscriber can subscribe to only the data it understands.
The focus of Homie (3.x) shall rather be to implement changes in a way that's backward compatible, so we don't ever need a Homie 4.x specification - and if we need a Homie 4.x most parts are backwards compatible. We have Homie 1 and Homie 2, and thus much knowledge so we can make a great Homie 3.
I have only one convention that should ever be met (up to Homie 42.x): The version attribute shouldn't ever move it's location, so a Homie 3.x compliant node should be able to read out a Homie 42.x compliant nodes convention version.
from convention.
euphi
commented on July 16, 2024
1
In which situation would this save overhead?
from convention.
traverseda
commented on July 16, 2024
1
That's what semvar is for though. Any major changes would break compatibility anyway.
Subscribing to homie/1/*/*/deviceId would subscribe you to all versions unless there's a breaking changes.
from convention.
lorenwest
commented on July 16, 2024
1
- never break basic things - getting/setting values. ever. If a new version has a better way, require it to also work the prior way.
- devices publish their compatibility version
- most of the time, stuff works without concern for version because basic things keep working
- if you care, subscribe to compatibility version to see what a device supports
Adding version to the path will break 1) every single time. It will either result in the death of homie, or isolated islands of things. probably both. I'm hoping this discussion goes nowhere, because homie deserves to live on.
Look at any convention that has survived. html, http, and take their lead. It's not perfect, but the basic things continue to work across compatibility versions.
from convention.
traverseda
commented on July 16, 2024
It would not. I was presuming the pubsub protocol was more complex then it was, I think.
from convention.
stefan-muc
commented on July 16, 2024
No no no noooo, please not.
MQTT paths should be stay stable because other clients implement against it. I don't want to change all implementations just because a client updates protocol (homie) version (and would have identical interface otherwise).
from convention.
euphi
commented on July 16, 2024
So, if there is no breaking change the whole feature is not necessary.
If there is a breaking change, you need to change your subscriber configuration anyhow... So your proposal does not help.
Even worse, if there is a incompatible change, but that does not affect you, with your proposal you are forced to change you subscribe without real need..
from convention.
traverseda
commented on July 16, 2024
If there is a breaking change, you need to change your subscriber configuration anyhow
Devices could use this feature to keep backwards compatibility with previous versions of the homie specification by publishing different data on different channels. Third parties could also use this to create shims running off-device, shims that transform the data from the new specification into an older one, for backwards compatibility.
Basically, they same reasons you'd use semvar in a large software project....
from convention.
ThomDietrich
commented on July 16, 2024
It is not a viable option to force continuous path change due to convention updates.
homie/node1/$homie offers the convention version of a client in the network. It is the task of a controller or interacting node to evaluate this information and act accordingly or to decide that the convention version offered is out of its supported range.
The use cases (shims, transformations) you are presenting seem outside the scope of the convention...
from convention.
traverseda
commented on July 16, 2024
MQTT support wild cards for levels in a path, so the "continuous path changes" are not actually a problem, as near as I can tell. What problems do you expect to run into if you subscribe to something like homie/1/*/*/someDevice? As long as it doesn't change to a different major homie version, it would work as normal. Minor and patch version numbers can change.
from convention.
traverseda
commented on July 16, 2024
Ahh, I see. It looks like you're releasing breaking changes a lot, so you're bumping the major revision a lot... If those aren't breaking existing subscribers, they should probably be minor revisions instead....
Consider re-familiarising yourself with semvar? https://semver.org/
from convention.
ThomDietrich
commented on July 16, 2024
In case you didn't see #46 you might want to catch up. Just as you are implying, we realized that a consistent versioning scheme should be implemented for the convention. That is why we took a leap and switched over to version 3.0.0 yesterday (with the switch of the repository namespace). Starting now every increment of the convention will be versioned according to semver.
The wildcard idea is a good thought but yet again, what's the advantage over a check of the version topic?
from convention.
traverseda
commented on July 16, 2024
One major advantage, if the subscriber support version 3 of the homie specification only, but the device support 3 and 4, the subscriber can subscribe to only the data it understands. This means that as a device manufacturer, you can upgrade your devices to newer versions of the homie standard without worrying that you're going to break existing deployments.
from convention.
traverseda
commented on July 16, 2024
The focus of Homie (3.x) shall rather be to implement changes in a way that's backward compatible, so we don't ever need a Homie 4.x specification
Then by the semvar standards it shouldn't be homie 3.0, it should be homie 2.whatever. Unless you're implementing a breaking change, you're not supposed to bump the major version number.
By definition by semvar, things located at homie/3/*/* should not be compatible with things located at homie/4/*/* or whatever. If you're not actually using semvar... Maybe make your versioning schema more explicit?
from convention.
euphi
commented on July 16, 2024
The way, auto-discovery works is breaking, but how the Nodes communicate is not.
Furthermore it is planned that some device properties (statistics) will be moved to "normal" node level. This is a breaking change, but only if you read the device statistics.
from convention.
ThomDietrich
commented on July 16, 2024
I have only one convention that should ever be met (up to Homie 42.x): The version attribute shouldn't ever move it's location, so a Homie 3.x compliant node should be able to read out a Homie 42.x compliant nodes convention version.
@stefan-muc well said.
Unless you're implementing a breaking change, you're not supposed to bump the major version number.
Semver doesn't work this way. Semver defines rules when you have to increase the patch, minor, or major version number but it doesn't restrict those choices. Version 3 is a major step in Homie development. Not only in the way discovery is handled but also as it is now in a new namespace and decisions regarding its further development will be handled were made.
Your key argument is that the version as part of the MQTT path will automagically increase compatibility between Homie nodes and controllers. That is not necessarily true or sufficient. The version attribute in combination with logic in the controller is the more flexible way and as @stefan-muc mentioned, this is the way every other network protocol is working.
from convention.
traverseda
commented on July 16, 2024
this is the way every other network protocol is working.
It's not the way most versioned http API frameworks have worked in my experience. In them, you can specify the version of an API call in a querystring, or as part of the path. It's not included inline in the json response, and you don't specify what api version you want to use in your request.
HTML, the example given, was intended as a document protocol, not a data protocol.
from convention.
ThomDietrich
commented on July 16, 2024
Now we talking about a different issue. A node (thin client) is not intended to talk multiple Homie Convention versions. It is the task of the controller to handle the version the node offers.
from convention.
traverseda
commented on July 16, 2024
You don't think that node-to-node communication is likely to happen? A switch connected directly to a solenoid (over MQTT) with no controller, as an example?
from convention.
traverseda
commented on July 16, 2024
Let's say I made a "smart lightswitch". I know it supports homie devices running versions 3, 4, and 5. I could subscribe to the whole tree of homie objects, or I could only subscribe to streams that I know I support. That's not important now, but if in the future there are 20k node office buildings using homie, it could be a lot more important.
And that's sort of the thing, you don't know what the future is going to bring. Putting it in the path, and requesting that nodes explicitly subscribe to versions they support, well that has the potential to save a lot of headaches. If you use an attribute, vendors will get it wrong. When you release homie 11 in 10 years, and 2m light panels break because they think it's homie 1, don't be too surprised.
from convention.
euphi
commented on July 16, 2024
Sorry, but your ideas are not thought to the end.
If a smart lightswitch supports another Homie device as command source (or better: sink), so why it should be necessary to send a command in different "version-trees" and receive updates with a wild-card subscription?
Either the Lightswitch supports a Homie version, then it can subscribe in a correct way to that specific version. If not, you their will be problems anyhow.
And if you update a light panel (the command sink of your light switch): When your device sees a new version of that device, it then can adapt its command and subscription to that new version.
And what can a vendor do wrong here, what he can't do wrong with "version-paths"?
Your proposal would introduce a bunch of new problems without solving a single problem.
from convention.
Related Issues (20)
- Tools - datetime
- $state and $homie can be empty HOT 1
- Human readable types vs machine optimzied types HOT 14
- Please add Java implementation to the list
- Clarify handling of empty strings HOT 13
- add a 'format' for booleans
- Matrix room for project chat HOT 1
- How can I create a settable property, which takes two arguments? HOT 2
- Homie future? HOT 52
- New firmware - GrowNode
- drop the Percent type HOT 1
- add a "step" or "precision" element to the number formats HOT 3
- drop the `node.$type` field
- QoS of non-retained messages HOT 3
- using `set` with retained messages HOT 1
- Define a way to handle NULL values HOT 3
- Protocol Buffer for the payload? HOT 4
- Add location format attribute to Homie V5
- Support streams or binary data HOT 7
- Arrays got removed, but specification uses one as example HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from convention.