Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not to sound negative, it reads like the author quickly dismissed HA without a great reason so they could build their solution.

There's a lot of home devices beyond ZigBee, with a large community supporting them. Beyond ZigBee, we will see Matter devices also cropping up over time.

I do like the idea of being in control of one's automation software. The risk that I've seen though is when one ends up spending more time on building the software than the automation, which can happen when one writes their own integrations from scratch (i.e. not using Z2MQTY, ESPHome, HA, etc).

With that all said, I like HA as the central programmable hub, but have come to dislike the proliferation of ecosystems that require add-ons I'm mostly looking at Sonoff devices that tie you to ewelink and phone home in opaque ways.

I'm personally probably going to go with Matter for store-purchased and DIY devices. I'm already nearly done with our first DIY devices at home. A light strip for the kitchen, that has some sensors for useful automation.

Not rolling my own solution makes it easier for me to build a few devices for friends later.



HA is _very_ good for integrating stuff, mostly due to it being the de facto standard for DIY home automation. Basically if something has any kind of API that can be accessed in any way, someone has already made a HA integration for it.

On the other hand, it's absolutely crap at doing complex automations. The Web UI gives me heartburn any time I need to make it do anything else than simple "if temperature is over 40 on this, do this" things.

The UI does make complex automations _possible_ for non-programmers. But for me, every time I click on the UI or attempt to "program" using the convoluted YAML syntax I keep thinking "this would've been like 5 lines in an actual language...".

Thus: I use Node RED for the more complex stuff paired with an external program I made that connects to the HA Mosquitto server and pokes stuff directly when needed.


Pyscript adds rich Python scripting to HASS : https://github.com/custom-components/pyscript

An example script:

    @state_trigger("security.rear_motion == '1' or security.side_motion == '1'")
    @time_active("range(sunset - 20min, sunrise + 20min)")
    def motion_light_rear():
        """Turn on rear light for 5 minutes when there is motion and it's dark"""
        task.unique("motion_light_rear")
        log.info(f"triggered; turning on the light")
        if light.outside_rear != "on":
            light.turn_on(entity_id="light.outside_rear", brightness=255)
        task.sleep(300)
        light.turn_off(entity_id="light.outside_rear")
It's what made me ditch node red after going down the same path.


Can anyone comment on whether Pyscript vs AppDaemon is the better path? It felt like to me as someone that codes as a living PyScript was the better choice, but I also only ever used Python in college and grad school, and just haven't had the time to investigate a difference between the two and wanted to just get started. Using PyScript seems easy but it also feels like its just the main authors preferred way of working and is pretty buggy outside of how he likes to work in Jupyter notebooks

The Home Assistant community seems to have the entire gambit of people who can't code at all, the people who never coded professionally and make riduclously complex things like the fabled Excel accountants, to the professional developers doing stuff for fun, but nobody actually shares anything worthwhile outside of awful YAML and youtubes about awful YAML.


I'm currently using AppDaemon for a couple of webparsing-scripts. That has worked just fine without touching it for... well over a year by now.

But i have a nagging feeling that i should probably use PyScript instead.. If anyone has a more thorough analysis i'm open to hear it..


For what it's worth, I don't use the Jupyter notebooks. Just have a folder somewhere with python scripts that get reloaded as I edit them.


I've found that it just feels like I'm fighting a river to go up stream if I don't incorporate the web browser + Jupyter work flow that the author likes.

Auto complete for discovery just refuses to work in PyCharm and VSCode for me. The way PyScript is setup seems to be a strange bespoke system that kind of breaks the import system between files, type safety only sort of works sometimes, and just other quirks where I seem to just have to get used to all of the red underlines if I want to use an IDE as part of my development process.

But it still seems to be best option for allowing me to use any libraries in the ecosystem, gets rid of boilerplate, and the author is actively maintaining it. I didn't really find any other viable options outside of Python that would let me actually code my automations without yaml or a GUI.

I was very excited when I found a Kotlin implementation, KHome, but by the time I found it, it was already a seemingly dead project.


If you are expecting auto discovery of state variables or service calls then that would be nice, but that seems like a bit too much to ask. And it's not something that I personally feel is necessary as you're likely already are familiar enough with the home assistant states/services that you want to interact with by checking them out in the home assistant developer UI.

My PyCharm just shows those types as unknown, not as errors. I get auto completion & type checking for all the code I write myself.

It's also important to note that PyScript isn't regular python. Instead it's an interpreted script[1] that is compatible with the Python syntax. This is unfortunate, but enables most of the magic of PyScript which otherwise would not be practical.

[1] https://github.com/custom-components/pyscript/blob/master/cu...


The thing is, the Jupyter notebook does support auto discovery/complete of all of the state variables and services, but only in the browser. Not even in the notebook running inside the IDE.

It's just maddening that I can't seem to figure out how to get that one part working. I end up using a mix of the notebook and going through the developer UI, but wish I could figure out that one quirk.


Where is that stored? My beef with NodeRed was that it's not very git/manual-change/file friendly - random IDs and minor change in UI causing a large on-disk shuffle.

Even if I use a UI for making a modification sometimes, I want to be able to commit a clean diff like:

      sensorLightBackdoor:
    -   timeActive: range(sunset - 20min, sunrise + 20min)
    +   timeActive: range(sunset, sunrise)
Or whatever. Which obviously I can do with python, as long as it's stored neatly in config in a .py file, or even if embedded in HA yaml or something?


> Where is that stored

In a `pyscript/*.py` file, so you can open it with a full blown IDE and use all your usual comforts, and commit the results to git.


Awesome, thanks, this may be the push I needed back into HomeAssistant. :)


There's also NetDaemon for those who prefer C#: https://netdaemon.xyz/


Yea I kinda wish you could just write code for it. I’d even accept writing it in python as that’s what ya is written in (as I too don’t like python)


Their reasons for dismissing HA seem sound to me. Python is a negative for some people. Suggesting to run in docker is a negative for some people.

Personally, I gave in and installed HA in a VM, because it seemed like the least effort way to use HomeKit capable devices without purchasing Apple products, and I was able to connect the HomeKit things, but I can't figure out how to do what I want with them, so I not sure what I got. Ideally, I want to make my 'smart' thermostats a bit smarter ... better coordination between zones, different minimum fan runtime rules than I can get from the thermostat, loosen the setpoints when the tv is on or someone is on the phone, so the hvac noise is less bothersome, etc. But I can't figure out how to get HA to track the fan runtime, so all that complexity is like ugh, I'd be better off doing it myself, except the homekit stuff isn't sensible either.


Yeah I thought not liking the way of self-hosting it especially was fair enough. And I suppose language is too even if I don't mind in this case - Java certainly puts me off OpenHAB (and anything else it's used for).


I've been running openHAB for 3 years with over 100 Z-Wave devices (every light and window in the house, auto-sensing everything), 25 touch screens (one in every room) and wifi/ethernet integration with everything else you can think of (eg UPS, TV, Sonos, Sonnen batteries, Envoy solar interters, air conditioners, sprinkler systems etc). It's never failed and the community is helpful. Irrespective of whatever it's written in, the versatility and 365 x 24 reliability is absolutely rock-solid.


The risk is real and reasonable if one is willing to rationalise it as a hobby / learning / playing with hardware and a trivial amount of soldering.

In my case I wanted to play with sensors and the pico w. A pi with a sprinkling of c#, Nats, and influxdb connects, controls Ikea stuff, and reports all the things.

Micropython on the pico is not my favourite part of the process but it might have been faster for me than just writing in c.


That’s cool - I’ve done something very similar and used the Worker Service project type along with Quartz .NET for scheduling.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: