In the past I often used Email as a way to notify me whenever something happens in my home automation. At first this seemed like a good idea: No extra app needed, I could receive notifications on mobile phone and desktop and even the wife-factor wasn’t very high – she’s using email anyways.
However I stumbled upon unforeseen issues, especially after the update to OpenHAB2:
- Emails were automatically put into my spam folder, since the text never changes
- I used my GMail account to send the mails, which forced me to allow unsecure apps
- Since I used my GMail account, messages sent by OpenHAB were always handled as “Sent”. My wife was getting notifications, but I did not
- In the past I used a GMX account instead, but this service was not as reliable as GMail
- Google put my mails into some sort of automatic spam filter, which prevented OpenHAB from sending any emails
Of course I could solve all these problems, and most of them I have. But I was never really satisfied and recently looked for an alternative. I looked into the following services, but found some disqualifying issues:
- Notify my Android: This app has a lot of bad reviews lately. There is a premium service, but even that seems to be unreliable
- Prowl: I heard a bit about this service, but it seems as if there is no built-in Android support
- Pushover: This service looks really nice by looking at their homepage. But a premium subscription is needed to use it. I do not mind paying for a good service, but if there’s a free alternative available I see no reason to use the paid one
- Twitter: Seems not to be a good idea to have notifications publicly available. I also really don’t like their Android App
In the end I went with Telegram. Telegram is a messaging app like Whatsapp or Threema, but with a major twist: It is possible to define your own bots, these are then usable via an API. I really like the concept and can see this being really useful. Another cool thing about Telegram is that it is available for every platform, not just mobile. Whatsapp and Threema provide this too, but by connecting via the phone. The Telegram web client connects directly to their servers instead of routing via the App. Overall I really like what I’ve seen so far, bummer that all my contacts are using Whatsapp and Threema.
I configured it the following way:
My config looks like the following:
It is then possible to write via the configured bot by using
sendTelegram("stettiner", "This is a test notification!")
The notifications appear on the phone instantly. Cool thing is that it is possible to set the chatId of a group chat, so I have my wife and me in the same group and the bot notifies us.
Today I brought my existing doorbell into OpenHAB via ZWave. Since I did not want to replace my existing wiring, button and bell I had to hack it a bit.
The wiring uses 12V DC and activates a battery-driven bell. So everytime someone pushes the button, 12V will be sent up to the bell which then plays a sound. I figured that I needed something connected to the 12V that notifies OpenHab whenever power gets activated.
In comes my unused Doorsensor by Devolo! This sensor is usually put on a door, a small magnet is placed on the frame. Whenever the magnet is near the sensor, it notifies that the door has been closed. What I did was to connect an electro magnet to the bell wiring and placed the door sensor beside it. So whenever someone rings the bell, the magnet gets activated and the door sensor sends “Door Closed” to the system.
Last weekend I finally took some time to get my home automation system upgraded. I recently had some problems, like not being able to access it remotely anymore. I’m also planning some features that are way easier to realize with OpenHAB2.
The first version of OpenHAB2 got released in January 2017, but has been tested for multiple months now. The main features for me are as follows:
- Out of the box support for REST-calls
- Easy integration with my.openhab.org
- Modernized UI (in fact they provide multiple systems for different usecases)
- HABmin is integrated out-of-the-box
The best thing however is that it’s really easy to install. With a pre-configured Raspberry Pi2 image called Openhabian I was able to set up a new instance of OpenHAB in just a few minutes. Most of my existing configurations could be used without modification, just a few rules needed to get upgraded.
Overall I’m quite happy: Everything works as I want to, in addition I can play with a few new things.
During the last months I had multiple discussions with management about the right workload for software developers. Of course it looks like having a load of 100% is optimal, and for most professions it is. In software development however this is not the best you can do:
- Anything software related is very shortlived. What you’ve learned 2 years ago can be considered a bad practice or dead technology today. It’s one of the main treats of this profession: You’re always learning new things. But you need time to do this.
- Software Development is a very creative process. It’s highly complicated, even for smaller projects there are thousands of possible solutions. You will not find a good solution if you do not have time to think about alternatives. You will also lose your creativity when always working within the same rails.
Henrik Kniberg talks about pauses between Scrum Sprints in his book “Scrum and XP from the Trenches“:
In real life, you can’t always sprint. You need to rest between sprints. If you always sprint, you are in effect just jogging
The concept is quite clear, but I still had a hard time getting this appreciated by management. I recently read a story by Stephen Covey that probably would’ve helped a lot. It was about a man in the woods, working feverishly to saw down a tree:
“What are you doing?”
“Can’t you see? I’m sawing down this tree.”
“You look exhausted, how long have you been at it?”
“Over 5 hours, and I’m beat! This is hard work.”
“Well, why don’t you take a break and sharpen that saw? I’m sure it will go a lot faster.”
“I don’t have time to sharpen the saw. I’m too busy sawing!”
For my new job at Ubimax I need to improve my Java knowledge. I was tinkering around for the last weeks and got to know the language itself, the class library and some technologies like Spring. I also tried different tools, so far I really like IntelliJ and I’m impressed with the amount of tools to improve code quality like Findbugs or Checkstyle.
Playing around just goes that far and soon I needed a project where I could apply what I’ve learned. Luckily I was in need for a very specific usecase: During the last months I accumulated a lot of overhours and Rheinmetall wants me to use them all till my last day. I first calculated manually how many hours I needed to work each day to reach 0 overhours on the last day, but why do this if there’s an app for that?
I created a small and simple Android app called “AppBummler”, based on a German word that describes spending overhours and working less. Just for the sake of it I put it into the Play Store. Feel free to test it out, but it’ll probably not be of any use for a lot of people.
While clearing up my office book shelf I stumbled upon a book I got during my ISAQB training. It’s written in German and called “Vorgehensmuster für Software Architektur” which translates to something like “Software Architecture Patterns”. It’s written by Stefan Toth, a well known software architect and consultant here in Germany.
After getting the book some years ago I read it and found it very useful. Somehow it landed on the book stack, being forgotten about until recently. After rediscovering it I took some time to read it again. I was surprised on how many ideas it planted into my daily worklife and how much of its patterns I actually used during the last years in my job as a software developer and architect.
I’ve read a lot of books, but I wanted to point out this book in particular. Here are some of the patterns I found most useful. They are all described in detail in the book, so go get it if possible for you:
- Keep quality factors in mind: Software is always a trade-off between software qualities. Qualities like security and usability contradict each other, so you have to factor them in right from the beginning. Toth is taking this into account during every phase of the project, beginning with requirements analysis.
- Keep everyone involved: Context is King, a developer that does not know in which project context he’s working will probably not create what he should. Everyone knows the picture with the swing on the tree project. Toth describes how all project members should be involved during the project. He shows a lot of methods like project and architecture reviews that help building up knowledge about the context.
- Last Responsible Moment: The concept of LRM and how to handle it is one of the key concepts in project management. After a bit of practice it comes naturally, and a good architect knows how to handle it. That’s not to say that a good in-depth analysis of this concept and how to tackle it does not help.
- Active Risk Management: Along with LRM comes risk management. What are the different types of risks and how to minimize them? The book categorizes risks and shows a handful of concepts about what can be done for each category.
- Architecture Reviews: There’s nothing better than to crowd-solve a problem. It’s extremely rewarding to finding the best solution together. Even better, you get a lot of knowhow-transfer and free training on top of it. This is especially true for architecture – in the past I found that basic architecture and software design are among the most critical parts of a project. If you have the possibility to get everyone on board during this part of the project you will probably not have to deal with miscommunication and out-of-context development later on.
- Use feedback and retrospectives: A good software development process consists of as much feedback opportunities as possible. You should always reflect on your past decisions and ideas, often you find better ideas that are still possible to be implemented. This goes for architecture, but also for process and the whole social stuff.
- Show your progress early: This is also related to the whole feedback topic – Show what you got and see what the customer and other stakeholders think about it. Be as transparent as possible in your development process, you’ll get feedback that otherwise would never reach you and cost you a lot of trouble later on.
- Root Cause Analysis: I see this way too often – A problem occurs and a developer fixes it right away, not thinking about the real root cause of the problem. Oftentimes only the currently visible symptom gets fixed, but the real reason for trouble stays in the system. With proper methods like the 5 Whys it is possible to get to the real issue and fix it once and for all.
I also found a few things that I always wanted to do, but never had the opportunity. The biggest of them are Architecture Katas. I think Katas can improve architectural thinking and collaboration in the dev team a lot. The book names the coding dojo of the clean code school. A short google also turned up this English site.
Back in October I got the chance to write a guest blog post over at the Conan-Blog about how we’re using Conan at work.
Hopefully someone finds use in it. Conan really helped us pushing our C++ dev environment onto a new level.
I assume that I’m the first Rheinmetall employee who wrote a public blog post about how stuff is handled internally. #neuland 😀