While checking out an ASUSTOR NAS (the Lockerstor 6 Gen2), I tested various configurations of storage and storage types. As part of that, I set up iSCSI targets for a Proxmox cluster, to enable the use of High Availability.

The previous post covered the creation of the iSCSI Target and LUN on an ASUSTOR NAS, but the concepts are generally transferrable no matter your NAS platform, so pop over there to set your LUNs up before coming back.

This article will show the process of mounting iSCSI storage and creating a LVM (Logical Volume Manager) which is sharable across nodes on Proxmox VE 7.3 through Proxmox VE 8.1, however, the underlying components are stable and these instructions are likely to work on older/newer versions, too.

Open a Shell

Either SSH to your Proxmox node, or log in to the web interface, choose the node, and select Shell.

We're going to edit the file /etc/iscsi/iscsid.conf, so using your favourite text editor, open the file.

nano /etc/iscsi/iscsid.conf

n-comment the following lines (or just paste them again, at the end of the file) and edit to add the username and password you set when creating the iSCSI target.

node.session.auth.authmethod = CHAP
node.session.auth.username = testtesttest
node.session.auth.password = your_password

Save the file, and head to the Proxmox web interface.

Add iSCSI

From the web interface, choose Datacenter -> Storage -> Add -> iSCSI.

You'll be prompted to add an ID (so you can identify the created iSCSI object). The Portal is the IP of the NAS/storage location, and the Target is, unsurprisingly, the iSCSI Target on that device.

You can confirm your CHAP settings are correct if you click the dropdown arrow and the IQN populates in the list.

If you want the target to be available to all nodes in the Datacenter, leave Nodes as 'All', otherwise choose the nodes you want from the drop-down. Leave Enable...enabled.

Use LUNs directly is checked by default, but you'll most likely want to uncheck this. When enabled, a created VM will use the entire LUN as its storage drive, where we want to create an LVM on the large LUN.

Click Add to confirm, and your iSCSI device will now be available.

Add LVM

From the same Datacenter -> Storage page, again click Add, and this time choose LVM.

Enter an ID, and then for Base storage, click the dropdown and choose the iSCSI Target we just configured. Now under Base volume, you'll see the list of LUNs available to us. In this case, there's only one... select it.

Next, name the Volume group. As we're creating one logical volume on the LUN, I've just given this the same name as the ID but appended with -VG.

For content, you can specify whether you want to allow only containers or VMs, but leave as default if you want both. Like with the previous 'Add iSCSI' pane, we select what nodes should have access to this LVM. Select what you previously chose, but leaving as All is most likely what you want. Leave Enable checked, and then check Shared if you want to allow the LVM to be treated as shared storage (i.e. used for High Availability failover).

Once you're happy, click Add. Now under storage, you should see the new LVM, and if you go through to create a VM, when you get to Disks, you should see the new LVM show up!

Potential Issues

If you're adding your LUN to a cluster, you'll most likely need to reboot all but the primary node, otherwise you might see a question mark icon over the iSCSI and LVM options in the Server View, and find that these nodes are unable to connect to the target at all.

Summary

That's it! You've created an iSCSI target and LUN on your Asustor NAS, and you've configured one or more Proxmox nodes to use it as storage (or maybe shared storage) for VMs and containers!

Although this post is specific to Proxmox VE and written from the point of view of using an Asustor NAS, but Synology/QNAP systems are equally viable, or any other storage system that supports iSCSI.

If there's anything I've missed, please leave a comment or let me know at @techbits@fosstodon.org.

While checking out an ASUSTOR NAS (the Lockerstor 6 Gen2), I tested various configurations of storage and storage types. As part of that, I set up iSCSI targets for a Proxmox cluster, to enable the use of High Availability.

This article details how to create iSCSI targets (with CHAP authentication) and LUNs on an ASUSTOR NAS that is running ADM (this process was tested on version 4.2.7.RRD1).

If you're already happy with how to create the iSCSI Target and LUN, you can head straight to the next post: Proxmox: iSCSI LUN as Shared Storage

Storage Manager

After logging into ADM, go to Storage Manager then iSCSI.

Create iSCSI Target

Click Create -> leave An iSCSI target with one LUN selected -> Click Next.

Enter a Target name (useful for identifying the target in future if you have more than one). This becomes part of the unique IQN (iSCSI Qualified Name).

There are also options for integrity checking (CRC / Checksum). Enabling this is likely to drop your network throughput rate to/from a client but with the benefit of reducing the chance of transmission errors. There is some interesting reading on this subject, but I'm going to take the easy way out and say it's outside the scope of this article, but I invite you to read this ipspace post!

Authentication

Next up: Authentication. You should obviously use this. For this example, we're going to use CHAP (Challenge-Handshake Authentication Protocol). To authenticate, we enter the credentials on the initiator (client) configurations when connecting to the LUN(s). Mutual CHAP is where both sides enter credentials for the opposite side.

Create iSCSI LUN

On the next page, we'll create a new LUN and choose a name for it. This will show up on the hypervisor, so giving it a descriptive name is probably a good idea.

If you have multiple storage volumes, select where the LUN should be created.

This provisioning with let you create the full size of your volume without having to allocate the disk space until it is required by the guest operating system. It's usually a good idea to say Yes to this, unless you want to be very sure of the available space for each guest, or you're particularly worried about disk fragmentation (warning: big internet arguments on the pros and cons of this, performance benefits etc. I'm not getting involved. Have a link.)

Snapshot support is worth enabling, as you might decide to use it, but don't have to.
Finally, LUN size - if you're using thin provisioning, you can set a realistic/generous capacity. Then click Next.

You'll be prompted with a final confirmation screen–check you're happy with everything and choose Finish.

Summary

The steps above detail how to create an iSCSI Target (using CHAP authentication) and LUN on an ASUSTOR NAS running ADM. While it's geared towards the ASUSTOR NAS operating system, the theory is transferrable to most other NAS manufacturers (such as Synology and QNAP) and storage systems.

Next up, we'll connect to this LUN from our initiator (or initiators) if we're creating a highly-available cluster: Proxmox: iSCSI LUN as Shared Storage

This is a fairly low-level entry to iSCSI, but if you think there's anything I've overlooked, please leave a comment or let me know at @techbits@fosstodon.org.

Whether you're writing a review of a NAS, are trying to troubleshoot your NAS read/write speeds, or are just plain showing off, it seems that benchmarking the transfer speed of a NAS is a common enough request that multiple vendors provide methods to achieve this.

While it's not strictly (by default) a tool to measure NAS network and read/write speed, iperf3 is a very handy command line tool that can give you a good indication of your system performance, especially if you're trying to compare configurations and improve your setup.

Install iperf3

Getting started on an Asustor NAS is fairly simple. Firstly, head into App Central and search for iperf3, then hit Install. That's it. But...where is it? How do you use it?

Because it's a command line tool, you'll need to SSH into the unit to start the iperf3 in server mode.

Enable SSH

If you've not previously enabled SSH on your NAS, go into Services ->Terminal. Select the box to enable SSH, and if you don't need SFTP, uncheck that box. Then click Apply.

Connect via SSH

Now that it's enabled, you can connect to the NAS with your SSH client of choice using an administrator or equally permissioned account on your NAS.

Run iperf3 Server

Now that you're connected to the NAS, run the following:

iperf3 -s -p 5201 -4

-s tells it to run in server mode. -p allows us to specify the port (it can be anything, but 5201 is common for iperf3). -4 specifies that we're using IPv4, not IPv6.

The server process will keep running until you tell it to stop with ctrl + C.

Run iperf3 Client

On another host on your network , i.e. where you're simulating the NAS traffic from, you'll also need to download iperf3.

You can download it for lots of different operating systems from [here](https://iperf.fr/iperf-download.php). In this example, I'm using Windows 11. After downloading and unzipping the Windows version, open a command prompt as Administrator (right-click the icon -> Run as Administrator). Either change directory to where the extracted program is (cd c:\Users\you\Downloads\whatever), or add the program to your user PATH.

Now run:

iperf3 -c NAS_IP -p 5201

When you hit enter, you should see your SSH terminal to the service, and your client both start running.

Other client options

-t

If you want the test to run for longer, you can use -t to specify how many seconds the transfer should run for, where running a longer transfer might be useful if you're dealing with buffers/caches that might mask your true throughput.

e.g. iperf3 -c NAS_IP -p 5201 -t 30

-F

If you want to specify a file to transfer rather than the stream of made-up data that iperf3 will use by default, use -F c:\path\to\your\file. Bear in mind that you'll want to use a large file to get a better idea of throughput.

-R

This runs the test in reverse mode! The server will send data, and the client receives it. A nice option that means you don't have to change the command on both ends.

Other server options

-F

Just as the client has a -F option, so does the server. -F here will write the received file or datastream to the location your specify. This is where using iperf3 to check the write speed of a NAS comes into play, because you're actually forcing the machine to combine the network and disk write elements in the same process.

Depending on what volumes you have on your system, you'll want to specify the path according to the kind of test you're running (in my example, I have SSDs for volume's 1 and 2, but hard drives for volume 3).

iperf3 -s -p 5201 -4 -F /volume2/testfile

End-to-end test

With the -F option for both client and server, we can technically test the disk read from the client, the network transfer, and the NAS's write, giving us an end-to-end test of the transfer. The downside to this comes back to the file caching, so for multiple tests, you might want to duplicate a large file.

Run multiple tests at once

iperf3 will run multiple times, although you'll need to connect a second/third/as many as you want SSH session to the NAS and run the server commands so they don't conflict with each other.

For example, note the different port numbers and filenames:

### SSH connection 1:
iperf3 -s -p 5201 -4 -F /volume2/testfile1

### SSH connection 1:
iperf3 -s -p 5202 -4 -F /volume2/testfile2

### SSH connection 1:
iperf3 -s -p 5203 -4 -F /volume2/testfile3

### Make sure each client connects to a different port!

Why would you want this? Well, some Asustor units have multiple multi-gigabit ethernet connections, and as they can run in an 'aggregated' mode, that's a lot of bandwidth that you might not be able to maximise from one PC, so using more clients let's you work out the maximum throughput your NAS can handle (even if the process will require you manually starting the session on multiple machines as quickly as possible).

Conclusion

I'm pretty new to using iperf3, but it's been very useful for generating baselines of various networking and NAS configurations. If there's anything I've missed, please let me know in the comments, or @techbits@fosstodon.org.

Systemctl is a command line utility that is used to manage systemd services on Linux systems, and if you don't regularly manage Linux systems, you might find yourself guessing at the syntax before having to look it up.

So if you arrived here because that's you, here are the basics:

Check the status of a service

systemctl status servicename

The output will show the path of the loaded service, whether the service is active (running), where to see the documentation for the service (in the above example the command man cron would load the manual for cron). It will also show the most recent log entries for the service.

Start a service

systemctl start servicename

Stop a service

systemctl stop servicename

Check for failed services

This will list all services that are in a failed state (i.e. they've crashed or errored and stopped). The simple command here is:

systemctl --failed

But this is equivalent to:

systemctl list-units --state=failed

Enable a service

Enabling a service means it will start automatically when the system next starts

systemctl enable servicename

Where as:

systemctl enable --now servicename

The above will enable the service for automatic start on next reboot but it will also immediately start the service too.

Disabling a service

This is the opposite of above–disabling a service will prevent it starting after the next reboot, disable --now will do the same but also immediately stop the service.

systemctl disable servicename
systemctl disable --now servicename

What else?

These are some basic commands, but if there's anything you regularly forget, please leave a comment so I can add it here!

When Apple classes a Mac as too old to receive macOS patches, it's usually a signal to the owner that a shiny new device is in order (if, of course, the owner kept it that long and didn't upgrade sooner).

A lot of the time, however, while the hardware of said device may no longer be performant, it may still be completely capable of running the latest macOS version, if only there was some way of forcing it to install. Oh wait, there is: Open Core Legacy Patcher.

Download OCLP

Installing a too-new version of macOS on your ancient device isn't the point of this article–the documentation from OCLP is pretty good, see here:

No, given that the process for installing includes installing custom EFI bootloaders, performing a major version upgrade was surprisingly less well documented. So, if you're using one version of macOS thanks to OCLP, and want to upgrade to another (specifically, Sonoma), here's a good place to start.

Download the latest version of OCLP (this is important as the newer macOS versions may have specific fixes or support for newly deprecated hardware).

Download the macOS Installer

Choose Create macOS Installer then Download macOS Installer if you haven't got the latest version downloaded already.

Create a bootable USB drive

Once downloaded, you'll be prompted to select a USB device to turn into a bootable installer.

You'll be prompted for your password, and once you've confirmed you want to override/reformat your USB stick, OCLP will start building your USB.

It says it can take over 30 minutes, and it's really not lying. Go and make some tea or something while you wait. Maybe walk the dog.

Install OpenCore to USB

Once the process is complete and verified, OCLP will ask if you want to install OpenCore on the stick. This is what allows what would otherwise not be able to run on your hardware to start up anyway, so choose Yes. It will build and ask for confirmation to Install to disk.

Boot from the USB installer

Now you can reboot your Mac, holding option/alt when it boots. You need to choose the USB stick's EFI option here, and then on the next screen, choose the install macOS option.

Begin the installation

Once in the macOS recovery/install view, choose the 'install macOS' option to begin the upgrade. Choose to install it over the existing drive and it'll automatically know it needs to upgrade the installation, so don't go into Disk Utility or fiddle with the disk/partitions at all.

Once the installation begins, it will reboot a couple of times, and when it does, you'll need to make sure to hold option/alt on start-up so you can choose the external USB EFI partition again. Once in the EFI parition, choosing the macOS option instead of install macOS should be fine, as it'll know to continue the install.

Install OpenCore to disk

Once finished and booted back into macOS, you may (should?) get a prompt from OCLP to say that you're still booted from the USB EFI parition, and ask if you want to install to the internal disk. Choose OK, then Install to disk.

Once done, shut your Mac down, remove the USB stick then boot it back up. It should automatically make it back to the Desktop without requiring any manual intervention.

Post-Install Root Patch

I didn't need to run this, I assume OCLP handled this as part of the OpenCore step previously.

To confirm, choose the Post-Install Root Patch option and it will check to see if anything is required, so install these if required.

A Log Aggregator or Log Management system allows you to delve into system and software logs for many machines, or create alerts for particular issues for all hosts in one place, rather than individually on each system.

This makes identifying issues/faults easier and faster, and allows you to create alerts and pre-empt future problems.

Aside from the sysadmin's 'software broken, must fix' point of view, this has security benefits as you can use this data to establish system baselines and identify anomalies more easily as a result.

The last benefit, specifically in the context of Proxmox and virtualisation: If you're writing logs pretty constantly, that's disk I/O that could be used better by your VMs or containers. Or perhaps you want to network boot your VM compute nodes, write logs to one location, and use network storage for VM/containers.

This post will cover configuring Proxmox VE 8 (and actually, VE 7 or pretty much any Debian-based system) to send syslogs to a remote syslog server.

Prerequisites

Before proceeding, ensure you have:

• A running Proxmox VE 8 server (or other applicable Debian system).
• Access to the Proxmox VE web interface or SSH.
• A remote syslog server (e.g., Syslog-NG, graylog) that is configured to receive logs over the network.

Configuration Steps

1. Accessing Proxmox VE

Log in to your Proxmox VE server via SSH or through the web console. If you're using SSH, the command might look like this:

ssh root@your_proxmox_server_ip

2. Configuring Rsyslog on Proxmox VE

Proxmox VE uses rsyslog for managing system logs. You will need to configure rsyslog to forward logs to your remote syslog server.

Edit the Rsyslog Configuration

Open the rsyslog configuration file in your preferred text editor, such as nano or vim:

nano /etc/rsyslog.conf

Add the Remote Syslog Server

At the end of the file, add the following line to forward all logs to your remote syslog server:

*.* @your_syslog_server_ip:514

The *.* specifies that logs of all 'facilities' and levels should be forwarded. The @ symbol followed by the IP address (or hostname) and port (514 is the standard syslog port) tells rsyslog where to send the logs.

If your remote server is using TCP instead of the traditional UDP, use a double @@:

*.* @@your_syslog_server_ip:514

Save and Exit

After adding the remote syslog server configuration, save the changes and exit the text editor.

3. Restarting Rsyslog

For the changes to take effect, restart the rsyslog service on the Proxmox VE server:

systemctl restart rsyslog

4. Verifying the Configuration

To ensure that the logs are being sent to the remote syslog server, check the logs on the remote server. The specific steps for this will depend on the syslog server you're using.

Conclusion

Setting up Proxmox VE to send syslogs to a remote syslog host is a straightforward process that enhances your log management capabilities. By centralising your logs, you can more easily monitor all activities within your virtualised environment, leading to improved performance and security.

Remember to regularly check your syslog server to ensure that it's correctly receiving and storing logs from your Proxmox VE server(s)! It's pretty useless if you're shipping logs elsewhere just to realise that your syslog server ran out of your space months ago...

While testing out OMV on a variety of hardware, I was looking to install the openmediavault-flashmemory plugin (to decrease the wear of the USB onto which I'd installed OMV - the pSLC drive from SwissBit).

I've played around with OMV previously, but I'm not comfortable enough with the system to remember much from before. So when I went to plugins, and searched for openmediavault-flashmemory, I found nothing. Eventually, I recalled having to enable something to be able to add community plugins to OMV.

From the command line (or via SSH), run the command:

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Once finished, back in the web interface, a quick Ctrl + Shift + R will make omv-extras show up under the Plugins menu option, and now Plugins will include all of the extra plugins not previously available.

Everything is easy when you know how to do it, right?

I wrote a few posts (and scripts) last year focused on Mastodon, how to install it, and various surrounding ideas, which were all based on what I'd learnt while creating and running my own instance. A year or so later, and while running the instance was a fun project, the cost and time required for very little benefit (a single user instance) led me to decide to shut the instance down.

I've already migrated my account to fosstodon.org/@techbits using Mastodon's mechanism to notify/move your followers to a new account, and while I'm sure there aren't many hits to the previous URL, it seems like bad practice to shutter a service and not at least redirect users.

As it's a single user instance, I want to redirect all traffic to the domain, and using Cloudflare's free redirect rules or page rules, this is very easy to do.

Enable Proxy

The caveat to all of the following steps is that traffic needs to run through Cloudflare for the rules/redirects to take effect. Cloudflare can just be used for DNS entries (and there are times where you might want to just use this) so if the page rules/redirects aren't working, make sure you see orange 'proxied' icon for the domain A record.

Redirect Rules

Within the section for that domain in the Cloudflare console, choose Rules -> Redirect Rules, then 'Create Rule'. Name the rule and choose 'All incoming requests'. Set the redirect to 'Static'. Enter the URL to redirect to, set the status code to 301 and click 'Deploy'.

All traffic will now redirect to the new account. If I want to specify a different redirects depending on the destination (i.e., my account URL redirects to a different location than the root domain) then you can use Page Rules...

Page Rules

Instead of Redirect Rules, a Page Rule can be used to either the same effect, or for more granular control.

For a simple redirect, under Rules, choose Page Rules -> 'Create Page Rule'.

For the URL, enter yourdomain/*, e.g. example.com/* and then in the settings box, choose 'Forwarding URL'. Set the redirect status code to 301/302 as appropriate, and set the destination address to your new location, then click 'Save and Deploy Page Rule'.

Multiple Page Rules

As Cloudflare gives you 3 page rules even on a free account, you could create multiple rules. Realistically, I only need to redirect visits to @techbits and direct post links to the new Mastodon account. Anything else I want to redirect elsewhere (I may even redirect to this post, because, why not?)

To do this, create two rules: One for example.com/@youraccount* to the new account, and then another for example.com/* to the alternate location. If you create them in a different order, make sure to change them so the more specific rule is triggered first, otherwise everything will get picked up by the broader rule.

What next?

With this rules in place, I can decommission the server without worrying about inbound traffic. The next step is to create a Ghost rule to rewrite all of the instances of the old url/account to new!

If there's anything I've missed/messed up, please let me know in the comments, or send me a message at @techbits@su....oh yeah... @techbits@fosstodon.org or @techbitsio.

The built-in Windows Snipping Tool isn't a bad utility. On the contrary, when you're using an unfamiliar system, knowing that a tool like that is there by default is great. The problem comes when you are using something else on your main system, and you want to re-map the default Snipping Tool shortcuts.

Both Win + Shift+S and the Print Screen key will trigger the snipping tool capture by default, but Windows seems to be extremely obnoxious about letting you use these keys for another purpose.

Uninstall Snipping Tool

Windows, weirdly, does allow you to uninstall Snipping Tool. Just go into Programs & Features / Installed apps, find Snipping Tool, and choose uninstall.

Once you've done this, however, the crosshairs still show up when you use the Win + Shift+S and the Print Screen shortcuts.

Disable Snipping Tool 'Print Screen' Shortcut

To remove the Print Screen <> Snipping Tool link, hit the Windows key and search for print screen. Choose the option that will take you into System Settings > Accessibility > Keyboard, then uncheck  'Use the Print screen key to open Snipping Tool'.

Disable Win + Shift + S Shortcut

Finally, disabling the other Snipping Tool shortcut will prevent the pointless crosshairs from triggering if we use that old shortcut by mistake.

Open the registry editor (Win + R > type 'regedit', hit enter). Click 'yes' if you see the UAC prompt.

Navigate to Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced, and in the pane on the right, right-click, and choose New > String Value.

Name the new string DisabledHotkeys and set the value to S.

Click OK, close the registry editor, and give your computer a reboot.

Capturing with another utility

After this, other screenshot utilities should be able to map to the Print Screen key, although this isn't a complete fix as with Snagit for example, the Print Screen key can't be mapped to a specific saved workflow (you can map other shortcuts to these, but not Print Screen or Win + Shift + S), but it instead runs the workflow that was run last. For the most part, this works pretty well, but it should be easier to make Windows relinquish control of shortcuts like this.

If there's anything I've missed, or if you use a product like this, please let me know in the comments, or send me a message at @techbits@sudo.cat or @techbitsio.

Swissbit very kindly sent me a sample of their 16GB U-56n pSLC (pseudo-SLC) industrial flash drive to review, which on the face of it, seems odd for a website that is aimed at tech enthusiasts.

But bear with me here, it could be a worthy investment for a home-lab application where the corruption of a memory stick or SD card would mean hours/days of rebuilding a system.

SLC, MLC, TLC, QLC?

Traditional SLC (single-level cell) NAND flash drives are extremely expensive/low capacity (or a combination of the two) due to the fact that only one bit of data is stored per cell. Compare this to MLC (multi-level cell), TLC (triple-level cell) and QLC (quad-level cell) technology found in newer generation 3D NAND packages where multiple (two), three and four bits can be stored per cell, and you see that the capacity of these options increases dramatically while the cost decreases. So why would anyone use SLC? The answer comes down to reliability, performance and data integrity.

While the performance of SLC is theoretically faster than the others, it's generally not produced in high enough capacities to compete with products aimed at performant applications, but at a theoretical level: it's faster to write data to a single-level cell than MLC/TLC etc.

Instead, the appeal of SLC is the expected lifespan and data integrity that it offers. For example, you might expect around 50-100,000 write/erase cycles for SLC cells before encountering errors, but only around 3,000 write/erase cycles for MLC, and 1,000 for TLC.

What is pseudo-SLC?

pSLC is a way of using MLC or TLC chips but only using 1 bit per cell, thereby increasing performance, data reliability/integrity and the product's lifespan (total write/erase cycles).

By implementing NAND vendor-specific commands and algorithms in the Flash controller firmware, 3D TLC NAND can be operated in 1-bit pSLC mode where endurance and performance behaviors are in line with native SLC NAND. SMART’s pSLC technology is designed to optimize the balance between cost and performance.

-- SMART

As the storage device's controller is aware that it's using MLC/TLC, it is able to optimise reads/writes and use other functions such as wear-levelling to ensure that the cells are equally used over time to prolong the lifespan.

That expected lifespan falls between that of true SLC and MLC. SMART's own example suggests that with a SLC device of 60,000 write/erase cycles and 3D TLC of 3,000 write/erase cycles, pSLC would come it at around half of SLC, but 10x greater than 3D TLC, at 30,000 write/erase cycles.

While TLC NAND flash is typically only designed for 3,000 programming and erase cycles, the same memory in pSLC mode achieves 30,000 cycles with the previous flash generation and even up to 100,000 cycles with the most current flash technology.

-- Swissbit

Swissbit's implementation of pSLC is using TLC, and from their information on how they use it (available here):

• "pSLC can be read twice as fast as TLC and written at six times the speed."
• "The combination of the extremely high number of cycles and the smaller page size results in a lifetime that is rarely exceeded by an application."
• "By storing only one bit per cell instead of three, the capacity is reduced by a third or three times the amount of flash must be used. The service life, on the other hand, increases by up to 33 times."

SLC vs pSLC

So if SLC is so great, why buy anything else? It generally comes down to cost, and to an extent, availability (there's not a great deal of demand, so most memory manufacturers don't produce it).

Swissbit does still manufacture some SLC products: The U-500k comes in a few different capacities, but for a 16GB stick, the price is around £210-250 (finding availability is hit or miss). In contrast, the pSLC U-56n 16GB is more readily available and costs around £72-84.

This is a very high cost for a relatively low capacity and so wouldn't replace a cheaper stick you might use for occasionally moving documents around, but it's all too easy to grab an SD card or memory stick from a drawer when setting up a Raspberry Pi, a mini PC/NAS or some other home-lab application, with absolutely no thought to how long that stick might last with constant log file writes, or some default SWAP space you forgot to turn off.

The U56-n

Ok, that was a lot of explanation. Thank you for either sticking with me or just skipping to this point.

The U56-n is available in 4GB, 8GB, 16GB and 32GB capacities. Each capacity tier has a Commercial operating temperature range (0°C ~ 70°C), and a more extreme Industrial range (-40°C ~ 85°C). Swissbit sent me a 16GB Industrial stick (the exact product SKU: SFU3016GC2AE2TO-I-GE-1AP-STD).

The stick itself is very small, measuring 24mm x 12.1mm x 4.5mm. It has a brushed aluminium finish and a green indicator LED inside the keychain loop.

It has a USB-A (USB 3.1 Gen 1 SuperSpeed) interface, and Swissbit advertises the performance as being:

• Sequential Read up to 197 MBytes/s, Random Read IOPS up to 3,850
• Sequential Write up to 126 MBytes/s, Random Write IOPS up to 2,600#

In terms of endurance, it can withstand 697 TBW (terabytes written) for sequential writes, or 42 TBW for random 4KB writes. Bearing in mind the capacity is far less than even 1TB, this works out at around 43,500 and 2,625 write/erase cycles of the entire 16GB capacity respectively.

Swissbit also promises data retention of 10 years at the beginning of the product's life, and 1 year when it's at the end of its life.

When talking about a product that is designed to last longer than the system it's running, mentioning the warranty seems silly. Of course, some products will just fail due to manufacturing defects. Swissbit offers the Industrial U56-n with a 3-year warranty (or to the 'TBW' endurance limit–whichever comes first). It should be noted that when you buy something from a company/vendor that primarily deals with business/industrial sales, you might find that returns/RMA processes are slightly less friendly than they would be from a consumer-oriented equivalent.

On that note, the packaging really highlighted the industrial nature, but you know what? I'd love all devices to be packaged like this. Keep the device safe, avoid unnecessary plastic, and keep the total size down.

Performance

The measurables line up with the advertised 'up-to' read/write speeds, and over multiple runs, the device is very consistent.

Aside from benchmarks like the one above, I got a feel for the device by running it in a couple of test systems. First, as the boot device in an Intel NUC running Proxmox VE, and then as the boot device for a Raspberry Pi NAS.

When setting both of these up, I initially skipped any optimisation steps (writing log files to a separate disk, disabling SWAP space, etc.) and ran them for a week or so. While this isn't a very concrete test, the system felt fine, responsive, and it didn't ever have to wait any noticeable time for files to load.

After running it like this, I enabled the aforementioned optimisations (and for Proxmox, setting a different disk as the primary location for ISOs, files etc.) for no other reason than it being good practice.

This period of testing didn't provide any revelations about the U56-n... Its performance is good, and my data felt safe(?). Unfortunately, there's no way of testing the lifespan claims without deliberately writing (and tracking) a lot of data.

I do, however, still have it running in a test box, so will update if I have any other observations to share.

So why do I need one?

If you run any sort of home lab (whether a bunch of servers, mini PCs, or even a Raspberry Pi or two), there's a good chance that after setting something up, you've come to rely on that system enough to consider what you would do if it fails.

There are plenty of good examples of this, but I'll use Home Assistant as an example. Plenty of people have bought a Pi, grabbed an SD card that they had laying around, and installed Home Assistant. You only start with Home Assistant to mess around and play with it, right?

But then, oh look, you've found lots of devices are compatible, added them, and started creating cool automations. These are so useful that you've introduced the rest of your family/pets to them, and before you know it, this is a system that you can't do without.

Did you check the advertised lifespan of the SD card? Do you know how many write/erase cycles it can sustain before you might encounter corruption?

You know you should back up the system regularly, and you keep telling yourself you'll set it up soon, but wouldn't you know it? The system crashed and the last backup was from 6 months ago.

This is obviously an exaggerated scenario, but the Home Assistant forum regularly has people trying to deal with the fallout of a corrupted SD card/flash drive. That the RPI 4 can USB boot allows people to use higher quality drives, but if that's a TLC/QLC drive, it's still a drive that's not designed for an always-on application. A traditional spinning disk is a good option for reliability, but at the cost of read/write speed (and the size of the disk, of course).

I'll also add that the reliability of industrial products like the U56-n doesn't make the inverse true: cheap devices won't necessarily fail. You could run a system from the cheapest no-name SD card and not encounter issues, only that your chances of that happening are significantly higher.

Price

The price for this exact model is around £84. Due to the nature of the industrial/commercial target-market, you'll only find prices listed without VAT (around £70). You can find this at Digikey and Mouser.

Final Thoughts

Score: 5/5*

*This is a difficult product to rate, but I'll revisit this once I've given it even more testing.

Would I recommend this product? Yes. Would I recommend it for everything? No.

If you're just getting started with running a system on an old PC, NUC, Raspberry Pi, there's nothing wrong with using what you have on hand. The point where you should consider this (or a product like it) is when you start heavily relying on the system. I've already mentioned Home Assistant as an example, but as another: a lot of people run AdGuard Home or PiHole on a Raspberry Pi, but when you force everyone connected to your network through a device like this, the outage is pretty significant when the card/USB stick dies (especially as you're going to need the internet to fix it!)

If you do start to use a more reliable device like the U56-n, you should also regularly check the S.M.A.R.T. statistics to see what the total TBW is at (and while you're there, see if there are any unexpected errors)! If you've somehow made it to the end of the usable life, you should continue replacing it–if this is you though, you've already experienced the reliability benefits that I'm trying to push!

As a side note, Swissbit also produces products aimed at data security, not just data integrity/reliability, so if you need a device with locked (or hidden) partitions, take a look at their website.

If there's anything I've missed, or if you use a product like this, please let me know in the comments, or send me a message at @techbits@sudo.cat or @techbitsio.

If you're new to Virtualisation, Proxmox Virtualization Envionment (Proxmox VE) is a great introduction to the world of Hypervisors. It's an open source server management platform with an intuitive web interface. You can run Proxmox on a single relatively low-end system (think an old PC, or an Intel NUC) or you can run it on multiple boxes and create your own home computing cluster!

Not only can you run virtual machines, but you can also run Linux Containers (LXC) for lower resource/footprint requirements.

If you've not already got Proxmox running, I'd suggest downloading the installer, copying it to a USB stick (using something like Balena Etcher), and following the instructions - install it, play around with it, break some things, then install it again to fix what you've broken. I may come back to the installation process in future, but it's fairly intuitive to get started.

For this post, we're assuming you already have Proxmox installed and you want to get Home Assistant up and running as a virtual machine.

Once you've logged into your Proxmox server's web interface, you want to find the Shell option. If you have multiple servers in a cluster, click on any server, then shell:

In this window, paste (Right-Click > Paste, or Ctrl + Shift + V) the command below and hit enter:

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/vm/haos-vm.sh)"

Follow the prompts, and if you stick to the simple setup, it's only a few steps:

1. "This will create a New Home Assistant OS VM. Proceed?" - I mean, yes. Choose yes:

2. Default Settings are probably fine for most people, but for the full list of Advanced options:

3. Select where the VM's disk will be stored (arrow keys to move up and down, space to select, tab to move down to OK/Cancel):

4. Wait for the script to download the Home Assistant OS image file:

5. Wait until you see the 'Completed Successfully!' message:

6. If you go back to your Proxmox web interface and click on the newly created VM, you'll see an information box which includes the new VM's IP (if it has managed to get one via DHCP. If it hasn't use the VM's shell to set the IP):

7. Take IP and go to http://<ip-of-new-vm>:8123 and follow the Home Assistant setup steps, either to setup a new install, or to restore an existing backup:

What next?

That's it for this setup. It's a pretty quick way of getting Home Assistant setup on a Proxmox VE host, but the real star of the show is the script from tteck, and I know I've already said it once, but I'd highly recommend looking through the other available scripts to see what else you might want to install!

If you notice any issues with this post, please leave a comment to let me know, or message me at @techbits@sudo.cat or @techbitsio.

I recently signed up with a new broadband provider (Cuckoo Broadband - review on the way) with one of the benefits being support for multiple static IPs–see my last post on configuring these on the UniFi Dream Machine Pro:

Set Static IPs on the UDM-Pro

This guide will show you how to add one or multiple static IPs to your Ubiquiti UDM-Pro (or other compatible UniFi product).

techbits.iotechbits

Once I had these setup, I wanted to be able to ping these over the internet, firstly to test they were all working, and secondly so I could continually ping what I was going to use as the 'main' internet IP with a Broadband Quality Monitor (@ thinkbroadband.com).

The layout of the firewall pages and panes has changed a bit over the years, with there now being greater control over the source and destination (or in the case of pings, using Internet Local to designate that the destination is the UDM-Pro itself).

Internet Contains IPv4 firewall rules that apply to the Internet network.
...
Local Applies to traffic that is destined for the UDM/USG itself.

-- UniFi Gateways - Introduction to Firewall Rules

From the main page of your UDM-Pro (or other compatible UniFi device/cloud-key) go to Settings -> Firewall & Security ->Create New Rule:

Set the Type to Internet Local and enter a descriptive name for the rule (no really, you'll thank yourself in future). Leave the default of Before Predefined Rules unless you have a specific reason to change it. You obviously want the action to be Accept.

Set the IPv4 Protocol to ICMP, and the IPv4 ICMP Type Name to Echo Request.

You can leave the source as Any unless you know the specific address you want to be testing from. If you have a cloud server setup to monitor devices, you could set the Source Type to IP Address and specify the address, therefore allowing only you to monitor, but ICMP is deemed to be a fairly low risk protocol to leave open, and if the monitoring service has multiple/unknown sources, you don't have much choice here.

For the destination, you want to set whatever your external IP is. You could leave this as Any (and you might have to if you don't have a static IP, but a dynamic/changing IP) but in general, a more specific rule is better. In my example, where there are multiple IPs, I ultimately only want one IP to respond to Ping requests, so I've specified that destination IP. During testing, I left this as Any so I could ping all 4 addresses.

Once you're happy with the rule, click Apply Changes and it will take effect.

To test it, you can ping from something like a cloud server, or you can download a Ping-type app. I used 'Ping' by Michael Frohlich. Remember to disable Wi-Fi if you're on the same network at the static IP (although I had to be on 4G to successfully ping–3G didn't work for me), enter your IP in the app, hit the play button and confirm that you get the green replies.

That's it! You can ping your IP from the internet. What next? You could set up an internet quality monitor or use your own cloud server to monitor it.

If this has helped you, please leave a comment. I'd be especially interested in what you're using to monitor your network health below, at @techbits@sudo.cat or @techbitsio.

I have recently signed up with a new broadband provider (Cuckoo Broadband - review on the way), one which offers some pretty cool features for a home internet provider. Well, one cool feature: static IPs. Yes, IPs - plural.

Previously, the only ISP that I was aware of that offers even one static IP (and I believe still does) is Plusnet. However, because Cuckoo uses TalkTalk Business broadband for its services, it seems that Cuckoo is happy to enable this service for customers.

Talking to their very helpful customer support team before signing up, I found out that they offer 1 IP or blocks of 4, and however many you choose, they cost £1 each per month. I have a few ideas for projects, and figuring that the first IP will replace the DHCP address of the modem/WAN interface, I went for 4.

There's no option to sign up for this in the Cuckoo account, you have to ask the customer support team to add them to your account, but within a space of a couple of hours, the very helpful James provided me with a /30 CIDR block.

On the UDM Pro, setting the IPs is fairly straightforward: Login to your UDM (or cloudkey if you're using something other than a UDM/Pro), go to Settings -> Internet, then select the WAN interface you want to add the static IPs to.

Scroll down until you find Additional IP Addresses (almost at the bottom). Here you can add an IP, or a range–I tried entering as a range and kept getting "IPv4 CIDR range is not valid". Both of these options require addresses to be entered in CIDR block formats (if you had 4 non-sequential IPs, you'd enter them as ipaddress/32).

Enter each IP, or the range and click add for each one. Once done, apply the changes.

The change should be pretty instant, and to check, from your local network, ping the added IPs (you're accessing them locally, so they should all ping):

PS C:\Users\techbits> 172..175 | % {ping -n 1 -w 20 172.16.16.$_} | Select-String -Pattern 'Reply from'

Reply from 172.16.16.172: bytes=32 time<1ms TTL=64
Reply from 172.16.16.173: bytes=32 time<1ms TTL=64
Reply from 172.16.16.174: bytes=32 time<1ms TTL=64

Only three responded, so I went back in and changed the addresses to 2 /31's, which seemed to do the trick:

PS C:\Users\techbits> 172..175 | % {ping -n 1 -w 20 172.16.16.$_} | Select-String -Pattern 'Reply from'

Reply from 172.16.16.172: bytes=32 time<1ms TTL=64
Reply from 172.16.16.173: bytes=32 time<1ms TTL=64
Reply from 172.16.16.174: bytes=32 time<1ms TTL=64
Reply from 172.16.16.175: bytes=32 time<1ms TTL=64

What next?

That's all there is to it! If anyone can explain why the /30 range didn't work, please leave a comment or let me know at @techbits@sudo.cat or @techbitsio.

Next up will be some cool little projects where you can utilise these static IPs, so check back soon.

SwitchBot recently contacted me asking if I wanted to test their new Blind Tilt product for the purposes of a review, as well as show off the installation process and the quite fully-featured Home Assistant integration setup.

It should be noted that they sent me the hardware for this review and the associated how-to's, plus some other devices for me to potentially discuss in future Home Assistant posts.

Final disclaimer before getting started: I'll mention the Hub Mini in this review, purely to discuss the cloud control functionality.

What is the Blind Tilt?

The Blind Tilt is a retrofit blind controller, suitable for wand-controlled tilt blinds. The main unit is 48.8 × 29.2 × 144.2 mm, weighs 130 grams, and is available in both black and white options.

It's a battery-powered rechargeable device, sporting a 2000 mAh lithium battery. SwitchBot claims up to 10 months of use per charge, and if I extrapolate from my testing, I think you'd hit that with normal use. However, the battery life is a bit moot, as in the box is an included solar panel which you can feed through the blind and stick to the window. If you choose not to install that, you can track battery life through the app and then connect a USB-C charging cable when (infrequently) needed. The battery itself is an 18650 cell, which could be replaced if it becomes faulty.

The Blind Tilt uses Bluetooth to communicate (specifically, long-range BLE 5.0, to maximise range and battery life), and while you initially have to connect it to an Android or iOS device, you then have the option to control it via one of the SwitchBot Hubs (Hub Mini or Hub 2), or directly from Home Assistant. To recalibrate the device (which you'll probably need to do a couple of times, and anytime in the future if you find the wand has 'slipped') you'll always need to do this from the app.

What is Included?

Given the nature of retrofit devices, manufacturers have to expect a wide variety of blinds (e.g. size of headrail, diameter of control wand, spacing between pull cord and wand), and to their credit, SwitchBot appears to have anticipated a lot. This is demonstrated volume of included accessories and adapters. For example, there are two different mounting adapters, and if neither of those fit to the left of the control wand, you can reverse the whole product and fit it to the right.

The full listing of included parts (also shown below) is:

• Blind Tilt Unit, Solar Panel
• Open Flex Coupling, Mounting Base A & B, Base Cover, Cord Holder
• Adapter with Adhesive (S/M/L/XL)
• User Manual, Measurement Paper Tape, Alignment Card, Adhesive Stickers
• Wet Wipe, Type-C Power Cable, Ejection Pin, Spare Double-sided Tape

How Easy was Installation?

I'm not going to go into the whole process here, but I'd recommend skimming through the process in my 'getting started' post, linked below.

I took my time as I needed to take photos throughout, but the whole process didn't take long (I'd estimate it took me 20 minutes). I didn't follow the manual exactly–it advises you download the app first, then guides your installation showing the manual and an install video in-app–instead I went ahead with the physical installation first. Had I watched the helpful video, I wouldn't have hesitated when it came to sticking the bits with 3M pads.

The included tools are simple and appropriate for the task: The included wand-measure tells you which size adapter to use, and the alignment card dictates where on the wand the adapter should be affixed.

The SwitchBot App

My overall impression of the app is good. It's well designed, and if you were using it as a point from which to control your home devices, it would allow you to do this without being too invasive. My only point against this is the fact that one of the bottom tabs is a link to the SwitchBot store... A link somewhere in the app would be fine, but if people are using the app, they've already bought some devices, so this tab could certainly have been used for a much more appropriate option (an overview of schedules, perhaps?).

The UI of the Blind Tilt in particular is very well executed–the background animation of the blind opening makes the experience feel very polished.

One area where I found the app to be a little confusing was when trying to set a timer for the Blind Tilt. It seems to re-use the code from the 'Schedule' option, and prompts with 'At Time'. The Hour & Minute wheels run for up to 24 hours, so again, you get the impression that you're setting a one-off time for the blind to open/close, but once you've set it, you realise that the timer has begun to count down. It's minor, and I'm sure can be addressed.

On the subject of scheduling: The light-sensing capability is a nice idea to supplement a fixed schedule, but the values I see in the app don't ever seem to change. I've reached out to SwitchBot to see if there's something I'm missing.

Blind Tilt + Hub

In my opinion, the Hub Mini tries to do too much. Being able to act as a relay between Bluetooth devices, but also acting as an infrared blaster means that to fully utilise the features, you'll most likely need a hub per room with IR-controlled devices. Because you might need multiple hubs, SwitchBot have designed a system where all of the hubs talk to the cloud and are managed from your SwitchBot account (meaning the app talks to their servers, rather that directly to the devices–if you're out of Bluetooth range, anyway). It would've been nice for all hubs to be aware of each other, allowing any to act as a main controller, but the specifics on the hub is outside of the scope of this review

The other concern with the Hub Mini is that once you've added it, you can't disable remote control, even if you only wanted the IR blaster functionality. Even though by default, cloud services are disabled on each of the other attached devices like the Blind Tilt (SwitchBot defines cloud services to be Google Home, Alexa, IFTTT etc. - they don't include their own cloud within that definition).

If your plan is to use a Blind Tilt with something like an Amazon Echo, or Google Home device, then this isn't an issue, and would be required to function, but I guess my gripe is the fact the functionality can't be disabled.

Blind Tilt + Home Assistant

Now this–in my opinion–is where things get interesting. I have long been sceptical of any home automation/control device which uses Bluetooth, partly thanks to the historic latency, battery and useability issues associated with the protocol.

When Bluetooth Proxies were added to ESPHome and Home Assistant towards the end of last year, I didn't pay too much attention, thinking I'd never have a need to investigate, and that while the proxies might make things easier, you're still stuck with the inherent Bluetooth issues.

However, I was proved to be completely wrong! After digging out an esp32 from a drawer (bent IO pins and all) and configuring it as a proxy in ESPHome, the SwitchBot integration with Blind Tilt device instantly showed up in Home Assistant under available integrations. Once I paired and configured the device, it just worked. Throughout my testing, there wasn't a single occasion where the device didn't respond, and the response time was pretty low throughout (only a couple of times did I have to wait more than a couple of seconds for it to start opening/closing).

I've no doubt that this seamless functionality is down to the Bluetooth Low Energy 5.0 radio, but this is where one of my concerns around security comes from. BLE has 'advertising' channels, where it can broadcast data without needing an active connection between the device and the receiver. This seems ideal for a device containing multiple sensors, as it can keep broadcasting updated information without having to use more power than necessary. The concerning side of this is that, after more testing, I was able to add the device to Home Assistant without pairing the device at all. I should clarify: I couldn't control the device without pairing it–it just didn't respond–but I had access to all of the sensor information (light level, open/close position, battery level). You might not mind your neighbours being able to see devices like this pop up in their own smart home system, but it's definitely a good reminder of the benefits & limitations of the protocols being used.

Security concerns aside (for now), after I added the device to Home Assistant, the functionality was good. The only minor wrinkle was the default behaviour of 'cover' devices in Home Assistant where it expects only two states: Open and closed.

Because the Blind Tilt can close up and close down, it means that 0% and 100% are closed, and 50% is open. This messes with the logic a bit, but with a combination of using a template cover (more details on my Home Assistant-specific post here) to ensure it always closes one way and calls to the service, you can end up with the control functionality you want. This is more of a limitation in Home Assistant, and the information you need is also listed on the SwitchBot Home Assistant integration page.

Performance

The Blind Tilt always responded when I manually set the blind to open or close. There was an occasional delay, as my phone or the hub had to communicate with the device (more expected with the hub being controlled via the internet), but nothing that was unreasonable. Performance from Home Assistant always seemed to be better (the Bluetooth proxy I was using was of the Wi-Fi kind too, not the recommended Ethernet variety, so it seemed like a real-world test).

As mentioned, the battery life appears to live up to SwitchBot's claim of 10 months (of course, this is extrapolated). Ignoring a potentially faulty battery, I doubt anyone will experience problems with battery life.

I thought I'd prefer it when I enabled Silent Mode, but I don't think it made much difference. I eventually convinced myself that it was indeed a bit quieter, but that could've been down to the slightly slower motor speed (therefore lower pitched sound), but I just got used to the noise and it didn't bother me at all.

I did experience the geared coupling slipping inside the wand casing at one point (causing an alarming groaning noise and my blind tried to close further than 100%). I put this down to not quite aligning things, although it did all appear to be correct. After re-seating the wand coupling and recalibrating, everything worked fine.

How Much Does it Cost?

In the UK, the Blind Tilt retails for £69.99 ($69.99 in the US) via the SwitchBot website, or through Amazon. Both seem to offer 15-20% discounts (at the time of writing, Amazon is offering 15% off the price of one device and SwitchBot offers 20% off when you buy at least two devices).

Given the contents of the package and that the solar panel is included, the price doesn't seem excessively high. It would be expensive to retrofit an entire house, but significantly less to do that than replace all blinds with motorised equivalents.

The design is fairly simple and compact, so it'll blend in fairly well in most environments. The build quality feels quite good, so perhaps goes some way toward justifying the cost, but I do wish that all of the regulatory and product information was hidden away inside the wand casing/latch. It seems silly to say after generally praising the device, but if I had to mount the device backwards (which you may depending on the layout of your blind), I would've hated seeing the obvious grey text. There surely has to be a better place to put this information, or a more subtle way of including it.

Summing Up

Upon reflection, the Blind Tilt might suit a few different target groups:

• People wanting to create fixed schedules for blind opening and closing. Maybe with a fancy light-sensing rule thrown in. This group could buy just the Blind Tilt and achieve everything right out of the box.
• People wanting to control their blinds from a service that utilises cloud-based connections, such as Google Home, Amazon Echo (even Samsung SmartThings seems to be supported). This group can buy one or more hubs to accompany the Blind Tilts, and with little effort, integrate their blinds into an existing ecosystem.
• People wanting to control the device directly from Home Assistant without needing cloud-based services or proprietary hubs. This group needs just the Blind Tilt if they already have Bluetooth on the Home Assistant server/Raspberry Pi, or some low cost esp32 devices otherwise.

It probably goes without saying that I fall into the third group, and given that, my view on the best way to achieve home automation/home control can be a little narrow. I expected option 3 to be the only method I'd recommend, but given the capabilities of the device, option 1 seems like a really solid choice too.

I'm still not convinced on cloud-based services for home device control, so I find option 2 harder to recommend, but if you already control multiple devices/platforms via the cloud, I would recommend the Blind Tilt as you can still manually control the blind (which some other retrofit devices leave you unable to do).

For all three options, the big takeaway is data privacy, and the fact that with a Bluetooth LE device like this, you're broadcasting a bunch of sensor data to anyone who might be listening. I'm still not sure how I feel about this particular example, as any prolonged data gathering might enable someone to make assumptions like 'this person is at home', 'this person is on holiday'. However, that's an extreme example, and the BLE benefits could outweigh these concerns (assuming SwitchBot pushes some firmware to address these issues).

Pros

• Doesn't interfere with original control stick/wand
• Clean unobtrusive design
• Long lasting battery + included solar panel
• Good native Home Assistant support

Cons

• Confusion over internal light sensor
• Clean design...unless you have to install it backwards
• No option to disable SwitchBot's "cloud"
• Very poor Bluetooth security

Rating & Recommendation

As it stands, I wouldn't recommend the Blind Tilt. The hardware is good and feels very well made, battery life is long, control is responsive and the Home Assistant integration is very good, but the use of BLE advertising/broadcast for data is quite a big pill to swallow.

If you're using the app, you'd never notice, because it prompts you to put the device into pairing mode, but the issue is that other people might be using other devices to read from your devices.

If you're not bothered about other people potentially getting your sensor data, then my other concerns are pretty minor, the biggest being the internal light sensor not working. Maybe then the risk is worth it for the benefit it provides–it's certainly the best concept I've ever seen for a retrofit tilt blind solution.

If you think it is worth it, SwitchBot provided a 15% off code–15TECHBIT–valid on their store until the 12th May.

I'm going to keep testing the Bluetooth security and will update when I hear more from SwitchBot. Hopefully they'll commit to securing the devices (at which point I'd wholeheartedly recommend the product) but for now it's a rating of 3/5.

Following the recent launch of the Blind Tilt, SwitchBot got in touch asking if I wanted to test a couple of units with a view to reviewing the product. As part of that, I've written a walk-through with some of my findings on the initial installation of the Blind Tilt which you can find here.

This guide shows how you can get the BlindTilt unit working with Home Assistant, as well as a workaround to get the behaviour working reliably.

It should also be noted that the process below is just as applicable to any other supported SwitchBot devices (only without the specific custom cover for the BlindTilt).

Add the Integration

Once I had a Bluetooth proxy running on an esp32 board (thanks to ESPHome), the SwitchBot Blind Tilt instantly showed up in Home Assistant under 'Integrations':

To pair the device, press and hold the pairing button on the bottom of the Blind Tilt for 2 seconds (until the white light flashes). Now start the Home Assistant setup process by clicking 'CONFIGURE' (or if it doesn't show up under discovered items, click Add Integration in the bottom right, search for and choose SwitchBot, and then follow the prompts.

Once added, aside from the control cover entity, you'll see 2 sensors (Light level, Battery) and 1 binary sensor (Calibration). If Calibration is showing as Off, try recalibrating it using the SwitchBot mobile app.

The control cover is a bit odd. In the SwitchBot app, the control makes sense. Slide up to 'close up', halfway down to fully open the blind, and slide down to 'close down'.

In Home Assistant it's not quite as obvious... The default cover control expects 0 to be closed and 100 to be open, but the open/close service calls do seem to understand that open is 50 (or close to it, depending on the calibration) and 0 or 100 is closed.

The 'close' action will move to 0 or 100, whichever is closer. The problem with this is that if it closes to 100, the 'open' action then can't be selected because Home Assistant expects 100 to be open.

Calling the cover.open_cover_tilt service will open the blind, so as confusing as this is, I think avoiding the default cover in lieu of open/close buttons for these devices will mask any confusion.

Create a Template Cover

Looking through some Github PRs/conversations, I found this post from BelowAverageDev:

The way the blinds operate with 50%=open conflicts with the way covers are expected to behave. For example, when exposed to google home, it assumes the blinds are at 100% when open, but they are actually at tilt=50. Because of this, opening to 99% will result in the blinds closing up to tilt=99, but opening to 100% results in an open call setting tilt=50.

This can be worked around by creating a cover template and adding some math to scale and offset tilt values in service calls. However, this has to be done in yaml, and it can be daunting for those without any experience writing HA yaml/programming to do this (without a step-by-step guide). Owners can decide if this is acceptable.

They also included the following example that will create a new cover entity to bypass the above issues. The limitation is that it will always close down (or up if you set tilt_position: 100), but the benefit is that the open and close actions will always behave as you expect them to.

# Example by Github user BelowAverageDev

example_blinds:
  device_class: blind
  friendly_name: Example Blinds (Simple Down)
  open_cover:
    service: cover.set_cover_tilt_position
    data:
      tilt_position: 50
    target:
      entity_id: cover.example_blinds
  close_cover:
    service: cover.set_cover_tilt_position
    data:
      tilt_position: 0
    target:
      entity_id: cover.example_blinds
  position_template: >
    {{ int(states.cover.example_blinds.attributes.current_tilt_position)*2 }}
  set_cover_position:
    service: cover.set_cover_tilt_position
    data:
      tilt_position: "{{position/2}}"
    target:
      entity_id: cover.example_blinds

To use this example, change the first 'example_blinds' line to what you want your new cover to be called, then find and replace all other instances of cover.example_blinds with your device entity. Here is a working example:

cover:
  - platform: template
    covers:
        blind_tilt_c5c1_tmpl:
          device_class: blind
          friendly_name: Example Blind
          open_cover:
            service: cover.set_cover_tilt_position
            data:
              tilt_position: 50
            target:
              entity_id: cover.blind_tilt_c5c1
          close_cover:
            service: cover.set_cover_tilt_position
            data:
              tilt_position: 0
            target:
              entity_id: cover.blind_tilt_c5c1
          position_template: >
            {{ int(states.cover.blind_tilt_c5c1.attributes.current_tilt_position)*2 }}
          set_cover_position:
            service: cover.set_cover_tilt_position
            data:
              tilt_position: "{{position/2}}"
            target:
              entity_id: cover.blind_tilt_c5c1

And once you reload your configuration, you'll have a working cover entity:

Once you've added this, you can still call the cover.set_cover_tilt_position service with a % value. You might have a button that uses this to set a slight tilt up to block the sun's glare (or better, combine weather forecast, time of year, luminance value from the blind itself so automatically call it...).

This cover template workaround is a bit frustrating but seems to work much more reliably than the default. In conjunction with creating some other custom presets, it's probably good enough until SwitchBot can improve the functionality (or documentation, at the very least).

Adding Multiple Blind Tilts

Adding a second device is as simple as the first. Reading the official SwitchBot integration instructions made me think it would be more complicated (it says about making a note of the Bluetooth MAC address) but in reality, you put the device into pairing mode, add the new SwitchBot device, and it shows up. The default name has the last 4 characters of the BT MAC address appended (as opposed to the SwitchBot iOS app with appends the last 2 characters of the MAC address).

Basically: If you're installing and adding one device at a time, you won't need to worry. Maybe knowing the MAC address of the device in each location may help with future troubleshooting...

What Next?

Adding the Blind Tilt to Home Assistant adds a whole world of extra possibilities for creating automations that the standalone SwitchBot app can't compete with. The BlindTilt also adds a potentially useful sensor in the form of the light level meter. Making the blind partially close when the TV is on, the sun is low and the light level is over a certain threshold used to be a pipe-dream, but no longer!

Alternatively, you can add any of the other supported SwitchBot devices using the same method as above. As a side note, this was my first experience using Bluetooth proxies, and I was pleasantly surprised at how responsive and reliable the control was.

If I've missed anything, or if you want to share a cool blind/curtain automation, please leave a comment or send me a message at @techbits@sudo.cat or @techbitsio.