I’m using openHAB since 12 years now and been through a lot with it. Kinda love it, some things are more straightforward there than they seem to be with Home Assistant - some things are tedious.
I’d like to have a deeper look into Home Assistant so I:
installed Home Assistant OS on a NUC
got some of my devices into Home Assistant and I can see them and play around with them.
Having some first successes…
But what I’m really having a hard time to understand is how to do smarthome logic.
Within openHAB I can start a logic via rules (best based on JavaScript) and within those rules I can access items (like entities?) and based on their states I can do stuff - or update states.
how am I supposed to do a bit more complex logics in Home Assistant?
let’s say, the use case is the heating of our whirlpool:
I’d like to have it heat up, if there’s enough PV excess or my dynamic energy tariff is cheap hours. This one would be easy, but I’d like to:
have different target temperatures depending on
** seasons
** time of day
** battery SoC
** planned other consumers like EV, heat pump, washing machine,…
have an “override” function, to heat up to a controllable target temperature no matter what
So in openHAB I’d create a new rule (automation?) which triggers every 5minutes or if there’s changes on the consumption of my pool - but only if “override” isn’t active.
Within the JavaScript I’d be deciding, which season it is, what the current time of day it is, the battery SoC (and the expected SoC after Solar prediction and consumption, …). Then I’d do all the magic within JavaScript logic - and the embedded JS-Engine has access to all states of device endpoints (aka entities, which I could manipulate then).
With several automations. There really is no benefit in cramming everything into one and it can make maintenance much more difficult. Write an automation for each trigger - you can combine them later on if you want to make them more “elegant”.
HA is event-driven, so they shouldn’t have to run every five minutes - only when something changes.
Helpers make good overrides, particularly “toggle” and “threshold”.
So, if I understand correctly, I would have multiple triggers:
everytime PV power changes
everytime pool consumption changes
everytime battery SoC changes
everytime seasons change
everytime time of day changes (every second? every hour?)
but, e.g. the “target temperature” entity would differ not only if a season changes, but what time of day in conjunction with all the other information it is. and yes, that seems to be the complete opposite way of doing things - not use case based, but event based. But now I have like a dozen triggers, which have impact on one entity (target temp), not one automation around one entity having all states of entities. Seems pretty complex system of triggering then? or do I don’t get it yet…
With pyscript. You can do pretty much exactly the same as the JS code you mentioned in OpenHAB, only that’s it’s Python.
Native Home Assistant automations are so clunky for anything but the most simple cases. I mean you can do pretty much everything with them, somehow. But the resulting Jinja code squeezed all around your automation YAML is just such a mess. Have a look at pyscript !
That’s not really a way. I use node-red extensively to either integrate hardware, which isn’t accessible from openHAB or the integration is bulky or for stuff there’s like load-limits on it (e.g. Kia-API) and I’ve got multiple consumers for it and so I use node-red as a means to access the source and then let it send all information via MQTT.
Building smarthome logic within node-red would result in not needing a smarthome framework in the first place!
Well, there’s going to be changes and challenges no matter what you do. You’re jumping onto a very different system after all.
pyscript is as close as you get to a fully programmatic way to handle automations (there’s also a C# integration, if you’re more into that). Yeah it’s Python, sadly. But that’s the way it is. There’s no native JS automation support in HA, unless you go over Node Red (which is another option, as mentioned). But if you have over 10 years JS experience, doing some basic automation logic in Python shouldn’t be a big deal. I’m a C++ developer in my everyday life and I hate Python with a passion. Still I managed to do all my automations in pyscript without any major issue. Python is a super simplistic language.
Native automations in HA with Jinja are much much worse
Aren’t you overthinking it a bit? If I were regulating pool temperature, the trigger would be air temperature. The state of your batteries etc. would be conditions and the action would be heat the pool…
perhaps. But this is, what I do: automating the process I’d do manually. And yes, I would do exactly as described manually: slowly degrading the targetTemperature over time. I’d like to use the pool like a battery. I don’t need 38.5 degrees, but if there’s more than enough midday sun, I’d be silly to not heat up the pool for the evening but instead throw away the PV excess and to buy expensive when there’s no sun. Works very well since years.
There is nothing stopping you from doing the same thing in HA. Many say that triggering on a time pattern isn’t good programming but there are times when it works best. And it’s offered in HA for a reason - because sometimes it’s a good option (or at least not a bad option). And especially that you already have that logical understanding in your head and the framework already works in OH.
you would just create a time_pattern trigger for every 5 minutes, a trigger for the pool consumption entity state changing.
then add the override being off as a condition of the automation.
for that logic I would look at the “choose:” syntax.
each of those conditions can be checked in the coose action and then can be acted upon. Just remember that the choose actions are first come first served so you may have to get creastive on how the conditions are checked hierarchically.
You still may end up getting into some Jinja templating but without know the exact requirements of the locig it’s hard to know for sure.
it may just be as simple as checking straight-forward conditions to achieve what you want.
