Arcus on Kubernetes: self-host your own Arcus
1 1

6 posts in this topic

It's taken about a month, but I'm pretty close to having a self-host version of Arcus that doesn't take take days to setup. I have put together a set of scripts and kubernetes configuration files (available on https://github.com/wl-net/arcus-k8) which can be used to host your own Arcus deployment, provided you have reasonably deep *nix experience. In my testing, I was able to get tear down my Arcus setup and build a new one in about 25 minutes - far better than my first experience of 20+ hours. This version is still missing a lot of features, like notifications, backups or any redundancy, and a clear upgrade path. However, if you have Iris devices you're not using and want to try Arcus, and are comfortable with loosing all your data / configuration, this might be worth taking a look at. I have not tested recent versions in Google cloud, but have instead been focused on local deployments (e.g. you provide a bare metal system with 12GB or more RAM and 20GB or more disk). Furthermore, nobody besides me has been able to complete these instructions (as far as I'm aware) from start to end and achieved the same result as me.

https://github.com/wl-net/arcus-k8

Going forward, I plan to migrate my existing Arcus deployment over to these configuration files, and until that is complete, this configuration should not considered to be stable (e.g. at any given time, the repository could be broken or updating could otherwise destroy your deployment).

Share this post


Link to post
Share on other sites

Hi there @AndrewX192, I have been following your work the last few weeks and signed up to ask a question or two. As background, I was not an Iris user, but have been interested in the creation of the Arcus platform based on the source of the Iris code. Very cool that they made this move.

Anyway, I've been toying with the idea of playing with a deployment based on your repository. It looks like you are doing some great work! Since I'm not really from an Iris background, is your repository meant to replace the whole Iris ecosystem with one that your run on your own hardware? For example, I have a Iris hub (I think v2 . . . maybe v3?). After deploying the Arcus install, does this hub connect locally to that deployment? Is there anything special that I need to do to the hub or does it detect and connect to the Arcus deployment on its own?

Sorry for the very basic questions! I'm very interested in how this project is going for you. 

Share this post


Link to post
Share on other sites

Hi e-dash,

Thanks for reaching out. I think it's probably better to first talk about what Arcus is rather than what my repository or plans are with Arcus. Arcus is the source code behind the Iris platform (e.g. arcusplatform/platform) and parts of the hub (arcusplatform/agent). Not all of the iris code was released as part of Arcus, the most important missing parts being: on the agent - parts of the zwave and zigbee code is left out, and on the platform - many of the components that depended on third parties (e.g. nest or honeywell). This is enough to bring existing Iris hubs back online, and use many of the zigbee/zwave devices that were supported under Iris again, with a great deal of success. Using Arcus, I was able to restore one home that was previously using Iris back to all of it's original functionality, add Iris equipment to a new home, and provide a friend that also used Iris enough to run an alarm system and a few things (although they're currently using a mix of Arcus and SmartThings). I also have a stack of v2 hubs that are connected to various other deployments of Arcus that I have for testing (e.g. in GKE, or one of my on-prem k8s clusters). 

Based the community around Arcus today, I don't think there will be support for third party hubs in the next few months, especially given the unknowns around zwave/zigbee. The code does have references to running the arcus agent on a local machine for development, but it's unclear which dongles are required (e.g. I know EZSP, but what specifically are the requirements). The issue of not having source code shouldn't be an issue because this is a java project and you can simply add the closed source jars on $CLASSPATH. Since the iris hub can be found for very cheap (I got one for $5), I also don't see a good reason to invest resources in this problem. Thus, my approach has been to get the Arcus platform up, and make a simple onboarding process to bring existing hubs online. That process is not publicly documented, since it's coupled to my infrastructure, but I've gotten the high level process down to 1) get root on the hub (already documented by Mike S.), 2) copy a jar file over to change hub trust store 3) copy a jar file that changes default server to connect to OR keep a USB stick in with the publicly documented configuration options set.

My goal has been to get this whole process down to the minimum time possible, since it means more users can evaluate Arcus and contribute to it or learn from it, and because it makes my development purposes much easier. As it stands today, AFAIK I am the only one to get Arcus to work, and despite several people trying the scripts on arcus-k8 there's always been an issue with services reaching cassandra or kafka. This problem doesn't seem unique to Arcus, but rather is the reality of running stateful services in Kubernetes, especially with mTLS (via Istio). I'm still trying to figure out how to replicate cassandra across multiple pods and clusters in k8s, which in itself seems like an immensely complicated subject.

Anyway - back to hubs. While I'm not convinced that the Arcus agent is the right thing to keep working on (especially given that we're not going to get another hub anytime soon), I have been looking at new ways to connect devices, via the IPCD protocol (also released as part of open sourcing Arcus). Using IPCD, I was able to add support for Insteon switches, using a completely different hub - something that was not supported before in Iris. I believe this approach can be taken to achieve many more integrations, such as controlling general python automators on raspberry pis or whatever you want to do (as long as Arcus has the capability defined for it). As an example, I plan to add music controls (play <URL>/pause/volume adjust) in Arcus.

Some of the concepts in Arcus aren't as completely thought out as they are in other systems. As an example, you can't create a schedule that only runs when a person is home. Adding support for this concept requires storing additional state about each place that a particular partition of the subsystem-service knows about, increasing memory usage and adding complexity. I'm not sure if this is the right thing to do in the Arcus ecosystem, and development of a large scale java enterprise application is difficult. For this reason, I'm also considering adding permission scoped "service accounts" that can connect to Arcus, listen to the event stream (e.g. over a websocket much like the app or web portal does) and provide unlimited customization with simple python code or a groovy DSL.

Share this post


Link to post
Share on other sites

Wow, dang, thank you for the detailed response. Seems like there is a lot more involved than I originally thought. The IPCD idea and service accounts seem like a good way to take advantage of the Arcus platform while still expanding it beyond what it is currently capable of. Although, if it does take so much effort to get it working, I wonder when it would just be more beneficial to develop for a different platform. Either way though, it is still fun to play around with. I'll keep my eyes on your progress and thanks again for the work you have put into it!

Share this post


Link to post
Share on other sites

In theory it shouldn't be a huge undertaking to get running. The main problem is that I don't know what all of the edge-cases that people are running into. I've looked at OpenHab, Home-Assistant, Hubitat, etc. - they all have limitations, and so does Arcus. It's not uncommon for people to use multiple solutions for their home automation and security today, and I don't think that's going to change any time soon. I like Arcus as a place to build off of rather than something like OpenHab, as Arcus actually supports the concept of users, permissions, has a reasonably detailed capabilities model, and relies on websockets and event based messaging heavily. There could be a future where Arcus uses OpenHab's zwave controller logic, OpenHab for programming rules, Home-Assistant for ???, and the existing Arcus apps for ease of use for less technical users in a household as well as solving the problems of AAA (authentication, authorization, and auditing).

Share this post


Link to post
Share on other sites

Oh nice, yeah, that sounds like a great idea. Like I mentioned, I haven't used the Iris platform, but user / permissions is something seriously lacking in most of the home automation systems I have tried. It hasn't been a big problem for me since my children are young and my wife isn't interested in home automation. I could see the necessity as my kids get older and perhaps get their own smart phones or other device to control our connected devices. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
1 1