Add a location/geoip tag in device attributes #78
Comments
|
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?
|
|
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, ***@***.***> 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
<#78 (comment)>,
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. |
|
I'm happy with both sides tbh, so I'll let you guys work this out :P |
|
@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. |
|
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:
|
|
@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.
|
|
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:
Topic:
Open questions
|
|
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: |
|
Because $unit etc are attributes of properties. $location is an attribute of a device/node, not a property. From the convention:
Not sure why you've posted these links. I guess everyone here is well aware of those rules. |
@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.: |
|
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. 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 |
|
All, please try to keep your answers short and technical. @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- |
|
$location/geo, $location/relative, $location/text like with the $stats topic sounds like an option. |
Yeah, that's how I found the RFC. It's on the very first sentence of the wiki. 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? |
|
This is derailing (literally). Could we please go back to #78 (comment) ? |
|
@ingoogni geolocation isn't, but location is. So, to keep things simple I propose that the location is an optional device attribute of name I don't think there is a need to add more rules for type to the convention. If someone want's to use geolocation, he can write the "geo:..." uri to the location string. We may add a example for location with geo-string. |
|
@euphi You are not thinking about the controller perspective :/ On the controller side, I'm of course interested in the semantic of $location, otherwise it's useless. |
|
I kinda agree with @euphi, if you want to use the https://en.wikipedia.org/wiki/Geo_URI_scheme use Also everyone just keep this in mind: #95 (comment) |
|
Would be a good thing to actually evaluate topic hierarchy Vs string parsing. So we are back at Thomas proposal, that was quite decent. |
|
Thanks David. |
I opt for
I opt for arbitrary types. We could propose some useful "official" types (like geo:), but there can be many other possible types, like "room number" or domain-specific location designations (as the mentioned EN 15380).
Is there a standard for relative coordinates? Wha
I opt for yes, nodes shall also have an optional $location. |
|
I'll take care of this one in the PR following after #129 (comment) |
|
@ThomDietrich did you ever flesh this out in a PR? |
as per title
The text was updated successfully, but these errors were encountered: