Sadly, Samsung seem to be winding down their SmartThings Zigbee/ZWave home automation setup and it has always been quite painful using devices that weren’t officially supported. I’ve recently migrated my non-SmartThings native devices to Zigbee2MQTT, here’s how I did it:
- Purchase a SBC, in my case an OrangePi 4 running Armbian/Ubuntu – but a Raspberry Pi 4 is more mainstream. Set it up on your home network (perhaps you already have this running Home Assistant).
- Buy a supported zigbee adaptor. I strongly recommend the electrolama zzh adaptor (this requires firmware flashing post purchase, but this is straightforward).
- Install the adaptor, ideally via a USB extension cable.
- Install zigbee2mqtt.
- The version of node installed wasn’t recent enough; I downloaded a newer version.
- As the name suggests, you’ll have to set up an MQTT server, typically mosquitto to receive the status messages.
- Configure zigbee2mqtt / Home Assistant integration.
- Add your zigbee devices.
- Reconfigure your Home Assistant Automations etc if necessary.
Very pleased with my recent order from Mr Memory. The DIMM they sent me didn’t work but the return & replacement process was free & efficient.
With unsurprisingly, the UNIX “columns” command (will need to install autogen package).
du -hc --max-depth=1 . | columns
diff <(ls dir1/) <(ls dir2/)
As Alpine Linux uses busybox for a lot of its system tools it won’t set up the necessary routing if you have a default gateway on a non-local subnet to the IP. You want /etc/network/interfaces to look something like this:
iface lo inet loopback
iface eth0 inet static
netmask 255.255.255.255 # or whatever is netmask
up route add DEFAULT.GW.IP dev eth0
up route add default gw DEFAULT.GW.IP
then run alpine-setup again
The best thunderbird extension is now working on current Thunderbird. Please donate to the author!
Decommissioning or migrating services in enterprise environments will frequently reveal previously unknown dependencies which result in changes getting rolled back, wasting a lot of time.
To try and head these issues off you can test these changes with “brownouts”, shutting off the relevant infra temporarily (eg at a weekend) to expose any hidden dependencies.
When brownout testing, the following need to be borne in mind:
- Dependencies may only be exposed for certain functions. Eg at startup, shutdown or other operations such as login. Thus a full test suit should be run and components restarted.
- The effects of DNS, such as caching.
- Regional differences.
Try clearing your browser cache
That’s because there’s a bug: https://forum.armbian.com/topic/15593-no-network-with-590-sunxi-on-banana-pi-m2-berry/
Either get the patch or downgrade. Wifi appears unaffected so you can use that to connect.