There are a couple of things I do not like with the default WordPress UI, namely the “Featured Post” header:

and the “Proudly powered by WordPress” quote at the bottom of the page.

Here are the hacks I use to remove them

1)

1. Featured Post:
   1. Appearance > Theme Editor > content.php
   2. HTML Comment out the block :

     <!--<?php if ( is_sticky() && is_home() && ! is_paged() ) : ?>
    <div class="featured-post">
        <?php _e( 'Featured post', 'twentytwelve' ); ?>
    </div>
    <?php endif; ?>-->

1. Proudly powered by WordPress:
   1. Appearance > Theme Editor > footer.php
   2. HTML Comment out the div class=”site-info” block :

    <!--<div class="site-info">
        <?php do_action( 'twentytwelve_credits' ); ?>
        <?php
        if ( function_exists( 'the_privacy_policy_link' ) ) {
            the_privacy_policy_link( '', '<span role="separator" aria-hidden="true"></span>' );
        }
        ?>
        <a href="<?php echo esc_url( __( 'https://wordpress.org/', 'twentytwelve' ) ); ?>" class="imprint" title="<?php esc_attr_e( 'Semantic Personal Publishing Platform', 'twentytwelve' ); ?>">
            <?php
            /* translators: %s: WordPress */
            printf( __( 'Proudly powered by %s', 'twentytwelve' ), 'WordPress' );
            ?>
        </a>
    </div>--><!-- .site-info -->

Ubuntu lists USB devices by default under /dev/ as ttyUSBx where x is a number starting 0. Issue with this is if USB devices are swapped to a different port, it’s not clear with ttyUSBx device relates to which physical USB device.
There are a few ways to change settings to point to the correct USB Device. I’ll list to 2 most common ways. The below is an examples for an RFXTrx433 USB Transceiver, but the process works the same for any other USB device.

Option A

1. Point the app to the device’s serial id. Run this in a terminal:

   ls /dev/serial/by-id/

2. This will list all serial USB devices. Pick the one that you need to communicate with and set its address in your app, e.g.

   /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1XETWB5-if00-port0

Option B

1. 1. Run this in a terminal:

      udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)

      (if necessary replace ttyUSB0 with ttyUSB1)

   2. You need to locate the block where it gives you the correct value for your device, ATTRS{manufacturer} and/or ATTRS{product} and take note of the ATTRS{idVendor} ATTRS{idProduct} and ATTRS{serial}:
      
   3. Edit the following file with your preferred editor:
      /etc/udev/rules.d/99-usb-serial.rules and add this line:

      ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A1XETWB5", SYMLINK+="RFXTrx433"

   4. Replace the values in ATTRS{idVendor} ATTRS{idProduct} and ATTRS{serial} with the ones you found in previous step, replace RFXTrx433 with a name that makes sense to you. Save and Exit
   5. Run this in a terminal:

      sudo udevadm control --reload && sudo udevadm trigger

   6. You should then have a new device listed in /dev matching the name you provided after SYMLINK. To confirm, run this in terminal:

      ls /dev/RFX*

      (replace RFX with the name you provided after SYMLINK)

   7. Enter the device’s “new” address in your app, e.g.

      /dev/RFXTrx433

Now it does not matter which USB port your device is connected to, it will always be found.

I’ve recently discovered OpenALPR and I’m really impressed by it.

OpenALPR is a software that performs Automatic Licence Plate Recognition (Hence ALPR) from a video stream. The free account is quite basic as it does not offer alerts, but it still allows plate recognition and saves them as well as the actual picture for a few days.

All I had to do was to install the agent and create an account on http://cloud.openalpr.com

And this is how impressive it is at recognizing plates:

OpenALPR Full Image

OpenALPR Console

It appears to be quite resource hungry though (well my camera’s resolution is 3072 x 1728 !) so I’ve only got 1 camera fed through the agent now. I’m planning on trialling another agent on a raspberry pi and see how it copes…

[EDIT – 16th Aug 2018]

Turns out a Raspberry Pi would not be strong enough to cope, or so that’s what the people at OpenALPR say… 🙁

I saw this little plug on Amazon recently and decided to add it to my “arsenal” of gadgets.

Edimax SP-2101W

The interesting bit about it is that not only it can be remotely controlled, but it also provide energy monitoring, so you know if the “dumb” appliance that’s connected to it is on or off.

I’ve connected my kettle to it as a test, and I think it might stay there for a while now.

Thanks to C4rtm4N I now have the status of my Sky+ HD box in Home-Assistant. When used in conjunction with dalhundal‘s sky-remote-cli it becomes close to a fully fledged solution.

Playback or Live TV is now automatically paused if the Sky+HD box is on…

The code I used (for now, there appears to be times when it generates errors in HA) is:

Sensor to catch the box’s status:

- platform: command_line
  name: sky_hd_status
  command: curl -i -s -o /dev/null -w "%{http_code}" 'http://sky_ip_address:49159/photo-viewing/start?uri=http://any_ip_address/null.jpg' && curl 'http://sky_ip_address:49159/photo-viewing/stop'
  scan_interval: 300

Template Switch to control the box:

- platform: template
  switches:
    skyhd:
      friendly_name: Sky+ HD
      value_template: "{% if states.sensor.sky_hd_status.state == '200' -%}on{% else %}off{% endif %}"
      turn_on:
        service: shell_command.sky_hd_power
      turn_off:
        service: shell_command.sky_hd_power

The shell commands are:

sky_hd_power: sky-remote-cli sky_ip_address power
sky_hd_pause: sky-remote-cli sky_ip_address pause

of course replace the ip addresses with that of the Sky box (which should be fixed by your router). You’ll need to ensure sky_remote_cli is installed of course:

npm install -g sky-remote-cli

Head over to dalhundal‘s page for more info on sky-remote-cli…

I’ve been using the excellent cloudmqtt since my early days getting to know MQTT. It’s been flawless except for about 3-4 times this month where it failed and I had to contact cloudmqtt support. Now I have to praise the support team as they did an excellent job very quickly, but the few faults made me think it was time to get myself my own broker.

In addition to going away from potential third party failures, it would allow me to keep controlling my devices should I have any internet access issues.

So I followed this page to set up mosquitto on my server.

Once done, I didn’t want to just switch everything over from cloudmqtt to mosquitto as I have quite a few devices to connect to cloudmqtt, some less accessible than others. I therefore created a bridge between my mosquitto and cloudmqtt to get the best of both worlds.

This was done by a new mosquitto config in the` /etc/mosquitto/conf.d/ directory`, I used cloudmqtt.conf (it can be any name as long as it ends with .conf so mosquitto will read it) with the following info:

connection cloudmqtt
address <Cloudmqtt Server>:<Cloudmqtt Port>
remote_username <Cloudmqtt User>
remote_password <Cloudmqtt Password>
clientid <Cloudmqtt user>
try_private false
start_type automatic
topic # both

All I then had to do was to point my Home-Assistant config to my own mosquitto broker.

Et voilà !