Archive for September, 2016

So the X400 board arrived is a small cardboard box. The board was wrapped in an appropriate anti-static bag and the jumpers, nylon screws and standoffs were in their own little bag. No instructions in the box, but the website has pretty good documentation. Customer support is pretty rapid as well given the time difference between the UK and China when I did have a question.

x400_860p_1

X400 Image from Suptronics WebSite

As the X400 board also powers the Pi, it needs it’s own power supply. The docs say that it needs between 18 – 25 V supply that it then steps down to the levels necessary to supply the both devices. After rummaging around to find a suitable power supply, I ended up using an old laptop adapter that had the right size plug.

X400 itself fits on the RPi2/RPi3 via the 40 pin GPIO interface with nylon standoffs to support the card. There are also 3 jumper pegs in the box that allow you to turn on and off the headphones output, amp and to mute the audio. I guess these are used to disable the services you don’t want to use.

Volumio was the OS of choice based on my previous experiments with Audio OS’s, and as it supports the X400 card natively (an added bonus I found after reading the Suptronics website). As I already had an SD card built, I just used that. I didn’t do anything special to get the X400 working, although the Suptronics site talks about ensuring certain kernel modules are installed, I think these are more for older Raspbian versions. All I did with the Volumio build was select the correct device from the dropdown list in the config. page and it was all working!

At this point I got the new Volumio device to scan the FLAC library on the NAS and used it to playback some tracks via the headphone s. I’m not an audiophile, my FLACS aren’t the highest quality you can do and the headphones are cheap Sony ones I got from work a couple of years ago, but even with those limitations playback of a variety of tunes was impressive. Details and quality were much better that the ‘norm’ I’ve come to expect from high quality VBR MP3 via my iPod.

The only other thing I had to do was find a case. I’d seen some bundles that included the board and case, but I’d decided that the bundle was too expensive. After quite a bit of searching I actually only found one supplied who could get me an enclosure to protect the electronics. That was ordered from an Italian shop on eBay UK that then shipped the stand direct from China (isn’t international commerce great!?). This isn’t a case, but rather a clear stand with a top to prevent things coming into contact with live electronics – be they fingers or errant wires.

To be honest at this point I’ve completed the first and most basic version of my HiFiPi. If I can figure out how to do things like get power and channel selection buttons to work via the GPIO, find a suitable enclosure and speakers I’ll try and get the Kitchen Radio version built.

Advertisements

As usual I found myself with more ideas and things to experiment with when building the MooMusic prototype. Seeing all the possible things I could build made me want to move the project on far beyond my original ideas. But that wouldn’t be fair as the use case for MooMusic was very specific – a simple music player for my daughters. So I decided to use one of the various Pis floating around and try to build something more ambitious. I’d seen lots of people restoring antique radios or building small touchscreen enabled devices, so I wanted to do something like that.

First stop is to figure out the best way to get decent quality sound out of the Pi. Do I install something with a headphone style jack, something with phonos (RCA) or something that can take speakers? My initial thoughts were to install a DAC with some phono outs. If I wanted to use headphones I can easily get a phono-headphone adapter (assuming there isn’t one in my cable bin already!).

From the forums related to this kind of project it became apparent that HiFiBerry make some excellent small scale expansion boards that provide all of the connections I can think of and more. The prices aren’t bad either, and are cheaper than some of the true audiophile level DACs that I could try to use.

The problem is, I don’t actually have a real-world use case for this project: I’m not building this for a specific reason, just because I can. I soon realised that because I have no real use case, trying to build something that is suitable suddenly becomes much more complex. If I want speakers, I need an amp. If I want headphones I need a suitable jack. If I want to connect to an external amp, I need phono or maybe SPDif/Optical. Do I need to support Bluetooth? Will I use WiFi or ethernet?

Head-spin.

After taking a step back I decided that I want this to either be my audio source in my office OR to replace the annoying kitchen radio. The actual outcome would depend on how easy to use the final thing was and how pretty it was.

Based on that it became apparent that I needed the ability to drive speakers AND the ability to output via headphone jack. Faced with this, the HiFiBerry boards became a bit too expensive for me to play with. ~£45 for the Amp and ~£23 for the headphone with no indication that I can stack them and use both boards in a single build.

I’m not confident that what I end up making will be good enough to use in the kitchen, so just buying the amp is risky.

While trying to resolve this matter I came across a reference to the X400 board. A bit more digging revealed the X400 board from Suptronics. This board includes phonos, amp (with speaker terminals) AND headphone jack. The downside is that all that requires a separate power supply. Thankfully the power supply also powers the Pi, so there’s no need to use 2 plugs! For ~£20 via eBay (of course) I ordered the board and crossed my fingers.

Building this little box has unfortunately had two side effects.

The first and less of which is me now trying to figure out how to get the MPD binding working in OH2 so I can do things like control the music player as part of a rule or scene. Maybe ensuring that the box turns off at a certain time each night so that my daughter isn’t listening to music all night. Or turning it on in the morning with something loud and inappropriate to wake her up.

The bigger problem is the desire to build something a little bit more ‘sophisticated’ with maybe some better speakers and a better interface….. Maybe my own HiFiPi

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