In lots of cases, they could just remain deprecated forever. But shunted into a separate menu with warnings not to use these but they are kept for legacy purposes. That could split the difference, allowing use to gradually change the supported blocks for consistency sake but not break too many things in the long run.
But even with this approach we need to be judicious because there are only so many different versions of blocks we can create.
Honestly, I would vote for option 1, or maybe 3, definitely not 2.
I think the green color should be clear enough that it represents a string, and is a reference to an item as represented by its identifier, which is its name (a string). The same goes for things, referenced by their UID.
It’s okay to call it ‘item’ even if it’s not the entire item structure as most API calls would accept the identifier as representing the item.
The issue you ran into is actually a pretty common one and not specific to this “item” block. When you use variables you lose the type information. So when you have a loop and define a variable to be the iterator, you can basically use this variable anywhere even if it’s not the right type.
That’s why I designed it to be just “item” (and the green color to denote it’s just the name, thus a string, but you can use that to perform stuff on items by just referencing its name, so it’s basically the item).
Ok, thanks Yannick. At least with the better typed checks, it is more uncommon to make mistakes.
Variables are really a pity here, I agree, as they lose information about the type and you really need to know what you are doing.
This seems to be the most sensible solution. Usually you wouldn’t use UTC unless you’re not sure where in the world you are and where your server is. For instance see this: Use home's location timezone instead of client's one in UI · Issue #1537 · openhab/openhab-webui · GitHub
When you’re away from home and in a different timezone the charts in the UI are wrong because the API offers UNIX timestamps and they depend on the timezone you’re in.
For rules, this shouldn’t be a problem because the server isn’t changing timezones so the local time is reliable.
Hello, I’ve been looking for one of the simplest solutions for a long time, switching on/off, according to the scheduled time with correction, but I can’t find it.
I wanted to use Blockly. Habpanel. Basic Ui. (for setting any time on the fly)
First of all this is the wrong thread to ask that question as this is about adding new features to Blockly, please open a new thread and secondly I honestly have no idea what you want to achieve.
Thank you, you can then delete my wrong post.
Recreated in a tight topic.
Hi there
Not sure how to post that, but as i use this a lot in my rules, i created some Blocky for semantic features, like described here: [semantics] Add ActionService to support using Semantics features in Rules by cweitkamp · Pull Request #2088 · openhab/openhab-core · GitHub
Having something like:
Anyone interested to add that to any lib ?
First of all, thank you for that idea and the effort so
A few hints on designing block:
If you want, you could provide these as blockly library and upload it to the marketplace.
If you feel we should add this to the core blocks, please create an issue in github and I can plan it in if more people feel that it would make sense to have them in 4.x.
Is that true? In the documentation section linked below, Equipment, Location and Point all have their first letter capitalised.
Hi Stefan
Thanks for all the good advice…i will take some time and beautify it a bit.
Personally I think that this would be nice to have in the core as from my example it helps still transforming rules etc. more from OH2 (groups…) towards OH3 and the semantic model.
So i will open an issue (after i am done with making things proper) and you can decide.
Cheers
Yes, that is true but in blockly we keep the wording lower case (which is also a recommendation from the blockly community)
But this is Blockly for openHAB, so I assumed openHAB convention trumps Blockly convention (as long as it didn’t prevent Blockly from working in the first place).
I personally don’t particularly care - I know just enough about openHAB to understand what’s going on - but for novices I would suspect it’d make more sense if all of openHAB presented the same conventions, to prevent confusion.
Yes, and the original guideline from Yannick is that we follow these guidelines from Blockly because we (he and I) feel that it does make sense.
just out of interest, are there more ephemeris blocks planned for the future?
I’m thinking of
getHolidayDescription(<holiday name>)
getNextBankHoliday
getNextBankHoliday(<file>)
thanks
Roli
Can you create an issue in github please. It might make sense then to add (a) more generic blocks that allow(s) to choose via a dropdown what should be returned. I am not sure though if it makes sense to add the file parameter. There is a load of ephemeris functions and we would have to come up with a clever block design to avoid the same amout blocks here. Also it would probably require blocks that change the appearance (so called mutators) based on the choice of function you select.
Maybe someone takes the time and comes up with a clever block design that only requires very few blocks while covering most of these functions… 
I made up some blocks already which I thought they would be useful.
I tried to implement a mutator already in another library but failed. I don’t know if this is even possible in yaml…
No, you cannot create mutators in a blockly library.
Where are these?
Those are the blocks
The get holiday description can be combined with the existing blocks
I can share on the marketplace if needed.
Sorry for that inappropriate sentence of mine 
, of course it’s needed.
You ment probably something like that,
That is only one Block.
uid: ephemeris full
tags: []
props:
parameters: []
parameterGroups: []
timestamp: Mar 4, 2023, 6:06:37 PM
component: BlockLibrary
config:
name: Ephemeris full
slots:
blocks:
- component: BlockType
config:
args0:
- name: VARIETY
options:
- - getBankHolidayName
- getBankHolidayName
- - getDaysUntil
- getDaysUntil
- - getNextBankHoliday
- getNextBankHoliday
- - isBankHoliday
- isBankHoliday
- - isInDayset
- isInDayset
- - isWeekend
- isWeekend
type: field_dropdown
- name: MULTI
type: input_value
colour: 0
helpUrl: ""
inputsInline: true
message0: "%1 %2"
output: ""
tooltip: datetime, string and numbers can be used as input
type: holidayDescription
slots:
code:
- component: BlockCodeTemplate
config:
template: "{{utility:Ephemeris}}.{{field:VARIETY}}({{input:MULTI}})"
utilities:
- component: UtilityJavaType
config:
javaClass: org.openhab.core.model.script.actions.Ephemeris
name: Ephemeris