I just migrated to OH4 today. On startup it shows 20 to 30 of the following warnings. It is perhaps related to this thread albeit the latter is from 2016. It is probably a timing issue related to ‘start level’ since it does not occur after the ‘Rule Engine started’ information has appeared in the log file.
2023-08-16 17:33:51.921 [WARN ] [s.internal.SingleValueTransformation] - couldn't transform response because transformationService of type 'JS' is unavailable
You need to install the JS Scripting add-on to use JS in a Script transformation.
Of course it is. (See below). I have the ‘featured’ language installed, rather than the ‘Nashorn’ (which is I think deprecated). The problem is evidently a timing issue since OH is apparently trying to use JS to transform values before the feature has installed. Once the ‘Rule Engine started’ has been logged (when presumably JS has indeed finally be loaded) then the errors go away. i.e. the errors only appear in the interval between system start and ‘Rule Engine started’.
That can indeed happen after an upgrade. The JS Scripting add-on, like all other add-ons, must be replaced with the new version.
That was probably a fluke of timing. I’ve seen cases where the JS Scripting add-on still wasn’t available by that runlevel and it starts complaining that there is no automation add-on that supports application/javascript.
However, this should only occur immediately after clearing the cache (which is one of the steps done during an upgrade by can occur at other times too). It should not happen every time OH reboots.
Indeed. But it does exactly that.
Nothing like that has been reported before. I don’t know what could be the cause unless somehow the cache is being cleared on every restart somehow.
Well it was. In 2016. And even if nobody else would have reported it does not mean that the problem doesnt exist, (you are beginning to sound like my ex IT support department)…
I don’t know what you want from me.
I don’t have this problem.
I’ve never had this problem. I’ve never helped someone with this problem.
I’ve never event seen anyone report having this problem until now (a post from 2016 on OH 2.? doesn’t count).
I offer you my condolences but have absolutely nothing else I can offer. If that isn’t good enough you can complain to my manager.
@AndrewFG this is coming from modbus binding, right?
I think we need to do something to the add-on load order so that automation add-ons get loaded before bindings.
I think so. The thing code is below…
Bridge modbus:tcp:g24 "Modbus Binding" @ "Under Stairs" [host="192.168.1.xxx", port=yy, rtuEncoded=true] {
Bridge poller poller "Electricity Meter Poller" @ "Under Stairs" [start=0, length=10, refresh=5000, type="input"] {
Thing data voltage "Electricity Meter Voltage" @ "Under Stairs" [readStart="0", readValueType="uint16", readTransform="JS(24g-dV.js)"]
Thing data current "Electricity Meter Current" @ "Under Stairs" [readStart="1", readValueType="uint32_swap", readTransform="JS(24g-mA.js)"]
Thing data power "Electricity Meter Power" @ "Under Stairs" [readStart="3", readValueType="uint32_swap", readTransform="JS(24g-dW.js)"]
Thing data energy "Electricity Meter Energy" @ "Under Stairs" [readStart="5", readValueType="uint32_swap", readTransform="JS(24g-Wh.js)"]
Thing data frequency "Electricity Meter Frequency" @ "Under Stairs" [readStart="7", readValueType="uint16", readTransform="JS(24g-dHz.js)"]
Thing data powerfactor "Electricity Meter PowerFactor" @ "Under Stairs" [readStart="8", readValueType="uint16", readTransform="JS(24g-percent.js)"]
Thing data alarm "Electricity Meter Alarm" @ "Under Stairs" [readStart="9", readValueType="uint16"]
}
}
I do also use a JS transform on the state description of one Item (as below).
Number:Time System_CPU_Uptime "System CPU Uptime [JS(24g-uptime.js):%s]" <time> {channel="systeminfo:computer:g24:cpu#uptime"}
So the conclusion is that we need to ensure JS is loaded before things and items are loaded (rather than before bindings are loaded).
Can you please try
It is very difficult to find a start order that works for everything. Loading items and things after scripting add-ons is not a solution, because that will probably create issues with DSL rules.
I will certainly try that. But IMHO that ‘solution’ is really just “papering over the cracks in the wall”.
Understood. So – given that the issue stops after the system has reached the full start level – and that you are considering a “papering over the cracks in the wall” solution – perhaps you should just simply suppress the logger warnings until the necessary start level has been reached. Not a pretty ‘solution’ but hey-ho.
It was not meant as a solution but as an additional information to find a solution.
The best solution would be to remove all DSL related code (thing/item/rule). That would allow us to remove a lot of workarounds and lead to a much more clean and stable code.
Not helpful for finding a solution, but I also get this message every time after an OH restart since I upgraded to OH4.
I just didn’t report it, as I also considered it to be some timing issue caused by the order of components getting loaded. (I would even have to check, if I’m still using the associated item that uses the state transform 
)
Actually, I also usually get a bunch of warnings (right after starting) that claim that there is no such thing as a MAP-transformation…
So, not a big deal for me to ignore those warnings, but I remember, that at least the JS-warning didn’t exist on OH3 for me. The warning about MAP … I can’t remember.
That would be the equivalent of a lobotomy for openHAB. Being able to write rules in actual files is what makes openHAB so wonderful for me. Having to create and maintain rules/things/items/transformations/any other objects through GUI is a complete turn off for me.
Thankfully I can create things and items through code, so if .items and .things file support is removed, I can still deal with it by creating my items through code.
If I had something helpful to say towards finding a solution I would say that.
Not if there is a replacement (see RFC: YAML configuration · Issue #3666 · openhab/openhab-core · GitHub). The problem isn’t text file configs in and of themselves. The problem is DSL.
Just a small remark on that point (I think everyone knows that I also love file based configs):
Creating things through code is different than creating things from file.
A file based config will always result in the same object because it’s (more or less) immutable.
If you create something it still can change afterwards so that your code will not necessary reflect what you are using.
But with file based config you can ensure that:
I’ll gladly contribute (with my limited skills) to find a file format that is both easy to maintain (e.g. from the code base) and easy to used (from a user perspective)
Seems like it should be possible to create a Thing (or whatever) programmatically and mark it read only/locked the same as file based Things (or whatever) get marked. Then it shouldn’t be modifiable, right?
@rlkoshak thanks for clarifying / correcting me. OK, I must have misunderstood what “all DSL related code (thing/item/rule)” meant. I apologise.
If DSL Rule means literally RulesDSL, and not file-based rules in js/jruby, then OK. I don’t use RulesDSL anymore, but I do use file-based jruby rules.
As for .items and .things file, if they’re replaced with another file-based syntax (e.g. YAML), that’s fine, as long as they’re still file-based, and I don’t have to create / edit them through GUI.
However, I don’t understand what .things / .items syntax vs YAML would have to do with solving the issue described in the original post.
It also covers .things files, .script files, .items files, .sitemap files, and .persist files. The syntax of all those files are a custom DSL defined using Xtext. And it’s that dependency on Xtext and Xtend, coupled with the fact that the grammars are hard to work with and there are few maintainers who know them well left to work on them.
I’m certain @J-N-K could go into detail but my understanding is that they way they work and how they get loaded coupled with the way everything depends on them being loaded and available before they can load themselves causes a lot of challenges for startup.
Presumably YAML (or any other standard config syntax approach, YAML is attractive because we already have representations of OH configs in YAML in MianUI) with it’s fixed and non-custom grammar and standard library that can just be loaded by each unit in OH that requires YAML parsing eliminates that interdependence and should lead to a more consistent and deterministic startup.
That’s my understanding at least.