Self-Hosting & Hubitat

[vmsman]

I would like to know if there may be interest in a live stream or even a small group live chat with folks here interested in learning about Self-Hosted applications and their role with Hubitat. My post on the Echo Speaks Local Cookie server became quite popular and my blog on that subject has been read/commented many times.

It seems that the majority of Hubitat users are Windows users and that they are not comfortable with Linux applications. For example, the use of Docker apps, docker-compose, LXD containers and Linux server configurations are scary. There is constant growth in applications that require local network instances like the Echo Speaks Cookie server.

Most folks here that delve into these apps host them on a Raspberry Pi. Raspberry Pi's have become prohibitively expensive for what they are and there are better, more cost affective solutions providing more utility.

I would be glad to host a discussion among fellow Hubitat users to explain the role of containerized apps callable from Hubitat and and how these are important. My ScottiBYTE YouTube channel goes into a lot of detail on self-hosted Infrastructure. However, I feel like a Self-Hosting 101 Q&A might be good for the Hubitat Community? Thoughts and comments please?

[chowell]

There’s definitely a discussion worth having here. It’s tough due to the wide range of expertise and needs. It could make a many part video series. Due to the very international nature of the Hubitat community, I’m not sure how well a live stream would do. But I’m also not one that watches live streams. So maybe I’m the wrong person to ask.

As far as the prior discussions about self hosting. Check out this thread.

Raspberry PI companion for HE

Hi everyone ! I know that it's easy to one make suggestions when the person itself does not know how to implement it, but nonetheless I'll make this one. When we at HE community have tools like Hubitat Package Manager (HPM) available, it makes everybodys life easier - I think there's no question about that. However, there are some solutions like local WebCore server, Alexa TTS, VPN, local e-mail client (some that I can think of now, and certainly there are much more), that requires a Raspberr…

[jtmpush18]

I would be very interested in something like that.

On a personal level, my knowledge of Linux 3 years ago was NIL.
However, I am now investigating the use of Proxmox and LXC containers.
I am still learning about this world and I have a long way to go.

I would also like to personally thank @vmsman for his ScottByte stuff which I used to make an Alexa Echo Speaks server.

[maffpt]

As I suggested at the thread the Raspberry Pi Companion (as noted by @chowell ), I believe that the ideal, desirable and not absurdly difficult to accomplish environment could be one where a simple interface or definition file is used.

A json definition file, for exemple - created by the developer of the solution (e.g. Echo Speaks Local Server) - where all information needed to create/install/configure/update an application would be defined. I personally would not go into that direction since this option is not interactive and, since we have a "server" available, it could use a web interface instead.

This web interface, provided by a Docker instance (RPi HE Companion server), where a developer could fill parameters with all information needed to create a Docker file, like packages necessary, port informations, IP callback, etc and additional information to be used by a Docker app (like app config file). Everything standardised. It would abstract to the developer all complexities of defining Docker file, config files, etc. The same interface would allow the end user to update and operate the Docker instance running.

For example, I have plans to develop an UPS interface using a RPi. This interface would "sit" between the UPS - handling all communications with it - and an app/driver running in the Hubitat hub itself. It would allow us to avoid eventual HE database corruption events where a non-controlled HE shutdown occurs.

I am pretty sure that it is feasible - all elements are available. The problem, in my case, is the lack of time, energy and, most of all, experience with the platforms - linux, Docker, to begin with.

As I said in the post cited by @chowell, it is easy for someone with all these "deficiencies" to say that it is "feasible". However, I'm confident that the hard really hard work would be to define, create and validade the infrastructure to be used by all Docker apps, create the web interface including the Companion management pages. From then on, I believe that it could run smoothly.

Until august I'm finishing the first year of my master's and then I'll have at least two months of less pressure to start my thesis. So, I'll willing to prepare a diagram defining the infrastructure to be discussed.

How about that?

Note: it's not necessary to use Docker - any containerised solution like LXD would do.

[vmsman]

@maffpt you may have gone down the rabbit hole a bit. So, my thoughts in regards to this training is to try to get really beginning users to understand that there are instances where an external container docker, LXD, or VM might be needed to perform local processing on the LAN to provide utility for a Hubitat automation which may need to be external.

and yes, there are things like a UPS monitor that I covered on my YouTube ScottiBYTE channel lately. The thing is, there is a gap for Windows users in understanding when a LXD container might be needed and how to implement one. A good example of this might be my Harmony-API LXD container that uses the Hubitat Harmony skiil, the Cast All the Things (CATT) director which needs a CATT server, the Camera Motion Capture custom device that uses a web server to store time lapse images based on motion events, or the Echo Speaks Cookie Server.

There are many other examples. The issue here is that Windows users who automate with Hubitat could use a 101 course in hosting these types of apps and understanding the basic Linux skills to do so.

[maffpt]

Yes, I believe that containers is the way to do it.

As the thing grows, it would be possible to create something like "ready to install" apps - Docker hub like. This way, when an end user decides to use a solution like UPS connected to the HE, just choose the "package", install and configure it and voilà! Magic.

I'll take a look at your YouTube channel.

[wsramz]

after beginning implementation of a self-hosting instance, I think many Hubitat users would find it extremely informative.
vmsman convinced me that it was a good way to go and I'm slowly working towards the local option, good learning process as well, his how-to videos and notes are first rate and teaching worthy and very concise.

[marktheknife]

Also just wanted to say I've learned a lot from Scott's youtube videos and posts in his discourse forum. Would love to continue learning more about Linux, the command line, or other topics related to self-hosting. But my work and home schedules make it tough to commit to learning synchronously at the same time as others. Always happy to check out anything that's recorded for later viewing though.

[tomw]

@vmsman

there are better, more cost affective solutions providing more utility.

What do you recommend these days?

[vmsman]

@tomw Come by my chat server at https://chat.scottibyte.com/ so that I can ask you questions and we say what might be the best fit.

[vmsman]

Thx Mark. We can always tag up on my chat server and talk. Often I get a better targeted perspective by speaking with others on what I should cover.

[vmsman]

@wsramz thx. 165 videos and counting on the channel and I am continuing to expand. I am a proud user of a Hubitat Elevation and really I am finding increasing instances where I need supplemental self-hosted app instances to augment my automations.