Hi there,
I try to get a simple rule done in OpenHab 4.3 using the UI and Blockly.
The Trigger is at the moment “When a member of a group changes”, which works fine.
then I use this Blockly Script:
and get the error “TypeError: Cannot read property “name” from undefined” in the log.
Why is the variable “UNDEF”?
I searched and tried a lot the last few hours. Reading a lot, but didn’t understand it well enough.
Are you actually triggering this rule with an item change, or are you trying to test it by pressing the “Run Now” button? If you try to test a rule by using the “Run Now” button, then there is no event context and the contextual information object is not populated with anything.
You are also going to run into trouble in the next step of the rule:
When you get the triggering item name, that is just a string of the item name. So it doesn’t have a separate name property and the attempt to access a name property from it will continue to throw an error. But you also do not need to get a string with the item name since that is exactly what your sensorName variable already contains. You just need:
Thank you, now I receive a feedback in the concole at least.
I change an item of the group ( open and close a reed contact ), I am aware that this Script part is connected to the rule.
2025-01-02 20:15:07.740 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OM_Fenster_OG_Niklas_links' changed from CLOSED to OPEN
2025-01-02 20:15:07.741 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gWindowOG' changed from CLOSED to OPEN through OM_Fenster_OG_Niklas_links
2025-01-02 20:15:07.743 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gWindow' changed from CLOSED to OPEN through gWindowOG
==> /var/log/openhab/openhab.log <==
2025-01-02 20:15:07.748 [INFO ] [nhab.automation.script.ui.5e060b723b] - undefined
The item is a direct member of gWindowsOG.
Do I have to do sth. special with this variable “SensorName”? There are typed variableds and variables ( I chose variables, but had also tries with string or item name typed variables )
Can you post the javascript generated by your blocks? (Use the Show generated code button in the lower right corner of the blockly screen.)
var SensorName;
function getOrInstantiate(cache, name, condition, create) {
condition = (condition === undefined || condition === null) ? ((manager) => false) : condition;
let manager = cache.get(name);
if(manager === null || condition(manager)) {
manager = create();
cache.put(name, manager);
}
return manager;
}
var OHRT = (() => {
const ohrt = require('openhab_rules_tools');
ohrt.helpers.validateLibraries('4.1.0', '2.0.3');
return ohrt;
})();
function getTimerMgr(cache, name) {
return getOrInstantiate(cache, name, null, () => OHRT.TimerMgr());
}
SensorName = event.itemName;
console.info(SensorName.name);
if (event.itemState?.toString() == 'OPEN') {
getTimerMgr(cache.private, 'OpenReminder').check(SensorName, 'PT' + 5 + 'S',
function() { console.info((String(SensorName.label) + 'ist offen')); },'TRUE' == 'TRUE',
function() { }, SensorName);
} else {
if(cache.private.exists('OpenReminder')) {
cache.private.get('OpenReminder').cancel(SensorName);
}
}
The console line here indicates that you didn’t fully follow the second recommendation from my first post. SensorName is a string variable (it’s a java string and not a javascript string, but that doesn’t matter in this case). String variables do not have a .name property. So, when you try to get SensorName.name you get undefined as the result in that console log statement. Instead of matching what I put here:
you are still using the get name of item block in the log statement.
Thank you.
Yes, my bad, but indeed the error remained the same.
What I did wrong: ( probably )
I used the method “contextual info” within a script. Now, I run it in an “inline script” and it works so far, that I now have an output for the name.
So maybe the main problem was, that I didn’t care when to use those 2 different options?
Blockly has some type checking which will prevent you from connecting a block of one type to an inappropriate input of another block. The devs have put a lot of work into implementing this and improving. However, when you create a variable without type, that type checking just gets bypassed. So when you use the regular Variable blocks, then it’s up to you to make sure you always understand what type your variable currently holds and what type each block is expecting.
The other options would have been to use the Typed variable blocks instead of the regular variable blocks. Using the typed variables doesn’t, I believe, change the code produced in any way but it does give the Blockly editor clues about where your variable blocks can go. If you had created SensorName as a string type variable then Blockly would not have let you attach it to the get Name of item block because the type would not have matched.
Neither one is more “correct” than the other, it’s just a matter of whether you prefer to manage some of that type tracking yourself or offload some of it to the Blockly editor.
looking back, there were several mistakes.
Maybe, this could help, my working solution:
Thanks a lot, Justin!
@JustinG Already did a great job explaining this but here is a reference to the explanation of typed variables that are highly recommended to be used:
Thank you Stefan. I will do my very best 
