3 ms·

We are making Gladys Assistant ( https://gladysassistant.com/ https://gladysassistant.com/ ), an open-source smart home software. It's less "techy" than HA (no

We are making Gladys Assistant ( https://gladysassistant.com/ https://gladysassistant.com/ ), an open-source smart home software. It's less "techy" than HA (no YAML files, no CLI), and UI first. We have way less integrations for now, but are working hard on it. Don't hesitate to try it and make us some feedback.

robertlagrant 3y ago
I do feel like there's no point in making non-UI first home automation technology. It's not as though you'll be rolling it out across multiple environments.
- jasonjayr 3y ago
  For technologists, DIY'ers and coders, CLI first or CLI parity means you can use common dev tools to build, integrate and track changes. UI first means you have to build an awful lot of extra cruft to emulate parts of an already solid + flexible toolchain. EDIT: I should mention that includes text + file based config too...
  - emsixteen 3y ago
    Locking the ability to set up a smart home behind the ability to code and do a heap of DIY if a big part of the problem.
- SweetLlamaMyth 3y ago
  > It's not as though you'll be rolling it out across multiple environments. Definitely not for home use, but I could imagine a place for an open source server to manage a commercial property too. I'm admittedly a total outsider at property management, but I could imagine someone who operates several hotels, office buildings, or maybe even a school district wanting a building automation solution that doesn't lock them into a particular vendor. They'd have enough rooms and hallways with identical equipment that populating it via files, CLI, or an API might make sense.
  - robertlagrant 3y ago
    That would be fantastic, it's true.
- gregmac 3y ago
  I missed the manual config at first, and being able to quickly fix things, but it turns out it's not so bad, and I think because of: 1 - Most setups are done once 2 - Stability and quality has improved in recent years, and you don't have to fix or mess with it as much That said, I very much like being able to edit the yaml for automations and the lovelace UI. I like being able to flip back and forth between visual and code from the UI itself. Best of both worlds, especially because there's a lot of automations that are like 60% copied from another one. Being able to use a text editor (that has autocomplete!) to change entity names as opposed to clicking through several layers of UI for each one is awesome.
- aequitas 3y ago
  Aside from easily rolling out (parts of) my home automation to multiple environments (like my parents home, office, etc). The real use case for non-UI first is that with home automation software you often have to roll it out on the _same_ environment very often. Be it a corrupted SD card, broken state after software update, database bit rot, hardware RMA, etc, there are many reasons state gets corrupted or lost. So you either need to rely on a backup (if possible and hope it's up to date and works with the version you have installed) or configure everything by hand, again and again and again, via the UI, step by step, hope you don't forget that one setting you didn't write down. I rather have my home automation setup be build and deployed reproducible from a (VCSed) source.
  - robertlagrant 3y ago
    Ah yes agreed, but I was thinking more of an export/import mechanism, that can be version controlled, diffed, etc, than full on cli- or programming-first interactions.
kkielhofner 3y ago
Very nice! Would you be interesting in integrating with my project Willow[0]? Willow supports Home Assistant, OpenHAB, and generic REST+MQTT endpoints today. With Home Assistant and OpenHAB we benefit from their specific API support for providing speech to text output and processing through things like the HA Assist Pipelines[1]. From our standpoint we handle wake word, VAD+AEC+BSS, STT, TTS, user feedback, etc. All we really do is send the speech transcript to the Willow command endpoint (like HA) and speak+display the execution result. Other than all of the wild speech stuff and our obsession with speed and accuracy Willow is really quite "dumb" - think of it as a voice terminal. OpenHAB has something similar but it's significantly more limited. [0] - https://heywillow.io https://heywillow.io [1] - https://developers.home-assistant.io/docs/voice/pipelines/ https://developers.home-assistant.io/docs/voice/pipelines/
- pierregillesl 3y ago
  Nice! What languages do you support? (for STT & TTS)
  - kkielhofner 3y ago
    Thanks! STT is "just" a very heavily optimized (beyond even faster-whisper) Whisper implementation, so all of those languages[0]. For TTS we now use Coqui, which has a wide range of models with various voices, languages, etc. It even supports Meta MMS which has support for 1,100 languages[1]. [0] - https://github.com/openai/whisper#available-models-and-languages https://github.com/openai/whisper#available-models-and-langu... [1] - https://about.fb.com/news/2023/05/ai-massively-multilingual-speech-technology/ https://about.fb.com/news/2023/05/ai-massively-multilingual-...
    - pierregillesl 3y ago
      Ok! And what kind of hardware do your users run on? Do you get great quality of detection like Google Home/Alexa speakers?
riddleronroof 3y ago
Nice work Last I looked, the industry was trying to roll out some protocols to block open source efforts. Is there a plan to tackle that?
goodpoint 3y ago
Is in packaged in Linux distributions?

robertlagrant 3y ago

I do feel like there's no point in making non-UI first home automation technology. It's not as though you'll be rolling it out across multiple environments.

jasonjayr 3y ago
For technologists, DIY'ers and coders, CLI first or CLI parity means you can use common dev tools to build, integrate and track changes. UI first means you have to build an awful lot of extra cruft to emulate parts of an already solid + flexible toolchain. EDIT: I should mention that includes text + file based config too...
- emsixteen 3y ago
  Locking the ability to set up a smart home behind the ability to code and do a heap of DIY if a big part of the problem.
SweetLlamaMyth 3y ago
> It's not as though you'll be rolling it out across multiple environments. Definitely not for home use, but I could imagine a place for an open source server to manage a commercial property too. I'm admittedly a total outsider at property management, but I could imagine someone who operates several hotels, office buildings, or maybe even a school district wanting a building automation solution that doesn't lock them into a particular vendor. They'd have enough rooms and hallways with identical equipment that populating it via files, CLI, or an API might make sense.
- robertlagrant 3y ago
  That would be fantastic, it's true.
gregmac 3y ago
I missed the manual config at first, and being able to quickly fix things, but it turns out it's not so bad, and I think because of: 1 - Most setups are done once 2 - Stability and quality has improved in recent years, and you don't have to fix or mess with it as much That said, I very much like being able to edit the yaml for automations and the lovelace UI. I like being able to flip back and forth between visual and code from the UI itself. Best of both worlds, especially because there's a lot of automations that are like 60% copied from another one. Being able to use a text editor (that has autocomplete!) to change entity names as opposed to clicking through several layers of UI for each one is awesome.
aequitas 3y ago
Aside from easily rolling out (parts of) my home automation to multiple environments (like my parents home, office, etc). The real use case for non-UI first is that with home automation software you often have to roll it out on the _same_ environment very often. Be it a corrupted SD card, broken state after software update, database bit rot, hardware RMA, etc, there are many reasons state gets corrupted or lost. So you either need to rely on a backup (if possible and hope it's up to date and works with the version you have installed) or configure everything by hand, again and again and again, via the UI, step by step, hope you don't forget that one setting you didn't write down. I rather have my home automation setup be build and deployed reproducible from a (VCSed) source.
- robertlagrant 3y ago
  Ah yes agreed, but I was thinking more of an export/import mechanism, that can be version controlled, diffed, etc, than full on cli- or programming-first interactions.

kkielhofner 3y ago

Very nice! Would you be interesting in integrating with my project Willow[0]? Willow supports Home Assistant, OpenHAB, and generic REST+MQTT endpoints today. With Home Assistant and OpenHAB we benefit from their specific API support for providing speech to text output and processing through things like the HA Assist Pipelines[1]. From our standpoint we handle wake word, VAD+AEC+BSS, STT, TTS, user feedback, etc. All we really do is send the speech transcript to the Willow command endpoint (like HA) and speak+display the execution result. Other than all of the wild speech stuff and our obsession with speed and accuracy Willow is really quite "dumb" - think of it as a voice terminal. OpenHAB has something similar but it's significantly more limited. [0] - https://heywillow.io https://heywillow.io [1] - https://developers.home-assistant.io/docs/voice/pipelines/ https://developers.home-assistant.io/docs/voice/pipelines/

pierregillesl 3y ago
Nice! What languages do you support? (for STT & TTS)
- kkielhofner 3y ago
  Thanks! STT is "just" a very heavily optimized (beyond even faster-whisper) Whisper implementation, so all of those languages[0]. For TTS we now use Coqui, which has a wide range of models with various voices, languages, etc. It even supports Meta MMS which has support for 1,100 languages[1]. [0] - https://github.com/openai/whisper#available-models-and-languages https://github.com/openai/whisper#available-models-and-langu... [1] - https://about.fb.com/news/2023/05/ai-massively-multilingual-speech-technology/ https://about.fb.com/news/2023/05/ai-massively-multilingual-...
  - pierregillesl 3y ago
    Ok! And what kind of hardware do your users run on? Do you get great quality of detection like Google Home/Alexa speakers?

riddleronroof 3y ago

Nice work Last I looked, the industry was trying to roll out some protocols to block open source efforts. Is there a plan to tackle that?

goodpoint 3y ago

Is in packaged in Linux distributions?