I’m using RRD4J as persistence layer.
My main issue is that I have exactly one Time (the WakeupTime) that is always lost after reboot. Yes I read the manual and I know this might not work because RRD4J can only store numbers.
Is there any other way how I can store and retrieve this information?
I found “storedValues” in the new Version of Blocky but I did not found any manual about it.
That stores the value of the variable from one run of the rule to the next. The only way to save and restore a value across an OH reboot is through persistence. If rrd4j doesn’t save the types you need, look into MapDB.
The “if stored value “NextBulb” = null” . To start, the value will be undefined because it doesn’t exist. Nothing in this rule actually sets it to null so the if statement should never run. But the logs are showing that it did run so I don’t know what’s going on.
The proper way though would be to test if it equals undefined and initialize it then.
Accessing an uninitialized stored value should throw an exception:
21:16:10.625 [ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID '4b9f2cd9ba' failed: TypeError: Cannot read property "Testdummy " from undefined in <eval> at line number 20
That error implies that this.storedValues doesn’t exist, which shouldn’t be the case because as soon as you us a store value it should create that dict. When you query for a key that doesn’t exist in a dict, you get back undefined, not an error.
I would want to see the JS code backing that Blockly to understand more about what’s happening.
Sure. I was just trying to replicate @FranzS’ log output that doesn’t make sense to me.
It depends:
Create a new rule:
var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
logger.error(('Test124: ' + String(this.storedValues['Test124'])));
Result:
22:26:35.396 [ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID '8fc7061bec' failed: TypeError: Cannot read property "Test124" from undefined in <eval> at line number 4
store value will put the value into this.storedValues. stored values will pull the value from this.storedValues. You can’t pull a value before you’ve stored it.
And the code that creates this.storedValues in the first place doesn’t get added to the rule until you have a store value block. It doesn’t make sense to create it if you are not storing anything in it. And it doesn’t make sense to query values from it if you never store any values in it in the first place.
I would hope this is something that can be made clear in the docs.
But if you for example, store a value “Test123” ad then try to retrieve "Test456" you will get back undefined`, not an error.
Well, Blockly is an additional abstraction layer that has a number of pitfalls in store for users that don’t/aren’t able to read the source code. IMHO we will see a lot of posts with complaints about Blockly scripts that ‘don’t work as expected’. And yes, the answer is: good docs.
Right? and then the question begs… what is the point
Original post in this thread shows it is entirely possible to create scripts that, at best, don’t work
It’s always going to be possible to create scripts that don’t work. Blocky isn’t going to change that. And even if things were changed in this instance so that instead of an error it returns undefined, it makes no sense what do ever to try to read a cake from this.storedStates when no babies are ever stored there ever.
It’s not just bad coding practice, it doesn’t make any sense.
Bl9ckly does a lot to make the coding easier but it is still coding. It can’t protect you from all the potential pitfalls and illogical things you might try to do, like trying to read variables that are never created.
Rich and I have always been on the path to try to make it as fail safe as possible during design and implementation but there is some limit to do so.
Instead of complaining I would rather ask you, how we can improve it? What would you expect the blocks to behave like? Would a block help with which it is possible to check if key has already been set at all?
The problem isn’t accessing a key with no values. The problem is a user trying to access a variable from the store without having stored anything in the store at all.
To my mind, that’s a different thing entirely and having a different error when that happens is a good thing.
It’s the difference between asking for a value that doesn’t exist now but may exist later and a rule where no value will ever exist because the rule doesn’t make logical sense.