Agreed. I was trying to address one of the original questions:
which I think needs one of those more complex filters.
Sorry, I was in a hurry with that original response. I was actually thinking about other possible ways to restructure the data so that you didn't need to process it as much - such as splitting the top-level by type so that all the lights were on one property. Then, once again, you could use Object.keys().length and stick with named properties if you wanted to. But of course, once you get into needing to filter an array or object by a sub-property, you might as well stick with an array so that you can use the filter function.
1 Like
It could help to step back from your specific questions and look at the bigger picture. Over the years I've worked with a bunch of home automation packages, open-source and commercial. Each one had a slightly (or wildly) different approach to mapping the real world onto an abstract data structure. Most of the time, you could see how design choices were influenced by factors such as (human) readability, efficiency (of storage or command execution), modifiability, as well as bias toward certain database tools and programming languages. There is also an element of the developer's notion of "usability" -- does it feel "natural" to organize the world this way and does it correspond to the things that happen or are made to happen there.
Regarding what you have so far, if it works for you, great. If it doesn't, change it. Don't lock yourself into anything until you've used it seriously for a while. In terms of publication, I think if you look at the NR Library, you'll find that lot of home automation projects have been published as flows rather than custom nodes. That's a good way to get something out there quickly and get feedback without putting a lot of effort into something you haven't done before, unless of course you just want to want to develop a custom node for the fun of it.
1 Like
