Lots of KDE hacking these days, and that comes with compiling large amounts of code. Right now, I am installing, well building from source Plasma Mobile on an “old” laptop so I can test some patches natively on a touchscreen device. The machine has just two cores (hyperthreaded), so builds take rather long, especially if you build Qt and all that 80+ packages that are needed for a fully working Plasma system. One of the tools that do an incredible job while being super flexible to use is icecream. Icecream (or “icecc“) allows you to distribute your build over multiple machines, it basically ships compile-jobs with all that’s needed to other machines on a local network, meaning you can parallelize your builds.
Icecream has this nice visualization tool, called icecream-monitor which you can stare at while your builds are running (in case you don’t have anyone handy for a sword-fight). In the screenshot you can see manta, the underpowered laptop doing a 32 parallel job build over the network. miro is my heavy workstation, 8 cores and 128GB of RAM, it duely gets the bulk of the work assigned, frame is my (Framework) laptop, which is also quite beefy, gets something to do too, but not taxed as heavily as that build monster in my basement office. Icecream can be used with most environments that have you run your compiler locally. Different distros are no problem! Just a matching CPU architecture is needed. Icecream does its job by providing its own g++ and gcc binaries, which will relay the build jobs transparently to either your local machine or across the network. So you basically install it, adjust your PATH variable to make sure icecc’s g++ is found before your system’s compiler and start your build. Other machines you want to join in for the fun just need to run icecc-scheduler and they will be automatically discovered as build slaves on your network. If you want to further speed up builds, it works with ccache as well.
Please note that you only want to do this in a trusted environment, we’re shipping executables around the network without authorization!
Robert de Leeuw came up with the suggestions to use AI for compiling a list of changes in OCPP (Open Charge Point Protocol) 2.1. Me being too lazy to go over the document myself, I headed over to ChatGPT and this came up. Note: Please take this with the necessary caution about correctness and completeness, as it’s still ChatGPT that spit this out. Proof-reading and suggestions are obviously most welcome.
The Open Charge Point Protocol (OCPP) 2.1 draft introduces a number of changes, enhancements, and new features compared to OCPP 2.0.1. Here’s a detailed breakdown of the changes:
1. New Features and Functionalities
ISO 15118 Plug and Charge: Enhanced support for the ISO 15118 standard, including Plug and Charge functionality, allowing for automatic authentication and billing between the electric vehicle (EV) and the charging station without requiring a separate card or app.
Improved Smart Charging: New profiles and parameters for smart charging that allow more sophisticated energy management strategies, including better integration with grid requirements and renewable energy sources.
Vehicle-to-Grid (V2G) Support: Preliminary support for V2G functionality, enabling bidirectional energy flow between the EV and the grid, which facilitates the EV acting as an energy storage device.
New Charging Profiles: Introduction of more flexible charging profiles that can be dynamically adjusted based on real-time data, improving the ability to manage charging sessions based on grid conditions, energy costs, and user preferences.
2. Security Enhancements
Enhanced Certificate Management: Improvements to certificate handling for secure communication, including the ability to manage multiple certificates and better support for certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP).
Improved Firmware and Software Updates: More secure and robust mechanisms for firmware and software updates, ensuring the integrity and authenticity of updates delivered to charging stations.
Expanded Use of TLS: Strengthened use of Transport Layer Security (TLS) for all communication, ensuring secure data transmission between the charge point and central system.
3. Transaction and Metering Enhancements
Detailed Transaction Records: More detailed transaction recording, including finer granularity in start and stop times, energy delivered, and cost breakdowns, which helps in providing more transparent billing and usage information.
Meter Value Reporting: Expanded options for reporting meter values, including more frequent and detailed reporting, support for different meter types, and enhanced data granularity, enabling better tracking of energy usage.
Multiple Transactions: Support for handling multiple concurrent transactions at a single charging station, allowing better utilization of charging resources and more complex charging scenarios.
4. Diagnostics and Maintenance Improvements
Advanced Diagnostics: More detailed diagnostics messages and status reports that provide better insights into the operational state of the charge point, enabling quicker identification and resolution of issues.
Error Handling Enhancements: Refined error handling processes, including more specific error codes and clearer guidelines for managing various fault conditions.
Improved Event Notification System: An expanded set of event notifications and more flexible configuration options for event handling, allowing operators to customize notifications based on specific operational needs.
5. Data Transfer and Customization
Custom Data Objects: Support for transferring custom data between the charge point and central system, enabling more flexible integrations and the ability to support proprietary features or business models.
Extended Data Formats: Introduction of new data formats and extensions to existing ones, improving the efficiency of data transmission and allowing for more complex data structures.
6. Communication Protocol Enhancements
Optimized WebSocket Communication: Refinements to the WebSocket communication protocol to reduce latency, improve reliability, and enhance performance, especially under high-load conditions.
Offline Message Queuing: Enhanced support for handling messages when the charge point is offline, ensuring that messages are properly queued and delivered once the connection is restored.
Extended Message Types: Introduction of new message types and updates to existing ones, allowing for more nuanced communication between the charge point and central system.
7. User Experience and Interface Improvements
Enhanced User Authentication: New options for user authentication, including support for contactless payments and improved handling of user credentials and identity management.
Better User Feedback: More flexible configurations for providing user feedback via the charging station interface, including enhanced messaging and status displays.
Remote Start/Stop Capabilities: Improved remote control capabilities for starting and stopping charging sessions, providing operators and users with more control over the charging process.
8. Backward Compatibility and Migration
Migration Tools and Guidelines: Introduction of new tools and documentation to aid in migrating from OCPP 2.0.1 to OCPP 2.1, ensuring a smooth transition and minimizing disruption.
Backward Compatibility Considerations: Efforts to maintain compatibility with OCPP 2.0.1 where feasible, ensuring that existing systems can continue to operate while taking advantage of new features incrementally.
9. Documentation and Standards Compliance
Updated Specifications and Guidelines: Revisions and clarifications to the OCPP documentation, providing clearer guidance on implementing and complying with the protocol standards.
Expanded Use Cases and Examples: More detailed use cases and implementation examples to help developers understand and apply new features and changes effectively.
10. Testing and Certification Enhancements
Enhanced Testing Procedures: Updates to the testing and certification procedures to ensure compliance with OCPP 2.1 standards, including more rigorous testing for new features and security enhancements.
Certification Criteria Updates: New criteria for certification that reflect the expanded functionality and security requirements of OCPP 2.1, ensuring interoperability across different implementations.
Summary
The OCPP 2.1 draft introduces a range of new features, security enhancements, and improvements over OCPP 2.0.1, reflecting the growing complexity and demands of the EV charging ecosystem. These changes aim to improve functionality, security, and interoperability, providing a robust framework for the future of electric vehicle charging infrastructure. It is essential for developers and operators to familiarize themselves with these updates to take full advantage of the new capabilities and ensure compliance with the latest standards.
Some of you may be wondering what I have been up to lately since I took a break from my work in the KDE community. Well, it was time for a change, a change towards family, friends and a more local life. The result is a more balanced, a more grown up me. These changes in my life lead to me having a small family and a group of new friends, both of which I spend a lot of time with. They brought more light into my life, one could say.
That is not all I want to talk about, however. I the past 1.5 years I worked on a new project of mine that combines my love for software with the physical world. I created a product and brought it to the market last month. Now, we’re ready for the international launch of Organic Lighting. The product is a design smart lamp for the living room. It combines unique and dynamic visual effects with natural, sustainable materials. Meet our Aurora lamp:
It’s a connected device that can be eighter controlled using its physical knob on the front, or via its web ui (or REST interface). Effects can be changed, tweaked and its firmware can be updated (nobody should want an IoT device that can’t get security of feature updates). The concept here, technically is to do “light in software”. The lamp is run by a microcontroller embedded in its foot. Its roughly 600 leds produce ca. 4000 Lumen and render effects at more than 200 frames per seconds. The lamp is built with easy repairs in mind, and it’s designed for a long-lasting experience, it respects your privacy, and it creates a unique atmosphere in your living space.
With our products, we’re offering an alternative to planned deprecation, throw-away materials and hidden costs of cheap electronics that make you the product by consuming your data for breakfast.
In the future, we will build on these concepts and technology and offer more devices and components that match our principles and that enhance one-another. Stay tuned!
This morning, while browsing the web, I wanted to listen to a Podcast from my laptop, and thought “Hey, can I stream this to our stereo?”. As it turns out, that’s rather easy to achieve, so I thought I’d share it here. The media devices in our home are connected using Chromecasts, which are small dongles that allow playing media on them, meaning you can play for example a video from your phone on the projector in the living room: very convenient.
I didn’t know if that was easily achievable with audio from my Plasma/Linux laptop and a quick search turned up “pulseaudio-dlna” which adds Chromecast devices on the local networks as output devices.
On my KDE Neon laptop, it’s as easy as installing pulseaudio-dlna from the standard repositories and then starting “pulseaudio-dlna” from the commandline. Then, I can pick an output device from the panel popup and the audio stream changed to my stereo.
Some time ago, I wanted to make my own desk lamp. It should provide soft, bright task lighting above my desk, no sharp shadows that could cover part of my work area, but also some atmospheric lighting around the desk in my basement office. The lamp should have a natural look around it, but since I made it myself, I also didn’t mind exposing some of its internals.
SMD5050 LED strips
I had oak floor boards that I got from a friend (thanks, Wendy!) lying around. which I used as base material for the lamp. I combined these with some RGBW led strips that I had lying around, and a wireless controller that would allow me to connect the lamp to my Philips Hue lighting system, that I use throughout the house to control the lights. I sanded the wood until it was completely smooth, and then gave it an oild finish to make it durable and give it a more pronounced texture.
Fixed to the ceiling
Internals of the desk lamp
The center board is covered in 0.5mm aluminium sheets to dissipate heat from the LED strips (again, making them last longer) and provide some extra diffusion of the light. This material is easy to work with, and also very suitable to stick the led strips to. For the light itself, I used SMD5050 LED strips that can produce warm and cold white light, as well as RGB colors. I put 3 rows of strips next to each other to provide enough light. The strips wrap around at the top, so light is not just shining down on my desk, but also reflecting from walls and ceiling around it. The front and back are another piece of wood to avoid looking directly into the LEDs, which would be distractive, annoying when working and also quite ugly. I attached a front and back board as well to the lamp, making it into an H shape.
Light reflects nicely from surrounding surfaces
The controller (a Gledopto Z-Wave controller, that is compatible with Philips Hue) is attached to the center board as well, so I just needed to run 2 12V wires to the lamp. I was being a bit creative here, and thought “why not use the power cables also to have the lamp hanging from the ceiling?”. I used coated steel wire, which I stripped here and there to have power run through steel hooks screwed into the ceiling to supply the lamp with power while also being able to adjust its height. This ended up creating a rather clean look for the whole lamp and really brought the whole thing together.
For my hacking, I love to use the KDevelop IDE. Once in a while, I find myself working on a project that has different indentation styles depending on the filetype — in this case, C++ files, Makefiles, etc. use tabs, JavaScript and HTML files use 2 spaces. I haven’t found this to be straight-forward from KDevelop’s configuration dialog (though I just learnt that it does seem to be possible). I did find myself having to fix indentation before committing (annoying!) and even having to fix up the indentation of code committed by myself (embarrassing!). As that’s both stupid and repetitive work, it’s something I wanted to avoid. Here’s how it’s done using EditorConfig files:
put a file called .editorconfig in the project’s root directory
specify a default style and then a specialization for certain filetypes
restart KDevelop
Here’s what my .editorconfig file looks like:
# EditorConfig is awesome: https://EditorConfig.org
# for the top-most EditorConfig file, set...
# root = true
# In general, tabs shown 2 spaces wide
[*]
indent_style = tab
indent_size = 2
# Matches multiple files with brace expansion notation
[*.{js,html}]
indent_style = space
indent_size = 2
This does the job nicely and has the following advantages:
It doesn’t affect my other projects, so I don’t have to run around in the configuration to switch when task-switching. (Editorconfigs cascade, so will be looked up up in the filesystem tree for fallback styles.
It works across different editors supporting the editorconfig standards, so not just KWrite, Kate, KDevelop, but also for entirely different products.
It allows me to spend less time on formalities and more time on actual coding (or diving).
Blood Moon of July 2018
Tonight, I spent some time on the balkony with my SLR, a glass of Shiraz and the most significant lunar eclipse of the century.
Plasma’s new screen layout selection dialogThis week, Dan Vratil and me have merged a new feature in KScreen, Plasma’s screen configuration tool. Up until now, when plugging in a new display (a monitor, beamer or TV, for example), Plasma would automatically extend the desktop area to include this screen. In many cases, this is expected behavior, but it’s not necessarily clear to the user what just happened. Perhaps the user would rather want the new screen on the other side of the current, clone the existing screen, switch over to it or perhaps not use it at all at this point.
The new behavior is to now pop up a selection on-screen display (OSD) on the primary screen or laptop panel allowing the user to pick the new configuration and thereby make it clear what’s happening. When the same display hardware is plugged in again at a later point, this configuration is remembered and applied again (no OSD is shown in that case).
Another change-set which we’re about to merge is to pop up the same selection dialog when the user presses the display button which can be found on many laptops. This has been nagging me for quite a while since the display button switched screen configuration but provided very little in the way of visual feedback to the user what’s happening, so it wasn’t very user-friendly. This new feature will be part of Plasma 5.13 to be released in June 2018.
by BanksyAt Akademy 2016, the KDE community started a long-term project to invigorate its development (both, technically and organizationally) with more focus. This process of soul-searching has already yielded some very useful results, the most important one so far being agreement of a common community-wide vision:
A world in which everyone has control over their digital life and enjoys freedom and privacy.
This presents a very high-level vision, so a logical follow-up question has been how this influences KDE’s activities and actions in practice. KDE, being a fairly loose community with many separate sub-communities and products, is not an easy target to align to a common goal. A common goal may have very different on each of KDE’s products, for an email and groupware client, that may be very straight-forward (e.g. support high-end crypto, work very well with privacy-respecting and/or self-hosted services), for others, it may be mostly irrelevant (a natural painting app such as Krita simply doesn’t have a lot of privacy exposure), yet for a product such as Plasma, the implications may be fundamental and varied. So in the pursuit of the common ground and a common goal, we had to concentrate on what unites us. There’s of course Software Freedom, but that is somewhat vague as well, and also it’s already entrenched in KDE’s DNA. It’s not a very useful goal since it doesn’t give us something to strive for, but something we maintain anyway. A “good goal” has to be more specific, yet it should have a clear connection to Free Software, since that is probably the single most important thing that unites us. Almost two years ago, I posed that privacy is Free Software’s new milestone, trying to set a new goal post for us to head for. Now the point where these streams join has come, and KDE has chosen privacy as one of its primary goals for the next 3 to 4 years. The full proposal can be read here.
“In 5 years, KDE software enables and promotes privacy”
Privacy, being a vague concept, especially given the diversity in the KDE community needs some explanation, some operationalization to make it specific and to know how we can create software that enables privacy. There are three general focus areas we will concentrate on: Security, privacy-respecting defaults and offering the right tools in the first place.
Security
Improving security means improving our processes to make it easier to spot and fix security problems and avoiding single points of failure in both software and development processes. This entails code review, quick turnaround times for security fixes.
Privacy-respecting defaults
Defaulting to encrypted connections where possible and storing sensible data in a secure way. The user should be able to expect the KDE software Does The Right Thing and protect his or her data in the best possible way. Surprises should be avoided as much as possible, and reasonable expectations should be met with best effort.
Offering the right tools
KDE prides itself for providing a very wide range of useful software. From a privacy point of view, some functions are more important than others, of course. We want to offer the tools that most users need in a way that allows them to lead their life privately, so the toolset needs to be comprehensive and cover as many needs as possible. The tools itself should make it easy and straight-forward to achieve privacy. Some examples:
An email client allowing encrypted communication
Chat and instant messenging with state-of-the art protocol security
Support for online services that can be operated as private instance, not depending on a 3rd party provider
…
Of course, this is only a small part, and the needs of our userbase varies wildly.
Onwards from here…
In the past, KDE software has come a long way in providing privacy tools, but the tool-set is neither comprehensive, nor is privacy its implications widely seen as critical to our success in this area. Setting privacy as a central goal for KDE means that we will put more focus on this topic and lead to improved tools that allow users to increase their level of privacy. Moreover, it will set an example for others to follow and hopefully increase standards across the whole software ecosystem. There is much work to do, and we’re excited to put our shoulder under it and work on it.
Warm white lightsSince I’ve been playing with various home automation technologies for some time already, I thought I’d also start writing about it. Be prepared for some blogs about smart lighting, smart home and related technologies.
Most recently, I’ve gotten myself a few items from IKEA new product range of smartlight. It’s called trådfri (Swedish for wireless). These lights can be remote-controlled using a smartphone app or other kinds of switches. These products are still fairly young, so I thought I’d give them a try. Overall. the system seems well thought-through and feels fairly high-end. I didn’t notice any major annoyances.
First Impressions
Trådfri hub and dimmer
My first impressions are actually pretty good. Initially, I bought a hub which is used to control the lights centrally. This hub is required to be able to use the smartphone app or update the firmware of any component (more on that later!). If you just want to use one of the switches or dimmers that come separately, you won’t need the hub.
Setting everything up is straight-forward, the documentation is fine and no special skills are needed to install these smartlights. Unpacking unfortunately means the usual fight with blister packaging (will it ever stop?), but after that, a few handy surprises awaited me. What I liked:Hub hides cables
The light is nice and warm. The GU10 bulbs i got give 400 lumens and are dimmable. For my taste, they could be a bit darker at the lower end of the scale, but overall, the light feels comfy warm and not too cold, but not too yellow either. The GU10 bulbs I got are spec’ed at 2700 Kelvin. No visible flickering either.
Trådfri components are relatively inexpensive. A hub, dimmer and 4 warm-white GU10 bulbs set me back about 75€. It is way cheaper than comparable smartlights, for example Philips Hue. As needs are fairly individual exact prices are best looked up on IKEA’s website by yourself.
The hub has a handy cable storage function, you can roll up excessive cable inside the hub — a godsend if you want to have the slightest chance of preventing a spaghetti situation.
The hub is USB-powered, 1A power supply suffices, so you may be able to plug it into the USB port of some other device, or share a power supply.
The dimmer can be removed from the cradle. The cradle can be stuck on any flat surface, it doesn’t need additional cabling, and you can easily take out the dimmer and carry it around.
The wireless technology used is ZigBee, which is a standard thing and also used by other smarthome technologies, most notably, Philips Hue. I already own (and love) some Philips Hue lights, so in theory I should be able to pair up the Trådfri lights with my already existing Hue lights. (This is a big thing for me, I don’t want to have different lighting networks around in my house, but rather concert the whole lighting centrally.)
Pairing IKEA Trådfri with Philips Hue
Let’s call this “work in progress”, meaning, I haven’t yet been able to pair a Trådfri bulb with my Hue system. I’ll dig some more into it, and I’m pretty sure I’ll make it work at some point. If you’re interested in combining Hue and Trådfri bulbs, I’ll suffice with a couple of pointers:
If you want to try this yourself, make sure you get the most recent lights from the store (the clerk was helpful to me and knowledgable, good advice there!). You’ll also likely need a hub at least for updating the firmware. If you’re just planning to use the bulbs together with a Hue system, you won’t need the hub later on, so that may seem like 30€ down the drain. Bit of a bummer, but depending on how many lights you’ll be buying, given the difference in price between IKEA and Philips, it may well be worth it.
\edit: After a few more tries, the bulb is now paired to the Philips Hue system. More testing will ensue, and I’ll either update this post, or write a new one.
