Blog

This is the Blog of the technical experts at GEN and its companies

Leaving HomeSeer for Home assistant

In the ever-evolving landscape of home automation, myriad platforms beckon with promises of smarter, more efficient homes. Among these, my journey began with HomeSeer, a choice influenced by recommendations and its compatibility with my alarm panel, albeit at an additional cost. The initial setup was manageable, and with some effort, I successfully integrated the alarm panel, marking a modest start to my smart home experience.

Over time, my system expanded, incorporating Z-Wave, Sonoff switches, and sensors. However, this expansion was not without its challenges. The Sonoff devices were erratic, often miscommunicating their status to HomeSeer, while my foray into Z-Wave was fraught with issues – devices that would initially function well, only to inexplicably duplicate, rendering my carefully crafted automations ineffective. The lack of a backup option for Z-Wave devices in HomeSeer meant the only solution was a complete reset and reconfiguration of the Z-Wave network, a Sisyphean task that offered only temporary respite.

Compounding these frustrations was the fact that HomeSeer 3 required an active login on a Windows PC – a platform not renowned for its unwavering reliability. Daily restarts became routine, necessitating additional software for auto-login and HomeSeer 3 launch. Yet, even this workaround was insufficient to prevent random disconnections from the alarm panel, the heart of my system, requiring frequent manual intervention to maintain functionality.

The release of HomeSeer 4 brought promises of improvements and a modernized interface. Unfortunately, the reality fell short of expectations. The new version, burdened by a significant upgrade cost, brought more frequent crashes and compatibility issues with previously functional plugins.

By the summer of 2023, my patience had waned. Frustrations with unreliable automations and the tedium of manual overrides led me to explore alternatives. My search narrowed to Hubitat, Home Assistant, and OpenHAB. Hubitat, while competent, was limited by its closed-source nature and support for third-party integrations. In contrast, Home Assistant and OpenHAB offered more promising prospects. After delving into their codebases, I settled on Home Assistant, attracted by its robust third-party support and the empowering nature of its open-source framework.

The transition to Home Assistant was not without its pains. Deciphering the functions of numerous zones, sensors, and outputs from the alarm panel was a daunting task. However, integrating Z-Wave devices with Home Assistant was refreshingly straightforward – a stark contrast to my previous struggles. Similarly, incorporating my Sonoff devices, now running Tasmota, required some manual configuration, but the process was logical and well-documented.

Recreating my automations in Home Assistant was a time-intensive endeavor, yet the platform's power and flexibility facilitated complex, conditional automations with ease. The intuitive interface and support for scripting with Jinja2 allowed for sophisticated, dynamic interactions within my smart home ecosystem.

A week into using Home Assistant, the system's stability and the reliability of its third-party integrations were evident. The dashboards were intuitive to set up, and integrating custom MQTT protocols was straightforward. As I waited for the inevitable hiccup, it never came – Home Assistant operated flawlessly.

Emboldened by this success, I invested in a Home Assistant Yellow, Nabu Casa's flagship hub, to support their ongoing development and subscribed to their cloud service. The transition to this new hub was seamless, encapsulating the user-friendly ethos of Home Assistant.

With Home Assistant, my aspirations for my smart home were no longer hindered. Tasks that were once insurmountable with HomeSeer became feasible. Integrating Alexa for announcements and remote routine triggering, once a distant dream, was now a reality, accomplished with minimal effort.

Six months into my journey with Home Assistant, I felt compelled to share my experience. This narrative is not a critique of either platform but a personal account of my challenges and triumphs in home automation.

Continue reading
  0 Comments
0 Comments

Firewalld on Redhat/CentOS 7 and later

CentOS 7 brings with it a new dynamic firewall interface deamon (firewalld) which allows for a fairly easy configuration of your firewall without having to learn iptables. The firewalld daemon provides a dynamically managed firewall with support for network “zones” to assign a level of trust to a network and its associated connections and interfaces. In reality firewall-cmd is just a front end for iptables and will indeed create and maintain the iptables rules required in your configuration. In a normal configration you would expect to have a local and remote interface, the local being the LAN and the remote either being behind a firewall or NAT'ed. The rules for each would of course be different and so you can create 'zones' with firewall-cmd for Internal and Public (or whatever you want to call them). 

If your using a graphical interface then you can use the firewall-config tool but for the rest of us that live in the shell, the command line interface is fairly easy to use. 

Let's assume you have two interfaces as

eno16777984 = LAN with a private address such as 10.1.1.10

eno33557248 = Public with a public IP such as 8.4.2.1

Now the magic with firewall-cmd is that once you've defined the zones (Internal and Public or whatever you want to call them)

firewallcmd --permanent --add-zone=Internal
firewallcmd --permanent --add-zone=Public

You can then assign some services to those with 

firewall-cmd --permanent --zone=Internal --add-service=ssh

and that's assuming your SSH'ing into the box, you don't want to be locked out. So now let's assign the interfaces to the zones. 

firewall-cmd --permanent --zone=Internal --add-interface=eno16777984
firewall-cmd --permanent --zone=Public --add-interface=eno33557248

and finally a restart of the firewall with 

systemctl restart firewalld

Now you can go ahead an add more services (with --add-service=) or ports with (--add-port=) and setup the rules for your interfaces. If your curious as to how this is configuring iptables then just issue iptables -L to see the rules. You'll find for each zone you've got an IN and OUT, Permit and Deny and your rules are allocated to the correct tables. 

One big tech tip here, for some reason, especially when your changing interfaces, IP's and the whathaveyou, firewalld can sometimes move interfaces between zones. Its rare, but not realising can be bad news especially if it moves the dirty interface into the Internal zone. To ensure your always aware of what zones are on what interfaces locate your .bashrc file (in your home directory - the one you land in when you login) and add a line on the end 

firewall-cmd --get-active-zones

You'll get output similar to 

Internal
interfaces: eno16777984
Public
interfaces: eno33557248

Every time you login so your always aware if an interface has vanished. 

The full reference can be found on the RedHat Site and there's ample community resources too. If you get stuck and need some help then feel free to post in the GENSupport Forum and someone will help you out. 

 

Continue reading
  0 Comments
0 Comments