What bothers me about many of my blockly rules is the inevitable nesting of AND or OR blocks when I have more than two conditions.
Are there others who are bothered by this? My attempts to create my own blocks with a variable number of input parameters failed. If I understand correctly, mutuators cannot be used in custom libraries. Is that correct?
My suggestion would be to include one block for AND and one for OR with mutuator in the openHAB standard. No mixed blocks, because that would make it complex and confusing again.
There is already a block with a mutuator under âdates and timesâ, so it should be possible. @stefan.hoehn was that perhaps yours? What do you (or other blockly-users) think?
Sometime back I thought how this could be done but I never had a good idea. I even thought about implementing a switch case form but then I thought it wouldnât help a lot.
First of all could you visualize your idea as I am not sure I grasp it fully.
Second, implementing it might not be that easy but first come up with a good idea.
Third, sorry that I havenât been active that much in last weeks. I have been distracted by too much with other private obligationsâŠ
Donât be sorry, you contributed so much. (Iâm nine months behind updating the install routine for zigbee2mqtt in openhabian ). Anyway itâs good to have you on board, no matter how much time you can spend.
Iâll prepare a sketch later. Itâs dead simple really.
Why didnât I choose the standard mutator (gear)? If thereâs only one type of element to expand, buttons are much quicker to use on both PC and mobile. On mobile, itâs quite hard to hit the gear.
External inputs or inline inputs? The design is made for external inputs. âInline inputsâ donât make sense for a block thatâs intended for more than two inputs anyway. Thatâs why I removed the option to switch to âinline inputsâ from the context menu.
As AND and OR is a drop-down anyway, shouldnât we include XOR, NAND and NOR too? Edit: I changed the above code to include them.
Hi,
If you can live with the fact that the generated code is no longer so easy to read, every() and some() could also help. Yesterday, I created a block (which has only been roughly tested so far) that uses these. A proper block with input validation (Boolean) is no substitute for that.
- component: BlockType
config:
args0:
- name: options
options:
- - and
- every
- - or
- some
type: field_dropdown
- align: left
check: Array
name: booleanList
type: input_value
colour: 260
message0: "%1 %2 "
output: Boolean
tooltip: OR oder AND in einer Liste
type: OR_AND_Liste
slots:
code:
- component: BlockCodeTemplate
config:
template: "{{input:booleanList}}.{{field:options}}(x => x === true)"