Making the best out of Corona-wise cancelled sports evenings, there was suddenly enough time to smartify my garade door. It already has connectors on the garage door hardware. That way, I could connect a button to the board that is used to open and close the garage. But what was missing is a way to control it remotely.
Since the remote went missing it was nearby to integrate the button into my smart home setup: Homematic actuators and a raspberry pie transferring all traffic via MQTT.
But there was one problem. The relay works with an input and output voltage of 230V.
That’s too much to control the board on the garage opener. So I had to integrate another relay that could switch an arbitrary input voltage but works with a rated Control Supply Voltage of 230V.
I finally came up with an relay by Entrelec.
Now to the fun part. Connecting all parts together according to the wiring on the left. The Entrelec relay is directly connected to the garage opener board. The control supply is provided by the Homematic relay. The switch input of the Homematic relay is provided by the hardware button and finally some 230V to feed the relay. That’s it.
In order to test it, there’s no faster prototyping than to use Node-Red. It enables visually wiring up a control that either automates a workflow or provides a rudimentary GUI.
In this case, it’s a simple UI consisting of one toggle labeled „Garage“ sending out a message to the MQTT broker to fire up the Homematic relay.
Since that’s quite a boring interface, the next step was to write a control app, fooling around with Combine and SwiftUI. But that’s a story for another time 😉
Almost 3 years ago I started a tool to analyse dependencies of Swift projects. For bigger projects it’s essential to plan dependencies between classes and among modules beforehand. Otherwise a project’s inter-dependencies grow wild and after a while, everything depends on everything.
Why that’s bad you might ask? Because then it’s impossible to replace a class with different functionality, since too many other depend on it. And thus, it gets harder to implement new features, adapt existing features and keep the bug count low.
So that’s planning, but what get’s implemented is another story. It’s easy to forget about planned dependencies while implementing and that’s even more true when working in teams of 5, 10 or more people. That’s where tools for visualizing dependencies come into play. Every now and then, one can use these tools to check the actual inter-dependencies of a project and compare them with the planned ones.
The existing tools all have one big shortcoming: They ignore ordering structures like modules. All classes are layed out in one space, which gets confusing when visualizing projects with more several hundreds classes:
While this visualisation looks quite amazing it renders quite useless overwhelming when trying to check for unplanned dependencies. What’s more helping is a visualisation that considers modules and Xcode groups. Xcode groups can be used to organise a project’s classes in package-like structures.
Like in the sample project above, one can see different features of the app organised in separate groups. There’s a Splash screen organised in the Splash group and an Integration group to accomodate a feature to setup smart kitchen appliances and a Network group to shelter the classes communicating to backends, etc. Inter-dependencies can be planned on these structures too. While it’s easily comprehensible why an Integration group is dependent on the Network group, the Splash group shouldn’t.
The above dependency tool shows dependencies between classes, enums and protocols. Furthermore, it depicts the groups and files as rectangles collapsable and expandable. When collapsed, the inter-dependencies of all contained elements to other elements outside this structure are still visible but depicted as dependency of the structuring element.
This tool is worked on by David Piper as part of his master thesis. I’m glad to be his advisor and very confident that at the end of his thesis, we’ll see a wonderful tool to supervise the dependencies of Swift projects. What’s even better: As soon as the master thesis is completed, the project will be open-sourced and as a contributor, I’ll gladly keep you updated with more to come feature.
So stay tuned ✌️