Ad

Showing posts with label OpenWRT. Show all posts
Showing posts with label OpenWRT. Show all posts

Sunday, January 23, 2022

Rooting the Creality Halot One resin 3D printer

I have finally decided to enter the 3D printing bandwagon. Having room for more hardware have always been the main inhibiting factor for not having done it longer ago. But with a little tidying up of the available space the impossible eventually became a reality. At least that was my reasoning, and the selection of a small resin printer seemed like an interesting choice in that respect, at least in what concerns the space occupied by the device itself.

Sunday, January 17, 2021

Redundant Internet access for your mission critical Home Automation setup

Introduction

When you decide to setup your own infrastructure in order to depend less on cloud providers, whether it be for saving money (depending on what you will be doing) or just for the sake of improving the technical knowledge, having more control, or both, you know you will be flying solo, at least to some extent. 

Wednesday, October 30, 2019

Waking up devices in Hass.io (Home Assistant)


This is a quick post on a challenge I had to overcome while integrating my SmartTV (an LG TV 55UJ620V) with Hass.io.

I wanted Hass.io to be able to turn on the TV (as such allowing automations to be built on top of it, or for example turning it on through a voice command via Google Assistant). As such I first resorted to using the Home Assistant Wake on LAN built in integration (https://www.home-assistant.io/integrations/wake_on_lan/). It kind of worked, but was not very reliable (perhaps 2 out of 5 times it would work).

I knew that by definition, the way that (Wake-up On LAN) WOL is implemented is inherently unreliable: essentially the target (dormant) device is expecting a frame with a specific pattern of bytes. If it receives that frame, it wakes up the host, otherwise nothing happens. The device will normally scan for that pattern of bytes in the frame regardless of the type of transport level protocol it may be on top of. In the case of WiFi in particular, there is the probability (high or low, depending on the network conditions) of that single frame not reaching the destination. This probability increases with the more hops we have in between.

With this Hass.io implementation I was requiring the magic packet to be sent from a host (the Raspberry Pi where I keep Hass.io running) that is in a separate router vlan, from where the TV is (these are connected via Ethernet and WiFi respectively):


Sunday, October 20, 2019

Consumer grade WiFi gear - when fixing the root cause is not at reach

Some time ago, I had to improve the performance and coverage of my home network, so as to be able to use the several devices around the house flawlessly, regardless of the location. Some of these devices have a certain demand for consistent bandwidth, as is the case of the SmartTV for watching IPTV and Netflix, and others such as the smartphones and tablets.

As always I tend to be frugal with spending money in hardware, trying to go with what performs well and is just about enough for the job.

This led me to aim for WiFi gear that would both be somewhat popular and low cost, while at the same time having some hope of being hackable and reflashed to OpenWRT in the future. This was the reasoning when I decided to buy a couple of TP-LINK TL-WR841N routers (with v9 hardware at the time).

At first I set these up and played with the stock firmware, configuring one to play the roles of  NAT, DHCP, DNS, firewall and so on, and the other to act solely as a WDS repeater, allowing WiFi coverage to be extended to the rest of the house.