Headworx

June 2020 was when another cross-SDO liaison group was formed. IP-BLiS followes the SDO convergence reinforced recently by initiatives like the OneDM (which proposed the SDF data definition language and served as the launchpad for the Project CHIP ). This was then followed by DiiA (the DALI Alliance) announcing cooperation with Zigbee, Thread and most notably Bluetooth SIG . Standards organizations working together is always a good thing. But listening to the IP-BLiS pitch , there is some insufficiency in what they aim for. Because IPv6 alone does not solve any interoperability problems. And also there are cases (energy harvesting, low latency secure multicast), wthen an IP-based approach doesn’t meet the needs of the market. And I would even go further by saying that IPv6 is not needed to achieve interoperability. Why? Because it is just a Layer 3 (the Network Layer) technology. So it can be used to run thousands of incompatible and not interoperable applications and services on to...

Even though 4K screens have become a norm in offices and homes, and laptops offering increasingly higher resolutions, a second screen is often handy. I have been using the iPad (with the Duet app ) to serve me as a second screen on the road. But at home I've found it cumbersome to keep connecting the iPad. Also very often I run some multi-hour monitoring / diagnostic processes and keeping iPad hooked all the time is not the best idea. On top of that every now and then there is a need to check (or work with) and equipment that requires HDMI screen. Such as the Raspberry Pi. Searching for a solution I found this gorgeous UPERFECT 15-inch portable screen . It is touch enabled, and has a (mini) HDMI input and two universal Type-C ports. And it is super slick. On top of that it works exactly as advertised. In my setups the two configurations I use it most often with are: A secondary (or tertiary, if you count the laptop's display) monitor. All it requires is a proper USB-C connectio...

It is not often that a perfect match is found. But this is the case between Bluetooth mesh and DALI. One is wireless, the other is wired. One distributes the control functions, the other has it centralized. Both are used for professional lighting to control lights and capture data: usage statistics, energy, sensors. I have been working with Bluetooth mesh and DALI for many years. Initially we had the idea to keep the DALI system architecture and use Bluetooth mesh as a wireless carrier for DALI. But over the years, as Bluetooth mesh has been pushing the intelligence and control functions to the end nodes, another approach started making much more sense Let DALI pick up from where Bluetooth stops:at the edge of a luminaire. Luminaires today are fairly complex. Long gone are days of a hot tungsten wire - replaced now by a network of electronic drivers with built in intelligence and sensors. An LED driver is a networked node. There may be just a single one inside a luminaire or there may ...

Somehow related to my last week's Multi-decade Stability blog , is related the concept of reboots. While the last week's conclusion was that software does not age (hardware does), getting a stable software in the first place is difficult. Typically there are two conditions in software that may result in it failing after some time of operation. The first one is a memory leak. If it is slow, it may take time (days, weeks, even months), but eventually the system will run out of resources and fail.If it is protected by a watchdog , it will reboot itself and continue for another week or month. This actually happens quite frequently, but software is written today in a way that you may not notice such reboot. Of devices I have, the one that does that most often is the Garmin watch. The reason I notice is that it takes a good while for it to boot (it does some filesystem checks and reads many GBs of topographic map data from its storage). But if the process was like 5 seconds, I probab...