Not the book of the movie, but the collection of short stories by Isaac Asimov. I’ve read this book several times before and enjoyed it, although this time I found it to be more dated than I remembered, both in its characterisations of technology as well as it’s handling of gender. Still enjoyable, but not the best book I’ve read recently.
One of the things I like about Home Assistant is that it allows you to take hardware from a bunch of various vendors and stitch it together into a single consistent interface. So for example I now have five home automation vendor apps on my phone, but don’t use any of them because Home Assistant manages everything.
A concrete example — we have Philips Hue lights, but they’re not perfect. They’re expensive, require a hub, and need to talk to a Philips data centre to function (i.e. the internet needs to work at my house, which isn’t always true thanks to the failings of the Liberal Party).
I’d been meaning to look at the cheapo smart lights from Kmart for a while, and finally got around to it this week. For $15 you can pickup a dimmable white globe, and for $29 you can have a RGB one. That’s heaps cheaper than the Hue options. Even better, the globes are flashable to run the open source Tasmota stack, which means no web services required!
So here are some instructions on flashing these globes to be useful:
Flash to tasmota. This was a little bit fiddly, but was mostly about getting the sequence to put the globes into config mode right (turn off for 10 seconds, turn on, turn off, turn on, turn off, turn on). Wait a few seconds and then expect the lamp to blink rapidly indicating its in config mode. For Canberra people I now have a raspberry pi setup to do this easily, so we can run a flashing session sometime if people want.
Configure tasmota. This is really up to you, but the globes need to know local wifi details, where your MQTT server is, and stuff like that.
And then configure Home Assistant. The example of how to do that from my house is on github.
This site is hosted at Dreamhost, and for reasons I can’t explain right now isn’t accessible from large chunks of Australia. It seems to work fine from elsewhere though. Dreamhost certainly has an explaination — they allege in their emails that take 24 hours that you can’t reply to that its because wordpress is using too much RAM.
However, they don’t explain why that’s suddenly happened when its been previously fine for years, and they certainly don’t explain why it works from some places but not others and why other Dreamhost sites are also offline from the sites having issues.
Its time for a new hosting solution I think, although not bothering to have hosting might also be that solution.
This is the third book in the Leviathan Wakes series by James SA Corey. Just as good as the first two, this is a story about how much a daughter loves her father, perhaps beyond reason, moral choices, and politics — just as much as it is the continuation of the story arc around the alien visitor.
Another excellent book, with a bit more emphasis on space battles than previously and an overall enjoyable plot line. Worth a read, to be honest I think the series is getting better.
We’ve owned this book for a while, but ironically Catherine lost it for a bit. It seems very topical at the moment because of the Marie Kondo craze, but its been floating around our house for probably a year.
The book is written by an 80+ year old and explains the Swedish tradition of sorting your stuff out before you keel over, which seems like a totally reasonable thing to do when the other option is leaving your grieving kids to work out what on earth to do. The book isn’t as applicable to people not at the end of the lives — it for example recommends starting with large things like furniture and younger people are unlikely to have heaps of unneeded furniture.
That said, there is definitely advice in here that is applicable to other life stages.
The book is composed of a series of generally short chapters. They read a bit like small letters, notes, or blog posts. This makes the book feel very approachable and its a quite fast read.
I enjoyed the book and I think I got some interesting things out of it.
Catherine and I have been huge fans of Adam Hills for ages, so it wasn’t a surprise to me that I’d like a book by him. As an aside, we’ve never seen him live — we had tickets for his show in Canberra in 2013, but some of us ended up in labor in hospital instead, so we had to give those tickets away. One day we’ll manage to see him live though, he just needs to get back to touring Australia more!
Anyways, I enjoyed this book which as mentioned above wasn’t a surprise. What was a surprise is that he said something interesting which I have been pondering for the last few days…
Basically, its nice to get on stage and say things, either entertaining the audience or in my case perhaps educating them a little (I give technical conference talks). However, that’s not the most important thing. You need to work out why you’re on that stage before you go out there. What is the overall thing you’re trying to convey? Once you know that, everything else falls into place. I think this is especially true for keynote speeches, which need to appeal to a more general audience than a conference talk where people can pick from a menu.
What Adam seems to be saying in his comedy (at least to me) is to embrace life and be good to each other. Adam is a super positive guy, which is delightful. There is something very special about someone who lifts up those around them. I hope to be that person one day.
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.
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.
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.
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… 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.
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.
So, I’ve been off in the GPIO library salt mines for a while, but am now ready to circle back and document how to get GPIO inputs and outputs working in Home Assistant. This now works on both Raspberry Pi and OrangePi, assuming that my patch gets merged.
First off, let’s talk about GPIO outputs. This is something which has been working for a while on both platforms (a while being a week or so, assuming you’ve patched Home Assistant with my pull request, but you’re all doing that right?).
To configure an output in Home Assistant, you would add the following to configuration.yaml:
rpi_gpio: board_family: orange_pi switch: - platform: rpi_gpio ports: PA7: LED
Where board_family can be either “raspberry_pi” or “orange_pi”. Note that for Raspberry Pis, the pin numbers are always numbers whereas for OrangePi we are using “SUNXI” numbering, which is of the form “PA7”.
The circuit for this LED is really simple:
Now we have a switch we can control in Home Assistant:
GPIO inputs are similar. The configuration looks like this:
rpi_gpio: board_family: orange_pi binary_sensor: - platform: rpi_gpio invert_logic: true ports: PA7: PUSHYBUTTON
With a circuit like this:
invert_logic set to true is required because our circuit sends the value of PA7 to ground when the button is pressed.
Noting that sensors look different to switches in Home Assistant, you can see the binary sensor at the top right of the image, with its history being displayed in the dialog box in the foreground.
As part of working through adding OrangePi support to Home Assistant, Alastair and I decided to change to a different GPIO library for OrangePi to avoid the requirement for Home Assistant to have access to /dev/mem.
I just realised that I hadn’t posted updated examples of how to do GPIO output with the new library. So here’s a quick post about that.
Assuming that we have an LED on GPIO PA7, which is pin 29, then the code to blink the LED would look like this with the new library:
import OPi.GPIO as GPIO import time # Note that we use SUNXI mappings here because its way less confusing than # board mappsings. For example, these are all the same pin: # sunxi: PA7 (the label on the board) # board: 29 # gpio: 7 GPIO.setmode(GPIO.SUNXI) GPIO.setwarnings(False) GPIO.setup('PA7', GPIO.OUT) while True: GPIO.output('PA7', GPIO.HIGH) time.sleep(1) GPIO.output('PA7', GPIO.LOW) time.sleep(1)
The most important thing there is the note about SUNXI pin mappings. I find the whole mapping scheme hugely confusing, unless you use SUNXI and then its all fine. So learn from my fail people!
What about input? Well, that’s not too bad either. Let’s assume that you have a button in a circuit like this:
The to read the button the polling way, you’d just do this:
import OPi.GPIO as GPIO import time GPIO.setmode(GPIO.SUNXI) GPIO.setwarnings(False) GPIO.setup('PA7', GPIO.IN, pull_up_down=GPIO.PUD_DOWN) while True: print('Reading...') if GPIO.input('PA7') == GPIO.LOW: print('Pressed') else: print('Released') time.sleep(1)
Let’s pretend it didn’t take me ages to get that to work right because I had the circuit wrong, ok?
Now, we have self respect, so you wouldn’t actually poll like that. Instead you’d use edge detection, and end up with code like this:
import OPi.GPIO as GPIO import time GPIO.setmode(GPIO.SUNXI) GPIO.setwarnings(False) GPIO.setup('PA7', GPIO.IN, pull_up_down=GPIO.PUD_DOWN) def event_callback(channel): print('Event detected: %s' % GPIO.input('PA7')) GPIO.add_event_detect('PA7', GPIO.BOTH, callback=event_callback, bouncetime=50) while True: time.sleep(1)
So there ya go.