OK got it, they’re linked by the channel. Any update to the channel causes the time stamp to update.
What about items without things (and therefore without channels)? Can you just make up a channel to associate with the items?
I have items that receive data from external sources via the cloud and associated time stamps with them via a rule. There’s no thing, and currently no channel either.
not sure if linking items is doable (as it is not my usecase) but from logical point of view - why should not 
Hmm. Not sure. I’ll try this with the Aeotec sensors, which don’t have their own timestamp. Currently I use my own rule-based time stamp, but it only seems to get triggered when values change, not when values are updated but remain the same. Perhaps the profile method might solve this problem.
Channels are the structure linking Item to Thing.
Can’t be used to link Item to Item.
Profiles modify link behaviour. As there is no link available, you can’t use them with a pair of Items.
Never mind, linked behaviour can always be accomplished with rules.
Rule triggers are available both for Item state changes and state updates (which may or may not also cause a change).
Choose rule triggers carefully.
There is no reason to “expose” Items any longer. That feature has long since been turned off because far too many people were needlessly exposing all their Items which caused the cloud server to crash periodically.
The only reason to expose Items through the Cloud Connector is for IFTTT integration. And since that feature has been turned off for a couple years now, there is no reason to expose any Items at all.
To make Items available to Alexa or Google Assistant one uses Item metadata, which cannot be set from PaperUI anyway.
Perhaps what you are referring to when saying “exposing items” is something different.
Yeah, I don’t think the update triggers work in 2.5
We’ve talked about this before but I don’t think I was clear about what I need to do. What I need is to send data to OH from my phone (amongst other things). How do I do that?
Maybe I never needed to expose the items if I use the REST API. In that case, the problem I have must lie elsewhere.
DOH! It was an account problem on my phone. Sorry. Delete everything I said.
Thousands of users testify otherwise. This is basic functionality since OH 0.1
There might be confusion about the term ‘update’ in openHAB context. When you want some help with that, show example.
This was already discussed at length here:
The conclusion was that all the solutions offered (GroupMemberUpdateEventTrigger, UpdateEventTrigger) were for OH3 only. I’ll see if I can get around to doing some more tests, but the ones I’ve tried (UpdatedEventTrigger (with a “d”), ItemStateUpdateTrigger) don’t seem to do anything.
If you are using the phone app, I know at least the Android app has the ability to send some phone related stuff to specific Items.
- phone events like an incoming phone call
- alarm time
- call state
- battery level
- charging state
- wifi name
- DND mode
Using Tasker you can send anything Tasker knows (which is pretty much everything) to openHAB through the openHAB plugin.
I don’t know as much about iOS’s app capabilities.
Without the apps, you would need to use the REST API of openHAB to PUT or POST commands/updates to Items. When you are not on your LAN, you would need to do so through myopenhab.org’s server. What ever you are using to issue the HTTP PUT and POST commands will need to be able to handle basic authentication with myopenhab.org.
There really isn’t anything specific that needs to be done to individual Items to achieve this. Once authenticated with myopenhab.org, all of the REST API is available to you (at least in OH 2.5, in OH 3 there is an additional authentication step to access parts of the REST API, but not for Items so what ever you do for now will still work in OH 3.
Exposing Items in the Cloud Connector is not necessary and in fact wouldn’t do anything to support this use case even if it were still enabled.
Anyway, I wrote all the above before I saw that you figured it out but I’ll leave it in case future readers find some use from the list of possible approaches.
For OH 3 everything here with “Trigger” in the name are the possible triggers.
For OH 2 your best bet is probably looking at the Python triggers.py from the Helper Library which provides the implementation that parses the “Member of Foo changed” to the Trigger Objects that need to be passed to the Rule.
Search for “Trigger” and you should see all the ones that are supported in OH 2. Note that for Items the triggers are (lines 126-132):
- ItemStateUpdateTrigger
- ItemCommandTrigger
- ItemStateChangeTrigger
Also take note of how Member of triggers are handled. What actually happens is all the members of the Group are pulled and a separate trigger is created for each member. The JavaScript Helper Libraries do not handle this I think so you’ll have to do something similar in your code. Then to see which Item triggered the rule you use event.itemName. Note there is a limitation where you’ll have to reload the rule when the Group membership changes. There is no event to tell you when a Group membership has changed so there is no way to automate that.
One work around you can find in the various Python rules I have at GitHub - rkoshak/openhab-rules-tools: Library functions, classes, and examples to reuse in the development of new Rules. (e.g. Debounce) which creates a Switch Item that you can command ON and have the rule reloaded/recreated with the new triggers.
1 Like
Do you mean that I’d have to create a separate trigger for each item? My conclusion from testing is that there is an inconsistency: if I use ChangedEventTrigger(“gRecordLastUpdate”) on a group, it works as expected, that is, I get a notification of a change to the value of any item in the group and I can obtain the item name and act accordingly. This allows me to have matching timestamp items with the same names as the items, but with _LastUpdate appended. With one rule I can handle changes to all of them. But if I try the same with UpdatedEventTrigger(“gRecordLastUpdate”), it doesn’t work. However, both UpdatedEventTrigger and ItemStateUpdateTrigger seem to work for individual items - but obviously that forces me to specify all of the items, negating the point of the group.
I expect OH3 will provide relief, but in the meantime I’ll just have to list the items separately.
Essentially yes. But you don’t need to type them by hand. In the Python version is looks for a trigger definition string that starts with “Member of GroupName”, pulls all the members of GroupName and creates a separate trigger for each member. I would expect something similar to be done in the JS code where instead of creating a single rule trigger, you would loop through the members of the Group and create a trigger for each.
That’s not how ChangedEvent is supposed to work. It should trigger only when the state of the Group changed and event.itemName would be “gRecordLastUpdate”.
Even in OH 2 the timestamp Profile was available. Is there a reason you are not using that instead of a rule for this?
1 Like
OK, dynamic triggers. I haven’t tried those. Maybe if the number of items grows it’ll be worth it.
I’ve never understood what the “group state” means. As far as I can see, it triggers every time one of the group members has its value changed. If this isn’t the intention, what are groups for?
The profile solution (which I didn’t know about until yesterday or the day before) only works, as I understand it, with things and channels. It wouldn’t work with thing-less items that I’m updating remotely. It would be a solution for a couple of sensors that don’t have their own timestamp items built in, but since I have the rule I almost prefer to have one solution rather than two.
See Items | openHAB. A Group’s state is an aggregation of all the states of its members. For example, the average of all temperatures or the count of ON Switches or “ON if one Item is ON else OFF” type logic. Whenever a member changes state, the aggregation function runs and updates the Group’s state with the result.
Therefore, if you had a Group defined something like:
Group:Switch:OR(ON,OFF) gMySwitches
gMySwitches’s state will be ON if one or more of it’s members are ON and OFF if all of its members are OFF. And thus triggering a rule with Item gMySwitches changed should only trigger when gMySwitches’s state changes and the triggering Item is gMySwitches, not one of its members. That’s how it has always worked since OH 1.6.
It wasn’t until OH 2.2 (IIRC) that Member of gMySwitches triggers were added which would let you trigger a rule based on events from the members of gMySwitches. Prior to that there was no good way to know at all which member of gMySwitches triggered the rule.
Finally, Groups can be used to command all the members of the Group all at once. When you sendCommand to a Group Item, that command is forwarded to all of its members.
Group state is derived from some aggregation of members states.
It follows that if no optional aggregation s specified, there’ll be no group state update.
Caution; because aggregation is calculated in an iterative way, you can get more Group state updates than the single member Item change that began the chain.
Member Items may update without change. Because there was no change, I don’t think this triggers any aggregation, so no Group state update.
Member Items changing should generate Group update events (if there is an aggregation), and may generate Group change events.
None of that has anything to with “Member of” rule triggers, which totally ignore Group state and Group events.
One more thing to add is that even in Rules DSL which has Member of rule triggers, the code that actually parses and loads the rule actually unrolls that into a separate trigger for each member behind the scenes similar to how the Python helper library does. That’s why you have to reload your .rules files to pick up changes in Group membership.