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.
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.
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.
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.
Devs already had closed similar request but about 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)
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.
That’s fine, if they want to make a home cooked alternative that is as functional then I’m all for it
This isn’t just about bolting blockly directly to HA, but adding/creating something that is similar in function.
Blockly was just an example of what I feel would be a decent solution
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:
Habmin and paper ui are not maintained as Openhab V3.x will be out in 1-2 months from now with a huge rework on the user interfaces as the main focus. The multiple ui’s will be removed and one UI will be introduced. You can Also write automations in Python (Jython) if you wish.
I am trying out HASS at the moment to see which platform I prefer before making the change to Openhab 3 or HASS as it seems a good time to trial both.
+1 from me
I come from ioBroker, switched to openHAB 3.0 and ended up with HA. HA is the most seamless of the three IMHO, really great work! The single and only issue for me ist the lack of Blockly! I loved it on ioB and OH! It took 2 days for me to be able to switch a simple HUE light with a simple Tradfri switch over Deconz with a Node Red flow. It is simply an overkill for situation like that. It would be nice if blockly got implemented.
you are right, I can confirm that it took about 2 minutes. It was one of the seamless features that impressed me by HA at once. To get the same result with node red took 2 days…
I wanted to code that and more myself I wish more flexibility than the automation editor offers but need less than node red is capable of. Here comes blockly.
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.
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.
In both, the user composes source code. That’s what is stored and later executed by their respective interpreters.
Blockly is a visual code generator. Those puzzle pieces you create are ultimately converted into a chosen programming language (blockly supports several). When you say “communicating directly”, there are currently only so many ways to do that. The native way is via YAML automations (which is just a way to format the data for use by the python interpreter). There’s also websockets which is employed by the Node-Red node for Home Assistant. However, Node-Red is also able to execute its own flows (it has a JavaScript interpreter) and simply interfaces with Home Assistant’s entities and services.
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 containing triggers so I don’t know what sort of complexity it entails.
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”.
My opinion on the matter is that the reason is simply because no one has been inspired to do it. I doubt Paulus would object to the addition of Blockly but it would be handled in the same manner as Appdaemon and pyscript (works with Home Assistant but isn’t part of the core and isn’t supported by the development team).
I wish more flexibility than the automation editor offers but need less than node red is capable of. Here comes blockly.