cant say I agree with him at all , I mean im not a major techie when it comes to linux/coding etc, but Ive worked out how to do bits in HA. To be honest the guy sounds like a idiot. Got his own HCS (Home Cotrol System) that he’s been designing since 2004… … you just need to read it… …!!
His main problem seems to be that he does not want to read any documentation.
How can you call one an idiot who programms his own home automation system?
2 Likes
True, idiot isn’t the word I wanted/should have put, but hey this is a family forum…
So this is one of those people who has their own website and business for years (still one man) and refers to it’s work as “our” work. Does he have some imaginary friends or something?
Also he made a system on its own. Nice work, but he has NO call to action button on his entire website! He does have some pictures of him demonstrating it at, what looks like, a convention. So it looks like he wants to sell, though not through his website obviously 
1 Like
A very badly designed website. If his app looks anything like his site, I wouldn’t touch it.
Doesn’t stop him being an idiot, there are loads of incredibly clever idiots out there. Just love people who say they have X years experience as an IT professional but because they don’t get it is obviously rubbish. Been loads on here who’ve said that over the years, all have been idiots and left with their tails between their legs. Equally there are still loads who have no professional IT experience and get on just fine.
5 Likes
Haha I’m glad i’m not the only one who picked up the constant use of ‘our’ & ‘we’ yet seems to say he’s the only person in his company. He’s been designing this oh so great home automation system of his since 2004 and yet I couldn’t find any demo’s, pictures or even youtube video detailing it.
1 Like
I’ve got years of IT experience 
All of the above points are valid, but I would also say that this is indicative of where homeassistant is currently heading.
Homeassistant wants everyone to be able to pick it up and use it. We’ve had massive change after massive change upsetting swathes of the community that were allegedly towards that goal.
That website proves that there are people out there who, in spite of all of that, still don’t get it. There’s probably millions of them, this dude just did us the courtesy of writing it down.
1 Like
This does remind me of my other life, building cars. And watching builders attempt to use the excellent open source EFI controller MegasSquirt and fail because it is beyond their software and electronics capabilities, or they just don’t read documentation. Then proceed to bad mouth the MegaSquirt at every opportunity even to the point of creating “megasquirt sucks” Facebook pages, YouTube videos and websites.
And for that matter, the same people to modify their RX-7s and blow up the engine running lean and then spend the rest of their life saying how much rotary engines suck and how unreliable they are.
Same types of people in every community. Always a good demonstration of the Dunning-Kruger effect.
1 Like
Upon a reread he does make some good points though.
The database is a major reliability of Home Assistant.
The insinuation that it can be run on an SD card based system is a disservice, as it means certain issues with frequent writes to the database unless other steps are taken.
He (they?) also approached his (their?) examination from a comparison on his (their?) homegrown system, so there is built in bias. Expecting one system to be like another, especially a pet project known intimately, sets one up for disappointment and one (many?) should be expecting different concepts, terminology and capabilities.
It is somewhat amusing that he makes specific mention of the low computing requirements of his home grown system as compared to Home Assistant, but then his “Contact Us” form has a big orange warning that is uses client side JavaScript to validate inputs and will not work if JavaScript is turned off.
ROFL!
But all jokes aside. There is always a lesson to learn.
I started with HA about 1,5 year ago. Abandoned it because I was not ready for all the yaml and templating. Bought a Atom Honey Pro. That lasted 1 week before sending it back (not reliable due to wifi only connection and limited to available hardware). Went to Hubitat, all local, everything I needed I thought. Until there were problems with slowness. No solution and no way to throw extra hardware to the problem. So I went back to HA. And at first I was excited to learn how HA has changed course to provide for a “less programming” way of working. Although I’m pro GUI. I also learned that home automation is very hard to create a GUI for. Especially the usability is a big obstacle. Because it has to provide an environment to an enormous amount of people with different needs and ways of automating their homes. I myself noticed that although a GUI is appealing, the programming way is eventually easier. But my background is IT and I’m an autist, so my opinion is just one of many (and maybe even a bit odd). I think there is no best way of doing it, though to keep everybody almost happy and serve about 80% of the audience (more is wishful thinking) I think a programming way with a UI next to it is the only way. But only if both are supported and the scope of both is clear upfront. And we users should help the development team by giving them guidance into what to do and what not. And we should try to be as impartial as possible. Also try to imagine or even ask how ‘non IT people’ would want to do it.
The review is basically an SEO advert for his own system. Just a quick glance through his site and I’d be willing to bet his target market are government agencies.
Well, I wish him good luck. if that is really his goal with the website, he should learn more about SEO.
1 Like
Torn on this response. His website is atrocious to the point where its really hard to read his article. Also the name of his product appears to be ‘Smartisant’ which I find absolutely hilarious. I can’t imagine using a product named Smartisant and I certainly wouldn’t tell anyone if I did lol.
But all that aside, the content of his article seems fair to me. I’ve always been really bothered by the lack of nested areas in HA (and frankly most) smart products. It’s one of those things I just kind of took for granted since I hadn’t seen any products do it but now reading this reminds me how annoying it is that I can’t bucket my rooms into an “Upstairs” or “Downstairs” area.
Actually I’d probably take that further and say HA’s room (ok fine ‘Areas’ support) is a a pretty significant usability issue to HA in general. I feel like for someone trying to get started with HA automation of your lights is basically the 101 use case. HA isn’t too bad at helping you get to the point where your lights can be automated using a combination of time, sun events and “arrived home”/“left home” events.
But after that the next logical step for someone (at least to me) is to get it so your lights turn on when you enter a room and turn off when you leave a room. And HA completely drops you off a cliff there. It’s been a year and I’m still trying to figure that one out. People think of their house in terms of rooms and floors, if HA is to become more approachable then those concepts to become first class citizens in HA.
It’s kind of nuts for instance that we have a “Device” option in the actions menu of scripts but no “Area” option to turn off all devices in an “Area”. Turning off everything in a room seems like a 101 use case yet today HA makes you drop to YAML to make your own groups in order to accomplish it. I can’t really fault him for calling that out.
His SDCard point is totally valid too from everything I read on here. I’m gathering that I’m pretty lucky mine hasn’t bricked yet. I just decided to pre-emptively invest in this setup since I assume its only a matter of time until my SDCard is shredded. But obviously that will significantly increase the cost of my setup and I’ll have to figure out how to set it up on my own since the guide is for SDCard setup.
I will say I find it strange how much stock people put in Z-Wave support. I feel like I’ve read a few things recently about how HA’s poor Z-Wave support is holding it back. I really don’t understand that one, is that just because so many people are coming from SmartThings? Idk when I went looking for more simple sensors it seemed to me that the choice was really between ESPHome and ZigBee. Z-Wave stuff seemed the same as Zigbee stuff except more expensive since it had the “SmartThings supported” label. But I’m probably missing something.
1 Like
This is actually quite easy using the Automation Editor these days. When you create a new automation there’s a dialog you get first with Almond natural language stuff and one of the four default examples is “Turn the light on when motion is detected.” You simply pick a motion sensor and then an area and hit done.
It’s also been possible in YAML since areas first launched (or very shortly afterwards), basically you just replace entity_id: with area_id: in your service calls like so:
- service: light.turn_on
area_id: '9b02f6f09c824d60a80d1039279a41de'
&
- service: homeassistant.turn_off
area_id: '9b02f6f09c824d60a80d1039279a41de'
But admittedly almost nobody knows about this functionality because it’s not exposed anywhere in the UI, and I don’t even think it’s mentioned in the docs either. So it’s definitely a fair criticism and one of the many examples of things that needs to be made easier / more discoverable.
2 Likes
device_id and area_id were clearly never intended to be exposed to human eyes (and managed exclusively by the UI). No one would willing require people to handle identifiers composed of lengthy random strings.
Even if you wanted to do that, finding the identifiers requires an exploratory trip into the .storage directory, where we are often told we should not tread.
My quibble is with what happens to a Device Automation if you uninstall/re-install an integration. Upon installation, devices are assigned unique identifiers (device_id). If you create a Device Automation, its device trigger refers to that device_id. If you uninstall/re-install the integration, the device is assigned a new unique identifier which, of course, is not the same as the previous identifier. So the Device Automation you had created now has a device trigger whose device_id is no longer valid.
Currently some integrations configured via config flow do not provide the ability to modify their options. Your only recourse is to uninstall it and re-install it so you get a chance to reconfigure its options. There is a way to modify its options without uninstalling/re-installing but it requires tinkering in the .storage directory.
Great point about areas
I was recently looking in the docs to try and understand the schema for areas for this type of thing.
If movement in an area, what are the entities in an area (which I understand is tricky as devices belong to areas, not entities directly?).
How to add entities without devices to an area …
There’s a relatively easy method to get at both of those ID’s without messing with .storage folder:
- area_id can be retrieved on the Areas panel in the settings cog upper right corner
- device_id can be retrieved by going into the automation editor, selecting a device from the dropdown and immediately switching that card to “Edit as YAML” mode (via the overflow menu / 3 dots icon on the card). No need to save that automation or anything.
But yes, I agree with your overall assessment - they are more geared towards the UI currently.