convention
convention copied to clipboard
homieiot
Add a location/geoip tag in device attributes
IMO that should be part of your mqtt string if geolocation is important, in principle it is nothing different from "front/door" or "headlight/left".
I agree with @ingoogni, the only thought i had was if we had device stats implemented as a node, then this is something you could add to that stat node to make your own device stats. So would be nice to also open up device stats for custom user device stats i guess? @nicola-lunghi, would this satisfy this?
If you agree to have optional/recommended nodes, it actually would be a good idea to specify how locations are going to be published. A lot of homie nodes will do that anyway, why not standardize it.
When last skimming the issue I had a similar question. Which kind of location are we talking about?
- "1st floor, left bedroom"
- "geo:51.6848,15.9205"
- ...
maybe I can implement this using a property node could be more flexible
The reason i was thinking a device stat is because who said locations were fixed? The location could change... device $attributes are not meant to change over time? or has that changed also?
Attributes are more or less fixed yes. Regarding locations: I would have thought of a "location" node and the node type would be "geo" or "relative" or "room". Geo would require longitude, altitude, relative would require X,Y,Z and room requires a string.
If geolocation is important, for a moving device, set up a node for it. I think a geo location spec would belong in $unit and would fit the Convention well. (Next question I can imagine is yaw, roll, pitch ..... all just a node with '$unit'.)
A location string is very useful for auto-discovery, so I opt for adding it to the convention as optional device property with arbitrary string, e.g. a room name (For example openhab automatically groups devices by location).
This location usually don't change often - if you move a device to another room, you can change the configuration of the device.
If you a moving device, e.g. a drone, the geolocation would be a normal node, of course.
in my setup i need something like an x/y coordinate (geographical coordinate are not very practical in a building)
On Wed, 2 May 2018, 09:03 Ian Hubbertz, [email protected] wrote:
A location string is very useful for auto-discovery, so I opt for adding it to the convention as optional field with arbitrary string, e.g. a room name (For example openhab automatically groups devices by location).
This location usually don't change often - if you move a device to another room, you can change the configuration of the device.
If you a moving device, e.g. a drone, the geolocation would be a normal node, of course.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/homieiot/convention/issues/78#issuecomment-385896618, or mute the thread https://github.com/notifications/unsubscribe-auth/AYPsTE4SleBaCS4o64SF0DTAoH3tgJ1Fks5tuWhfgaJpZM4TjZRA .
"A location string is very useful for auto-discovery, so I opt for adding it to the convention as optional device property with arbitrary string, e.g. a room name"
Lets have a single device with 4 temp probes built in the ceiling on a strategic spot so it can measure the temperature in 4 different rooms, that could even be on a different floor. Is location really a device property? IMHO not.
It can be nice that software groups certain data on location, but it should do it on (semantic) topic strings instead of yet more properties of a device that in most cases can (and should) be expressed as node properties.
IMHO not only the (ESP) implementation of the convention should be light weight but also the convention it self. This I think can be accomplish be looking for the most general relevant spec instead of adding more specifics.
@ingoogni A device is usually an entity that has a single location. But I do understand your concern, that a node might have a different location than the device itself. I would allow both. The location is optional anyway.
From a controller perspective, the device location is of more interest though. A node is usually rendered as part of a device and a different location can not always be considered.
I have a 'device' that lifts and lowers a hose, it is a spindle with a steppermotor controlled by a Nano over I2C connected to a Wemos over MQTT connected to a Wemos that is the dedicated remote. What is the device? how many devices are there? Now there are also a few end-switches the hard stops connected to the nano, the soft stops connected to the Wemos. There is a hand switch that can be operated from three places, there s a thermo sensor etc. How many devices?
For messaging mqtt topics, for me only one, the all live in the same namespace. From a device point of view, two esps? But why stop counting there, a switch is also a device and yes, in this case its location is important, it is the end switch on the top side.
Maybe namespace is a better word than semantic topic. An ESP with one temp sensor services two namespaces, the sensors one and the ESP one. Wether a node on a mesh is a carrier of other node does not matter and imo should not be seen as something different, they are all nodes that communicate, mqtt, 1-wire, i2c etc.
So, yes, a device constisting of devices consisting of devices etc. can have a location as can have all the sub(sub) assemblies.
Maybe I should add that what y'all see as device, homie on an ESP to me is just a router in a network that transmits messages from and to endpoint, sensors, actuators or other procedures that happen to run on the ESP. Now of coarse I have a peek in the logs every now and then to see how the router performs, but it is not the interesting thing in the network, my NAS and local web server are of more interest as that is what I work with, knowing that without the router I could not.
That seems too far fetched. We have to insert an abstraction layer somewhere and a tree in the form homie->devices->nodes->properties should be able to cover most applications at least sufficiently.
Regarding location: I get why a location might be useful for nodes (Heck, one of my projects publishes plant sensor data for multiple Bluetooth-connected devices distributed in the house under the namespace of one device).
As for the convention: I think an optional location for the device should be more important. Additionally I don't see why we shouldn't allow it for nodes as well.
Could we go back to the data format? From what I got, three formats should be considered. In the following I propose three distinguishable schemes in one string:
Topic: homie/mydevice[/mynode]/$location
- An informal location name (room): "1st floor, left bedroom"
- A standardized lat-lon location (geo): "geo:51.6848,15.9205"
- A location in a cartesian coordinate system (relative): "(1, 2, 3.456)"
@ThomDietrich Exactly. But thing of our little constrained devices and remove as much boilerplate as possible. The Geo URI schema should be followed, but without the "geo:" keyword. The relative coordinate can be comma separated floats only.
homie/mydevice[/mynode]/$location/$type defines the semantic: "geo", "relative", "informal" or so.
Not sure what you mean with "remove as much boilerplate" as your proposal is more complex.
Regarding geo: fine with me of course
Regarding type: Probably follows our existing scheme better. I don't particularly like that type is an attribute-attribute but it's not a deal breaker.
Topic: homie/mydevice[/mynode]/$location/$type or homie/mydevice[/mynode]/$location-type (optional, defaults to "text")
- "text": A non-interpreted string
- "geo": Follows the scheme https://en.wikipedia.org/wiki/Geo_URI_scheme - the "geo:" in the beginning is optional
- "relative": cartesian coordinates in meters
Topic: homie/mydevice[/mynode]/$location (optional, no default)
- text: "1st floor, left bedroom"
- geo: "37.786971,-122.399677;u=35"
- relative: "1,2,3.456"
Open questions
-
$location/$typeor$location-typeor something else? - "text"?
- "geo: optional?
- relative in meters?
- For devices and nodes alike?
Sorry guys, I don't get it, why "invent" $location &type geo: etc when we already have $unit, $datatype and $format in place? Make those available system wide.
And in most cases a fitting topic string will suffice: a standard example of topicstrings: http://www.steves-internet-guide.com/understanding-mqtt-topics/ even better: http://tinkerman.cat/mqtt-topic-naming-convention/
Because $unit etc are attributes of properties. $location is an attribute of a device/node, not a property. From the convention:
Attributes: Devices, nodes and properties have specific attributes characterizing them. Attributes are represented by topic identifier starting with $. The precise definition of attributes is important for the automatic discovery of devices following the Homie convention.
Not sure why you've posted these links. I guess everyone here is well aware of those rules.
- A standardized lat-lon location (geo): "geo:51.6848,15.9205"
@ThomDietrich for latlng pairs, you'd also need a projection (most likely ESRI 4326). A projection is a way to plot coordinates on a flat surface (a map). To my knowledge, there are several thousands, and some are required to be used when working for governments.
If we add a $location property, what projection should be used needs to be specified on Homie when using the geo type. Declaring what decimal precision is expected is also important.
The easiest standard format to encode location for embedded systems, to my knowledge, would be WKT POINT (e.g.: POINT (-13.7040324, -69.6703397)), or by using a custom format like the one you specified (I preffer this solution), but both the projection expected and decimal precission need to be noted on the Homie standard if we go for a custom format.
exactly. It is a node.
Lets build HomieZero, put homie on an esp and start stripping away everything in such a way that we in the end still have something that sends messages. That would be mostly the network related topics that survive. In this most minimal yet functional situation, does location matter? No, in the same way as it does not matter where a router or a DNS server is located, physical location.
Now ad something to the HomieZero, a random number generator that emits a number every second using MQTT. We now have two 'namespaces', HomieZero and Random. Does it change something to HomieZero? Yes, it has to transmit $nodes. Does it require location? No. Does Random require location? No.
Add a sensor to HomieZero, same questions. For the sensor it may be useful to include location information, so we have an extra node property.
Put the whole thing in a train and have HomieZero emit the location every 10 sec. Is the location an aspect of HomieZero or the TrainDevice? I think it's train. Even if the total device does not move at all, it is still a node and the information is 'encrypted' in the topic string or as a (static) measurement $unit.
So when is it an aspect of HomieZero? IMHO never.
Another one in the same league, $stats/battery. Battery levels only get important if you use them in a device that HomieZero is part of. It is a node of the total contraption, not HomieZero specific. Probably even $stats/supply, it tells us something about the powersupply, not HomieZero, so a node. What I want to know from HomieZero, is the supply enough, that tells us something about the state of the HomieZero device, a voltage does not. I would like to get a message "need more juice". HomieZero connected to a power source messaging voltages is a Voltmeter, a complete device with a Voltmeter namespace and the HomieZero namespace.
Homie is a provider, it provides network connectivity and provide a means to communicate using mqtt. This hypothetical minimal implementation is just that and it only actually can do something once attached to an information provider or consumer. Practically we often use the same hardware that Homie runs to attach sensors to though both could be separate and miles away from each other. Homie provider and I2C master in one chip.
Regarding (auto) discovery, is it Homie you want to discover or the sensors/actuators. Mainly the latter, but you also want to keep an eye on the Homie aspect of the whole device. Homie is the provider for the discoverability of the sensors (but that does not mean it has to do all the work)
Regardless of agreeing with this view, just do the exercise once, go through every thing in the convention and think, is it part of HomieZero or should it be a node node/property of a whole device (with its own namespace). I think there are very few changes to the current convention as it is very well designed but it will help with future decisions.
@ingoogni Please try to keep your answers short or move the important parts to the beginning and elaborate later on in your post. A "I thing this should be an optional node and I don't like it" would have been sufficient :)
@fermuch The projection is not required for the GEO URI schema.
@ThomDietrich
What about homie/device/location to make it a normal node and specify "$type=location". Properties are "geo", "text", "relative". So all of them can be given, or just one.
@fermuch The projection is not required for the GEO URI schema.
Very true! WGS-84 is the default coordinate reference according to the RFC (section 3.4.2).
All, please try to keep your answers short and technical. In my last summary posting I posted 5 questions. It would be great if you provided your feedback on them.
@fermuch did you follow the link I provided? Here it is once again: https://en.wikipedia.org/wiki/Geo_URI_scheme
@davidgraeff "location" as a normal node/property would be contradictory to the convention as it is right now. The convention only specifies attributes, while it leaves nodes/properties to the application. Attributes are for metadata and discovery, while non-$ topics (device, node, property, set) are for the actual application.
I would prefer to not break with that.
$location/geo, $location/relative, $location/text like with the $stats topic sounds like an option.
@fermuch did you follow the link I provided? Here it is once again: https://en.wikipedia.org/wiki/Geo_URI_scheme
Yeah, that's how I found the RFC. It's on the very first sentence of the wiki. I'm okay with using geo uris. I was just concerned about forcing everyone to use one kind of projection when requirements might be different for someone else.
After re-reading what I wrote, I might be talking a little bit pedantic, which isn't my intention, it's just that I already suffered a lot with projections and decimal precission in other projects, I don't desire it for anyone else.
@ingoogni An IOT device is not an DNS server. (Relative) Location does matter, there are use cases, so it does belong to HomieZero (optional). And because there are also use-cases for the location of the sensors, the location may also belong to a sensor.
BTW, regarding your train example: It is common practice for devices on trains to provide their relative location in device meta-data. There is even a train specific standard EN 15380-3 for that...
The train is a nice one. Do they provide their location like a beacon? If so, how different is that to the random number generator? Do they communicate to establish their relative position? IMO 'geolocation' is not the core business of Homie, just like timestamps are not the core business of Homie even though both are important aspects of IoT and both deserve require proper specs for $unit, $format etc.