Unfortunately the breaker panel is in a locked room secured by a microcontroller which was hacked years ago and is now only capable of mining crypto and minting pictures of cartoon monkeys.
The fact that this appears to be a current product implies to me they need to find another vendor who’s partnered with Cooper to install it. Reload software on a new server and take over all the controllers. Rip & Replace seems really extreme here.
I’ve nothing but contempt for the A/V integrators that handle Crestron and its ilk. It’s all about the repeat service calls. Everything looks simple, but you can’t touch it.
All the DALI segments with the lights, switches and sensors seem to be a defined open standard. It’s just the box, and single point of failure, at the center, that’s proprietary.
I think @anon29537550 has a solution to that problem. I have a set of tools, too:
Or a large cabinet full of contractors.
not enough eyeroll emoji in the world
This-topia is a you-topia.
That’s what I’m thinking too. They may be using proprietary software and hardware, but these things can be reverse engineered with free tools like Ghidra. You can often decompile directly from firmware files if on a disk, or dump it from the device with cheap JTAG-capable dongles, or get destructive and decap a sacrificial device and “read” that way. Chances are nothing will be super difficult to reverse though.
These things aren’t magic and vendors are generally lazy. Most vendors aren’t going to bother with the challenges, expense, or time with things like complicated encryption, custom hardware, or custom software, or anything like that. These things are almost always using off the shelf SoCs with extensive documentation, and well known software frameworks. Any encryption is usually easy to defeat. And if nobody can figure it out, there’s a whole community of reverse engineers and hardware hackers on the internet that love figuring out shit like this just for the fun of it.
I do hardware hacking and reverse engineering as a hobby and I refuse to believe that this isn’t solvable by a couple of nerds with access to the hardware and software, and a few weeks time.
For everyone saying reverse engineer - DMCA. There’s likely at least a thin DRM layer to drag in the DMCA.
Having flashbacks to every new quote including, “Need to replace all hardware and network equipment with equivalent models compatible with our system and controllers.”
Most of the time this was a quote-inflating lie, but smaller businesses are not equipped to understand the nuances of systems they’re hiring “experts” to manage for them.
I’m not a copyright lawyer, but two facts (per the article and discussion) that work in favor of the school going the hacking route are the vendor changing ownership multiple times and not informing the customer, even to the point where it implies the original contact information (for service) was eliminated, and the software being abandoned to the point where they don’t have a copy or documentation of the software or anyone with the programming skills who could work on it, let alone an upgraded version for installation.
Both these points tell me that the owners, former and current, no longer consider the software to be commercially valuable anymore, whether to sell to new customers, or to charge current or former customers for service and maintenance.
Personally, I’d advise the school that, as long as they don’t try to sell or distribute the software or otherwise compete in the automated lighting industry, they can go ahead and hack it to fix it.
Have they contacted Zero Cool? I believe he knows how to hack the school’s computer system.
Yes this what I expected. It’s actually ok.
Here’s an open source example of Arduino code initializing a Dali control protocol managed lamp.
https://projecthub.arduino.cc/NabiyevTR/c652b7d0-8439-4be1-9aa5-6fb66e4efc76
The protocol is documented and available.
The control side is all low voltage and doesn’t need (much) coordination with a licensed electrician to modify.
I’d shitcan the entire control stack and rebuild using something like M5 controllers (commodity, commercial esp32 based controllers) that manage all the physical hardware on the Dali bus and abstract each device to present state to an MQTT host.
The new hardware stack would sit in an industrial control cabinet mounted on din rails. It wouldn’t look like a science experiment.
I’d then use a server hosting the mqtt server and drive the whole thing with node red to control the logic (this part would be the bulk of the work), influxdb to remember historical states and power consumption metrics, and grafana to make pretty graphs about state and power consumption.
It could literally be ran on home assistant, which would provide managed docker containers.
This is a problem where the intersection of electricians and software engineers don’t intersect enough, so you get wildly weird responses like rip it all out and replace because nobody spoken to yet understands industrial controlled lighting.
Between the hours coordinating with an electrician to validate the legality of the modifications, I’d say the develop, v&v, commission, and document the system would probably be around 600-1000 development hours in total. (From concept to handoff)
So it’s like the secret of Roman cement or Damascus steel or getting photos from Voyager, eh? The knowledge of the ancients, lost forever.
That’s so BER.
cough The first thing I’d do would be to look at existing off-the-shelf DALI controller boxes & software. (Ones that don’t somehow cost $1.5M.)
Talk to an industrial lighting expert and ask “high school building, DALI segments, what would you use?”
They’re probably commodity solutions now, which is why all those proprietary box makers went out of business.
Your wheel sounds rounder, but I can’t believe that there aren’t some okay ones already on the shelf at the tire store.
This is like something out of Snow Crash. Because it’s both cyberpunk and satire writ large into real life.