Changes in OCPP 2.1 [draft]

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.

Bringing light to life

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!

Streaming audio from Plasma to a Chromecast

3 Comments
Chromecast devices in the sound settings

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.

$ sudo apt install pulseaudio-dlna
[...]
$ sudo pulseaudio-dlna
[...]
Added the device "Stereo (Chromecast)".
[...]

Desk lamp

desk lamp with mirror behind
desk lamp with mirror behind

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.

desklamp-ledstrips
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
Fixed to the ceiling
Internals of the desk lamp
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
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.

Different indentation styles per filetype

2 Comments

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:

  1. put a file called .editorconfig in the project’s root directory
  2. specify a default style and then a specialization for certain filetypes
  3. 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).

(Thanks to Reddit.)

Connecting new screens

10 Comments

Plasma's new screen layout selection dialog
Plasma’s new screen layout selection dialog
This 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.

KDE’s Goal: Privacy

by Banksy
by Banksy
At 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.

IKEA Trådfri first impressions

2 Comments

Warm white lights
Warm white lights
Since 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
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
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.