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)"