ReferenceError: "input" is not defined by SCRIPT transformation

Setup, Configuration and Use Migration
, ,
1

Hello everyone,
I have the problem that I can’t get a SCRIPT transformation to run. I always get the following error:

023-03-18 22:50:06.210 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: “input” is not defined

My thing and transformation look like this:

Thing http:url:nbbPool "*******" [
	baseURL="http://www.blabla.de/test-json.php",	
	refresh=300] {
		Channels:
			Type number : PoolTemp "NBB Pool Temperatur" [ stateTransformation = "SCRIPT:js:nbb_PoolValidation.script" ]
}

nbb_PoolValidation.script:

(function(data) {
  var returnValue = "String has " + data.length + " characters"
  return returnValue
})(input)

System is running on 4.0.0.M1

has anyone had the same experience or found a solution? Thanks in advance :slight_smile:

LG partytown

2

It may or may not be related, but your transformation returns something like “String has 3 characters” but the Channel is of type number which needs to be linked to a Number Item. I would expect a different error for this so it may not be the root cause of your problem, but that is a problem.

You are also using Nashorn JS as the language for this transformation. I only bring it up in case that’s not intended. To use the newer JS you need to us SCRIPT:graaljs:<nameoffile>.script. In both cases you must install an add-on, and they are provided by different add-ons.

3

Hi rlkoshak,

thank you for your quick response. That the return value is not a number is a good clue. I adjusted my function:

(function(data) {
  var returnValue = data + 100;
  return returnValue
})(input)

I also adjusted my thing:

Thing http:url:nbbPool "*******" [
	baseURL="http://www.blabla.de/test-json.php",	
	refresh=300] {
		Channels:
			Type number : PoolTemp "NBB Pool Temperatur" [ stateTransformation = "SCRIPT:graaljs:nbb_PoolValidation.script" ]
}

Add-on für JS is also available:

Bildschirm­foto 2023-03-19 um 14.53.30
Bildschirm­foto 2023-03-19 um 14.53.301638×640 77.5 KB

Still get the error message:
2023-03-19 14:49:52.396 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: “input” is not defined

Are there any other approaches?

thnaks

LG partytown

4

I tried this but using jruby as that’s what I’m familiar with and have already got it all set up. I noticed that input is a String, so if you want to do arithmetic on it, convert it to integer / float first.

Then you need to return a string representation of a number, or you can return an actual numeric data type, either way seems to work. If you return something like “abc” which is an invalid number, your item will be set to UNDEF.

In any case, with jruby I didn’t experience the issue described.

I then tried installing jsscripting and it seems to work too.

My script:

(function (data) {
  return data + 1;
})(input)

When the channel retrieved “99”, the item became “991” but again, no errors.

I can only suggest trying to restart openhab. FWIW, I am using openhab 4.0 snapshot Build #3379 with a test version of the script transformation module, but I’d guess it should work the same on the stock openhab 3.4.2

5

BTW I noticed your return statement is missing a terminating semicolon… does that matter in js? That might be the problem here - it confused the js parser!

6

OK new insights. Is it possible that openHAB only loads the script again after a complete restart?
I’ve run the script now. Does openHAB buffer the script somewhere?

LG partytown

7

I almost forgot. There was a bug where changes to the script file isn’t being reloaded. You’d have to restart openhab. This was fixed only in the recent 4.0 snapshot.

I’m not sure if this reloading bug existed in 3.4.x though.

8

Thanks JimT,

That is the solution. I just tried it with the current snapshot. Works without any problems. :slight_smile:

LG partytown

1 Like
9

It shouldn’t matter in this specific context but it’s always best to use it.

It does and as far as I know the fix isn’t going to be back ported to 3.4.2.

10

I haven’t done a deep dive, but afaik, openhab 3.x has a different file watcher implementation, and this fix was applied to the openhab 4.x newer file watcher implementation.

So, maybe this bug didn’t exist on 3.4? @partytown was running 4.0.0M1 as stated in his original post.

11

Before I opened the issue that lead to that fix, I helped someone on 3.4.2 who was experiencing the same problem. I think the bug was carried over during the reimplementation of the watcher.