1-Wire home automation tutorial from linux.conf.au 2019, part 2

Share

For the actual on-the-day work, delegates were handed a link to these instructions in github. If you’re playing along at home, you should probably read 1-Wire home automation tutorial from linux.conf.au 2019, part 1 before attempting the work described here. Its especially important that you know the IP address of your board for example.

Relay tweaks

The instructions are pretty self explanatory, although I did get confused about where to connect the relay as I couldn’t find PC8 in my 40 pin header diagrams. That’s because the shields for the tutorial have a separate header which is a bit more convenient:

GPIO header

I was also a bit confused when the relay didn’t work initially, but that turns out because I’d misunderstood the wiring. The relay needs to be powered from the 3.3v pin on the 40 pin header, as there is a PCB error which puts 5v on the pins labelled as 3.3v on the GPIO header. I ended up with jumper wires which looked like this:

Cabling the relay

1-Wire issues

Following on the tutorial instructions worked well from then on until I tried to get 1-Wire setup. The owfs2mqtt bridge plugin was logging this:

2019-04-08 19:23:55.075: /opt/OWFS-MQTT-Bridge/lib/Daemon/OneWire.pm:148:Daemon::logError(): Connection to owserver failed: Can't connect owserver: Address not available

Debugging that involved connecting to the owfs2mqtt docker container (hint: ssh to the Orange Pi, do a docker ps, and then run bash inside the docker container for the addon). Running owserver with debug produces this:

owserver fails

Sorry to post that as an image, cut and paste for the hassos ssh server doesn’t like me for some reason. I suspect I have a defective DS2482, but I’ll have to wait and see what Allistair says.

Share

1-Wire home automation tutorial from linux.conf.au 2019, part 1

Share

I didn’t get much of a chance to work through the home automation tutorial at linux.conf.au 2019 because I ended up helping others in the room get their Orange Pi is booting. Now that things have settled down after the conference, I’ve had a chance to actually do some of the tutorial myself. These are my notes so I can remember what I did later…

Pre-tutorial setup

You need to do the pre-tutorial setup first. I use Ubuntu, which means its important that I use 18.10 or greater so that st-link is packaged. Apart from that the instructions as written just worked.

You also need to download the image for the SD card, which was provided on the day at the conference. The URL for that is from github. Download that image, decompress it, and then flash it to an SD card using something like Balena Etcher. The tutorial used 32gb SD cards, but the image will fit on something smaller than that.

hassos also doesn’t put anything on the Orange Pi HDMI port when it boots, so your machine is going to look like it didn’t boot. That’s expected. For the tutorial we provided a mapping from board number (mac address effectively) to IP address allocated in the tutorial. At home if you’re using an Orange Pi that isn’t from the conference you’re going to have to find another way to determine the IP address of your Orange Pi.

The way we determined MAC addresses and so forth for the boards used at the conference was to boot an Armbian image and then run a simple python script which performed some simple checks of each board by logging into the board over serial. The MAC addresses for the boards handed out on the day are on github.

An Aside: Serial on the Orange Pi Prime

As an aside, the serial on the Orange Pi Prime is really handy, especially with the hassos image. Serial is exposed by a three pin header on the board, which is sort of labelled:

Orange Pi Prime Serial Port
The Orange Pi Prime Serial Port

Noting that you’ll need to bend the pins of the serial header a little if you’re using the shield from the conference:

Serial port connected to a USB to serial converter

The advantage being that suddenly you get useful debugging information! The serial connection is 115200 baud 8N1 (8 data bits, no parity, 1 stop bit) by the way.

Serial debug information from an hassos boot

The hassos image used for the conference allows login as root with no password over serial, which dumps you into a hass interface. Type “login” to get a bash prompt, even though its not in the list of commands available. At this point you can use the “ip address” command to work out what address DHCP handed the board.

The actual on-the-day work

So at this point we’re about as ready as people were meant to be when they walked into the room for the tutorial. I’ll write more notes when I complete the actual tutorial.

Share

linux.conf.au should rethink how they present hardware content at linux.conf.au

Share

I was originally going to pursue this as a bit of a project in 2019, but that’s no longer possible as I resigned from the linux.conf.au papers committee late on Thursday to spend more time with my family. So instead I’ll just throw this out there and maybe something will come of it, but also maybe not.

Should hardware events such as the Open Hardware miniconf or this year’s Home Automation workshop be part of linux.conf.au? Certainly they’re very popular, often selling out and having to maintain waiting lists in case someone cancels.

Let me take you on an journey and explain why is hard to take hands on hardware content for the conference… I feel qualified to have an opinion on all this having served on the LCA papers committee since 2004, and having been on a conference core team twice.

Complexity

Hardware assembly sessions are much more complicated to run well than a conference talk. While we expect conference speakers to be well researched and have depth in their field, we don’t expect them to perform flawlessly in an environment with a lot of variables. A static slide deck or maybe a demo or two is all we ask of them.

On the other hand, we do expect hardware assembly sessions to take a group of people with varying skill levels, and get them to assemble non-trivial hardware and have it work at the end. These devices have now reached a level of complexity where they have surface mount components, microprocessors equivalent to to the one in your phone, and software stacks often as large as that on your laptop.

Under recognition of the number of people involved

I haven’t asked the Open Hardware miniconf how many people hours were spent preparing for this year, but I am sure it was a lot. I know that Alastair D’Silva spent a truly huge amount of time on his preparation — think all his spare time for several months while having a small child.

How do we reward that preparation effort? With a single conference ticket. This discourages there from being a team contributing to the project, because at the end of the day only one person can be rewarded with a discount to LCA. This happens because the conference has budget concerns, and can’t give away 20 free tickets to a miniconf without running the risk of failing to break even. It is also because the assumption in the past has been that miniconfs are “conference light” and require less preparation than a main conference talk, and therefore the reduced subsidy for the event was justified.

Lead time

The conference papers review process is fairly complicated these days, with a lot of effort put into promoting the event so that we get the widest range of speakers possible, as well as a diverse review team attempting to ensure that we have good representation of the topic areas you expect to have covered at LCA, as well as diversity in our speaker population. This means that while we normally advertise our call for papers in July, we don’t normally inform speakers that they have been accepted until September.

So, we have complicated hardware projects with a lot of variables, and we give the presenters three months runway to prepare.

One of the obvious ways to lengthen the runway is to just assume your proposal will be accepted, and start preparing earlier. However, that brings me to my next concern…

Out of pocket expenses

Let’s assume you start preparing for your hardware event earlier than September. Let’s also assume that because your hardware is a little complicated and involves surface mount components, that you’ll go through a few prototype rounds and get the final board partially fabricated professionally. This is how things work at the moment.

Guess who gets to pay for that? The organisers of the event. One of those organisers this year was personally out of pocket over $10,000. If the event doesn’t go ahead, or if no one registers for it, then that money is gone. That doesn’t strike me as fair when Linux Australia has $800,000 in the bank at the moment.

The registration process is a nightmare

I don’t know if you noticed, but the registration process for hardware events is also a mess. Again, its up to the individuals running the event to collect money from participants and ensure that there is a fair registration process. The first indications of the level of interest from conference attendees are in the few weeks before the conference itself, when its way too late to course correct if that’s needed.

This is harder than it looks, and comes at a time when the team is flat out ensuring the event runs at all. Worse, then people get annoyed and complain.

Finally on registration, the events are too expensive. In an attempt to simplify registration, there’s only one option — buy the hardware. However, if you already own a Raspberry Pi, why would you buy another one? That’s an extra $60 or so that you’re charged for hardware that you probably don’t really want. If you do want another Raspberry Pi great, but it should be an add on to the event registration.

In summary

Conference organisers generally phrase things in terms of risk versus reward when trying to run a conference. So, the hardware events we have at LCA are high reward for those who attend them, but hugely risky for the conference. Failure of such an event would reflect poorly on LCA, which has worked for 20 years to have a reputation as one of the best technical conferences in the world.

So this is why we shouldn’t run these hardware events — they’re risky, as well as being a super hard slog for the people running them.

But…

But… They’re also hugely popular and an important part of what LCA has become. In a way, LCA is what it is because it embraces a diversity of interests. Without the hardware events, LCA would be diminished from what we have today.

So instead…

If we can’t accept not having these hardware events, we’re only really left with one other option. Let’s blow up the status quo and find a better way of running them.

That’s what originally wrote this post to do — propose something concrete that minimises the impact on the conference organising team while reducing the risk of these events failing and hopefully making life easier for the event organisers.

So here’s Michael’s simple plan for hardware events at LCA:

There should be a separate call for hardware content from now on, for a specific small number of hardware slots at the conference. This should be done really really early. Like stupidly early. As in, opening next month for 2020 and closing in in March. One of the things which holds the call for papers for the main conference up is having the conference web site ready. So let’s not do that — we can use a Google form or something instead. The number of proposals is going to be small, and we can use a “higher touch” process for the review and approval process.

Linux Australia should provide fiscal sponsorship for seed funding to accepted events, based on a proposed bill of materials that is submitted as part of the proposal, on similar terms as is provided for LCA itself and other conference. In other words, Linux Australia should bear the financial risk of failure. Linux Australia should also directly fund conference tickets for hardware event organisers — obviously, we need to somehow validate how many people actually did some work and there need to be limits, but that can be worked through without too much pain.

The LCA website itself should offer registration for hardware events. I see this as relatively trivial in that we can just treat these events as new types of t-shirts and the code to handle that has been around for a really long time.

And finally, we as a community should recognise better the huge amount of effort that has gone into these events in the past (and hopefully in the future) and make a point of thanking the organisers as often as possible. Sometimes there might be warts, but these are human beings like most of us working hard to do something complicated and exciting while still holding down day jobs.

As I said at the start, I had intended to have a go at fixing these issues this year, but events have overtaken me and that will no longer be possible. Hopefully someone else will have a go.

Share

The linux.conf.au 2016 Call For Proposals is open!

Share

The OpenStack community has been well represented at linux.conf.au over the last few years, which I think is reflective of both the growing level of interest in OpenStack in the general Linux community, as well as the fact that OpenStack is one of the largest Python projects around these days. linux.conf.au is one of the region’s biggest Open Source conferences, and has a solid reputation for deep technical content.

Its time to make it all happen again, with the linux.conf.au 2016 Call For Proposals opening today! I’m especially keen to encourage talk proposals which are somehow more than introductions to various components of OpenStack. Its time to talk detail about how people’s networking deployments work, what container solutions we’re using, and how we’re deploying OpenStack in the real world to do seriously cool stuff.

The conference is in the first week of February in Geelong, Australia. I’d be happy to chat with anyone who has questions about the CFP process.

Share

OpenStack at linux.conf.au 2013

Share

As some of you might know, I’m the Director for linux.conf.au 2013. I’ve tried really hard to not use my powers for evil and make the entire conference about OpenStack — in fact I haven’t pulled rank and demanded that specific content be included at all. However, the level of interest in OpenStack has grown so much since LCA 2012 that there is now a significant amount of OpenStack content in the conference without me having to do any of that.

I thought I’d take a second to highlight some of the OpenStack content that I think is particularly interesting — these are the talks I’ll be going to if I have the time (which remains to be seen):

Monday

  • Cloud Infrastructure, Distributed Storage and High Availability Miniconf: while not specifically about OpenStack, this miniconf is going to be a good warm up for all things IaaS at the conference. Here’s a list of the talks for that miniconf:
      Delivering IaaS with Apache CloudStack – Joe Brockmeier

    • oVirt – Dan Macpherson
    • Aeolus – Dan Macpherson
    • Ops: From bare metal to cloud space – Phil Ingram
    • VMs on VLANs on Bridges on Bonds on many NICs – Kim Hawtin
    • OpenStack Swift Overview – John Dickinson
    • JORN and the rise and fall of clustering – Jamie Birse
    • MongoDB Replication & Replica Sets – Stephen Steneker
    • MariaDB Galera Cluster – Grant Allen
    • The Grand Distributed Storage Debate: GlusterFS and Ceph going head to head – Florian Haas, Sage Weil, Jeff Darcy

Tuesday

  • The OpenStack Miniconf: this is a mostly-clear winner for Tuesday. Tristan Goode has been doing a fantastic job of organizing this miniconf, which might not be obvious to people who haven’t been talking to him a couple of times a week about its progress like me. I think people will be impressed with the program, which includes:
    • Welcome and Introduction – Tristan Goode
    • Introduction to OpenStack – Joshua McKenty
    • Demonstration – Sina Sadeghi
    • NeCTAR Research Cloud: OpenStack in Production – Tom Fifeld
    • Bare metal provisioning with OpenStack – Devananda van der Veen
    • Intro to Swift for New Contributors – John Dickinson
    • All-around OpenStack storage with Ceph – Florian Haas
    • Writing API extensions for Nova – Christopher Yeoh
    • The OpenStack Metering Project – Angus Salkeld
    • Lightweight PaaS on the NCI OpenStack Cloud – Kevin Pulo
    • Enabling Compute Clusters atop OpenStack – Enis Afgan
    • Shared Panel with Open Government
  • The Open Government Miniconf: this is the other OpenStack relevant miniconf on Tuesday. This might seem like a bit of a stretch, but as best as I can tell there is massive interest in government at the moment in deploying cloud infrastructure, and now is the time to be convincing the decision makers that open clouds based on open source are the right way to go. OpenStack has a lot to offer in the private cloud space, and we need to as a community make sure that people are aware of the various options that are out there. This is why there is a shared panel at the end of the day with the OpenStack miniconf.

Wednesday

    There aren’t any OpenStack talks on Wednesday, but I am really hoping that someone will propose an OpenStack BoF via the wiki. I’d sure go to a BoF.

Thursday

  • Playing with OpenStack Swift by John Dickinson
  • Ceph: Managing A Distributed Storage System At Scale by Sage Weil

Friday

  • Openstack on Openstack – a single management API for all your servers by Robert Collins
  • Heat: Orchestrating multiple cloud applications on OpenStack using templates by Angus Salkeld and Steve Baker
  • How OpenStack Improves Code Quality with Project Gating and Zuul by James Blair
  • Ceph: object storage, block storage, file system, replication, massive scalability, and then some! by Tim Serong and Florian Haas

So, if you’re interested in OpenStack and haven’t considered linux.conf.au 2013 as a conference you might be interested in, now would be a good time to reconsider before we sell out!

Share

Long time not much write

Share

I haven’t written much in the last couple of months, but I have good excuses. Mainly, its a combination of joining a new team at work (its cool, but I’d have to kill you), playing with some cool toys, developing a new personal obsession, Andrew starting school, and not having much to say.

To make up for this, I give you a picture of me bowling last Friday:

I’ll also give you a sneak peek at that new personal obsession:

“There is little data on the relative popularity of the various
available SMTP server implementations. This data is of
interest because it aids the development of systems which
interact with these servers. For example, a potential DDoS
protection system should be tested with the most common
SMTP servers, as these are the ones that it is most likely to
encounter in everyday use.

This poster will describe our efforts to measure the deployment of SMTP servers on the Internet, using a combination
of passive observation of email traffic, as well as active probing of SMTP servers. A description of the methodology is
provided, as well as early results.”

That’s part of my poster proposal for LISA 2007 which I will be attending.

Share

MySQL Users Conference

Share

Well, they’re definitely thinking about getting started. Like last year I caught the VTA down — it’s hard to beat a $1.75 trip without having to worry about traffic. Registraton wasn’t as smooth this year as last, for example I didn’t get my free book (there didn’t seem to be any attempt to hand those out to speakers). Whatever.

I’m now waiting for the replication talk to start.

Share