@vmsman thinking through ways of making this more accessible for people (and me)... Couldn't we install debian or Ubuntu on a spare Android phone, set up the echo speaks cookie per your Linux instructions and just leave the phone plugged in? A lot of folks hesitant to buy an rpi might be willing to try with that old android in the top drawer.
1 Like
Personally I wouldn’t feel that comfortable leaving an old android phone (and it’s old Li-ion battery) plugged in all the time. Maybe with some kind of battery tending app or script running, but even then.
It doesn’t have to be an RPi running Linux. @vmsman has mentioned a few other options for small-form factor PCs that can run a Linux OS, and if you have a Mac or even Windows PC you can leave always-on, that’s an option too.
Do you have concerns about the RPi other than buying new hardware?
@giudicistefan I guess in terms of "practical" I personally shutter at even an RPI only because I know you will have far more than one app of this type in the future. That's why I strongly suggest an inexpensive device Cheap Self Hosting Server - YouTube like this one.
The type of infrastructure that you want for this type of application should run 24x7. A repurposed android phone running a debian on it is even less desirable than the RPI. The biggest reason for this is availability and stability of the device. Also, I would never want a server based application to be offered over a wireless connection. I know you can get a USB ethernet adapter and drivers for that old android phone, but overall, the phone option is something that I would never advise using.
1 Like
I have been using an old Moto G phone for 3 years so far as my text to speech interface to my in home audio and it's plugged in 24x7. I watched the battery though accubattery and haven't had any issues with the internal battery getting constantly charged. The same for a Amazon tablet, it's been running 24x7 for 3 years also and still never seen it attempt to charge a already topped off battery.
1 Like
Yes, I see the same thing. But my Echo Speaks appears to be working, and the cookie is valid.
Just curious.....is all of this docker trouble really worth $5 a month? 
If you already have the capability, definitely.
1 Like
Yes, since you wouldn't be paying $5/mo for Echo Speaks. You'd be paying $5/mo just to run a tiny script get your current login cookie from Amazon in order to inject it into the Echo Speaks app.
Set up the docker instance (or any of the other local installs of the cookie-getting-service) and consider sending a few $ to @tonesto7 instead.
4 Likes
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.
1 Like
to a billionaire - no. to me - yes.
1 Like
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.
1 Like
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!
1 Like
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.
1 Like
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.
1 Like
