Unexpectedly and to much excitement, my home internet is now provided via FTTP.
For background, I was previously in a FTTC environment getting average speeds due to my distance from the cab, however good enough to assumably be overlooked for the next phase of the Openreach Ultrafast rollout. Not that I’m complaining, 2020 is the year my speed gets a much-needed boost.
2020 also turns out to be the inaugural international work from home year, so had the opportunity to have a front seat view from my home office on the activity and timeline that brought FTTP home.
I’d like to share my observations and timeline as an example of what you can expect should you get the inkling of fibre coming to your street soon.
Before we get started, as my expectations rose, I found this post by Andy’s World invaluable for identifying activity and helping me confirm that FTTP was on its way.
In a series of events that I thought wouldn’t have happened for many years, FTTP (Fibre To The Premises) has just become available to my home. With available speeds of 1000/330Mbps available the temptation is to go for the maximum, but will my current infrastructure actually deliver what’s on offer?
My current router is a Draytek 2862ac, which has an advertised 400Mbps throughput at the WAN, but what can it actually achieve in the real world? This will be the basis on choosing a FTTP speed profile.
Speed testing a router can be setup with a couple of laptops…
Hopefully the mad dash for home working is over, and now
everyone who can has settled in to a comfortable home setup with new knowledge
of what a VPN and remote desktops are all about.
I thought my established home setup was great, however I
didn’t envisage words like Teams and Zoom to become the buzzwords of companies
the world over.
This posed an issue for myself. Even though my 2017 Dell XPS
has a webcam ready to go, it spends its home office days docked with the lid
closed. When opening the 4K screen combined with the Full HD monitors, Windows
implementation of scaling rears is appalling head and just looks terrible.
Combined with the Dell’s decision to locate the webcam below the screen to give
maximum nostril-cam angle, its not something I like to use.
Buying a USB webcam didn’t seem worth it for what is
(hopefully at time of writing) a temporary solution.
So in comes another Pi project, this time using a spare Raspberry Pi Camera module connected to an aptly placed Pi, that can be used on a Windows machine for the software likes of Zoom, Skype and Teams…
Recently
I’ve had the opportunity to deploy and test a call centre PBX product to gauge
if its viable to offer as a product and how it will sit within our
infrastructure.
Installing and poking around the GUI is all well and good but to really find out how a PBX behaves it needs some traffic, to find outs its performance in regards to resources but also to find out what a vendor’s interpretation of an advertised feature actually is.
To generate sample calls, instead of registering handsets/softphones and dialling manually it would be better to automate this, and SIPp is the perfect tool for this.
I like this time of year, a chance to reflect on the last 12 months and take stock of accomplishments and realise the achievements. And something I like to gauge a success on is the longevity of a solution, and a time-lapse comparison 6 months apart is seemingly my go to example.
To elaborate on this achievement, earlier this year was the setup of a homebrew CCTV solution using an array of Raspberry Pi’s with cameras, and a VM Cent OS server acting as a PVR host. A surplus Pi W Zero was pointed at the hills and used as a time-lapse experiment.
The real achievement is that since its conception in early June,
it has been stable enough to run in the background, capturing footage for such an
occasion.
So here I present my latest time-lapse, a split screen video on the difference between a June day and a December day:
It’s been a while since I had my last automated time-lapse solution, and since the change of location and change of servers the setup has been lost in the ether.
Back then, it was achieved with an off the shelf IP Camera, a Windows Server share and a batch script. Now that the Linux / Raspberry Pi CCTV solution is up and running, I hope to re-instate the automated time lapse in a simpler way using MotionEye and Cent OS.
Following the setup of a Cent OS CCTV server, I’ve been using Raspberry Pi’s as video sources. But what if there was a Raspberry Pi in perfect situ for a CCTV camera, but was already in use as a media player?
A Linux system has always had the impression that it is
versatile, so this should be an achievable task. A barrier would be how to get
this done with the operating system installed, in this case it is LibreElec, an
OS with the tagline “Just enough OS for Kodi”. Therefore, it would be more of a
challenge than a usual Debian install.
The team at LibreElec saw this type of thing coming, and included the Docker service as a Kodi addon to allow the curious tinkerer to add more than Kodi to a Pi.
If you have the LibreElec based Pi in the opportune
placement to add a camera, here is how to add Mjpeg streaming capabilities…
When a phone is no longer required on your service, there is
always trepidation on what will happen to it, the hope is that’s its unplugged,
stuffed in a drawer and never sees the light of day again. But in reality,
there’s a good chance that it will end up on the likes of eBay and Gumtree, and
since a phone is already provisioned with your server details, the next person
to get their hands on it could have unauthorised access to the system.
The simple step to prevent unauthorised access is to delete / change the secret to the extension, if your will to put up with the constant failed registration attempts. But what about the personal data on the phone? BLFs, local directories and the like.
Yealink devices since firmware version 81 have had the
ability to factory reset via a SIP notify command, meaning should a phone still
be online, a factory reset can be handled remotely and without end user
intervention.
If you’d ever searched for Raspberry Pi projects that
involved a camera then the results would certainly include Motioneye OS, an
easy to use self-contained operating system that is truly (write then) plug and
play.
Looking for a CCTV project earlier this year I too was drawn in by this, and with my small abundance of RPi spares it was the cheapest choice, using a couple of RPi 3B+ for video, and a Zero W for time-lapse image capture. All processing was self-contained on each Pi with capture data passed over via SMB to a Windows file share.
This worked, but had a couple of problems that prevented it
from being trustworthy. Firstly, it stops recording video after a few days of
uptime, by creating empty files. And secondly the time-lapse camera seemed to
reset every few minutes that created in white out image capture as the camera’s
exposure setting recalibrated, ruining a time-lapse video.
Looking wider there was also the performance issue. In
Motioneye OS’ default state of managing all features, the highest FPS seemed to
max at 15 fps even on the Pi 3B+. Forums suggest this is due to the motion eye
daemon handling all the image processing in software, putting a strain on the Pi’s
modest CPU.
The idea and goal is to move the processing and IO
responsibilities to my server, which would be far more capable than the then
latest available RPi, and as I have chosen Cent OS to be my go-to Linux OS of
choice, this is what I’ll be using.
A gateway to make this possible is an option in Motioneye OS, Fast Network Camera. This when set relinquishes the Pi of all processing duties and serves to just stream the camera capture as best as possible via MJPEG.
Here’s how to set up Motioneye on a Cent OS server to be a central data hub for a network of RPi Motioneye OS cameras.
For years, since it was XBMC on the original Pi I have been using OSMC as my Raspberry Pi media player. And following on from a whole home Pi redeployment for to include a CCTV system the latest installment was to install OSMC to two Raspberry Pi 3A+.
Raspberry Pi 3A+
The Pi 3A+ plus is the cut down little brother to the latest
3B+ much akin to the original Pi B and A models. Both have the same quad-core ARM
v8 processor, Broadcom Videocore-IV GPU and importantly the 2.4GHz and 5GHz
802.11b/g/n/ac Wi-Fi module for faster and stable WIFI out of the box. What’s cut
down is the RAM, halved at 512MB, USB ports are reduced to one due to the removal
of the onboard USB and gone is the ethernet port.
All the power without the ports make its perfect as a media player,
all that’s needed to connect is the HDMI, with remote control provided via a CEC
equipped TV.
The issue with OSMC
Here are the issues I experienced with OSMC on the Pi3A+,
this is in no way a snarl at the developers who are doing an amazing job. I
believe the 3 A+ is still a new and niche model so it’s understandable that development
is slow for this product. I’m just hoping this will eventually be looked into and
resolved, and putting it out there in case others have the same issue. Performance
on the 3B+ is still exceptional.
From boot, selecting a 720p file (via Samba and h264 encoding)
is fine, with subsequent auto-play files playing with no issues. However, with the
next selection the issues start, selecting a file loads it but doesn’t play, having
to go to the main menu and selecting Full-Screen to play the file. But then it buffers
constantly. On the third play this workaround fails, and selecting Full-Screen results
in a black screen.
In addition, even from boot any 1080p content fails to play with
a black screen in its place, and playing h265 encoded files results in an
immediate system crash.
480p content remains unaffected and plays perfectly.
LibreELEC to the rescue
Without resorting to buying a 3 B+, your media experience can still be made on 3 A+ by using LibreELEC, an alternative to OSMC that has the same goal of getting Kodi on the Raspberry Pi.
