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
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.
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.
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.
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.
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:
the behavior of your system is based on the description in the file
loading the file will always result in the same behavior because different behavior needs a different file
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?
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.