@ozpos most everything I described can be done with the dashboard nodes. I definitely don't want to start a debate between dashboard and uibuilder, however I'd ask you to consider looking into web development. It's massively rewarding and I've shared some of my web pages on this forum / github, so you can borrow/steal the code
Also, I only started using uibuilder and VueJS in the middle of August this year, and NR since the start of July this year and I already feel confident enough to build my full system on both.... I'm not saying it will be beautiful / a work of art, but I feel confident enough that I can make it work reliably.
Importantly to the discussion on "smart home creation", the real thinking behind what I want to do has very little / almost nothing to do with the UI.
I'm concerned about the back-end which will all be written using function and and handful of other nodes. How you visualise and interact with it is up to you.
It's the other end of the specturn to what the OP @jordan asked, but it might be helpful to share thoughts on this page, as a little dabbling quickly turns into a full blow implementation... and I'd wish I'd found posts like this earlier on to open my eyes up to more of what's possible at the start.
I'm working through this kind of thing too in order to replace my older setup that has slowly (and messily) evolved over time. The downside of such a flexible tool as Node-RED
I was going to base things around Homie but on reflection I found that to be unnecessarily complex as it tries to create a fully discoverable system in MQTT (anyone remember SOAP? that also pretty much fell by the wayside for the same reasons).
So I've been focusing on creating some standard data schema's that define static metadata and dynamic status data. These are used as global objects in Node-RED but also translate to MQTT topic structures.
If you want to give it a try, I can help you out. Just name a project. I can help you setup the structure and explain to you what I've done.
One day I'll get around to writing up some examples of the basic things that you might want to build... At the end of the day once you've built a few web pages you realise that for most home automation purposes there aren't that many things you need to do, of course there's a hundred ways to get to the same result and you can make it a bottomless pit, but you can also keep it simple.
Ouch! $45 for that screen. Too rich for me. Home automation is supposed to provide convenience and reduce costs. I'm not in it to create expensive toys I'm afraid. You could easily do something similar with a much cheaper screen.
In any case, the rest of the family wouldn't appreciate such a Heath Robinson-like think lying around the house. Oh, and no 3D-Printer here either.
Truth is that it is amazing how little information you actually need in the typical home control interface.
My own system is aiming to be almost as complex and complete as you describe, but I'm happy that NR is the way to go. I'm taking the approach of simplifying and modularising each part of it so that there shouldn't be any need to "break it up" when implementing a new subsystem, or extending an existing one.
The NR & MQTT concept of "messages" works very well for this, as each part of the system receives, processes and output only the messages it needs to, and communication between subsystems again uses specific topics.
Based on may years of developing fairly complex software, I think you might find that trying to implement a single overall framework will be a very large task, and you will also end up scrapping and rewriting parts of it as your requirements change and evolve. Keep it simple, and keep it modular are good rules for any development.
edit : reading further, I may have misinterpreted what you're planning to do. If my comments aren't relevant, please ignore them
I think I overcooked my explanation. It's more like building a number of good modules that link together well, so yes I agree with you very much on that point.
I've already dabbled with a hot water scheduler and it was surprisingly easy to build, so I'm going to assume that a full heating controller won't be much harder.
Interestingly spent just as much if not more time building the UI for it as the actual engine.
I'm going to think about all the modules /components I plan to build. It would be interesting to see if there are good examples / good ideas out there.
Else I shall trudge along and build it anyway... Ha ha
That is what you should expect. Experience over many years shows that the compute/logic part takes 20-40% of the time, the UI part is 60-80%. That seemed to be true even in mainframe times with printing as the main output
And unfortunately UI design and testing is almost always under-resourced and left until too late in most projects, which is why we have so many bad examples. At least that's my experience...
(The only people who have it worse are game audio teams, again in my experience )
Not to long ago when agile became popular I saw projects just skip most every form of pesky documentation, other than maybe a few PowerPoint presentations to sell the project itself, apparently you didn't need all that messy documentation with agile.... didn't take too long for people to cotton on.
PS: Once upon a time I did quite a bit of functional design and functional architecture, i.e. understand business needs, design application and data flows and core application functionality and let other people, who knew what they were doing, develop it, so I know how important certain documents really are.
The bulk of my system is my fibaro controller and fibaro have their own data structure. You can scrape the entire api of every device & room and much more, for example there are a number of panels, like a heating panel and you can scrape that as well. All of which has a predefined data structure.
So far, I have limited myself to just reading the data as it is structured by Fibaro and then writing severely cut down versions of it to flow and global variables.
I can see where you are going with your structure, to that end I'm currently toying with the following ideas:
keep my controller data structure - would be dangerous when I move controllers
build a central data structure, like the one you have proposed
this could be updated centrally or updated within flows that are considered to be a copy of the "golden source" of the data; to abuse the term slightly
build local (flow) data structures and allow duplicates
I'll paste in some thoughts I shared with a private group on the Fibaro forum. I'd be interested to see what you think.
