Can you please be exact where exactly you refer your statement to? Only this here (I already changed it)
Or anywhere else as well?
That cought my eye, yes.
Are there pictures of all widgets I could check?
Only at the beginning of the thread for the first release I did (I will always update when I do a release) and all the images in this thread unless you want to build your own version through the Merge Request here: Blockly enhancements 2 - scripts, ephemeris, persistence by stefan-hoehn · Pull Request #1212 · openhab/openhab-webui · GitHub
average state sounds a bit weird though, doesn’t it? After all, a ‘state’ is only valid at a certain point in time. If anything, IMHO it should be ‘average value of state’, ‘state deviation’, etc.
Or remove both ‘value’ and ‘state’? ‘Average’, ‘deviation’, ‘sum’ etc. look equally descriptive to my eye. Exception: ‘previous state’ needs to keep the ‘state’.
Where do you see “average state”? I only see values and the last one in the the drop-down has state.
Commenting based on the screenshots on the first post
-
send command
"value"to item MyItem: replace"value"with"command"(directing reader to understand the meaning of command)
Similarly for “post update”
-
get thing state: probably should be get thing status
Comments on
- item XX has changed since: would XX state has changed|updated since YY be better? Also, have the same past tense for changed and updated. I think this would emphasise the difference that we are talking about the state. That’s even more important now with these changes, as blockly commands deal with both item objects and the state values.
Comments on Extending Blockly with new openHAB commands - #176 by stefan.hoehn
- How about: get state of item XX
@maniac103 broughts good points about the exact spelling of the persistence functions. I will add one more proposal for your consideration
- get <average/delta/deviation> of item XX state since YY
Best,
Sami
First, Sami, I do appreciate that you take care, though keep in mind everybody like me is doing this whole work in our freetime, so I try to avoid double work (no offense, I just like to make that transparent), which is why I hesitate to do many changes afterwards - therefore I am posting everything I intend to implement here during the implementation before (I am aware you only jumped in now and have probably not seen that) Also every change needs to be reviewed later by someone else which is mostly Yannick who already has a big load of work to do (thx Yannick)
To make my life easier: Can you please edit your post above and add images of the blocks you want to have changed and even better scribble the changes what you want to have changed next to the block or on top of it. This avoids misunderstandings on my side.
Thank you
Stefan
PS:
“get <average/delta/deviation> of item XX state since YY” has already been amended by me, see above
1 Like
Hi Stefan, no offence taken, I do appreciate that.
Let me have a look if I can make it easier to pick up the proposed changes – makes it easier for others to comment as well .
I have updated the above post with pictures.
These are suggestions naturally and my feedback, and mostly bikeshedding. I leave it up to you if the changes make sense considering the effort involved etc.
Great, that definitely makes it much clearer and honestly this is almost no effort at all. I will post an update soon.
Looks great! That was fast
One comment on the second one, we post state updates, not commands. Are you able to have different placeholders depending on the action, meaning
<send command> "command" to item <item MyItem> <post update> "state" to item <item MyItem>
It was my understanding that you wanted to replace ‘value’ by ‘state’, in which case ‘average value’ would become ‘average state’.
Nevermind though, this has been cleared up by @ssalonen’s comments and your changes 
Probably would be non-trivial, that’s why the original block had “value” as the placeholder, which I thought was a suitable generic term for both what you send as a command or a state update.
i.e. update the state using this string value & send a command with this string value (commands and states are actually typed in OH core).
1 Like
I agree Yannick, I just tried to find a way to check and change the shadow block dynamically but that turns out to be either not straight forward or not doable at all.
By the way, do you by chance have some time eventually to look at the merge request as I do not want to make that even bigger with new changes? Just asking… 
1 Like
Hi Stefan,
very cool work, thank you for your effort and all the work. Are there any plans for a map transformation block to work with map files? A second need could be a block to detect the item of a group which triggered the rule. Is there a chance for such blocks?
BR
Johannes
Thanks Johannes, appreciated. Map transform is already there - see above somewhere in the thread and part of the next code drop. And the other are event ones that are mentioned as well above. Check it out above and see if that is what you are missing.
I made significant changes to Stefan’s PR and merged so we can test them in the upcoming milestones and release candidates.
I’m very pleased with Blockly’s new capabilities!
generates:
function addFrameworkService (serviceClass) {
var bundleContext = Java.type('org.osgi.framework.FrameworkUtil').getBundle(scriptExtension.class).getBundleContext();
var serviceReference = bundleContext.getServiceReference(serviceClass);
return bundleContext.getService(serviceReference);
}
var ruleManager = addFrameworkService('org.openhab.core.automation.RuleManager');
function convertDictionaryToHashMap (dict) {
if (!dict || dict.length === 0) return null;
var map = new java.util.HashMap();
Object.keys(dict).forEach(function (key) {
map.put(key, dict[key]);
});
return map;
}
var dtf = Java.type("java.time.format.DateTimeFormatter");
var zdt = Java.type("java.time.ZonedDateTime");
function getZonedDateTime (datetime) {
return zdt.parse(datetime + ' 00:00:00 +00:00', dtf.ofPattern('yyyy-MM-dd HH:mm:ss z'))
}
var persistence = Java.type('org.openhab.core.persistence.extensions.PersistenceExtensions');
ruleManager.runNow('ruleUID', true, convertDictionaryToHashMap({'key0': 'abc', 'key1': 'hey', 'key2': 'there'}));
if (persistence.updatedSince(itemRegistry.getItem('MyItem'), getZonedDateTime('2021-04-06'))) {
print(zdt.now().minusMonths(4));
print((persistence.averageSince(itemRegistry.getItem('MyItem'), zdt.now().minusHours(1))));
}
1 Like
Hi Yannick,
I currently comparing your changes to mine. Actually you were too fast with merging 
because I had some stuff not pushed because I was waiting for your review first to avoid to many commits. My fault that I did not mention that.
All in all, Yannick, can you do me a favor 
: I try to be very transparent during development what I do and what I am about to implement and I put a lot of thoughts into it and almost all the time I take your comments into account and I also prioritise my work based on your comments.
I am happy to learn but when you just change some blocks without discussing it here before (which I am aware is the most time efficient way of doing so for you and you are the only one I think who are doing webui reviews which is an awful lot of work) it makes my life much harder afterwards as I have to find out later like I did today what was changed.
Almost anything you do makes really good sense and there is no doubt about that but it would be really great if you either propose block changes first (not code of course) or at least quickly list what you have changed so I don’t have to do the research, ok?
Things missing due to not having been pushed by me:
-
I had added (and not pushed) the “previous state” in persistence which is now missing like mentioned here
- “‘previousState’: ‘Gets the previous value of the State of a persisted Item’”
- the mutation of the block in “oh_get_persistvalue” for the previous value therefore is missing as well
-
‘oh_sleep’ is still saying “thread sleep (ms)” instead “Wait for…”
More like a summary from my side that I hopefully found the most important changes you did:
- you made sure that the names created by provideFunction_ are then used in the code to avoid variable conflicts (understood)
- you use const instead of let consistently (understood)
- I wasn’t aware that I could return and use something like that in JS. (learned )
const { dtf, zdt, getZonedDatetime } = addDateSupport()
Questions
Ephemeris blocks
- you moved all ephemeris input blocks into “blocks-dateoffsets”. Did you only move it there but also changed something important (except renaming the blocks)?
- at least one thing I discovered is the following
Anything else?
Transformation
Why did you change the dropdown of the transformation to become a textfield? It is clear to me that a text field is more generic but I don’t like the idea here.
I think a dropdown is more safe to be used instead of a text field because people could do nonsense here
I see you have kept the dropdown in the code. I would prefer and like putting that back in instead of the text input:
like so
Cheers
Stefan
Rich, can you have a look here? There is a reschedule-timer-bug that I don’t really understand but I am sure you do and know what the fix has to be as you had been involved with providing guidance to me.
cc @enrico.mcc