It’s really not much trouble. While this is not my first attempt to use docker containers, I’m far from an expert or old hand in this area.
If you had to start from scratch and figure it all out on your own, I could see reasons for concern, but with instructions provided by @vmsman and others, it’s pretty simple.
to a billionaire - no. to me - yes.
I currently have a PI with Open Media Vault installed on it for storage. Would I be able to install this Echo Speaks local solution to the same Pi to run both programs?
@Pantheon Try to view setting up a docker or LXD server as a future investment in your home automation. Consider HE the center of what you do. This login/cookie authorization server for Echo Speaks is just one example of a local server instance. I also use a "Cast All the Things" CATT Server that communicates with the CATT director smart app in order to cast content to my Google Chromecast. Many times, that might be a voice command to display an HE dashboard on the TV. Another example might be my monocle RTP/RTSP gateway on my local LAN that allows third party cameras to be displayed on Echo Show and Fire TV sticks via Alexa Voice commands. I also use Logitech Harmony Hubs on HE to control switches that launch activities. In my case, I use the Hubitat Harmony Smart app that makes calls to a docker container running on my network to expand my Hubitat control of my Harmony Hubs to the device level. I also run a local Webcore editor instance rather than using the Webcore editor instance in the cloud. I use the Camera Motion Capture device type developed by Michael Barone in conjunction with a web server on my LAN that captures motion events from cameras as a series of frames that can be replayed. The list goes on. The thing to understand is that Hubitat Elevation is all about local control. It's not always the money. Many times it is about having all of your services hosted by yourself and not a plethora of companies that can arbitrarily discontinue their service or start charging. Just my take.
Sorry if this has been asked, but my echo speaks still works as is. Wasn't it supposed to stop working?
A RPi to complement the HE is what I suggested some time ago:
I "baptized" it as a "companion" because it would be a real companion to the HE platform, implementing complementary functions, as the ES local cookie refresher server, local WebCore, backup handler and so on - the possibilities would be endless.
It would consist of a Docker environment where someone could add HE-specific pre-configured images (like the ES and WebCore) and configure them, directly from the HE - no need to know anything from Linux.
So far, it's a dream - but dreams someday come true!
Kind of like pi-hosted ? The frameworks exist. What's required is a tiny bit of development and a whole fleets worth of maintenance and support.
It has, see above:
@maffpt That's an interesting proposal. It may add value for some people to be sure. Since I specialize in teaching people infrastructure, I think there is a fine line between just implementing something and understanding the technology. Arguably, the SmartThings platform evolved into a complete point and click environment sacrificing customization. Home Assistant goes down the rabbit hole of understanding much more than Hubitat Elevation to enable most functions. That being said, the world's desktops run Windows and the world's servers are primarily Linux. I have devoted my YouTube channel and my forum to decrease the mystery behind Linux and more robust networking options. Anyone who cared enough to search out and implement an HE had desires to do more than the point and click. An HPM for ancillary processing, be it Docker or LXD containers is an admirable future. I try to open options to learn the technology and leverage it to attain greater things. I enjoy passing along knowledge and giving folks leverage to enable bigger and better automations and self-hosted options. Raspberry Pi's are okay, but once you go down the rabbit hole learning about these desired additional functions, you soon develop more requirements. Here's an example. The snapshot below is an inexpensive Ryzen 5 running 19 LXD containers running all sorts of self hosted automations. The machine itself cost in the $275US range and the 32GB of memory was just over $100US. By comparison, a RASPI is fixed at 8GB max with no storage shipped with it.
What I envisioned was that the community could develop Docker (or even LXD) containers specifically for the HE-Companion.
An app (HE-Companion manager) would be responsible to "talk" to the RPi and request the installation (and update) of images and the creation of devices that would talk to the application running in the installed container. The manager would be also responsible to all communication with the container providing functions (API) that could be used by the device driver.
One application (container and device driver) that I'm eager to create would be a NUT for the HE.
I'll take a look at the LXD containers. Thanks for the info!!
@maffpt I hate to see people just going back to RPi's for this type of thing. The RPi, even in the 8GB model suffers from lack of CPU performance, very slow network connectivity and awful I/O even with an external USB3 SSD. An app (HE-Companion manager) needs to have at least some reasonable horsepower to run at least 5-10 containers.
The ideal server has at least 16GB of memory, a small NVMe drive at least 256GB, 4 cores, and 8 threads. It should run Ubuntu Server 22.04 which is super lean with no desktop. LXD should be configured. LXD containers can nest Docker apps for absolute isolation. All this is controlled via LXDWare LXD Dashboard and Portainer with the Edge clients to see docker instances inside LXD.
Everything mentioned above gives this a great GUI. Since all API's are different and some containers may be running docker and others may be running node.js, the "one interface from HE" that manages it all is unlikely. I am trying to promote the crazy good efficiency of LXD containers for these ancillary apps on my channel. Sure, you can run 5 LXD containers on an RPi, but not much more. Come by https://chat.scottibyte.com/ to strategize sometime or just to say hi.
I disagree!
I’m running OMV 6.x (Sata SSD for the OS) on my ancient HP MicroServer with 8GB ECC Ram and the CPU is a dual core 1.4Ghz AMD Turion N40L.
This server is running my 12TB raid array that contains all of my files and media + Docker and Portainer and 8 total containers.
Frankly, this server would have trouble pulling the skin off custard, yet it’s not being over stressed at all.
I wouldn’t recommend running something like Plex on this type of config (I have a dedicated Plex server, but the media is on my MicroServer), but most other services run just fine.
Even a RPi 4 would't be enough for low demand CPU apps?
Evidently high usage CPU apps would not fit in it - well, why not a second RPi Companion (one more requirement to add to my long list: multiple RPi ... 
).
For lightweight docker apps, even a Pi 3 would be adequate.
maybe discuss this somewhere else so those of us interested in ES4 can watch the thread without needless alerts?
@dJOS Derek, I think you just agreed with me. Also, OMV is not really designed as an application server. I am trying to promote the power and efficiency of LXD containers over any VM solution. At the same time, using an old dual core server or a RPi isn't going to give you a great experience overall. Plex is an interesting use case because it crosses the boundaries of requiring lots of storage for media content yet providing enough CPU to transcode up to 4k videos.
Typically NAS systems are woefully underpowered for anything CPU intensive such as transcoding. A small server like the Minisforum UM350 that I have been recommending has plenty of CPU and good memory expansion for most folks. Where it falls short is in storage connectivity.
I am impressed my the UM350 because it scales to 64GB of memory for cheap. Also, I only need a TB or 2 to host containers unlike hosting something like Plex. This thread is about locally hosted server instances to support callable functions from HE. I wanted folks to know that LXD containers and docker nested in LXD is a superior performance model on a really inexpensive device not much more than the RPi.
So, I like 1 Litre servers and even old data center servers. However, I shy away from them in regards to power consumption and heat generation. RPi's flirt with the "way too small" end of the spectrum to provide expansion options.
It's good when someone has an older box to run OMV, Proxmox, or the open source VMWare option. That being said, those options still prominently feature VMs and not containers. LXD just gives so much incredible bang for the buck and it doesn't tie you into an ecosystem like Proxmox.
Bottom line is that HE owners will need supplemental processing power as time goes on and understanding containers running on a local host will go a long way to a satisfactory solution.
Success!!!
I followed what @ jtp10181 posted above again, and now all is good. The Container still says "localhost:8091" but the Image is working with the proper IP Address.
The cookie was successfully refreshed last night.
Anybody able to help. My Echo Dots are showing "Announcements" & "Text-to-Speech" as "False" and so none of those functions work.
The "Music" stuff does work though, but not my use case.
So another cookie refresh was supposed to happen today.
My announcements are still working, but my Echo Speaks says this:
Does anyone know why it would say 364 days??
Download the Hubitat app
