I used to get the triggering member in a (JS) rule triggered by a GroupStateUpdatedEvent using
var triggeringItemName = event.raw.event.getMemberName();
After updating to 5.2.1 (not sure if it also happened in 5.2.0) I noticed these errors in the logs:
TypeError: undefined has no such function "getMemberName"
Apparently event.raw.event is undefined so I printed the raw event:
{6.lastStateUpdate=2026-08-05T22:06:17.548653797+02:00[Europe/Amsterdam], ruleUID=8b438a4d8c, 6.state=OFF, 6.event=Group 'Residents_present' updated to OFF through Tom_present}
And I noticed that lastStateUpdate, state and event have â6.â in front of them, so I changed my rule to
var triggeringItemName = event.raw['6.event'].getMemberName()
And it started working again.
Is this expected behavior? I couldnât find anything about it
switch(event.eventName){
case 'ExecutionEvent':
case 'StartlevelEvent':
/* snip */
break;
case 'TimerEvent':
/* snip */
break;
case 'ItemStateUpdatedEvent':
/* snip */
break;
case 'GroupItemStateChangedEvent':
/* snip */
break;
case 'GroupStateUpdatedEvent':
switch(event.itemName.toString()){
case 'Residents_present':
try {
//var triggeringItemName = event.raw.event.getMemberName();
var triggeringItemName = event.raw['6.event'].getMemberName();
} catch(e) {
console.error(e + ' event was: ' + event.raw);
console.error(e + ' event was: ' + event.raw['6.event'].getMemberName());
}
/* snip */
break;
}
break;
case 'ItemCommandEvent':
/* snip */
break;
default:
console.log('Unhandled event type: ' + event.eventName);
break;
}
I will test changing type âItemUpdatedâ to âMemberUpdatedâ And I probably have to change the switch to event.groupname.
[edit]
âthe state of a member of an item group is updatedâ, âThis triggers the rule if the state of a member of an item group is updated (even if it does not change).â doesnt seem to trigger on a group of groups.
This also needs to be done on most of the other classes in OHRT (e.g. Gatekeeper, LoopingTimer, etc.) so I would ideally likely to find a way to implement this once, perhaps in utils.newTimer() or some other utils function.
Iâm a little cautious about key collisions in the shared cache but there are ways we can deal with that.
Another approach would be to rebuild the Object on the other side (i.e. new TimerMgr(cache.shared.get(âmyTimerâ)) which recognizes that itâs been javafied and rebuilds the Object using the data in the cached Object. But that imposes extra work on the end user.
Indeed, that has always been the case. Thatâs why in some of the rules languages there is support for a âDescendentItemStateUpdatedâ which includes the members of subgroups. JS Scripting only supports the core sert of triggers though. Youâll need to create a separate trigger for each subgroup or create a Group with all the Items as a member instead of subgroups.
Ah I didnât know anyway, triggering on an ItemUpdated event linked to a group still works and it shows up as a GroupStateUpdatedEvent. The only different thing is event.raw['6.event] instead of event.raw.event since updating. My code/rule works as intended I just have a feeling the 6. is not supposed to be there?
hi @uk59821 yes thanks for picking that up - I changed this now but no effect (and it was working under 5.1.3 (I beleive the default is true anyway- so this would have been ignored ) and that was only for the legend: so really did not make an impact its still blank
Your widget breaking might either be a consequence of more strict validation, however it wonât harm to have a look at it in the dev server with a proper stack trace. Probably create an issue and note in the title that a custom widget broke.
That might indeed be the case here.
When the TimerMgr instance gets put into the shared cache, is should get javaified automatically. I wonder a bit that the code doesnât throw an error at that point because it should reject javaifying functions âŠ
Anyway, passing false as third parameter when putting something into the shared cache will disable the automatic javaify. Similarly, for get, you can provide a third param false to disable automatic jsify.
Yes, it is. openHAB 5.2 reverts a change that removed the (numeric) prefixes in the first place. Probably this should have been noted as a breaking change.
That triggers the rule when the state of the Group Item itself is updated. It will only work with Group Items that have a type and a function.
But the event wonât tell you which Item thatâs a member of the Group caused the update. event.itemName will be there name of the Group Item.
Normally you shouldnât be using event.raw in the first place. Just about everything you could possible need from the event is part of event itself. See JavaScript Scripting - Automation | openHAB. Every piece of information that is carried by every type of trigger is broken out and converted to a JS friendly format for you.
The only reason I can think of to use event.raw is if you are using a GenericTrigger, which is a very advanced trigger which requires deep knowledge of the event bus and how to parse out the raw payload.
So if you need to change your rules anyway consider updating them to use the already parsed out fields instead.
But then if itâs indeed used by different rules the user is back to potentially getting multi-threaded exceptions, right? I still think I should try to fix this in the library so they work with javaify and jsify.
But I didnât know about the third option which is good to know. Iâve one rule that used to throw a warning because I was using the shared cache to share a value between the condition and the action. I need to test that rule and potentially use that third parameter. Itâs all the same rule so there is no chance of a multi-threaded problem.
Yes. Fixing it in the library would be preferable then.
I think there might be not a lot of concurrency in that specific case so it worked fine without running into multi threaded access exceptions.
Itâs not in the README, only in the JSDoc. We should probably add it to the README, and also document javaify and jsify there.
I think the memberName might be missing, have to check that.
I agree! but I couldnât find any other way to accomplish what I have now. Since a group of groups trigger isnât supported and imho creating separate triggers for every group member defeats the purpose of a group. (I also use âdynamicâ groups elsewhere). For now my solution works and Iâm aware that it is unsupported and might break with the next update.
console.log(event.memberName);
outputs âundefinedâ on a group assigned to a itemtrigger.
My problem is the âreloadAllModelsOfTypeâ routine gets executed on every change of an item file. Many rules are then blocked for several minutes and items gets timed-out.
For me the maximum number of decimal places in an oh-time-series chart is not taken into account for values greater than 3. When setting the parameter to 4 only three digits are shown.
This appears to be the behavior that has always been in place. There used to be technical reasons see below why this was necessary but this behavior has been in place since OH 1.4 at least. I donât know if thatâs evidence for or against it being the intended behavior but there used to be enough problems with this behavior on RPi 2s back then (which were the minimum supported hardware) that people complained about it and tried all sorts of workarounds (no of which would apply to this specific problem). I imagine if it could easily be changed it would have been changed back then.
Run on different hardware with a better CPU.
Try using YAML or managed rules which do not appear to have this behavior (though I could be wrong).
Use a language other than Rules DSL, all of which are much more efficient when loaded and parsed.
File an issue and hope it gets changed.
IIRC, the technical reason why all the rules need to be reloaded is as follows.
When any .items file is modified, every Item defined in that file get deleted and recreated anew. (Note this is true for all DSL files as I understand it).
When an Item is deleted and created anew it exists as a new Object in OH.
The Items you can so conveniently reference by name in Rules DSL (e.g. MyItem.sendCommand(ON)) get injected into the rule at load time.
Therefore, if the rules were not reloaded, the Objects injected into your rules become stale and disconnected from the new Object. I think you can still send commands and post updates, but that stale Object will not be receiving updates. You canât call MyObject.state and get the most recent state.
OH has no knowledge as to which Items are references in the code of which rules. Often it cannot know this information (a simple search is not sufficient). So to make sure no Item becomes stale in any rule, all rules must be reloaded.
I believe the other rules languages do not have this problem because they access the Items through the Item registry. They pull the Items on demand instead of having them injected at load time.
But I donât know if that means they are not reloaded the same as DSL rules. Generally, the other languages, particularly JS, jRuby, and Python are much more efficient in loading and parsing even on low powered hardware.
Thank You Rich for the clarification. I understand now the reason for DSL recompile.
The thing that bothers me though is I never had real problems with this issue. Since 5.2 this seems to be introduced. There must be an explanation for this.
I donât like the idea to solve software issues with more powerfull hardware. Thats why I like to know the reason of this new behavior.
Someone can look through the PRs on Rules DSL. A number of changes were made to what is available in rules, bringing Rules DSL much closer to parity with what the other rules languages allow (e.g. access to Item metadata just to name one). Perhaps that was the straw that broke the camelâs back for your machine. Or some other change is making parsing Rules DSL just that much harder for your CPU to handle. Someone would have to hook a profiler up to OH and figure out where the bottleneck is.
Loading all the rules on changes to .items files has always been there so that has always been happening and nothing new.
I suspect using YAML instead of .rules files might help. Even if the script actions remain Rules DSL, there will be about 10-15% reduction in the amount of Rules DSL code to parse which might put you back under the threshold that causes the problem. But I canât say for sure.
anyway, triggering on an ItemUpdated event linked to a group still works and it shows up as a GroupStateUpdatedEvent. The only different thing is event.raw['6.event] instead of event.raw.event since updating. My code/rule works as intended I just have a feeling the 6. is not supposed to be there?
