Plex switch

Posted: January 20, 2018 in Home Media, Plex, Watching
Tags: , , ,

The current Kodi – Emby setup has been working well until recently. For some reason, the Kids profile is now refusing to play back certain files that work fine in the main profile. Other files play without issue in both profiles. I’ve also had the Emby client not working properly on the Roku boxes. Stuff has played on one Intel box that then refuses to play on the other one… even though it’s more powerful. With kids wanting to watch their stuff, having to troubleshoot which of their shows does and doesn’t work became increasingly frustrating.

Emby had been our default choice for one simple reason – it allow me to build profiles that meant the kids could have their stuff and just watch it. The non-kid friendly content was under a different profile. While this functionality was available in Plex, it cost money.

With a mix of self-built Intel platforms & Roku boxes, the need for a central server to handle synchronisation duties between all devices is critical; trying to juggle which particular episode of Pokemon the kids have watched is a full time job! Using Plex on the Roku and Emby on the Intel has been the work around, but this means trying to manually update both Emby and Plex watched statuses.

As part of the Black Friday deals I finally succumbed to buying a Plex pass… and a lifetime one at that. I mostly bought it to get access to the live TV and PVR capabilities allowing me to retire the TVHeadend Server that I never could get to work in the way I wanted.

After another episode – the Emby app crashed on the Roku3 – I decided to see what the actual front end Plex client was like. Initially I built a ‘simple’ RaspberryPi based Plex Media Player (PMP) to see how it could work and to see what the experience was like. Installation was simple and I was surprised to see that it was based on the same LibreELEC platform that we use for our Kodi players. The plan was to use the RPi in the playroom and see if the kids were happy with using it before thinking about updating their Kodi player.

After a ‘play-date’ with a room full of kids wanting to watch TV and the same issue of films NOT wanting to play – that was a happy 10 minutes – I finally decided to scrap their Kodi installation and install the PMP client. It’s an old NVidia Ion Atom board, so nothing huge, but runs 1080p content without issue and is speedy enough with a 30Gb SSD. The PMP installer did it’s stuff and within 10 minutes we had a working player. The only issue was that it wouldn’t detect my local Plex server automatically – it kept trying to route out of the house to Plex and then back again. Manually adding the local server IP address soon fixed that issue.

The kids are happily using the PMP client without issue on their box.

I should add that the issue has never been with Kodi as far as I can tell – it has always been with the backend Emby infrastructure – either the Roku app wouldn’t start or if it did it wouldn’t play back content. On the other side the Kodi plugin fails to play content under one profile that plays perfectly under another on the same device. Using the direct path capability was how it was originally setup, but this kept failing, so the only way to play stuff was through the plugin.

I can’t say that the the issue doesn’t lie with me using Emby as a Docker container on the unRAID platform and these issues aren’t related to this additional complexity, but all I know is that I run Plex the same way and it hasn’t caused issues yet.

After a couple of weeks running PMP on the kids box, I’ve also now migrated the main lounge player across to PMP as well. My biggest niggle about using the box is that the Harmony remote can no longer shutdown the box. I have to manually shut down before using the power off command to turn the rest off.

I felt bad moving away from Kodi – I’ve been using it in some form or another since the original XBMP on the first gen XBox – complete with Mechwarrior 2 hack to install it! I do miss the skins – the Plex interface is functional, it’s not pretty. I just don’t have the opportunity to debug/fix stuff when the kids want TV.

Advertisements

Xiaomi Smart Home

Posted: January 6, 2018 in HA, Hardware
Tags: ,

The OpenHAB community have been taking about Xiaomi and the raft of components that you can get relatively cheaply (even cheaper direct from China!). It’s ZigBee based, so it shouldn’t interfere with current devices.

I’m not keen on the idea of adding another hub/gateway to my setup, but for roughly £20, it might be worth a punt. I always tell myself that “worse case I can sell it on eBay”. Never actually happens though…. So AliExpress and GearBest both list the gateway, but the one on GearBest appears to be the 3rd generation. From reading the notes on the OpenHAB documents and forums it seems that gen 2 or later is supported. AliExpress may have the gen 2 and gen 3, but as all the suppliers use the same stock photo, it’s quite difficult to see. Being Christmas, there’s a sale on, so I’ve also picked up a button and 2 door sensors. Total cost ~ £30 with shipping.

Let’s be honest I couldn’t get 2 Z-Wave door sensors in the UK for that price!

The downside to all this is the time for delivery. I ordered the kit on 21st December and it finally arrived on 4th January. Not long really given the Xmas holidays, but I get impatient waiting for new toys!

Unboxing

When the parcel finally arrived, it contained 4 small white boxes. The largest – probably 10cm a side contained the new hub.

IMAG0470

Xiaomi Smart Hub with UK Adapter

The other 3 were the same size, each containing a device.

Each box also contained a small instruction leaflet in Chinese, and if appropriate some spare double-sided tape to mount the device.

The Hub includes a LED ring for light effects, an ambient light sensor as well as a speaker. The idea is to plug it into the wall socket somewhere central and use these features as part of the whole home solution.

Installing

The installation of the hub and devices is a little ’round-the-houses’, but is outlined in the OH documentation here.

Slightly disconcerting is the female Chinese voice bellowing out of the hub when you try to add devices. Once you jumped through the hoops of adding the hub to OpenHAB, any new devices appear in the Inbox for inclusion. As per the binding documents, I’ve blocked the hub from any external access. It means I can’t use the app, but I don’t need it as OH handles it all for me.

Using in OH

One of the things that took me a while to figure out was the alarm timer channel for the door sensor.

Number DoorSwitch_AlarmTimer <clock> { channel="mihome:sensor_magnet:<ID>:isOpenAlarmTimer" }

This value needs to be set on the hub by OH and determines how long the door should be in an OPEN state before the ‘isOpenAlarm’ switch to be triggered. I believe it’s currently defaults to 300 seconds, but I recommend experimenting.

In my rules I set the value on system startup

sendCommand(DoorSwitch_AlarmTimer,120)
or in the newer format
DoorSwitch_AlarmTimer.sendCommand(120)
So the alarm will trigger if the door is open for more than 120 seconds.
I’m happy with the kit so far, but finding somewhere to put the hub is an issue – it only comes with an integrated plug for use in China, so a China -> UK adapter is needed, which adds to the height of the device. With an adapter it is now about 15cm high, so far too big to just plug into the wall!

Next Steps

I’ve got a couple of Z-Wave Fibaro motion detectors that also supply temperature and humidity info that go through batteries at an incredible rate. To be honest, the temperature and humidity data is more important that the motion sensor, so I’ve ordered a couple of temp & humidity sensors to replace them as well as 2 more buttons.

 

FYI – These devices are NOT always CE certified for use in the UK, so using them is at your own risk.

Links:

https://xiaomi-mi.com/sockets-and-sensors/xiaomi-mi-gateway-2/

https://docs.openhab.org/addons/bindings/mihome/readme.html

 

Whoa

Posted: June 16, 2017 in Audio, HA, House, Work Stuff
Tags:

Well, apparently it’s been almost 6 months since I last posted…. where did the time go? New job, new projects and general family I guess.

Anyway, I had been playing with the HiFiPi, but I got sidetracked by trying to get it working with Logitech Media Server that runs on the family server… that way I can integrate it with OpenHAB and control it around the house (read turn off the kids music after bedtime!). That diverted into trying to get a touchscreen working and then the Pi got requisitioned for a different project…

A MagicMirror project…. that then involved me writing a couple of public transport modules – bus stop info and railway info just because I felt the need to write something! The not being a developer/R&D engineer occasionally bites.

That led to me rebuilding OpenHAB (again) using the new OpenHABian RPi image and then trying to tidy up the sprawl that our OH installation had become. Basically trying to make it a bit more ‘logical’; grouping rooms by floor and use, new targeted site maps and stuff like that rather than having one huge file for all items, one for rules, one multi-level sitemap etc etc. I’m now involved in helping to test a new OH binding that is used to control the Honeywell EvoHome system.

I’ve also finally got a reasonable amp and speakers in the lounge… but of course that meant cleaning up the rats nest of cables behind the AV cupboard and retiring as part of installing the amp!

So I have been doing stuff… I’ve just been too busy actually doing it to blog about it.

So I’ve gone through two use cases so far, and I have successfully got these working using the basic plug and play parts of an introduction to electronics kit. No soldering, just pushing pins into the prototyping board. The next couple of use cases I think I’ve figured out, but as the cheap electronics are coming from eBay via China, I’m still waiting for the parts to arrive before I actually try these ones….

So this is (at time of writing) all theory!

Use Case 3 – Volume Control

While the X400 has an on-board volume dial, I’m not convinced that I can build a suitable mechanical coupling to allow me to expose this outside of the enclosure. My gut reaction is to use this as the max level control and then use software to control the volume up to this hard limit. Volumio will then treat this as the 100 (max) point in its volume scale and allow users to set volumes. Volumio can also set the mute the same way, but how do I control the volume?

I believe that I can control the volume via the software mixer in Volumio. Like with mpc, I should be able to issue a command to increase or decrease the volume. As with my previous two use cases, adding a switch to the GPIO and detecting it appears to solve this problem.

Adding another set of switches seems ‘wrong’…. So perhaps I should try something a little bit more complex and user friendly? Maybe using a rotary encoder (a dial!) instead to control the volume? Maybe I should be really smart and try a rotary encoder with a push button (a dial you can click) to allow for mute as well?

usecase3

Rotary Encoder – NO Switch

Python Code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from RPi.GPIO import GPIO
from time import sleep

#Define GPIO Pins that have buttons
clk = 5            #volume dial clk
dt = 6             #volume dial dt

GPIO.setmode(GPIO.BCM)
GPIO.setup(clk, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(dt, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

volume = 0
clkLastState = GPIO.input(clk)

def changeVol(newVolume):
    print ("New volume is " + newVolume)

try:
    while 1:
        clkState = GPIO.input(clk)
        dtState = GPIO.input(dt)
        if clkState != clkLastState:
            if dtState != clkState:
                volume += 1
            else:
                volume -= 1
            changeVol(volume)
        clkLastState = clkState
        sleep(0.01)
finally:
        GPIO.cleanup()

Update: The encoder I have has 5 pins, not 3…. clk/dt/GND/3.3V/something…. and that is represented in the code above. It still doesn’t have a ‘switch’.

Update: The latest version of Volumio has its own command line client that allows for volume setting.

volumio volume <value>

Use Case 4 – Radio Stations

The final use case is the ability to switch to live radio streams – something that is a must in a kitchen radio! I think we’re back to simple GPIO buttons on this one, with each one triggering a predefined playlist of a single stream. How we trigger the actual stream is something I’ve yet to figure out.

usecase4

Radio Preset 1, 2 & 3

Still working on this bit…. #sigh

 

Use Case 5 – Modes

OK, so I lied. While playing with the HiFiPi I realised that the music is playing out of both the speakers and the headphone socket. As it was late and I didn’t want to wake the kids I needed someway to turn the speakers off. The X400 comes with 3 jumpers that are used to turn the amp on & off, the headphones on & off and mute all the outputs. Trouble is moving these around once inside the enclosure will be impossible.

x400-drawing

X400 Output Jumpers

As these are fixed jumpers, it should be possible to use locking switches to fix the state in either open or closed, thus enabling the device component. A quick email to Suptronics support revels that this is true, so I now need to add locking switches to the shopping list to test.

This will mean I can add a mute button without using up a GPIO or adding code. The other two modes – headphones & speakers are more useful to me using the setup in the study at night. That way I can turn off the speakers and just use the headphones to stop me from waking the kids.

Parts List (so far):

Wire – whatever is appropriate to you setting!

2x 1 row pin headers

Momentary contact switch x1 – for ON

Momentary contact switch x1 – for OFF

Momentary contact switch x4 – Media shuttle commands

1x Rotary encoder

Momentary contact switch x3 – Radio preset buttons

Locking switches x3 – Mode output control

So now the real learning starts. I need to decide what I want the box to do, how to do it and then build it. Easy huh? The code that I reference here is also in my GitHub repo, it’s likely that these snippets get superseded as I figure out how the stuff works. I’m also using the excellent Fritzing to figure stuff out with the wiring, so it may pay to look at that as well if you want to design your own parts.

The other thing to note is that my switch circuits run from the GPIO Pin to GND – making the Pins use the PULL UP resistor in the Python code. If I had run the switches from Pin to 3.3V, PULL DOWN resistors would need to be declared.

As we are access the GPIO, all the python code will need to be run under sudo to gain access.

Use Case 1 – We must be able to turn the player On and Off via a switch

OK so after a lot of Googling it becomes apparent that all the normal method to deal with this – add on boards with switches – are inappropriate because of the X400. As the X400 provides power to the Pi, none of the aftermarket solutions will work.

Use Case 1 (Amended) – We must be able to turn the player On and Off

The answer (in theory) is to use the ‘reset’ switch header as an ON and to add a switch to the GPIO with some code to handle the OFF part.

There is a P6 header on the RPi boards that allows you to reset the device when it is shorted. While absolutely not suitable for a clean shutdown, it will restart the box if it is in a powered but shutdown state. The issue is that this header isn’t populated, so we will need to add some pins prior to connecting a switch of some kind. This means soldering the pin header to the board itself (gulp) and then connecting the new header pins to a switch. So that’s the ON part sorted.

For OFF, connecting a momentary switch to one of the GPIO Pins and then detecting it with some Python to trigger the appropriate shutdown command appears to be the easiest and safest method. This protects the SD card and ensures that everything is clean before shutting down. As power is still applied, we can use the new ON switch to restart when required.

usecase1
Simple shutdown switch
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Assumes switch is connected to GND - so uses PULL UP

import subprocess
import time
import os
import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)

button = 20

GPIO.setup(button, GPIO.IN, GPIO.PUD_UP)

while True:
 button_state = GPIO.input(button)
 if button_state == GPIO.HIGH:
  pass
 else:
  print ("Shutdown")
 #os.system("sudo shutdown -h now") # Send shutdown command to os
 time.sleep(0.5)

Use Case 2 – Play, Pause, Next, Previous & Stop

So after some more Googling it seems that I can use the MPC client (the Music Player Daemon command line bit) to control playback from the command line. As Volumio includes this part, simply issuing commands allows us to control things via the terminal.

 mpc play

mpc pause

mpc stop

Issuing just

mpc

Will return a list of commands you can use.

So we’re back to the GPIO with an additional 5 4 momentary switches, each of which then uses Python to issue the appropriate mpc command.

** UPDATE **

Oops. While working on building the device modes (see Part 5), I realised that GPIO Pin 17 (Board Pin11) is already claimed by the IR receiver on the X400. This means that I have now lost my ‘play’ button. The solution is to remove GPIO 17 from the code and change the GPIO 27 (Board Pin13) from

mpc pause

To

mpc toggle

Which, unsurprisingly, toggles play/pause. The other advantage is 1 less button to fit somewhere on the final case!

usecase2

Play/Pause, Stop, Previous & Next

Python Code:

#!/usr/bin/python
# -*- coding: utf-8 -*-
# Assumes switch is connected to GND - so uses PULL UP

import os
import subprocess
import time
import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)

#Define GPIO Pins that have buttons
play_pause = 27 #Play/pause mpc toggle
stop = 22 #mpc stop
prev_track = 18 #mpc prev
next_track = 23 #mpc next

power_off = 20 # sudo halt now

#Configure PULL Up and pin connections
GPIO.setup(play_pause, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(stop, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(prev_track, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(next_track, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(power_off, GPIO.IN, GPIO.PUD_UP)

#Begin loop to wait for button press
while True:
 if GPIO.input(play_pause) == GPIO.LOW:
  print ("Play/Pause")
  subprocess.call(['mpc', 'toggle' ])
 elif GPIO.input(stop) == GPIO.LOW:
  print ("Stop")
  subprocess.call(['mpc', 'stop' ])
 elif GPIO.input(prev_track) == GPIO.LOW:
  print ("Previous")
  subprocess.call(['mpc', 'prev' ])
 elif GPIO.input(next_track) == GPIO.LOW:
  print ("Next")
  subprocess.call(['mpc', 'next' ])
 elif GPIO.input(power_off) == GPIO.LOW:
  print ("Shutdown")
  #os.system("sudo shutdown -h now") # Send shutdown command to os
 else:
  #print ("Nothing")
  pass

 time.sleep(0.25)
Parts List (so far):

Wire – whatever is appropriate to you setting!

2x 1 row pin headers

Momentary contact switch x1 – for ON

Momentary contact switch x1 – for OFF

Momentary contact switch x54 – Media shuttle commands

Links & Refs:

GitHub: https://github.com/nwootton/HiFiPi

Reset Switch – http://www.raspberry-pi-geek.com/Archive/2013/01/Adding-an-On-Off-switch-to-your-Raspberry-Pi

In the previous two parts I’ve looked at building something a little more capable for audio playback. What I’ve built works brilliantly with headphones, but isn’t in any way  suitable for use by ‘normal’ people and definitely not with small children around.

So I decided to look at following the herd and try to build the new music player in an old enclosure. After much eBay hunting, I found several nice radios that could be refactored. My issue with them was the size.

If I want to build a stereo radio I need 2 speakers (obvious huh?), but most of these radios are mono, so adding a second speaker either means running two tiny speakers or modifying the case to allow for a second speaker. Either way two speakers take up space and the X400 is already considerably bigger than the HiFiBerry or equivalent board.

If I go the whole hog and try to include some form of interface/screen then a repurposed radio chassis is completely unsuitable. I can try and find a large (think valve type) radio from before the modern radio. These are generally quite large but come with wooden cases that can make the end product look gorgeous. This scenario gives me the opposite problem. The end product would be far too big to sit in the kitchen, it would be more appropriate for the dining room or somewhere as a centre-piece.

The X400 is rated to drive 2x 20W speakers, I had originally planned to buy some car speakers from eBay once I had the rough dimensions of the enclosure I wanted them to go into. So everything really hung off of finding a decent box to put it in.

Being a total novice at this stuff, I decided that it makes more sense to try and build something, learning as I go. I’d have to be prepared to completely get it wrong, throw away stuff and to start again. Once I’d figured things out, maybe then I could build the ‘final’ version.

With this in mind I decided I would get a broken Roberts Colourstream internet radio. While big and modern, it has a couple of decent speakers and a touch screen that I hoped I could re-use. The case should be big enough to fit everything inside and it is already configured for stereo.

roberts_colourstream

Roberts Colourstream Internet DAB Radio

The previous owner had attempted to ‘fix’ the device – resulting in the guts basically being supplied in a separate bag, but that was just one less thing for me to do. Removing the facia allowed me to get to the speakers and after a couple of minutes work  I had stripped the plugs off the speakers and had wired them directly into the X400. A boot of the Pi and suddenly we have music from the speakers.

The next part is figuring out what I want to do, how to do it and what parts are needed!

 

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.