I’m trying this so more on it later, but why run it on openwrt? Is it because you’d use it as a router anyway?
I think my ISP regards the latest router as still “theirs” so I might hit problems replacing or flashing it.
So I think that should be possible largely with an automation, put a trigger on the external temperature to start the automation when the temperature changes, then use actions to adjust the values of the entities you mention by 0.5 degree up or down as you need.
More complex automations do require some script in yaml, it’s necessary to enable to wide range of flexibility across thousands of components that all work differently, but in many cases, following the new automation UI tools achieves a fair amount.
You have to remember that this is a community product, there is no obligation from anyone to deliver on this, but actually it has more support and updates than products that do.
It seems that you might be looking for the best of both worlds, in that you want a finished product with complete cohesion with a multitude of components.
Unfortunately this would lead to a very restricted choice of components and a low desirability. Hence these products are either very specialist and expensive (mainly because they too end up being complicated and you need to pay someone to set it up eg C4) or die a natural death because they just don’t have enough functionality.
As I mentioned before, as someone who has invested tens of thousands in a Control4 system. Yes it works, but only with certain devices with limited capability and the constant need to pay someone to make changes for me.
As for stability and a finished product rather than a Beta, nearly all software works in this way in the modern world. Control4 has many versions and upgrades, the difference is, you stay on one version and don’t upgrade, unless of course you want the new features and go through that activity and any associated pain. In the world of C4, you’ll also want to pay for it…
As I said, its the same with nearly all modern software, how many times do your apps on your smart phone update? It’s part of the modern day software development life cycle.
Personally I’m loving Home Assistant and yes it is chewing up a fair bit of my personal time, but that’s because I choose to. If you don’t want to invest the effort that’s everyone’s own personal choice, but the consequence is that you can’t be at the leading edge of what is possible in Home Automation (unless you want to spend lots of money for someone else to do it).
Just by way of an example, here’s a screenshot of an automation that enables the EcoDivert function on my EVSE car charger and then updates my VW ID3’s target state of charge to allow it to make the most of any spare solar power during the day.
I have another automation that runs at night to remove the EcoDivert and set the state of charge to 40% to ensure that I have enough energy to do the school runs and some as a minimum each day.
This way, where possible the car will absorb spare solar from my panels, and if overnight it is lower than 40% it will charge during cheap electricity rate hours to 40% only.
I do get that the Automations section of HA needs a bit more work, it’s very easy to end up with a very long and un-organised list of automations, this I think is one of the most requested improvements currently when you look at the votes in the community.
I did all of this by simply adding the components for the EVSE and ID3 to HA and then using the automation tool, no code written at all to do this and I think whilst in principle it’s fairly simple, being able to bring all of these things together without having a programmer write some script to make various API calls as a bespoke piece of work is pretty cool.
I like using openwrt for several reasons.
main reason I condensed my entire energy monitor , zigbeehub, automation, database, network storage , router …etc into one single device that consumes <20watts.
PRO;
1- very small to flash it only requires 14meg whereas flash with regular OS usually in 1gig file size. and then once it configured the way you like backing up the image is usually only 20 - 30 megs ( minus the database software and containers which i install on a internal drive mounted drive ) .
2- because it so small alot of the bloat has being removed and it runs very stable and very fast using very very little resources. which is especially nice on such small limited resources devices as PI
3 - the way the OS is designed it puts very little stress on the SD card and embedded that runs the OS. any stress is passes on to overlays and internal/external drives. I had my energy monitor running for over 4 years taking 10 of 1000s of inputs per hour into the data base and my SD card and OS still operated at 100% ( and if I do have a problem reflash the SD from backup and up and running in 5minutes or less )
4- web interface I like being able to install software and debug via an visual web interface
Con:
1-the software can be a little behind ( which is not always a bad thing)
2-compiling your own software can be a chore
3-not everything will work but there are always alternatives or you might have to recompile some software to have certain components included . as the reason its OS footprint is so small they took out some aspects of some software that bloated it size and memory requirements.
basically I use openwrt as my OS of choice for many PI devices ( if not all) as it not a cpu hog, memory hungry and very very tiny footprint .
I personally would not flash your regular basic router buy an opensource pi router platform you will have tons more resources to work with but then again some off the shelf routers do have alot of resources, but still not nearly as much as the opensource ones do
And that’s fine for more complex ones and expect that the temperature calculation will require some script, but simple timers should not be automations. I guess that’s one pretty basic thing that is a showstopper in HA for me.
(And as you probably know, yaml is a markup language, not a scripting language. Using it for scripting is slightly annoying too.)
How could I forget? The “no obligation” bit is screamed out when popular features are culled based on the limited usage stats collected by people who want to run a non-cloud control system but also don’t mind surrendering their privacy.
Meanwhile, you have to remember that I’m looking for an app not a development library.
I don’t mind if it’s not totally finished, but I do want it to be able to dress itself without surgery on its brain and without puking all over the dashboard at the slightest provocation. I’m also not looking for a multitude of components as long as it has the right ones: interfaces to MQTT and a plugin system in an easy language would suffice.
Yes, they update plenty. But how often do they include “breaking changes”? Very rarely. That practice of HA is not usual. With smart phone apps, if they break too often, users abandon them. I guess that isn’t happening with HA because it seems to have so few competitors, but this is not entirely healthy, even for a community free software product.
That’s OK. I don’t want to be at the leading edge. I want to turn some things on and off or up and down in response to timers (including sun-timers) and one thing in response to a calculation.
So what do you want the “simple” timers to be exactly? I’ve shown you in my last post just how easy they are? Is it the phrase automation causing you issue?
…
…
That’s OK. I don’t want to be at the leading edge. I want to turn some things on and off or up and down in response to timers (including sun-timers) and one thing in response to a calculation.
[/quote]
So taking into account all your arguments and your summation, if that’s all you need, pick a version of HA, install it, leave it at that version and setup the automations you need as I’ve shown and create your one bit of script for your temperature and you’re done. No brain surgery required, no puking dashboard (not experienced that myself) and no need to keep updating???
If you really feel that it’s a development library that you can’t stomach then you will have to stick with the multitude of separate apps for each of your products and make do. The best you’ll get with the user experience your looking for is something like Apples HomeKit, which puts you firmly back into the limited device capability department again.
All you have to do is choose. 
No, it’s the fact that you have to create automations and step through that long screen for each timer. If that’s simple in HA-world, I don’t want to see the complicated!
As explained back in post 9 or so, I broadly agree with @borpin on updates. Sooner or later, you have to update or die (or be insecure which can be worse than death) and when the development team so often breaks backwards compatibility, that update is likely to be be pretty painful. Possibly even restart from scratch, depending how long it was left.
If you’d like something to puke on your HA dashboard, enable UPNP on your router from the machine running the test HA and install the UPNP integration. Maybe I picked the wrong options somewhere, but I was surprised new devices added themselves to the dashboard instead of waiting for an invitation and that the default units were so small.
Why pretend that HA is the only game in town, that it’s HA or the broken balkanised product apps? I could, you know, try the other home automation apps mentioned in the first post. On that note…
So, I installed Domoticz last night to try it out. Its filesystem footprint is about 80Mb and the runtime memory use is 40Mb resident with a virtual of 260Mb. For comparison, HomeAssistant is 300Mb filesystem, 70Mb resident with a virtual of 600Mb; and ioBroker was 500Mb filesystem, 200Mb resident and over 1Gb virtual (and too damn slow to use on my RPi IMO).
I added some hardware from the menus and it seemed to work. The basic supported hardware list is actually longer than HA but there’s no obvious equivalent to HA’s “Integrations” installer, so adding more is more complicated. The basic list contains MQTT with autodiscovery which finds my smart plugs and heating control, and it contains some RPi hardware devices.
The user interface design is a bit old-fashioned and will probably offend sensibilities used to round-rects and material design icons, but it all seems to work, which is more important.
Things can be reordered within their sections by dragging, switches can be switched by clicking their icons or radio-buttons and there’s things about Scenes and Floorplans which I’ve not tested yet.
Once off the dashboard, devices gain a star (for toggling whether they appear on the dashboard: default is not) and a row of buttons for “Log” (opens changelogs and/or graphs, depending on device type), “Notifications” and (except sensors) “Timers”. The Timers screen is not as slick as some of the third-party HA add-ons (that I didn’t yet figure out how to install!) where you draw on timelines, but it works:
For more complicated automation, there is also a Settings: More: Events scripting area which can be programmed in Python, Blockly, Lua and its own dzVents language, but I would warn people that the Python example script was buggy in the last stable release (oops! A working one is on their wiki) and the Blockly is an old version missing the Maths blocks and access to some hardware. If the events system not enough, the system can be extended with plugins (which I’ve not tried yet), plus controls (including dummy controls) can run external scripts or poll web pages when they’re activated.
Domoticz does seem a smaller, slower-moving system but it all seems to work so far. My main concerns are the smaller community and that the core is C++ which is a rusty language for me (so my ability to find and fix any core bug would be limited) and, for extensions, Python and Blockly feel like second-class citizens at the moment compared to dzVents and Lua, with all other languages relegated to external processes. On the other hand, while I write Python almost every day, learning HA’s structure enough to find and fix anything would probably take as long as remembering enough C++! But the bigger community probably means there’s less chance that I’d need to. It’s not a clear-cut point, really.
just mentioning on openwrt domoticz is only 9 megs . it only uses 4.9 version . but everything works and is stable. the only issue I had is for zigbee2mqtt I have to use an older verion of it ( and for newer version zigbee hardware I have to manually install them. but that pretty easy I given full howto on openwrt forums )
if you are adventurous – [OpenWrt Wiki] Raspberry Pi
or other devices
Index of /releases/22.03.0/targets/
edited :
according to system monitoring on openwrt - it is 6% of my memory( 1gig) is used by domoticz and with everything running it foot print still pretty low ( energy monitoring, zigbee2mqtt, routing, VPN, influxdb, chonograf, kapacitor, domoticz etc… )
Umm the screen might look long, but it’s mostly text describing what you need to set. To turn a switch on, you need to enter just 3 things, the trigger (time you want it to run), the action (switch.turn on) and the device that you want to switch on…
How much simpler can it be? I’d like to see the equivalent in other tools?
And that broadly applies to all software. Your point then is really about the amount of breaking changes. In my experience, I’ve been using HA for about 12 months now and updated each month (but at the end of the cycle), thus far I’ve reviewed each updates breaking changes and only had to ensure that my VW integration had to be upgraded accordingly to prevent my particular implementation being broken. I am aware that there was a fairly significant breaking change for ZWave users earlier this year. I’m not really sure what the issue is though, review the upgrade requirements, make your decision and if you need to move forward with the upgrade, do so being prepared for the breaking changes. The propensity is the same for most platforms?
I won’t entertain uPnP on my network full stop! My router doesn’t even support it for security reasons.
The default dashboard is set to auto maintain and add every device to it so that you can find them easily as an out of the box setup, otherwise you would have an empty dashboard with many users wondering how to put things on it. My recommendation would be that you either turn that off or create a seperate dashboard with the content you want to see. It’s expected that a default auto maintained dashboard is going to keep changing itself as and when devices / sensors are added.
I didn’t, but you seem keen to stay away from anything that is deemed to be “in development” in your terms. I simply stated that if you’re not prepared to work at a solution that can be customised and accept the technical challenges it presents that maybe limited apps are better suited to you.
But if you find something that meets your requirements and you feel is easier to use then that’s great. I’d love to see how much easier / better any alternative you come across can be…
It seems at this point that we won’t agree. I think the only piece that I can recognise as a shortfall in HA thus far is the desire to have a scheduling capability built in based on your and Borpin’s comments that it’s a key component. For me, I don’t have a key need for scheduling other than switching my EV charging profile overnight and I showed how simple that was. Other automations are typically triggered by something other than time in my requirements, hence I guess why the scheduling piece hasn’t really occurred as a shortfall to me.
Can’t help but feel a contradiction in this alternative of a slow moving, small community development product? But I haven’t sampled it and I am sitting here currently with my “Home Assistant” hat on. If it fits your needs better then hopefully it works out well for you.
Well, if the timers were attached to the switch device, once you’ve opened the correct one, then there’s only two things to enter for each one: the time and the action. One of my devices has 12 times set, so that’s 12 less things to enter. Also, if they’re neatly filed under each device, it avoids the HA problem of “a very long and un-organised list of automations”.
You wrote earlier that you get this bit of HA needs work. Sadly, it’s also the main thing I use.
Yes, exactly.
We’ll see. I’ve been around far too long and I don’t recall any software project with so many compatibility breaks becoming this popular before it moved to either a stable/testing/nightly or major.minor.patch version plan and keeping most of the breakages to the less frequent major/stable releases.
Yeah, I restrict it. I confine and control proprietary home devices for a similar reason. But the machine I tested HA on did have access to it due to other stuff I worked on.
Personally, I’d deal with that by putting a card on the default dashboard explaining how to add things. A card telling users how to stop HA messing it up would be almost as good, but showing a cluttered board of all detected devices isn’t a great first impression for new users.
I don’t think I used the phrase “in development”. I believe I wrote that I’m looking for something resembling a working app more than a development toolkit.
I feel there’s doing a bit of customisation work, and then there’s unnecessary technical challenges like bending yaml into scripting, instead of using something widely-known like Python.
Yes, our needs differ, as well as how many resources we’re willing to devote to this problem. If you don’t use timers much, the HA way is not going to annoy you as much. Triggered scripts seem not to differ as widely between systems, with it seeming like you usually need to use a module or library which isn’t specific to that system.
Another key thing is probably you mention having another system for your wife to use, while I don’t have another dashboard around, so I prefer that the wires don’t stick out too much and other inhabitants can control the laundry and the lights and ideally set timers.
What device do you need to schedule 12 different times for and why? I can’t think of anything I have that I would need to do anything near that many scheduled events for? Genuinely interested to know?
I was referring to the organising of the list of many automations if you have them, not scheduling, although it’s fair to say there is no In-built scheduler it seems, but from the sounds of Borpins post, there are add-on components. I haven’t seen them as I don’t have much need for time scheduling as mentioned previously. With that said, the screenshots you provided of Domoticz didn’t seem to demonstrate how well it manages this, I’ll see if I can find something on YouTube to that end.
If the scheduling is so key for you and other users, you could look to help the community by describing why it’s an issue and how it could be improved on a feature request with examples of how the UI should integrate this. If you did pursue this avenue, at least with HA you’d stand a chance of it being heard and actioned as it has such an active community?
A selective quote, but not replied on the rest of the same paragraph regarding the reality of breaking changes and how few people it affects most of the time… Have you used HA sufficiently long enough and gone through enough broken upgrades to determine the likely impact for yourself? Sure you can go on the forum posts, but if you want to be a “youngling” and just hit upgrade at the earliest opportunity without any consideration of the listed changes, you’re going to end up with a busted system.
That may partly be a reflection on just how popular and flexible HA is though. Positives and negatives exist to that end.
I too have been around software a long time, generally this is how software is now, fast paced with short development life cycles and quick upgrade access. Not like the packaged software of old. Slower development life cycle projects do still exist as Im sure you know. Some of my work is in financial institutions and the change cycle there is snails pace compared to the majority of other clients.
There are also branches of in progress builds for testing ahead of the month releases, so there is a regime. HA is probably just a bit too eager to get a release out every month in order to push things on which inevitably leads to some issues on the initial monthly releases, hence for stability, upgrade at the end of each month after the “younglings” have crowd tested it!
There is a message presented to that effect the first time you try to edit the default dashboard, so they managed to achieve both things, show items on the dashboard by default without having to walk users through doing it for their first few devices as they add them and then offer them the opportunity to take control of it or create another as soon as they start. I don’t really think you can say that this is a big deal personally. It didn’t take me long to dump the maintained dashboard, I can’t imaging anyone keeping it (or at least not using it as default) after getting up and running.
I probably mis-interpreted comments like those…
We’re still not on the same page regarding this… I didn’t have any yaml experience prior to using HA, I’m still not educated in it by a long shot, and I don’t have any python experience, yet doing the simple things you’ve list so far would require neither, so I’m still at a loss as to your challenges other than a simple scheduling tool.
Now if we’re talking about writing a custom integration to work with a component not currently supported by HA or create a brand new feature, then yes technical challenges abound, but this should be right up your street as they would be written in python!
Not sure what you’re referring to with the “wires sticking out”, if you’re referring to HA being a system for developers and not users, then I can tell you that my wife finds the camera system and the ability to control the cars pre-heating in the winter as well as a home page with key info and lighting / blind control on much more usable out of the two. I suspect this is all in the art of creating great dashboards, something that you have next to zero control over in C4.
But unfortunately HA doesn’t do all that I need just yet, so we can’t dump C4. Consider it like having to switch between the Heatmiser App for heating and Phillips Hue for lighting, not ideal for sure because neither does all that I want currently…until I get it all under one roof.
The reason it’s not all under one roof currently is because HA is not targeted at properties with whole house audio and video distribution and overcoming that will likely need a fair bit of work. This is a feature that isn’t really for the masses, as I’m sure there’s only a smaller audience of people that wish to run an 8x8 video matrix and 16 audio zones. This is where Control4 excels, but unfortunately, C4 misses out on so much more, such that I’d rather have an all encompassing system and thus far I think HA is probably the best option for that, hence my journey.
That’s one of the heating controls. A combination of fairly low precision on the manufacturer’s control, how widely the energy prices vary at the moment (thanks to the UK Energy Price Guarantee) and that the last hours before sunset are almost always the warmest part of a day (so best “fuel” for the heat pump) means that 12 timer periods are accurate enough, easier to adjust than a formula and more efficient (mainly in development time) than having a automation/script/whatever recalculate that input to the target temperature hundreds of times a day.
The HA github specifically says not to open feature requests and tells people to go post on the forum. There are already several forum threads about it which describe what’s needed, probably better than I would. Most attract few votes before being strangled by a moderator or developer pointing to some add-on not easily installed from the HA front-end. For a particularly comprehensive early strangulation example, see Input Schedule integration - Feature Requests - Home Assistant Community - so I don’t feel that I’d stand much chance on that route.
Well, obviously no, because I installed HA, it doesn’t seem to do the tasks I need and didn’t look like it would within the time I had available.
Well, it sounds like you’ve only one pretty simple automation and HA isn’t mission-critical to you.
And don’t underestimate the importance of easy simple scheduling to me. I use a lot of scheduling, including for pausing automations for a while. Seems like a bit of a missed opportunity if I can’t quickly tell the home automation to do stuff later and free me from having to remember it then.
Blimey, folk have alot of time on their hands (I didn’t read everything!)
For a small footprint Linux install, it is hard to beat DietPi. I have used this a lot on my Pis.
As I said, YMMV.
I’ll be interested if you do actually find one (I honestly don’t think it exists). Certainly you will not find one with such a large and active community, and high rate development cycle.
For example, Matter (stupid name) seems to be the protocol of the future and HA have just released their own dongle to use it. I think this demonstrates their commitment and forward look.
But again YMMV.
The problem I ran into with this is the slow release cycle. Jan 22 last release. When new devices are released daily, it just isn’t keeping up I’d suggest. Once you have it, and it does what you want, it is probably fine. But I see it being left behind for new users.
Comparing it to HA Core repo, it has a 10th of the contributors and 1/20th the forks.
I just don’t see it keeping up and providing the scope of device support HA is achieving. HA isn’t perfect (far from it), but I do think it has the greatest chance of success long term.
I really find that hard to believe. I looked and (for instance) there is no integration listed in the Domoticz docs for a Levoit Humidifier. True, the integration didn’t work in HA immediately for what I needed, but I added to a PR and now it does (although I am using a custom integration and overriding the core integration for various reasons - which I see as an advantage).
It may be surprising but it seems that almost everything is an add-on/integration/whatever in HA (and many of them seem to need patching and/or overriding like the one you used). Plus, there seem to be multiple competing options for many things, often with little documentation and devs that are a bit abrupt, to put it mildly (and I’m far from a diplomat, after all, so if I think that when reading their replies to users…)
I meant specific to deploying as a container (in my case on the RPi running EmonCMS) but actually let me also correct that I haven’t found anything I couldn’t do with the container deployment, it might just take some extra steps (not the standard path).
Fair enough. Just for reference, my ubuntu machine is running on a ± 10 year old Intel Core i5 consumes <100Watts (and that is in part because of the spinning hard drives) But for sure more than any Rpi.
I did the self install for Google Assistant integration (without Nabu Casa subscription) It requires quite a few steps, but it ain’t rocket science either. I did it for both my setups. One with reverse proxy one without. Both with let’s encrypt for HTTPS with duckdns.
I agree that automations have a steep learning curve, and this is one of the biggest hurdles IMO for Home Assistant adoption by a wider audience. For example you probably won’t use “Device” as a trigger but you’ll want to use “States” instead, similarly for most actions you’d use “Call service” and not “device”. Not to mention the way the logic operators like “and”/“or” work. This is not intuitive for first time users.
I have hit 1 breaking change, clearly release noted, where the credentials of my integration had moved from the yaml to the UI, as the integration now supported this. But yes this risk does define how I adopt (or skip) integrations.
In my experience it is possible to use Home Assistant without too much maintenance trouble if you stay on the beaten path and steer away from the bleeding edge and random github addons that haven’t been updated for 2 years.
For me personally, the key benefits I get using home assistant:
- I can integrate with virtually any smart home component (from Sonoff to IKEA to full DIY ESP32), over wifi, zigbee zwave, 433Mhz etc. (nowadays I first check integration availability before I buy any smart home electro )
- Usually I can do so with only local access (bypassing some unreliable and obscure cloud service) ideally without having to flash the device
- very powerful automation capabilities of which I probably only use 10%
- active development with large community (although perhaps not as nice as this one
)
good luck!
2 Likes
dietpi not very small base image - example image at 117 meg for an zeropi, with openwrt it is a 7 megs base image. to configure for base operation it size is usually grows to about 30 megs image after adding in python and other base software. then after that any secondary software I stack on top ie database or zigbee2mqtt. and really I have tested alot of different linux flavors and openwrt as a Base OS for small devices, while not really a full fledged OS it is the most stable and uses the least amount of resources to do stuff… where other linux based stuff is stalling out because the resources ran out. openwrt happily spits it out and keeps on chugging along .
BUT, I admit working with openwrt can be daunting for most, especially building a toolchain to compile software for it and the primary build taking up to 24hrs or more to set up and compile the base toolchain for your specific hardware . but after that compiling pretty quick for most software.
Domoticz supports alot of harware, and what not supported can easily added in with relative ease . but hey to each their own
Personally, …
-
Started with smartthings years ago - had great support, flexiblity, zwave zigbee IP etc etc
But it started to get more limited and their direction changed with some pros and cons -
Moved to hubitat - ok, flexible, but also things I dont like
-
Have Domiticz as well - so so, good at some things, not at others
-
Have HA more recently - started to use a bit, but feels rather ‘hard to get in to’ so far
-
All this combined with webmin, nodered (and dashboards), mqtt, webmin, containers, s3, shinobi, grafana, emoncms, iotawatt, lots of API integration etc etc
-
And many many gadgets from RPIs, cctv, plenty of relays/switches, plugs, alexas/google, sensors, garage door, lights, curtains/blinds, heating, EV integration, EV charger integration, vacs, smartmeter and modbus integration, xlights etc with both out of the box integrations as well as custom integrations (drivers and also m5sticks and the like)
And of course emoncms
I find they all still have plenty of limitations and take a lot of investment to make something sophisticated - still way way off any nirvana of decent experience
1 Like
Compared to most distros it is very small 
I wasn’t suggesting it is smaller than OpenWRT, but if you want a small easy to use distro, DietPi is hard to beat.