How would be syntax (if it is even possible) when I need to follow group update?
I would like to have this, but syntax is not working eg. not sure if even possible
Profiles only work on Links and they mainly work on data coming from a Channel. It doesn’t really make sense to add a Link to a Channel on a Group. So you’ll have to implement that use case in a rule.
so it is not necessary to write a rule for that, just group into another group which works… I had it in rules but as per rule repair what is not broken i’m doing some rework on my rules/items … just because i can
I stumbled over this problem today and I do not agree with you here.
My use-case is to get the maximum opening of my heating valves to MQTT. The value itself is created by the MAX group function. Linking the group item to an MQTT channel using the follow profile should publish the value tobte bis, but it does not. IMO this is confusing and unexpected, because it works for a sknolenitem.
Only if it is valid to link a channel to a Group at all. In the general case, it is not, it makes no sense. The follow profile is an exception which looks sensible … but we don’t get that far because of the general prohibition.
I don’t think it is documented, when the Item type was invented it would not even have been a consideration. More like baked in to the the definition of Group.
I’m saying “it doesn’t work - because there is no code to support any channel link to Group”.
(Not just channels by the by - in ye olden days when Expire was set by OH1 binding links, that could not be linked to Groups either)
Why is there no code? because there has never been a need to link a Group. In almost every case, it is a nonsense idea - the Group state is updated by aggregation function, not channel. Group commands are sent to members, not channel. “There is no path for a channel for interact with a Group” is one way to look at this.
I understand what you want to do with using channel/follow to mirror a Group state, but if you want to make a case for that to be implemented you have to make a case for implementing channels at all. Don’t let me stop you making the case! but I don’t think “follow” is enough on its own. It would be a fairly fundamental interference with the established properties of Groups.
I agree that it’s confusing and unexpected. But, as @rossko57 explained better than I could, Group Items have not supported links to Channels in the past. I don’t know if it’s that it was not implemented or if it was something deliberately enforced. And without the Link you can’t use a Profile.
This is the root of my antipathy for Profiles. Because they are tied to Links, you are left out in the code when you don’t have a Link (Group Items, so called virtual Items). Even if we implement the most awesome Profile imaginable, it’ll only ever be a partial solution.
One of the very first things I implemented when I started as a wet-behind-the-ears beginner with OH is a very strong counter argument to this. Here is my simple (and common, I assume) scenario:
My wife and I both have bedside lamps. Obviously, these can be controlled independently. There is also a switch by the bedroom door that should control these lamps in aggregate. Currently, of course, this is achieved by a rule: if switch item changes then command lamp group. This could be achieved without the rule if the lamp group were linked to the switch’s channel.
This is not a huge deal BUT…the switch has an indicator light to show whether it is in the On or Off state and I want that switch to be On if either of the lamps are on. Now things get awkward. The lamps group is configured with OR aggregation state so that the group is ON if one or both lamps are on, that’s easy. A second rule can update the switch item: if lamp group changes then command switch item. I’m sure you see the issue immediately. I now have a loop that in my early OH days resulted in some very amusing chaotic light displays. So, now my simple rules have to have timed test conditions and an additional item that locks out the rules for a few seconds etc. This too is completely eliminated if the lamp group can be linked to the switch channel.
I have thought for a while that there is strong case to make here. My example above is just one practical example, but I also have never really understood why there is a theoretical distinction here with group states. In my mind the aggregation functions are not any different than UI control of an item. If
Actually, it’s just moved out of your control. The problem is still there and it’s a hard problem to solve in a generic way. There are too many use cases and each requires a slightly different sort of test and guard to prevent the infinite loops. Throw in the fact that autoupdate may be off and it gets really fun (maybe the Item never reaches the desired state ).
But I suspect that your specific problem could be handled more simply (you can post them to another thread if you want to work on them). When I see “timed tests” and the like I always think “there has to be a better way!” and often there is.
I think there is a strong case for linking Event Channels to Groups.
Event channels are stateless so there can be cases where the event (e.g. a button press) causes the Group to command its members. The state of the Group then becomes derived from its members in the normal way. @JustinG, your first example could possibly be handled by this sort of approach I think (give certain allowances).
The problem comes when we bring state into the picture.
That’s not valid. Or at least that’s not complete.
It’s a unidirectional flow involving multiple types of events with to possible paths depending on whether the channel or autoupdate (or both) handle the update.
Ultimately for two reasons.
The Group state is updated incrementally. If you have N members of a Group, when one member changes, there are up to N-1 updates to the Group as the aggregation function recalculates the Group’s state. You wouldn’t want to issue commands to the members for each of those updates.
The aggregation function updates the Group’s state, not commands. And updates don’t get forwarded on to the channel. So there’s be no way to have a Group behave the same way as an Item in this regard.
Also, don’t forget that not all commands can be states and not all states can be commands. since the Group get’s updated, the original command will likely be lost. If you have a case where autoupdate is off and you have, for example a Dimmer that gradually changes brightness, reporting it’s new state as it does so, there could be a flurry of commands flying around as the members of the Group update and change and new commands get issued.
Ultimately the problem stems from the differences between updates and commands which makes linking Channels to Groups challenging. If every change to a member results in a command to the Group which results in commands to all its members it’s going to be chaos.
Obviously these use cases are real and it would be great to address them. But we’d need to radically alter the concept of Groups and/or how Groups work in practice.
Maybe if there were a synchronize aggregation function where:
the state of the Group is UNDEF/NULL unless all members are the same state
only Item’s whose state can also be issued as a command are members
when an Item changes state from the Group’s current state, a command is issued only to those members who are not already in that current state (this eliminates some use cases though)
ignore updates to the members for a time (how long?) or maybe ignoring updates that are to the same state as the Group
throw up our hands and pretend the cases where the Items gradually change with multiple updates to the new state don’t exist
ignore the state from any Channel linked to the Group, treat any update as a command to send to synchronize the members
I regard that as oversimplified, and as often is the case, the fundamental difference between commands (“do something” instructions) and states (“its like this”) conditions must be observed.
my point is really that we are looking at unidirectional pathways, not interaction.
Using the Item state for a channel function can be done (see KNX binding) but it is very much the exception.
So for the “special” Group Item - the Group Item being invented specifically so that it acts in this way
It’s certainly not my decision as to whether links to Groups should be implemented or no. I see a weak case “for” and strong reasons not to mess with the architecture, not least because that will introduce more confusion than it removes.
“I’ve linked this Group to multiple zwave switches, why doesn’t it work?”
Ha…yeah, you’re both right. Sorry, that’s my biologist training which reduces much of molecular biology to the “central dogma” DNA <-> RNA -> Protein. The simplification was not intended to be complete or a statement that the directional pathways were complementary or even analogous. I merely intended to propose that from a theoretical perspective these pathways are feasible. I definitely didn’t intend to conflate commands and states, just elide the difference for now for simplicity’s sake…oh well, one more in the long list of ideas that seemed so promising in my head.
I surely don’t know any better. There are always solutions for any problem that group channels might cover, so it’s certainly not an emergent issue, but I would argue it remains worth thinking about:
again, from my personal experience, this was an issue I ran into nearly on day one of using OH, and there are several more examples floating around here of other beginning users running into the same sorts of questions
it has always felt a little…I’m not sure of the best word here…disjointed(?) the way Groups are presented. They are treated like items in many ways (both in core code and general usage), but they have so many specific functions and restrictions that it sometimes seems there are more caveats than similarities.
I admit, I’m not sure I see the confusion that would be introduced. As it currently stands, any item can be linked to multiple channels and except in a few cases it’s not a good plan and is going to lead to “why didn’t this half-baked idea of mine work”. Does this really change that at all? It’s a different thing to propose that one group linked to one channel can distribute/aggregate information between that channel and a list of member items, than to propose aggregating a bunch of channels in one group.
My problem is long since solved to within acceptable parameters of elegance, with the time-based requirements handled by expire and UI rule conditions breaking any loops. The point was not that a solution didn’t exist or that I was still struggling with the problem, only that even the “better way” does require what is, in fact, a moderately advanced solution for what is frequently a beginner problem.
That’s all I ever ask…
Now you’re just getting nasty…there’s no need to drag autoupdate into an otherwise perfectly civilized discussion.
The cloud of use cases is, I would argue, greatly reduced by the fact that it is only sensible to link a channel to a group item that has an aggregation function (setting aside the event channel idea). This pretty much restricts the system to binary and numerical considerations.
I think you both zeroed in on the one significant issue with the points about an update coming from a channel not being the same as a command going out to member items (and the converse, that an aggregate function update is not the same as a command triggering channel activity. But that same reduction in potential cases means this is not at all out of the realm of possibility here. When a binary aggregate group is updated by a channel from ON to OFF, there are not really that many options for what the equivalent command is that should be propagated to the member items. In fact, of course, most users who would recreate the function of this link in a rule would simply pass the stringfied state of some non-group item linked to a channel as the command to the group item. That’s obviously the most simplified example, but I don’t see numerical aggregation functions changing the basic argument all that much.
Yes, it does mean moving the problem to some specific functions in the group item that make reasonable guesses about state updates -> commands, but groups items already are essentially a collection of specific functions not found in other items entirely for the purpose of saving the user the hassle of doing that function the hard(er) way. So I don’t see it as being much of a stretch (again, in theory; can’t speak to the complexity of the actual java involved).
They are like other types of Items, except in the ways they aren’t. Not sure what can be done about that. They are different in lots of weird and interesting ways. But the way they are presented is something that can be addressed now without need for changes in how Groups work.
I would argue the opposite. It only makes sense to link a State Channel to a Group without an aggregation function (an Event Channel I could see linking to any type of Group). Then it’s simple, the state of the Group comes from the Channel and updates get forwarded to the Items as commands.
If you link to a Group with an aggregation function, where does the state of the Group come from? The Channel only, the aggregation function only, both? If both, how do we tell where the Group’s state came from? Does it ever make sense for the Group’s state to be different from what the aggregation function says it should be? How should the update events be handled? Do they get forwarded to the members as commands to keep everything in sync, or does the Group just maintain it’s own independent state separate from what the aggregation function says it should be when linked?
Note, I believe there is no way right now for the Group to know where the updates came from so that’s going to be a big change unto itself and a necessary change to address some of those questions.
I’m not actually worried too much about what the command should be. I worried about a flurry of commands being issued if the Group remains implemented as it is now. For example, let’s say I have 5 Switches that are members of a Group:Switch:OR(ON, OFF). They are all OFF right now. One changes to ON. The Group aggregation function runs and the Group gets updated 4 times, one for each step in the aggregation calculation. Each of those updates results in four commands to each of the Group’s members, one for each update. That brings us to at least 16 commands issued based on that one Item changing state. But it doesn’t stop there because those commands will result in the Items changing state (in this case) which triggers the aggregation function and again the process runs again. If I did the math right, we are looking at close to 80 commands until everything settles down from that first event.
And then we have the issue on how the aggregation function processes the Group’s new state. It does so incrementally so it’s entirely possible that in our example above, the first update is to OFF. If we are not careful that means when you turn that light ON it ends up getting turned back OFF because of the order the aggregation function calculated.
Some of this can be avoided but it’ll be tricky. But philosophically the bigger issue is, it doesn’t make sense that the Group have two independent sources for its state. I’d argue that if a Group supports a State Channel Link, it should not allow an aggregation function. But then the question becomes, what does the state of the Group represent then in that case? Why is it even a Group in the first place?
Or, if you link a State Channel to a Group, only the commands are processed and, as is usual, the commands are passed to each member of the Group. In that case, the state of the Group only comes from the aggregation function (if there is one). But this significantly limits the types of Channels that can be linked to a Group since most Channels only provide updates, not commands, even for things like switches.
If you want to keep the members of a Group in sync, I could see it being theoretically possible to write a new aggregation function to do that (we don’t want to break everyone’s system who use the aggregation function to get a summary of current state). It might be possible to do so in a way that avoids the problems described above. But I think that’s a separate problem/use case from linking to a Group. In fact, if I have time, I’ll code something up as a rule template to prove it out.
I can see where you’re coming from here. When I said ‘sensible’ there, I was thinking more structural than functional. I meant ‘sensible’ in the sense (blasted English) that the state of a group with no aggregation function has little to no inherent meaning, so linking it to a channel which has a concrete, real-world meaning/representation is not really a theoretically sensible thing to do. In contrast, an aggregation function tends to impart to a group a concrete meaning: this is the average temperature of the rooms on the first floor, or this is the indicator of whether any outside lights are on or not. There are times where it makes sense (to me at least) to be able to match these meaningful group states to real-world representations via channels.
If we shelve, for the moment, the fact that aggregation functions update a group state then, in my view, this problem simply disappears. It is no different than any other item that is linked to channel and can receive incoming state changes from UI actions or Rules or Other group commands. In my mind, it doesn’t seem to be such a stretch to abstract the aggregation functions one further step away from groups and just consider them one other way of altering an item’s state. Every aggregation function can easily be replicated by a rule (hence your interesting proposed PoC on a sync function), so why must we consider them such different entities?
The answer, of course, is update vs command. As I understand it, this is the crux of your argument: changing aggregation functions to fit group-channel links is too big (and potentially breaking) a change to be feasible. I don’t know that to be true; I’ve never looked through the aggregation function code (not sure how much I’d even get if I did given <0 java experience). You’re probably right, but I’m willing entertain the idea that this is not an insurmountable issue because, sometimes, that’s how really interesting new ideas are born.
I admit, you’ve lost me here. This can’t be how aggregation functions actually work, can it? It is completely illogical to attempt calculate an average value incrementally. If this is how aggregation functions work, then why don’t we see this behavior now? I must be missing something…
I hope you don’t find these discussions too exasperating (if you do please just say so, I do understand and won’t take offense). I very much enjoy having the chance to stretch my understanding, learn, and think about interesting directions OH might go.
Try setting up a rule triggered from a Group Item state update and observe.
Groups are quite an ancient feature, with some oddities. But that’s just about implementation, not about the logical sense of linking channels to something that was intended to interact solely with other Items.
I just want to be clear, I’m not arguing that Groups should not support Links.
However, what I do want is for us to think both about how Groups work now and what changes would be required to make them support Links in a meaningful way. I’m not sure we are there yet, but I’m not going to implement it so who cares whether I think we are or not.
OK, let’s take that and run with it. We link a Channel to a Group that provides a temperature reading of some sort. The Group has members that are Number Items and the Group’s type is also Number (lets ignore units for simplicity. The aggregation function is AVG.
What supplies the state to the Group? The Link, the AVG, both, neither?
If it’s just the Link, then what’s the AVG there for? In truth, it’s not even used so why have it? It adds nothing.
If it’s just the AVG, then what’s the Link there for? I think the argument is that the Link is there to command all the members of the Group. So do we automatically convert all updates to Commands? What if the update comes from something other than the Link? What about updates to the Group caused by the members changing? Can we even tell? Do we only support commands? Most Channels only update. And again, what if something else commands it other than the Link? Does the command just get forwarded to the member Items or do they also get sent to the Channel? What if the Group’s members never reach the state that came from the Link?
If it’s both we have to answer all of the above questions and more. How do we avoid infinite loops as members Change in response to commands forwarded from the Group which, if we can’t tell where they came from and updates are to be forwarded as commands? How do we know at any given time whether the state of the Group came from the Link or the AVG? If we can’t tell, does the state of the Group even have a meaningful state? What if the AVG calculated state never reaches the state/command that came from the Link?
So does the utility and purpose of aggregation functions. I don’t think we can just throw out what it currently means for a Group to have an aggregation function just for this convenience. That would be an epic breaking change.
Again, I’m not arguing that Groups should have Links. I think linking Event Channels is a no brainer (though suspect it wouldn’t be allowed right now) since they don’t have state. That would just provide one additional source for commands to the Group.
But what I am saying is it’s really complicated and there are a lot of design/UX questions that need to be answered. I am arguing that the way Groups and aggregation functions work today, Links do not make sense so we need to be deliberate in how we change Groups and/or aggregation functions to support it.
Were I to implement this I’d do the following. I really see this as two separate problems.
Links
Allow Event Channels to be linked to Groups with aggregation functions.
Groups with Links must have a type
If a Group has a Link, no aggregation functions are allowed.
Commands from the Linked Channel get forwarded to the members per normal.
Updates do not get forwarded to the members and only update the Group’s state.
The state of the Group can be updated (currently you cannot sendUpdate to a Group in a meaningful way)
Sync:
Create a new aggregation function called SYNC (or what ever makes sense). The purpose of this function is to convert changes from the Group’s members into commands to the rest of the Group’s members.
Commands to the Group are forwarded per normal.
Care must be taken to avoid infinite loops, handling autoupdate, cases where the member Items never reach the commanded state, and limiting the flurry of commands that can result
SYNC could be combined with other aggregation functions since it doesn’t actually update the Group’s state
SYNC maybe could be used even when a State Channel is Linked to the Group, but again care must be taken
But I’m not sure all the questions have been answered with the above approach. I think it avoids breaking the way Groups currently work while being able to cover at least some of the use cases, assuming that there is a robust way to actually avoid infinite loops and an unacceptable flurry of commands on every change.
Again, all I’m saying is this is not simple and we need to proceed with thought and concern.
Perform the experiment that @rossko57 proposed. You’ll see that if you trigger a rule based on updates to the Group (not member of, the Group itself) with an aggregation function, every time there is a change to one of its members, that rule will be triggered N-1 times where N is the number of members of the Group.
But, as @rossko57 says, that’s just how it works now and it’s something that could be worked around by changing how the aggregation functions work (though that would be a breaking change unto itself, though a pretty minor one I think).
2022-11-04 08:12:12.147 [INFO ] [openhab.event.RuleUpdatedEvent ] - Rule 'a92d5efca6' has been updated.
2022-11-04 08:12:28.749 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Switch_MasterBedroomFanLight_OnOff' received command OFF
2022-11-04 08:12:28.749 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Switch_MasterBedroomFanLight_OnOff' predicted to become OFF
2022-11-04 08:12:28.750 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_MasterBedroomFanLight_OnOff' changed from ON to OFF
2022-11-04 08:12:28.750 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gLights' changed from ON to OFF through Switch_MasterBedroomFanLight_OnOff
2022-11-04 08:12:28.750 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'MasterSuiteLights' changed from ON to OFF through Switch_MasterBedroomFanLight_OnOff
2022-11-04 08:12:28.750 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gLightsCount' changed from 1 to 0 through Switch_MasterBedroomFanLight_OnOff
And no response from the rule.
If I change the rule to include the update of a regular item, for example the same Switch_MasterBedroomFanLight_OnOff then the rule fires appropriately but only once (well three times, but once for each item linked to that channel).
Is it possible this behavior of groups has already been changed and aggregation functions are not a standard item update or the update event is suppressed? I’ve not heard of any such changes.
Although temps were one of my examples of a aggregation function supplying a group with a meaningful state, I agree that it is not an example that makes as much sense for a channel link because outbound signals to the channel are less sensible (what real-world thing would you want set to an average temperature?). But we can use it anyway.
The function. I can see two different forms of link here. One where any changes from the channel are presented as a command to the group and the state then changes after group members have processed the broadcast command and one where the channel is write only and input signals are simply ignored.
This is one thing I was trying to get to in an earlier post. I don’t think this is really all that unreasonable (perhaps only a little unreasonable). It’s certainly a little trickier to mentally picture what exactly this would look like with this numerical example, but it’s quite intuitive with the binary aggregation functions.
This is an interesting open question. But this isn’t really something that has an answer at the moment is it? I am free to send an update to a group item (with or without an aggregation function) right now but it is a purely symbolic act (as you say it is not done “in a meaningful way”). The issue of distinguishing between these things is certainly beyond my knowledge. You’ve indicated that you don’t think this is currently feasible and that makes sense, but I don’t know links work under the hood. It would certainly be the domain of the link to handle the transition from update to command, I would think, and that way the group does not have to distinguish update origins.
This sort of decoupling happens on occasion even now in all sorts of items, does it not. It is usually the other way where a command or update from the item side puts the item into a state that doesn’t match the channel data and shortly thereafter the channel reasserts itself and updates the state back.
I think I can see where you going with this though and there might be a possibility of a group state never and the channel data never matching and remaining in a back and forth conflict. Something like this?
channel update (converted to commands) gets broadcast to group member items, items change and group aggregation function gets updated but new state is not what channel expected and channel update gets sent out again.
Is that an issue that OH core needs to address or is that a configuration problem on the part of the user?
Not at all. I did not mean that we remove the ability of aggregation functions to alter a group state, only that we, for the purpose of the thought experiment, imagine that some pathway of changing the state other than update is available to us. Call it ‘state modification’ or ‘state functional adjustment’ or 'state correction` it doesn’t matter. If we start with a scenario where aggregation functions still work to give groups meaningful state value, but do it without the baggage that comes with the already codified and entangled system of ‘update’, can we get past many of these issues? I believe that a good number of them disappear. Is this valuable exercise or a likely scenario in terms of practical final end product, I don’t know, but it does change much of the thinking.
I think in the end my feeling is that this is just me saying exactly what you have here:
but since so much of that is internal, I’m not even really sure it would wind up as a breaking change at all. I definitely believe that you’re right that at worst is would be an exceptionally minor breaking change. How much of what users do with groups on a day-to-day basis is predicated on the specific fact that aggregation functions update groups. If the N-1 updates thing is still true (I’ll spend some more time this evening trying to see why I couldn’t get it to work) then I can’t imagine that any user out there relies on group state updates.
I suppose it’s possible. Once the member of triggers were added, the utility of triggering a rule based on updates to a Group became greatly reduced (I honestly can’t think of a good reason why one would ever want to do that actually). I imagine all sorts of changes to the aggregation functions could have happened without anyone noticing.
Does it have a type? IIRC the Group had to have a type for the update events to be generated. the fact that you are counting Switches (I’m guessing). Maybe count works differently. I only remember using SUM, AND, and OR in the past. I’m not sure COUNT even existed back then.
Another way you can see the behavior is to change the log level for ItemStateUpdateEvent (or what ever it’s called) to INFO which will add update events to your events.log. Or the developer sidebar event stream which will show the update events too.
Assuming that Groups use the same event processing as any other Item we do have the answer. Groups can’t tell where the event came from, they just know that the event occurred. Therefore any update, regardless of where it came from (rule, aggregation function, etc.) would be converted to a command and sent to/back to the members of the Group.
I’m not so sure about that. Since it’s only the Group that needs this it would seem odd to implement it anywhere else but the Group. I imagine that putting it in the Link might have impacts to all the bindings and this should really be transparent to the API. But I have no real insight into this and am just projecting based on observed behavior and only briefly skimming the code.
That’s one concern. At a higher level though I’m concerned that we know what the state of an Item is at any given time and if both the channel and the aggregation function can set the state of the same Group we end up in a situation where we don’t really know what the state really is. If I have an AVG aggregation function, I would expect the state of the Group to always be the average of the members. If the state can come from the channel too, that assumption flies out the window and I can no longer rely on the state of the Group for anything. I can never know if it represents the AVG or the last state that came from the channel.
We really haven’t discussed what configuration, if any would need to be exposed. I don’t know the answer to this question. I think it depends on the overall path that is taken to implement this.
I can’t imagine the core maintainers agreeing to invent a brand new event type to support this. Kai and company seem very conservative when it comes to such things.
But I don’t think this solves the root problem of never knowing what the state of the Group actually represents if it can be updated independently of the aggregation function. If the function is AVG but the state can be updated from other sources, you can never know from moment to moment whether the state of the Group actually represents the average. If the Group’s state can ever be anything but the average, what’s the point? We can never really rely on the state of the Group for anything.
To make an easier example, if I have a rule that makes a decision based on the state of a Group:Switch:OR(ON, OFF), if something besides that OR can come in and change the state of the Group, my rule will make the wrong decision.
That’s what I mean by the utility of aggregation functions goes away.
We don’t need to invent a new event type, we just need to lock down the Group’s state. If there’s an aggregation function, the state has to always come from the aggregation function and only the aggregation function or else there’s no point in having the aggregation function because you can’t rely on it.
If it changes how Groups and aggregation functions work, I guarantee you there is some user somewhere in the world that as written a rule that depends on the old way.
Just yesterday I helped someone with a rule that did so.
Yep, even tried with with my Switch:OR group and got the same result (or lack thereof).
Nope, didn’t see any long list of events this way either. Not sure what I’m doing wrong.
Hmmm…that’s a strong point. I don’t really know where the nuts and bolts of links are implemented. It just seemed to me make the most logical sense that if a link has a function that is aware of whether or not the item that is linked is a group then 1) that shouldn’t impact the bindings because they can continue to send the updates and 2) the group doesn’t have to try and distinguish the update origin.
I suppose it could be a profile… /joke.
I think we’re in complete agreement here at this point. As I said above in the Q&A, I think the function has to drive the state. The only way I see the channel impacting the state is that it has to (somehow - process tbd) command the items and then if that changes the aggregation the group state changes.
Oh man, did you really just drop Roy Batty on me! Well, so much for troubleshooting the group updates issue tonight; guess I’ll be watching Blade Runner instead.
).
Not sure what can be done about that. They are different in lots of weird and interesting ways. But the way they are presented is something that can be addressed now without need for changes in how Groups work.
