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 )
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.
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.