I’m trying to figure out of documentation if there is something like timestamp-update on items as well (eg. does not have a channel) but without luck
What I’m trying to do is to have 2items, one being updated by group members, and timestamp when group gets updated.
Is something like that even possible? if so, what’s correct syntax?
A group is not a channel and profiles only work on links between channels and items. So your solution will not work. I don’t think there’s a way to achieve what you are doing just through item definitions. The very simple solution here is just a rule. Trigger the rule when the group item changes or updates and update the timestamp item with the current time using system time or, as Oliver suggested, persistence. Just be careful using the persistence as you’ll want to make sure that the persistence server has actually registered the change before you get the time from it.
I have not yet worked with timestamp profiles, but if you added a second item to a channel?
I assume you have a thing where you get the presence of a mobile phone from one of its channels as ONOFFtype.
I’m too lazy to test it but just a thought to add a second DATE item with timestamp profile
This works and is the correct way to do it…if the item you want the timestamp for is linked to channel. The question is about getting the change of a group. A group item is not (cannot be) linked to a channel so there’s no channel to link the second item too.
It is possible, I suppose, if all the item members of the group are linked to channels that you could setup one single timestamp item and have that linked via the timestamp profile to each of those channels. But honestly, at that point managing one item with 20 profiles sounds like much more trouble than one simple rule.
thanks Justin - my intention was not to link a group item to a channel but all group members. Sure, then you do not have a group changed date…
I was just asking because I need this piece within my next project.
It’s pretty useless. If one Item followed another … just use the one Item.
If you want some Item to be a transformed version of another - timestamp, multiply by 1000, different language, whatever - it’s a fairly niche application and just what rules are good at.
You know you can have a Group of timestamp Items, and have that Group aggregation function select the oldest or youngest as Group state?
Not at all, that’s something different. Not following, but triggering some kind of transformative action. You know, like a rule.
But that’s not a follow either, it’s a transformative action triggered by a channel update event.
We got by before it was invented, doing the same thing with rules, so it isn’t strictly necessary - but it is very convenient for a common use case.
No. This is available right now, but you don’t like the method.
Go back a step - how is the Item getting updated/changed, what is doing that? Is there some unusual process involved for you that is not a channel or rule? (I can think of a few.) Why can’t the thing doing the update also create your timestamp?
typical use is group switch
which is triggered by bunch of items in there WITHOUT a rule needed.
Thing is not I dont like the way, i’m perfectly fine to work with rules which I do have a lot … but creating a extra rule to know time of the group which have been triggeret by the item in the group is simply not necessary.
Sure can be done and I have those of course as there is no other way, but since we have this feature for channels, I don’t see much point of not having it for items without channels
So, maybe a Group aggregation function of “TIMESTAMP” ? Or I suppose TIMESTAMP-CHANGE and TIMESTAMP-UPDATE
In the case of a Group, no “item follow” or “Item auto transform to another Item” will help you anyway - a Group Item state is set by some function acting on member Items states.
You can already link any number of channels to one DateTime Item using the timestamp profiles (there was a bug with that, but now fixed).
A channel is a pathway; routes events from A to B and B to A.
Profiles just modify the event payload.
Items are not pathways, they’re objects.
whatever it will be called … we dont have to play catch word in here… just simple way how to have timestamp of the change, nothing else.
If i was refering to the profiles it was because it’s working solution… no need of trying to point that it can’t be done or is useless…
Pointing out what can’t be done and what is useless for the desired result helps focus on what you actually want, rather than the means to achieve it.
What do you want?
The idea of “simple” here is (ironically) not as simple as it might seem. One of rossko57’s points here is that what you feel is “simple” from a UI perspective is actually quite complicated given that it doesn’t fit at all with the underlying structure of the core OH program.
It is easy for each of us to feel that because we have a use case for something that it must be a common use case. I’m guilty of it myself. In this instance, however, I have to agree with rossko57, this is a pretty small edge case. Users who are interested in timestamps are often more advanced users and interested at a more granular level than one large group of items (e.g., I have timestamps for every one of my door and window sensors and use those data in a variety of different ways).
You’ve been presented with three different possible solutions to the original question, each of which is “simple” in it’s own way (and complex in some different way). The other of rossko57’s points is that the nuances between these different solutions could actually be important based on your ultimate goal for this timestamp value, but you haven’t provided that so we can’t really make any further recommendations about which method is the “simplest”.
Method
Pros
Cons
Rule
The rule logic itself is really quite simple: when member of group changes set other item to time now. This is also the most extensible as no further action is required each time you add a new item to the group. Also, depending on your ultimate goal, you may be able to skip the additional item all together and just put the secondary logic of what you want done with this timestamp into the rule.
It does require some scripting because the UI doesn’t yet have a built-in point and click solution for this type of action, and some users find any use of rules inherently more “complex”
Group Aggregation Function
This might be the closest to the “simple” solution you are imagining. There will be a group item populated with other timestamp items and every change to one of those timestamp items can update the group value to the latest timestamp.
It requires the setup and tracking of an extra item with one of the timestamp profiles for every channel you want compared. This isn’t too bad, but you have to remember to do it and some users just work very hard to keep the number of “extra” items in their setup to a minimum.
One Item Many Linked Profiles
With the MainUI profiles are much more simple for beginner users than they were with just file configurations. This would also be a very “simple” solution therefore and wouldn’t even require trying to figure out the aggregation functions on a group (also fairly “simple” with the MainUI).
Similar to the con above, this does make that one item a little more complicated depending on how many different channels you wind up linking to it and each time you add a new channel you want tracked you also have to add a parallel profile link to this composite timestamp item.
The way Profiles are implemented they cannot be used for just plain Items. So a wholly new set of infrastructure and APIs and such would need to be added to enable the use of some new feature that works the same as Profiles except on Items without Links would need to be implemented.
I predicted this was going to happen when Profiles came out and frankly I’ve never been a fan. I would have much rather seen work done to make rules do the same job (except for the transform profile, I’d like to see all bindings drop transformations and have us use the profile instead so it works consistently) as now we have at least three ways to define behaviors in OH.
Profiles were created to handle some common use cases in a relatively simple way without rules. They don’t replace rules. One day one of the developers looked at the code and though “hey, I can intercept an Item’s state or command coming from a Thing and do stuff to it before it gets to the Item! That will solve a number of little things that require rules today!” But notice that middle part, it works between a Channel and an Item. \hey are limited to that specific context. They are limited in what they can do and how they can do things. And they never were intended to be a replacement for all simple rules. They were a target of opportunity and are and will forever be limited unless and until Profiles are replaced with some other completely different universal way to implement behaviors (hmmm, how is that any different from rules?).
But now that they exist all we get is “it’s stupid that I can’t do X with Profiles too.” That’s the problem with partial solutions. They work great in some cases but as soon as your use case doesn’t fit “it’s stupid that OH can’t support my simple use case too in the same way.”
This is not to be a knock on those who are saying this. It’s a natural reaction. Certain expectations were created by the mere existence of Profiles and those expectations are violated almost immediately. That’s the problem and why in general I’m relatively negative on Profiles in general. They establish expectations that can never be met.
I think this is supportable in Blockly now though which would be almost as easy. But it’s also a one-liner really (not counting the rule creation proforma stuff) so using a Script Action in the UI might actually be the simplest approach of all.
This could be an exceptionally simple to implement rule template if someone wants an easy first one to implement and publish. I’m focused on other things in the near term but will come back and implement it if I remember (ping me if I forget).
but all group members. Sure, then you do not have a group changed date…