#1

I use Node-RED for all of my automations as I find it MUCH easier to build the automations visually using the blocks in node-red vs multiple drop downs etc in HA.

I think HA would really benefit from something similar to ‘Blockly’ in Domoticz - I used this in the past and found it super easy to use, yet if you want to it’s possible to make some very powerful automations quite easily.

Here is an example of ‘Blockly’ - note that certain blocks will only fit with other block types, which makes the bar of entry quite low IMO, as it almost guides you to what is possible.
Blockymonday

#2

I’ve used Blockly in domoticz some years back, before I built my house on HA. It’s quite limited in comparison to node-red capabilities.

But there might be someone willing to make a docker container for it:slight_smile:

#3

Yes, certainly vs Node-Red i’d say that it is more limited.
However i think it would be a nice addition to have something like this ‘baked in’ rather than relying on an external program / container for automations.
I’d guess that for the majority of automation’s something like this would fit the bill just fine.

#4

I agree on all points. The comparison shouldn’t be to Node-Red, which is super powerful (and a complicated overkill for most automations).

Instead, look at it from the other point of view: your child or parent wants to create a simple automation. Them using Node Red for that is a non-starter. In fact, I’d argue the current GUI-based flow is basically a non-starter as well. The new-ish wizard helps… hopefully it continues to improve.

1就像
#5

As an experiment in 0.113, I tried to move some of my more complex NodeRed automations back over to native HA automations using Choose->Action. For something that would take me a few minutes to whip up in NodeRed, it took me over an hour to do in the HA Automations UI. Granted, I’m a lot faster just writing them in YAML, but sometimes it really helps to be able to visually see all the connections and flow visually.

Plus, with no way to debug in the HA UI, it makes writing complex automations kind of a pain.

#6

我一直都很喜欢。这是家庭自动化规则的示例伟德betvictor手机版openHAB’s documentation。

图像
图像 802×555 132 KB

#7

DEVS已经关闭了类似的请求，但关于NR。
Following their reasoning, IF it cannot be written by them and would create dependency to some 3rd party component, then it cannot be added as native tool to HA.

Also to rephrase them: The WTH is about Home Assistant, not Blocks.

BTW please let me voice my disappointment from closing threads about features they don’t want to implement (which cannot win anyway)

#8

I believe Blockly is web based and could potentially integrated directly into Home Assistant. But it could also be made available as an Add-on. Someone would have to spend time customizing it to spit out valid Home Assistant YAML.

#9

That’s fine, if they want to make a home cooked alternative that is as functional then I’m all for it:grin:

这不仅仅是直接击败HA，而是添加/创建功能中类似的东西。
Blockly was just an example of what I feel would be a decent solution:smiley:

1就像
＃10

I posted a similar feature request about a year ago, asking for a Blocky style flow-based visual editor UI for automations & scripts using graphical blocks included by default in Home Assistant’s web interface:

https://community.home-assistant.io/t/blocky-style-flow-based-visual-editor-ui-for-automations-scripts-using-graphical-blocks-included-by-default/149902

＃11

I understand that is also what OpenHAB has to do with their Blocky based Graphical Rule Designer:

https://github.com/cdjackson/openhab-blockly

也就是说，他们必须拼接谷歌的Block的代码并修改它以使其为Openhab生成规则：

https://github.com/openhab/org.openhab.ui.habmin/wiki/rule-designer%3a-building-blocks.

1就像
＃12

Habmin和Paper UI不会维持，因为OpenHab V3.x将在1-2个月内出现在现在的1-2个月以上，在用户界面上的巨大返工作为主要焦点。将删除多个UI，将介绍一个UI。您还可以在Python（Jython）中编写自动化如果您愿意。

我现在正在尝试哈斯，看看我更喜欢哪个平台，在使森林3或哈斯改变之前，似乎似乎是审判两者的好时机。

＃13.

+1 from me
我来自iobroker，切换到openhab 3.0，并结束了ha。哈是三个伊莫的最无缝的，真的很棒的工作！对我来说，唯一的问题是缺乏拦截！我喜欢Iob和哦！我花了2天的时间才能用一个简单的Tryfri开关通过Deconz的简单Tradfri开关，用节点红流来切换一个简单的色调灯。这只是一种矫枉过正的情况。如果已被实施，这将是很好的。

＃14

使用自动化编辑器，这将在不到2分钟内完成，所有在UI中都没有编码。

＃15

你是对的，我可以确认它需要大约2分钟。这是一个无缝功能之一，它一次对我印象深刻。要与节点红色获得相同的结果2天......
I wanted to code that and more myself：眨眼：我希望灵活性比自动化编辑器提供，但需要少于节点红色。这是封闭的。

＃16

I wouldn’t bet money on it. Anything generated by blockly would have to be convertible to a valid YAML-based automation. However, automations have certain structural requirements as well as limitations. Those same requirements and limitations would have to be imposed upon blockly to prevent the user from creating something that cannot be converted to a YAML automation.

If you were to try to convert the blockly example in Gamester17’s post to an automation, you would discover the example does a few things that aren’t easily convertible to how automations are structured.

＃17

Not necessarily, if a new graphical interface was developed there’s no reason that part of that development wouldn’t be to communicate with homeassistant directly rather than by converting the ‘flow’ to yaml. Appdaemon and pyscript don’t convert anything to yaml, for example.

＃18

I assume technically it would be possible as ioBroker and OpenHab demonstrates it. It must be a principal decision not including 3rd party codes.

＃19

In both, the user composes source code. That’s what is stored and later executed by their respective interpreters.

Blockly is a visualcode generator。您创建的那些拼图最终转换为所选择的编程语言（拦截支持几个）。当你说“直接沟通”时，目前只有这么多方法可以做到这一点。本机方式是通过yaml自动化（只是一种方法来格式化Python解释器的数据）。还有WebSocketS由Home Assistant的Node-Red节点采用。19463331伟德国际但是，节点红色也能够执行自己的流量（它具有JavaScript解释器），并简单地与主助手的实体和服务接口。19463331伟德国际

Blockly’s diagrams could also interface via websockets but the logic it generates must target some kind of language interpreter. Python would be a natural fit but that implies either storing the python code natively (like for the python_script integration) or as formatted YAML (like traditional automations). Native python would offer the most flexibility. However, I’ll stop there because I have never composed a python script containingtriggers所以我不知道它需要什么样的复杂性。

To support Blockly, you don’t have to include it in Home Assistant’s core code. For example, Node-Red, MQTT, etc are all separate projects that can be used by Home Assistant. Appdaemon and pyscript are purpose-built to work with Home Assistant but are “third-party”.

我对这个问题的看法是，原因只是因为没有人受到启发。我怀疑paulus将反对增加拦截，但它将与appdaemon和pyscript的方式处理（与家庭助理合作，而不是核心的一部分，并且不由开发团队支持）。19463331伟德国际