icecream!

4 Comments

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!

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.)