JS scripting error "undefined has no such function "persist""

Setup, Configuration and Use Scripts & Rules
1

Hello,

i upgraded to the latest javascripting version and wnat to rewrite my rules but I get a lot of errors.

Even when I try the example in the doc

https://openhab.github.io/openhab-js/items.ItemPersistence.html#persist

I get this error

Failed to execute action: 1(Error: Failed to execute rule deye test: TypeError: undefined has no such function "persist": TypeError: undefined has no such function "persist"

here is my rule

items.Shelly_Bett_links_TotalEnergy.persistence.persist();

but

console.log(items.Shelly_Bett_links_TotalEnergy.state)

is returning

0.711 kWh

so the item exists

2

The error doesn’t say that your item doesn’t exist but that item.persistence doesn’t exist.

There appears to be some mismatch between the docs and the current version.

For the version you are using, instead of persistence use history:

items.Shelly_Bett_links_TotalEnergy.history.persist();

The front page on the docs shows that syntax still:
https://openhab.github.io/openhab-js/index.html
scroll about 1/3 of the way down to the itemsPersistence object.

3

but

items.Shelly_Bett_links_TotalEnergy.history.persistedState(local_timestamp_yesterday)

error is

Failed to execute action: 1(Error: Failed to execute rule deye test: TypeError: (intermediate value).Shelly_Bett_links_TotalEnergy.history.persistedState is not a function: TypeError: (intermediate value).Shelly_Bett_links_TotalEnergy.history.persistedState is not a function

and for

items.Shelly_Bett_links_TotalEnergy.persistence.persistedState(local_timestamp_yesterday)

error is

Failed to execute action: 1(Error: Failed to execute rule deye test: TypeError: undefined has no such function "persistedState": TypeError: undefined has no such function "persistedState"
4

That seems to be true. Dumping the result of history gives me:

getAllPropertyNames(obj) = rawItem,constructor,averageBetween,averageSince,changedBetween,changedSince,countBetween,countSince,countStateChangesBetween,countStateChangesSince,deltaBetween,deltaSince,deviationBetween,deviationSince,evolutionRate,evolutionRateBetween,evolutionRateSince,getAllStatesBetween,getAllStatesSince,historicState,lastUpdate,latestState,maximumBetween,maximumSince,minimumBetween,minimumSince,persist,previousState,sumBetween,sumSince,updatedBetween,updatedSince,varianceBetween,varianceSince,__proto__,hasOwnProperty,isPrototypeOf,propertyIsEnumerable,toLocaleString,toString,valueOf,__defineGetter__,__defineSetter__,__lookupGetter__,__lookupSetter__

So on my system the js-library version doesn’t have persistedState either. There is definitely something up with the current state of the docs.

Ah. Looking at the repo:

The docs have been updated in the last few days to document the new breaking changes to exactly the system you are trying to work with. Looks like a bunch of the new persistence features will be available soon, (under the persistence object), but I’m not sure what the plan or timeline is for the release of those features.

I don’t know if there is a way for you to view an older version of the docs page.

5

But I see this commit

Which says

Rename `HistoricItem` to `PersistedItem` and introduce `PersistedState` for state as string, Quantity & number.

Just before the 5.0.0 release

6

Right, but unless you have installed the library yourself directly from the repo, the version you are currently using on your OH system doesn’t have that change. Right now, if all you did was install by re-adding the JSScripting add-on you have 4.9 which doesn’t reflect those changes. This is proven by the fact that history does give you a valid response where persistence does not.

The version of the library linked to the add-on is not just the state of the library at that moment. Static releases of the library are connected to the add-on, and 5.0 hasn’t been released yet or connected to the add-on. It looks like 5.0 is do for release soon, because the docs have been updated to 5.0 docs, but again, I don’t know.

1 Like
7

I updated the npm package and this says clearly Version 5.0.0 via the openhabian menu

see also

npm list
js@ /etc/openhab/automation/js
├── openhab@5.0.0
8

Did you disable caching in the add-on settings?

9

Yes…I did several restarts… delete tmp and cache folders …

My simple idea is that the rest of openhab-core is not yet ready?

10

That is not the same thing.

The JSScripting add-on comes with a built-in version of the library and it will use that by default. If you want to use a version of the library other than the built-in one (for example that you installed via npm) then you have to go to the add-on settings for JSscripting and explicitly disable the setting that caches the built-in library so that your custom library gets injected into the rule contexts instead.

image
image729Ă—535 38.4 KB

11

I think they are shooting for 4.2. Most of the changes have been made I think. The latest openhab-js changes were merged last week IIRC. I probably would have tried to go a version or two deprecating the old names but not removing them instead of pushing a breaking change on a point release of OH, but I’m not the king. :person_shrugging:

I don’t think the changes are backported so I think if you change the version of the docs to stable or even to 4.0 you should see the older docs.

image

You can see which version of the Helper Library you are using with the following line in a script:

console.info('openhab-js version: ' + utils.OPENHAB_JS_VERSION);

That will give you a sanity check whenever there is any doubt what version of the helper library one is running with.

Note, openhab_rules_tools has a similar version number property:

console.info('OHRT version: ' + helpers.OHRT_VERSION);

as well as a utility to test the versions of openhab-js and OHRT are recent enough

helpers.compareVersions(utils.OPENHAB_JS_VERSION, '4.1.0') >= 0

That will be true if the installed version of openhab-js is at least 4.1.0 or later. The code is at openhab-rules-tools/helpers.js at main · rkoshak/openhab-rules-tools · GitHub. You can use that to provide sanity checks in your rules to catch when the version of openhab-js changes on you.

Though as @JustinG described well, the version of openhab-js doesn’t update independently from the JS Scripting add-on, unless you install it manually through npm. So the version should only ever change on you when you install an updated add-on or you’ve manually chosen to update it through npm.

One final note about the docs. When running the snapshots and milestones the docs may not accurately reflect what the code is in your specific version. If you are runing a snapshot the docs are very likely going to be a bit behind. If you are running a milestone, the docs are very likely going to be ahead.

1 Like
12

I use so many of the utils methods and somehow I’ve never noticed this…That’s an eye-opener!

Here I was talking about the github io full reference docs. Is there some way to rollback the version on those? I’ve never found one.

13

I know it’s there because I specifically asked for it. :wink: I wanted a way to throw a meaningful error in my rule templates when they are run with a version of the library too old and is known not to work. That caught me up awhile back.

It’s not in the docs though. You’d have to look through the code to know it’s there. There are some other great functions in there too like dumpObject. It’s a great place to check on periodically.

If the files are checked in and not autogenerated, you should be able to go back to the release tag you want and see the older versions of the docs. At least for the openhab-js repo they are good at snapping a tag for each release.

image
image664Ă—1296 46.6 KB

But I don’t know if the github io maps to that…

I tried a bunch of stuff and can’t figure it out. I’d be surprised if there wasn’t a way but what I tried wouldn’t work. You’ll have to look at the actual code itself I think.

14

Okay thank you both for a better understanding and I learned a lotout of your discussion…

Unfortunately still not running…

But this is because the rest of the openhab core and addons is not yet ready…

15

When manually updating the npm package, you should always read the docs before.
The add-on itself is always shipped with a version that is compatible to the openHAB version it is shipped with, but when manually installing from npm, you have to check compatibility yourself, see:

openhab-js version 5.0.0 requires openHAB 4.2.0 (which of course hasn’t been released yet, but I don’t want to make the table bigger by adding milestone information).

Exactly, the changes from openhab-js are aiming at 4.2.0.
5.0.0 is already shipped with the add-on since the breaking changes in openHAB core required this.
Breaking change alerts are shown during openHAB upgrade and Blockly is updated as well, so Blockly users just have to re-save their scripts (the breaking change warning also mentions what to do for Blockly users).

The problem is, that openHAB core has changed several return types — even if I had tried to keep history, openhab-js 5.0.0 wouldn’t have been compatible to openHAB versions prior to the changes. Therefore I decided to rename and extend the API as there already were breaking changes (better bundle breaking changes to one API instead of split them up over several releases).

It should be possible to have JSDoc put the docs into a folder according to the current version, but that also wouldn’t lock the docs to the release version as I increase the package version only before publishing a new release and not after one (this way I can follow semver by checking what has changed and then deciding on the version number).
The problem would be though to have the links inside the add-on docs point to the correct version without having to update the links manually.

Should be possible to uninstall the npm version of openhab-js and then use the one included in the add-on.

1 Like