search

openhab / openhab-core

Core framework of openHAB
https://www.openhab.org/
Eclipse Public License 2.0
924 stars 424 forks source link

Discussion on ontology improvement #1791

Closed lolodomo closed 1 year ago

lolodomo commented 4 years ago

I open this topic to help improving the current ontology. Of course, the ontology cannot cover all cases but at least it should cover what most of users will need.

Here are the changes proposed in the next messages.

New location entries:

New location synonyms:

New equiipment entries:

New property entries:

Properties removed:

lolodomo commented 3 years ago

Gate added.

mhilbush commented 3 years ago

What do you want to do about Door? Currently there are three children of Door - FrontDoor, GarageDoor, and Gate.

Personally, I think it's inconsistent to have FrontDoor, but not any other types of doors (SideDoor, BackDoor, etc.) that are often part of a home. I don't have strong feelings one way or the other. It just seems inconsistent at the moment.

lolodomo commented 3 years ago

Personally, I think it's inconsistent to have FrontDoor, but not any other types of doors (SideDoor, BackDoor, etc.) that are often part of a home. I don't have strong feelings one way or the other. It just seems inconsistent at the moment.

I don't like the idea to break user setup already using FrontDoor or GarageDoor. So I can add few other ones...

lolodomo commented 3 years ago

Smartphone, LightStripe, BackDoor, CellarDoor, SideDoor and InnerDoor are now added in my PR.

cweitkamp commented 3 years ago

I am missing few locations to finalize/improve the model of my house:

lolodomo commented 3 years ago

am missing few locations to finalize/improve the model of my house:

* pantry or storeroom (Room)
* stairs or stairway (Room)
* toilet or guest toilet guest bathroom (Room)
* court or yard or courtyard (Outdoor)

To be added in the next PR. Hope the initial PR will be merged soon.

lolodomo commented 3 years ago

A property "Position" Is missing too.

cweitkamp commented 3 years ago

What about something like "Person" or "Pet" as additional equipments? I know it sound weired and in general you can add a whole new set of stuff for creatures or humans.

bwosborne2 commented 3 years ago

What about something like "Person" or "Pet" as additional equipments?

My wife & sons would take offense being categorized as Additional Equipment. Person & Pet should probably have a new parent, but what?

They may not be Family.

ghys commented 3 years ago

As discussed in https://github.com/openhab/openhab-webui/issues/572, I think "Luminance" is redundant since there's already "Light", on both cases the property is the level of light, that you can either control or measure. The Light property and the Lightbulb class of equipment are very similar to the temperature property and the HVAC class of equipment: a measurement implies we're talking about the ambient property and a Control or Status would mean that it's obtained or influenced through some equipment.

A point of type Measurement related to the Light property is therefore IMHO pretty clear already and there should ideally be only one way of giving semantic meaning. I'd vote to remove Luminance from the ontology.

bobadair commented 3 years ago

They may not be Family.

Occupant?

bobadair commented 3 years ago

I just noticed that “Lightstripe”, assuming that is not a typo above, should probably be “Lightstrip”.

bwosborne2 commented 3 years ago

Occupant?

Person would be better. You may be tracking non-occupants ( with their permission, of course).

lolodomo commented 3 years ago

I think "Luminance" is redundant since there's already "Light", on both cases the property is the level of light,

@mhilbush : you are the one who requested Illuminance. Ok with @ghys to remove it? I agree with @ghys argument on my side.

mhilbush commented 3 years ago

Yes, I agree it should be removed.

lolodomo commented 3 years ago

I just noticed that “Lightstripe”, assuming that is not a typo above, should probably be “Lightstrip”.

It should even rather be "LightStrip" I believe as the correct naming in English is "light strip" (2 words).

bwosborne2 commented 3 years ago

It should even rather be "LightStrip" I believe as the correct naming in English is "light strip" (2 words).

Is this something other than Light ? If not, this is redundant too.

lolodomo commented 3 years ago

@TBail : you are the one who requested lightstripe (with a typo) . Can you argument a little more why light is not enough?

At the same time, we also added Television because screen was a little too much vague and everybody owns a TV.

TBail commented 3 years ago

Ahhhh, i think i was comming from lightbulb. Lightbuld is very specific so i addes the light strip. I am fine with only one description. maybe we should differ between light and lamp. A lamp is the equipment and light is the outcone. it is not so easy a non native speaker

lolodomo commented 3 years ago

So we have lightbulb as equipment and light as property. Does it make sense to add lightStrip as equipment? Or is lightbulb sufficient? If we add it, should it be a child of lightbulb or at the same level?

bwosborne2 commented 3 years ago

Does it make sense to add lightStrip as equipment?

I think that is a slippery slope. There are light bars & light tubes too. I think lightbulb is sufficient.

TBail commented 3 years ago

Maybe we should differentiate between

Light sources like Light Bulb, Light Strip, ...

and

Lamps like Ceiling Lmap, Redaing lamp, ...

jensflorian commented 3 years ago

I miss from testing around in OH3 M5: Location: Balcony Location: Living room Equipment: Awning (synonym: sunblind) Category: Speaker I think equipment could also extended to smart showers and baths, for example see https://www.smarthome.kohler.com/

lolodomo commented 3 years ago

Location: Living room

image

lolodomo commented 3 years ago

There is no consensus for light strip with only few people interested and I think it is now too late to change something before the 3.0 stable release. Any change in the core requires a change in UI too. I propose to postpone the final change with lightbulb/lightstrip to 3.0.1. That means we will have to live with a typo in semantics (lightstripe)...

TBail commented 3 years ago

What about going one step back and use just light . This could cover bulbs, stripes, tubes, etc.

jensflorian commented 3 years ago

Indeed light should be sufficient. The proposal should also suggest enhancement to the location widget. Currently status/control will add lightbulbs as icons, but a measurement of light (illuminance) in lx is not depicted.

EDIT: I see the badge is already implemented: https://github.com/openhab/openhab-webui/issues/556

sancho-sumy commented 3 years ago

Could you please add location Balcony (loggia).

It's not actual if you live in your own house, but if you have a flat it's needed for 100%. Especcialy for people who live in Eastern Europe (Ukraine/Russia etc.).

servim commented 3 years ago

Не могли бы Вы добавить локацию Балкон (лоджия).

+1

grzegorz914 commented 3 years ago

please add also: wardrobe

bwosborne2 commented 3 years ago

please add also: wardrobe

I am not too sure about this btu if added it should likely be an alias for closet.

hannibal85 commented 3 years ago

Regarding Points I'm missing something like Prediction. Maybe could be a Sub-Point of Measurement to be used for numerical values that are not real sensor values but predicted/calculated based on some algorithm.

E.g. weather forecast, calculated timestamp in the future

WDYT?

powerpolly commented 3 years ago

could you add "Aquarium" or "FishTank" as Equipment pls?

bwosborne2 commented 3 years ago

I view that as something that might be useful for a local customization.

IMO the discussion here should be what is used by close to a majority of users.

CSchlipp commented 3 years ago

I'm currently missing the property "Color". As "ColorTemperature" already exists, it seems straightforward to include "Color" as well.

violine-21 commented 3 years ago

Please can you add the "weatherstation" to the equipment?

krocans commented 3 years ago

It would be nice to have equipment type "Tracker" or "GPSTracker" ... OH has GPSTracker binding and thing so I'm surprised why there is no such equipment type. Also seems that there is no property type which clearly means "Battery charge/level"

May be there is some help page where meaning tags/types are explained? Those are a bit unclear. Like "level" - is it meant to be battery level or water level in tank?

Mchl commented 3 years ago

Hello, I would like to suggest a property type for 'air quality' or 'air pollution' (or maybe more general 'quality' and 'pollution'). I'm running my own luftdaten.info compatible sensor and currently have these items mapped as 'smoke' which is not exactly right (and might conflict with actual smoke detectors).

robmachab commented 3 years ago

Very interesting topic. I missed all of this and have been a bit busy since I started using OH so have not had a lot of time to keep up or fully understand all off the capabilities.

I think the ontology covers the concepts around physical concepts very well. There will always be discussions about adding extra bits of equipment or locations rather than using the generalisation.

When setting up the model in my home, I had some thoughts about the behaviour and function of the physical concepts. It is clear that many of the points have states and behaviours. I think just now the ontology leaves the challenge of dealing with theses concepts to one side. Rather than trying to explain this a link to http://wonderweb.man.ac.uk/ would be a better starting place for a discussion on taking the ontology forward to new areas.

lionhe1966 commented 3 years ago

I would suggest to add the following equipment tags

Equipment: Airconditioner (Synonim InternalUnit) Equipment: Computer (Synonim DesktopPC)

niwla23 commented 3 years ago

I would suggest a mailbox equipment

TomMarg commented 3 years ago

I'd like to propose an list of NetworkAppliances to have the environment more structured

Equipment: Printer (e.g. HP Printer Binding) Equipment: Server (e.g. Plex Binding, Network Binding) Equipment: SAT-Receiver (e.g. Enigma2 Binding) Equipment: Remote (e.g. Logitech Harmony Binding) Equipment: Router / Switch etc. Equipment: CoffeeMachine (Parent=WhiteGood)

lolodomo commented 3 years ago

Maybe time to prepare a new batch of changes ? The problem is all the ultra specific requests.... I will go through all unhandled requests to continue the discussion.

TomMarg commented 3 years ago

I've in the meantime learned that I could just live by using a category of equipment that is not yet used in my configuration and changing label and picture in the UI. Having said that - a couple of 5 - 10 Dummy entries for Equipment would totally help rather than changing the model too frequently. (just my suggestion)

krocans commented 3 years ago

I think there are lots of efforts being put in wrong direction. There are huge amount of different kind of predefined "rooms" and in my opinion it's totally useless to maintain and implement it. All these restrooms, bedrooms, living rooms are "rooms". For most people those tags does nothing else than duplicates item name or description. OH itself also does no any differentiation between those different "rooms" - any way it's room (location). So single tag "Room" I guess is enough. And if somebody needs some script which behaves differently for different kind of rooms - custom tags will do the trick.

There is totally different situation with "equipment". At first for equipment OH by design "is aware" of equipment type - it groups equipment by type, it shows card badges etc. Opposite to rooms where "all kind rooms are rooms" for equipment fridge is not camera and receiver is not a washing machine so for perspective there are 2 options:

  1. update hardcoded model as often as necessary to include all possible devices in the world :)
  2. As others are also proposing - make equipment types somehow user defined. I know that is not an easy thing but probably better now than later. As a theoretical solution I may suggest following. Single tag "equipment" and put equipment category somewhere in metadata like ["Equipment"] {equipmentType="camera"}. This "equipmetType" can then be absolutely user defined data and OH can use it for for example grouping - let's say if user configured 100 different equipmetType then 100 cards will be generated in equpment tab. And in addition some of these equipmenttypes must be listed as "well known" - only a few equipment types OH is aware of. Like you can call your device type however you want but if equpmenttype metadata will be set to "Light" then bulb will be shown on card if switch is on.
openhab-bot commented 3 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-semantic-classs/114699/2

kaikreuzer commented 3 years ago

I think there are lots of efforts being put in wrong direction.

I tend to agree with @krocans and we should really be careful not to run into an uncontrolled proliferation of semantic tags.

A few comments:

krocans commented 3 years ago

Here is how I see ideal and universal (in my opinion) location hierarchy. Top level of hierarchy is GEOLOCATION - that means not geographic coordinates but site/campus ... people my have houses, apartments in several geographical locations controlled by one OH instance. GEOLOCOTION consists of OUTDOORS (eg there may be different climate measurements for outdoors in different locations) and 0-n BUILDINGs (whatever it is house or barn). BUILDING consists of FLOORs - no first or ground or basement or other "special" floors here. Like may be there is some mad scientist having labs 5 floors under ground level :) should OH developers hardcode "ungergroundfloor[1-5]" for him? And finally FLOORs consists of ROOMs - just rooms whatever you are doing there cooking, eating or sleeping or may be watching TV and falling asleep there :). Sometimes "room" may not even be surrounded by walls - in modern plans it's hard to tell is is living room or kitchen. Answer in this case do whatever is easier/suitable for you make it either one or two logical ROOMs in OH. As a summary GEOLOCOTION, OUTDOORS, BUILDING, FLOOR, ROOM is all that needs to be hardcoded in OH. All that fancy building, and room types and rules for them can be implemented using names, descriptions, custom tags, non-semantic groups - there are lots of options without need to be hardcoded in OH. I'd say such approach gives much more flexibility than being bound to bunch of hardcoded tings (and by Murphy's law among those hundreds of hardcoded there is no tag you exactly need :) )

rkoshak commented 3 years ago

I completely agree with Kai and kriocans. I've watched this thread with growing alarm at the proliferation of tags which for all practical purposes do not add any real meaning to the model. I really like the set of tags krocans proposes.

Equipment also has a bunch of areas where there are too many tags (do we really need seven different types of door tags?) but there are other areas where the specificity in the tags unnecessarily excludes things. For example, we could have a generic Appliance Equipment tag and then handle the difference between a dish washer, coffee maker, and washing machine through Categories and labels. I know there is a "WhiteGood" tag but if we are going to have a "catch all" tag, what do we need the specific tags for in the first place?

I think we have a pretty good set of Point tags actually, though LowBattery seems unnecessarily specific and makes it feel a little off to use for an Item that measures how much battery is left as a percentage as opposed to a Switch.

Where I think we should be looking to add rather than remove tags though is the Properties. For example, there is no Property that would go with controlling media (e.g. a Roku remote or the currently playing stream on a Sonos). There are no information technology type properties at all (bandwidth, online, bytes/kbytes/mbytes). Does it make sense to use Status/Power to represent the online status of a NetworkDevice? That's what I use but it's not intuitive. Does it make sense to have a SmokeAlarm Equipment when we have and Alarm Point and Smoke Property? That seems unnecessarily redundant.

Anyway, I've tried to say this before on this thread but felt like reiterating again my thoughts.

One final note, ontologies are hard to create and hard to use. The more stuff you add to the ontology the harder it becomes to use. We will actually make creating a model easier for users if we have fewer more generic tags with other ways to add specificity (labels and categories for example) than to try to cover each and every possible subtype (e.g. the doors tags) in the ontology. When you have lots of specify then it becomes weird.

A concrete example might be illustrative. Let's say I have a smoke alarm and a CO alarm. They are not the same Equipment, they are separate devices. How can I model this with the current tags? One option:

Equipment Point Property
SmokeAlarm Alarm Smoke
AlarmSystem Alarm CO

That's inconsistent. They are both the same type of device. The only difference is what it is they are alarming on. Plus SmokeAlarm and Alarm are redundant.

Maybe:

Equipment Point Property
Sensor Alarm Smoke
Sensor Alarm CO

That makes more sense and is in fact what I use myself. But then what's the SmokeAlarm Equipment tag for? It doesn't add any value because it's too specific.

Also note that by using the second approach is you can model any type of alarm in a consistent manner.

Equipment Point Property What it represents
Sensor Alarm Water Water leak detector
Sensor Alarm Rain Rain alert (though one wonders why there is no snow)
Sensor Alarm Temperature Freeze alert, or too high temp alert

The mere existence of SmokeAlarm as an Equipment type only serves to add confusion and inconsistency to the model without actually allowing you to model something that isn't already supported by the model.

Sorry for the long post.

TBail commented 3 years ago

I totally understand the discussion and beside @rkoshak examples you will find many other that are inconsistant and/or not complete. Eg. Equipment Lightbulb with point control/setpoint, but no property color.

The there is no documentation when to use what and some meanings are different from country to country.

An other point is that the longtime OH user are familar with some concepts. They all have build typically a group structure for items etc. so it is more or less easy to adapt the semantic sheme. For a new User it ist the next hurdle to work with openhab.

Maybe we should think about the option to reduce the semantic area to location, equipment, point a and property and the rest could be dynamically created by the user.

And yes i know that is a big effort, but sometime it is neccessary to throw things away