Archive for the ‘Hacking and playing’ Category

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

Advertisements

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

 

Presence Detection

Posted: September 21, 2015 in HA, Hacking and playing, House
Tags: , ,

The ‘ol bug bear – how do I see if anyone is home?

I’ve tried OwnTracks, but the app on Android isn’t the most accurate and reliable (although it is being updated). I’ve tried the network health monitoring binding in OpenHAB and asked it to detect the phone when it connects to the home network (spot the flaw #1). I’ve tried using a BlueTooth (BT) dongle in the OH controller and running regular scans for my phone.

But none of them work 100%. OwnTracks just lets me down (waypoints especially). I leave my Wi-Fi off most of the time to save battery (and network health doesn’t seem to detect it when it is on). BT does work, as long as i am in range. But the minute I go upstairs the phone is out of range and the system thinks I’ve left the house. The other gotcha is that my wife doesn’t turn BT on, so that’s a pain as well.

When I’d spoken to SmartThings (some CES trip before Samsung got involved!) we had discussed the presence tag that their system supported. Fast-forward to the UK release of the new Samsung version and the presence tags suddenly are actually available in the UK. Yay!

Boo! They are ZigBee. So absolutely bugger all use to me. I’m not plugging in the Almond+ or building some new Xbee device just to solve this issue.

I need a device that is small enough to be with me all the time, not be intrusive and allows for reliable long term use before requiring battery changing. Oh and the batteries need to be cheap. I’m not spending more on a replacement battery than the actual device cost me. The other driver is that I’ve managed to get some more scripts written that control our heating system. So if I can prove that no one is home, I can automatically turn the heating off!

BlueTooth Low Energy

A long time ago (~2012) I’d done some experiments on presence detection for work. My concept was to use BT, BTLE, Wi-Fi etc etc to try and establish who was in a room during set-top box use. While this wouldn’t give a one-to-one correlation between who actually watched something and who was there, it would narrow the field considerably. If device X was always present when cooking shows were watched, we could start to recommend cooking shows when device X was in the room. The more devices we detected  and more watching data we got, the better the correlation would become.

Anyway, the idea was greeted with enthusiasm and then totally mis-understood and ended up being something to do with localised advertising in bus stops…. No I don’t know how it got to that either!

The point of this is that when I was looking at this, BTLE beacons were just starting to actually be available. Devices like the Fitbit bands used BTLE to communicate with the phone.  What was the state of cheap BTLE devices today?

The Concept

After thinking about it, the only thing that I always have on me when I leave the house is my door keys. When I come in, the door keys get put in the front door lock and that’s where they live. Can I find a device that I can detect in this position in the house reliably? That is also small enough to fit on my keyring? And is tough enough to survive being thrown around as part of the normal lifecycle of a bunch of keys!

Google and Amazon searches revealed several companies selling iBeacons in various size and power formats. After a couple of email conversations with a company called Avvel I ordered a ‘long range iBeacon’.

Avvel iBeacon (long range)

The device turned up the next day and was simple to setup and configure. At this point I’m not really bothered about the Major and Minor broadcast values – this is only for me. Maybe later if it works I’ll look to use these to indicate the device and who has it…

The Code

I’m already using the bluez library via python on my RPi2 to detect the phone via BT. Every 5 minutes I scan for the BT address of our phones. The true false flag is posted into our mqtt broker where OpenHAB uses the value to set the in/out switch. The plan was to do exactly the same except using BTLE.

As usual, it didn’t happen. While i could happily

sudo hcitool lescan

and find the keyfob, the ability to do this in the python script eluded me. Various tutorials talked about using gatttools or adding extra libraries (that failed to either install, compile or run), but none of them worked.  I wanted to use python in order to limit extra packages, libraries and complexity that installing extra things could add to the system. I can’t have a HA controller fall over because of a clash between different bits.

FInally I expanded my search to other languages and found noble for NodeJS.  I’ve actually used noble when I was doing the presence detection work before – that time I was using it embedded in Node RED. As all my recent work has been in NodeJS, I figured I’d try it for this.

The beacon is set to broadcast every 9.9 seconds (at least I think that’s what I set it to be), so the script scans for 25 seconds every three minutes. At the end of the 25 seconds, the script totals up how many times it has seen each of the specific devices and then sends a true or false value to the mqtt broker for each one where it is again picked up by OH and used. The three minute cycle is controlled by a crontab -e while the 25 seconds is a simple JS setTimeOut().

The Result

Well so far it has worked (sort of). The script picks up the keyfob successfully and OH gets the updates as I come and go. The issue is signal propagation. In a straight line with no obstructions I’m able to detect the keyfob up to about 50m (bottom of the garden!). The issue is that between the RPi2 that has the USB dongle doing the detection and the front door where the keys are supposed to live are walls, radiators, kitchen units and potentially small children. This drops the successful detection rate down considerably – it doesn’t stop it completely, but it does drop it enough to make it unreliable.

My next option is to move the OH box to a better location that may have a clearer ‘line of sight’, but that will mean grubbing around behind the AV cupboard and thats not a job to be taken lightly!

 **UPDATE**

As the keyfob is on a big clip on my door keys, it’s actually easier for me to just unclip it and drop it with my other keys in the lounge rather than leave it on the door keys. It’s also safer than me rummaging around in the AV cupboard.