Context:
I’ve been searching a solution high and low for in house room by room presence detection (and better presence counter) solution based on door sensors and motion sensors only. Mainly this is an unsolved problem.
I’ve tried Wasp In a Box algorythm but I can confirm @rlkoshak (I cannot find the forum topic) that it has an issue with sensor/door timings and this is a not a simple way to decide on room entry/exit only based on sensor states. It might work for some people for in house presence detection which is a much simpler example.
So I started working on an algo that uses some timestamps of RoomA and RoomB ON/OFF state changes and if there is a Door state change ON/OFF timestamps in between. With this there is a chance to get the direction of door passed by.
Problem:
My main problem is that each equipment has only one default location but doors need two just as they have in real life In this problem I need to connect two motion sensors in adjacent rooms and examine the door between them. I work in JSScripting. The actions.Semantics.getLocation(item.rawItem) function works like a charm for all of non door items but for doors only the first location is retrieved but the second is not. (as this was my first idea to add to both locations)
I’ve already tried to add two items to the same channel of door sensor but there is still no connection between the two items as quering the Thing/Channel Registry adds far more complexity to the solution.
Also tried to query groups of the item but the location is above two or three levels of the item Equipment so this introduces recursion.
Question: Is there an easy solution that can be used to get a door sensor to connect two rooms and get that in a rule script?
I would like to create a generic solution for this to give back to community - warning: might not getting there to be usable, but worth a try. Specifying addtitional tags/metadata would again add complexity and I prefer the use the model to get locations of the door in question.
The semantic model itself is just tags and metadata. This information does not already exist in the semantic model (the only location relationships are the hierarchical ones, not sibling ones). So, even if you were going to “just use the model” for this that would include the addition of tags and/or metadata. You really cannot extract more complex information from a system without adding that “complexity” in somewhere.
You could include in a rule the ability to get the list of all locations in the same hierarchical level (e.g., all the rooms on a floor), but the relationship between those rooms simply cannot be represented by the semantic model the way it is currently formulated.
There are already exceptions to some of the standard rules in the model. For example, the basic advice is that all points should be inside an equipment group, however, there is a purpose for adding a temperature point directly to a location. Perhaps then you could file an enhancement request that allows door equipment to break the rule about only belonging to one location.
In the end, however, such a request is probably much more technically difficult and less likely to be acted upon than just adding your own “opensInto” metadata to each door item. This is exactly what the metadata system is for: adding an additional piece of relevant information to an item.
There are numerous other ways to store and retrieve this kind of data in OH. You could create a string item that holds a JSON formatted string associating each door item with its secondary location. But, editing that would be a royal pain. You could add an additional point to every door equipment which is just a static string item holding the name of the secondary location group. That really doesn’t fit the model however, because the model really should be about how the user interacts with the physical layout of the smarthome and having a non-interactive point in there seems counter to that philosophy. You could store this information outside of OH and retrieve it in the rule. None of these actually sound like good ideas, because they are not, and that is because none of them fit the stated purpose as well as metadata.
I agree with @JustinG. This just isn’t something that the semantic model can capture. Item metadata is the easiest approach I can think of.
In my rule templates that depend on Item metadata, The actual namespace is a property the end user fills in while configuring the rule which allows the end user to use what ever makes sense to them (of course there is a default also).
Then if the rule gets manually triggered (i.e. the event Object doesn’t exist) instead of doing the work of the rule, it goes through all the Items and configs and verifies they are configured correctly and generate a meaningful and actionable error message if a problem is found. For example, check that all the Door tagged Items have the metadata and the metadata is usable. Debounce [4.0.0.0;4.9.9.9] is a good example of this. The relevant code is at the bottom:
if(this.event === undefined) {
init();
}
else {
switch(event.type) {
case 'GroupItemStateChangedEvent':
case 'ItemStateEvent':
case 'ItemStateChangedEvent':
case 'ItemCommandEvent':
debounce();
break;
default:
init();
}
}
The init() function is where the config checking takes place.
