So I’d bought a TECEVO T4 NFC Bluetooth Wireless Speaker on an Amazon lightning deal a while back, partly because of wanting to play with Moo Music and partly to plug into my desktop so I can have sound that’s not via headphones.

I found plenty of people talking about connecting BT speakers to their Debian based systems, but a distinct lack of info about doing it specifically for Volumio. Working with the various guides I totally failed. Either the changes would result in  Volumio becoming unstable/not booting or would result in no audio anywhere.

If you dig deep enough you will find several requests for native BT support in Volumio, but they have all been rejected. While this is annoying, I actually agree with the reasons. Volumio is designed/tweaked to work as a High End Audiophile device when added to a suitable DAC. In no way is a BT speaker (no matter the cost) a high end output device. Providing support for such a device goes against the basic ethos of the platform.

Knowing that trying to install BT on Rune Audio was doubly cursed – I’m ignorant of ArchLinux AND it probably doesn’t support BT for the same reason, I went back to PiMusicBox.

As PiMusicBox is more of a wrapper for the Python based Mopidy system that is an extension of MPD, it is a bit less Audiophile biased. It also means that I can add and remove stuff to the OS without worrying about breaking some obscure kernel header tweak.

After a few false starts I managed to get the speaker to automatically connect to the Pi when they are powered. Audio from PiMuiscBox is sent to the speaker and as it is basically streaming VBR MP3 files, the quality is pretty good.

In fact I was so happy with the final result that I decided not to bother playing with the USB Sound card when it did eventually turn up…. about 2 weeks later!

#Install libraries
sudo apt-get install bluetooth bluez bluez-utils bluez-alsa

#Turn on BT Interface/Card
sudo hciconfig hci0 up 

#Use the BT device to scan for the speaker
hcitool scan # scan for your bluetooth device

This will return a list of devices and their MAC addresses, find the speaker you want to connect to and copy the MAC string. The run the  following commands:

#tell the adapter to connect to the MAC address and use 0000 as the pin
bluetooth-agent  --adapter hci0 0000 XX:XX:XX:XX:XX:XX 

#Test that the Pi and speaker are connected - should get you some beeps
bluez-test-audio connect XX:XX:XX:XX:XX:XX 

#Tell the Pi to trust this bluetooth device
bluez-test-device trusted XX:XX:XX:XX:XX:XX yes 

#Check that the device is now trusted - a 1 means it is
bluez-test-device trusted 48:5A:B6:A8:1C:A2 

#Restart the BT service on the Pi
sudo /etc/init.d/bluetooth restart

Now we need to modify some files

In /boot/config/settings.ini:

Change

output = alsasink

To

output = alsasink device=bluetooth

Rename the /etc/asound.conf

cp /etc/asound.conf /etc/asound.conf.bak

Replace the contents of asound.conf with:

pcm.bluetooth {

type bluetooth

device XX:XX:XX:XX:XX:XX ## your device id##

profile "auto"

}

Rename /opt/musicbox/setsound.sh

mv /opt/musicbox/setsound.sh /opt/musicbox/setsound.sh.bak

Backup the bluetooth audio config

cp /etc/bluetooth/audio.conf /etc/bluetooth/audio.conf.bak

And amend it, under [General] add the following

[General]

Enable=Source,Sink,Socket

Further down under the commented out #Disable add the following line

Disable=Media

Now reboot MusicBox….

 

I initially planned to use a simple wired speaker via the headphone jack – the kids already had one of these and it would mean one less thing to worry about. What I hadn’t considered was the fact that these were rev 2 versions of the original Pi B… so the sound quality via the headphone jack was pretty abysmal.

Adding a better external speaker wouldn’t solve the problem, it would still be using the same audio output. This left me trying to figure out how to use my other options – HDMI, USB, DAC or Bluetooth.

Option 1 – HDMI

My immediate response was to drop HDMI – although the audio would be excellent, getting hold of small, cheap HDMI equipped speakers was going to involve some weird devices or Alibaba shopping. I have a Cyp HDMI to Phono box…. But they cost ~£120 and for that money I’d rather buy a Sonos Play:1.

Option 2 – USB

I could add a cheap USB sound card (they are as little as £2 on Amazon/eBay), but that would mean extra bits sticking out of the case. For £2 these bits are not going to be robust enough to handle my kids. Spending more doesn’t really solve the problem, but it might be the best of a bad situation.

Option 3 – DAC

Buy a DAC… would love to…. But this means electrical things not in cases and vulnerable to pokey fingers. It also potentially adds a big lump to the cost of building the box, something I’m trying to avoid.

Option 4 – Bluetooth

Buy a Bluetooth speaker and connect them. No big extra bits hanging out or exposed on the case. I can re-use one of the BT dongles I already have. Speakers can be as big or as small as necessary. But I’d have to buy a speaker.

I decided to try the USB and BT options. I’d got a cheap BT speaker from one of the Amazon daily deals and with a few birthdays coming up I could add a £2 USB card as an add-on item to my basket.

In part three I’ll look at setting up the two to see which works best.

I love our Sonos and plenty has been written about how well they work and how easy they are to use. What they are not, is overly cheap. What are cheap are Raspberry Pi’s (especially when they are sitting doing nothing) and Bluetooth speakers (when on Amazon daily deal).

I’ve wanted to get a better music player for the kids for ages, but I’m not in a rush to trust them with a Sonos. So I fell down the rabbit hole of Pi as a music player….

But first things first – The OS

Originally there was RaspyFi – a complete distro for audiophiles that was designed to work with an external DAC and basically allowed the Pi to playback music at very high quality levels (24bit/192kHz quality). It appears that the various contributors then each went their separate ways and released their own versions. I could use a bare Linux OS and then install MPD (Music Player Daemon), but that doesn’t give me any interface on the device itself – it relies on external clients to control playback.

So there are four main contenders for the role of Moo Music OS. In no particular order they are RuneAudio, Volumio, Moode Audio and PiMusicBox.

Of these four I never really got Moode Audio to work happily, it would either fail to boot, fail to scan the library or just generally be as responsive as a brick. Both RuneAudio and Volumio are very similar. Both provide a nice, responsive browser based GUI that can be used from almost any device. Both provide carefully tuned and tweaked kernels for optimal audio. The only real difference is the underlying OS – Rune uses ArchLinux while Volumio uses Raspbian. Finally PiMusicBox. This is built on the mopidy application that is itself built on MPD. Again it provides a web GUI and allows control from any device. It’s only downside is that it appears to be much older than the other two with less frequent updates.

After playing with all of them I settle on using Volumio – the deciding factor? Raspbian. As much as I liked Rune Audio, trying to get additional stuff done under the hood is going to be much easier if I’ve got some experience of the OS!

In Part 2 I’ll look at the output side of things

Links

Volumio
RuneAudio
PiMusicBox
Moode

Migrating to OpenHAB 2

Posted: September 8, 2016 in HA, Hacking and playing, House
Tags:

With the Beta release of OpenHAB2, I finally decided that it was time to look at the migration path from OH1.8. I also decided to do the proper Veralite integration and use the excellent scripts provide by Guessed to convert everything in my Z-Wave controller and import it to OH2.

So far it has been quite easy to convert from OH1 to OH2, but the following things did catch me out. Most of this revolves around the new hierarchy/architecture of things/items/channels.

The old way to refer to an item:

Switch Hue_GF_Toggle_Snug   "Snug Bloom"  (gGfloor)  {hue="1"}

The new way to refer to a v2.0 item:

Switch Hue_GF_Toggle_Snug   "Snug Bloom"  (gGFloor)  {channel="hue:LLC001:000000000ab1:1:color"}

Device detection and inclusion with the Paper UI

If you install version 2.0 compatible bindings – Hue, Sonos, Weather, etc the PaperUI will allow you to discover the real devices on the network and extract the relevant items. However, these items are NOT stored in an item file; they end up in the /userdata/mapdb part of the file system. This makes it a PITA to then refer to them as you need to figure out the correct channel name & reference to make use of them.

So if I need to write a rule to turn on the Hue Bloom from the above example, I need to copy the channel info from the PaperUI interface and paste it into my rule.

Being pedantic, I prefer to have all my items in a single location (currently a loooong .items file) so I can find them again. If I add the ‘discovered’ item to my .items file, I’ll end up with duplicate entry error in the log. Actually writing this post made me realise why I kept getting the error despite repeatedly searching for the item and finding only a single reference in my conf dir!!!!

So I’ll end up using the auto discover and then not enable any of the channels the PaperUI displays, I’ll just copy and paste the value to my own items file.

Using 1.9 binding means using old style item mapping

Using the MiOS binding tools I imported into OH2 all the devices controlled by the Veralite Z-Wave controller. I then spent ages trying to figure out how I could convert

{mios="unit:house,device:139/service/SwitchPower1/Status"}

into the correct format that OH2 uses

{channel="mios:unit:house,device:139/service/SwitchPower1/Status"}

without success. All the examples talk about using this channel={} format and that the non 2.0 bindings (often called 1.9) will work using the compatibility layer that is built into OH2.

What I didn’t realise was that these 1.9 bindings still use the OH1 item convention, so there was no need to change them!

Import libraries

The migration docs point out that under the new architecture there is no need to include imports at the top of the rules/scripts. So in the past I would have:

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
import java.util.Date
import java.text.SimpleDateFormat

So when I copied across my rules, I happily deleted all the import statements.

Stupidly I assumed that as this was a Java environment this included the java libraries. It doesn’t. It only applies to the OpenHAB ones. Thankfully I use git, so rolling back all the changes wasn’t as big a deal as it could have been!

The new imports now include only Java libaries:

import java.util.Date
import java.text.SimpleDateFormat

 

Eclipse Designer and OpenHAB designer

This is more a moan than a gotcha… Needing to have OHDesigner open to access my OH1 configuration and Eclipse Smart Home Designer to edit the OH2 ones… EclipseSHD won’t open OH1 directories and vice-versa.

At least on ‘nix I can use workspaces and switch between them, on Windows, not so much.

Links

Official OH 2 documentation

Migration guide

OpenHAB WIki

Open Ports in RPi

Posted: August 22, 2016 in Hacking and playing

See what ports are open on the RPi

netstat -lptn

or the long version is:

netstat --listening --programs --tcp --numeric

 

In Part 1 I discussed the technologies that make up the Blocks themselves, adding a block to the end of the chain and handle the distribution of the final BlockChain. Now we can consider how we protect each block in the chain and how we can ensure that the chain stays unbroken.

Changing A Block

We have a new block with the contents all secured and consensus has agreed that this block will be added to the end of the chain. What is to stop someone from removing a previously created block from the chain and replacing it with something else?

If we calculate the hash of the contents of the previous block we can then use this ‘signature hash’ value as part of the process of adding the new block on the end of the chain.

 

Screen Shot 2016-08-09 at 10.50.22

If the contents of a block is changed, the ‘signature hash’ will be different from the one stored in the next block of the chain and everyone will know that it has been changed. Consensus ensures that only consistent chains exist and that broken chains get dropped.

Vulnerabilities

We’ve shown that the BlockChain won’t allow alterations to existing blocks, how could we add a false block to the end?

  • Create a false block that contains the fake data and the correct references to the previous block in the chain.
  • Control 51% of all the nodes in the network and force them all to agree that the false block should be the new one.
  • Do all this before the network decides which block to add to the chain as part of the normal process. FYI – BitCoin currently adds 9304 blocks per hour to the chain or 2.5 every second.

Smart Contracts

Smart Contracts are the next iteration of the original BlockChain concept.

They work on the idea of storing a small program within the BlockChain that can then run in its own virtual machine when required. When invoked this contract programme can then be used to validate, enforce and manage transactions between two or more parties in a trusted way without requiring the services of a middleman.

The outcome of this invocation can then be written back to the BlockChain or to local contract storage where it will remain.

Smart Contracts Vulnerabilities

While seen as the next big thing int an already big thing, Smart Contracts are still trying to establish themselves in real world use.

As they use ‘Turing Complete’ languages to define the contract they are vulnerable to poor coding or flaws in the underlying virtual machine. Development environments are still immature increasing the risks further.

Ethereum ‘lost’ ~$53 million because they built a VM and a language that had flaws that were exploited to make contracts do unexpected things, in this case transfer the holdings to another account within the Ethereum ecosystem.

N.B. This issue has since been rectified by basically rolling back to a point in the ledger prior to the loss and then forcing a fork in the BlockChain where the monies never left the DAO. This has caused a debate in that it proves that the BlockChain is not inviolate – if enough people say so, the BlockChain can be changed and more importantly there are no attempts to fix the underlying issues in the VM and language itself. So in theory this loss could be replicated again in the future.

BlockChain is the new must use buzzword in technology and it claims to provide the capability for building trust between disparate and non connected systems.

This post is based on the presentation I wrote to explain the potential of BlockChain for my employer.

So what is BlockChain, where did it come from and why the sudden interest?

Why?

The sudden interest comes from the fact that in theory a BlockChain allows for a trusted, accessible, permanent, encrypted, distributed record that is almost impossible to modify. It allows two parties to perform transactions without the need for a trusted third party – something that can add both costs and complexity to the original transaction.

BlockChain is being used for everything from currency and diamond registry through to medical record management and music rights control. Large scale schemes such as welfare payment control are being investigated by the UK government.

Where?

BlockChain is the underlying technology for a virtual currency called BitCoin. As a technology used for the manipulation of funds, it has to be transparent, reliable and secure. While BitCoin initially suffered from bad press relating to its association with criminal organisations (Silk Road) and the high profile failure of businesses (Mt Gox), it is now established as a true virtual currency.

What?

At its most basic BlockChain is the combination of four current technologies in a new and unique way:

  • Asymmetric encryption (A.K.A. Public Key Encryption)
  • Hashing
  • Peer to peer networks
  • Consensus

Asymmetric Encryption

Public key encryption uses two keys to protect content.

One key is Private and is held ONLY by the user, the other key is Public and is available to everyone. These two keys are created together at the same time and are a mathematical pair – they will only work together.

If I want to send a message to someone, I use their public key to ‘sign’ the message. Signing the message effectively encrypts it so that only the private key can open it. Any attempt to change the message will change it and will result in the private key not opening it. The inability to open it implicitly implies tampering has occurred.

Software such as Pretty Good Privacy (PGP) made this incredibly complex topic easy for everyone to use, much to the horror of law enforcement agencies worldwide. At one point the PGP software was classed as a weapon and placed on a restricted list limiting it’s availability outside of the US!

Hashing

Cryptographic hashing converts a value of variable length into an alphanumeric string of fixed length. Hashes are a ONE WAY function – you can’t take a hash and find out the original value. Hashes are also very quick to calculate with the ability to do so available in all programming languages.

The specific method of hashing used determines the length of the final hash output. SHA1, MD5 & SHA256 are all common hashing methods, each providing different levels of complexity and output size.

For example using SHA1 to hash a simple string:

Hello world => 7b502c3a1f48c8609ae212cdfb639dee39673f5e

Changing even the smallest thing (“H” to “h”) results in a completely different result!

hello world => 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed

Hashing can be used in everything from password validation to ensuring the file you download has not beed altered by malicious third-parties.

Peer to peer

Using Peer to peer technologies allows the BlockChain to be distributed across hundreds if not thousands of nodes.

A node can be a simple device making use of the BlockChain or a more complex or powerful device that is used to manage the BlockChain itself.

As only 4 nodes are required to ensure that the BlockChain remains available, accurate and up to date, the more nodes that host it serve only to increase reliability, speed and robustness.

Consensus

Consensus is a technique in which a set of nodes can reach an agreed outcome without a designated leader and with automatic detection of tampering.

When a new block is proposed to the BlockChain, all nodes must add it to their own BlockChain. If any node tries to lie, that node becomes tainted. As long as there is no single party with the control of >= 51% of the nodes, the BlockChain is always up-to-date and truthful.

Quorum systems are applied in BlockChain to reduce the complexity of the consensus algorithms with no penalty in consistency, partitioning the nodes in a similar way to electoral constituencies.

Consensus must happen before a new block can be added to a chain, so the only way to add a ‘bad block’ to the chain is to control the majority of the nodes.

As the nodes are distributed throughout the internet, this becomes impractical and this means that we have established an effective trust between all the users of the BlockChain without requiring a third-party.

Building the Block

By combining these technologies we can create the next block for inclusion on a chain:

  • The contents can be encrypted using Public Key Encryption
  • Hashing protects against the contents changing
  • Consensus agrees which block will be the new one on the end of the chain and that everyone agrees that this is true
  • Peer-to-peer networking distributes the new block to all locations for inclusion