PROJECT JOURNEY — PART 2

Difficulties of the project

The hard problems, unexpected dead ends, and unresolved challenges encountered during the development of SafetyIQ.

The structural engineering wall

SafetyIQ’s core promise is this: when the wind reaches a dangerous level for your tower, the system warns you and eventually acts. But to make that promise, the system needs to know what a dangerous level actually is — and that number is different for every tower, every antenna configuration, and every height.

I am not a structural engineer. I had no prior knowledge of wind load calculations, drag coefficients, or section moduli. But the system required it. The result was months of self-education in structural engineering methodology, culminating in a Dynamic Structural Monitor module that computes wind load limits from first principles.

Validation was the hardest part. A calculation that produces a number is not useful unless you can verify the number is correct. I obtained published PE-stamped engineering data for the ROHN 65G tower and validated the module against five independent test cases. All five passed within 0.001 tolerance. That gave me enough confidence to use the module in a real system — but only for towers with validated PE-stamped data.

The CT2IRY towers — Angelucci TC50 and TC90, Italian-made telescopic sections — have no published English-language PE-stamped engineering data. I have the physical towers. I have the installation. But I do not have the structural documentation required to put them into SafetyIQ. Until formal engineering validation is obtained, the CT2IRY towers do not exist in the code. This is a hard rule that cannot be overridden, and it means the primary testbed station cannot use the feature the system was built for.

That tension — building a worldwide safety system while being unable to fully deploy it at home — has been the most persistent frustration of the project.

The worldwide data problem

Committing to worldwide operation from day one sounded clean and principled. The reality was a long sequence of API discoveries, failed endpoints, regional quirks, and authentication schemes that varied by country.

Some national meteorological agencies publish excellent, well-documented free APIs. Others publish no API at all and distribute data only as PDF bulletins. Some agencies have APIs but no English documentation. Some have English documentation that describes a different version of the API than what is actually running. Several that appeared in research turned out to be decommissioned, rate-limited to the point of uselessness, or requiring institutional affiliation to access.

The solution was a ServiceDiscoveryAgent — an AI component that, for any country not covered by SafetyIQ’s built-in integrations, searches for available meteorological APIs, validates that they return parseable data, and adds them to the system dynamically. This works well for countries with discoverable APIs. For countries without any public API, there is no good answer yet. The community registry — where operators worldwide submit discovered sources — is the long-term solution, but it depends on building a user base first.

Session memory and the Drive problem

Claude Code has no persistent memory between sessions. Every new session starts fresh. For a project of SafetyIQ’s scale — 40+ services, 11 locked architectural principles, dozens of decisions that must never be contradicted — this created a real engineering problem: how do you maintain continuity across dozens of development sessions?

The answer was the MASTER document — a structured directive file read at the start of every session, containing every architectural rule, every completed milestone, every open TODO, and every blocked decision. Claude Code reads it, internalises it, and proceeds as if it remembers everything.

The difficulty was finding a reliable home for the MASTER. Early sessions used Google Drive, passing file IDs between Claude.ai and Claude Code. This failed consistently — the two tools operate in different Drive accounts or scopes, cannot read each other’s files, and the IDs became stale between sessions. Several sessions were lost to this confusion before the solution was found: the MASTER lives in the Git repository itself, committed with every version. It is always on disk where Claude Code works, never disappears, and is always in sync with the code.

It is a simple solution. It took several weeks of frustration to arrive at it.

The motor hardware decision

SafetyIQ’s auto-act feature — lowering towers autonomously when the operator is unreachable — requires a physical motor control interface. The software architecture is complete: a TowerMotorController stub with a clean interface that any motor type can implement. The routes are wired. The dashboard buttons are live. The remote panel sends commands.

But nothing moves, because the hardware decision has not been made.

The options are a relay board on the Raspberry Pi GPIO, an ESP32 microcontroller on the LAN answering HTTP commands, an MQTT broker with a subscribed relay module, or — for the many hams with manual-crank towers — an advisory-only mode with no automation at all. Each option has different wiring requirements, different failure modes, and different implications for stations with multiple towers of different types.

The decision is deliberately delayed until the right answer is clear. An incorrect motor interface, once wired into a station, is not easily changed. The stub architecture means the software waits patiently — and correctly — for the hardware decision without requiring any refactoring when it comes.

The dummy load and the ESP32 that doesn’t exist yet

The plan for antenna protection when a tower cannot be lowered — guyed towers, towers mid-operation, towers whose motors have not yet been wired — is routing the antenna through a dummy load. SafetyIQ sends a command to an ESP32 microcontroller inside the dummy load enclosure, which activates a relay to switch the feedline.

The ESP32 firmware is designed. The HTTP API is specified. The SafetyIQ proxy routes are implemented. The dashboard button exists and toggles correctly in simulation mode.

The ESP32 has not been purchased. The relay module has not been purchased. The enclosure modification has not been done. The CAT7 cable has not been run to the shack switch. The local weather station — an Ecowitt WN90LP RS485 ultrasonic sensor — has also not been purchased or installed.

These are not software problems. They are components on an order list, waiting for the right moment to purchase and install. The software is ready for them. They are not ready for the software.

The Windy API situation

SafetyIQ uses the Windy animated map layer on the full-screen dashboard. The free Windy API key returns real map data — useful for the visual overlay. The Windy Point Forecast API, however, returns randomly shuffled data on the free tier. A free key for point forecast data is effectively non-functional for any real application. The data cannot be used for safety-critical decisions.

Windy offers free Professional API access to non-commercial open-source projects. SafetyIQ qualifies on every criterion — it is non-commercial, it will be open-sourced, and it has real users. An application has been submitted. The response is pending.

In the meantime, SafetyIQ uses Open-Meteo and Tomorrow.io for all weather data. Both provide real, accurate data on their free tiers. The Windy Point Forecast was removed from the codebase entirely in v0.7.4 — keeping a data source that returns random data in a safety system, even unused, was not acceptable.

What remains open

SafetyIQ at v0.7.5 is a functioning safety monitoring system. The weather pipeline works. The AI assessment works. The alerts work. The remote panel works. The dashboard works. The Progressive Web App works. The presence detection works.

What does not yet work:

• Tower motor control — hardware decision pending
• Dummy load switching — ESP32 not yet installed
• Local mast anemometer — RS485 hardware not yet purchased
• CT2IRY structural data — awaiting engineering validation
• Community registry — VPS deployment pending
• Public release — GitHub repository still private during development

None of these are software failures. They are the gap between a system that is architecturally complete and a system that is physically deployed. Closing that gap is the work that remains.

Acknowledgements

Anthropic — for Claude Code and Claude claude-sonnet-4-6, without which the pace and scale of SafetyIQ development would not have been possible.

IZ6UVW — Tralicci Angelucci — awaiting structural data for the TC50 and TC90 tower sections that will unlock the CT2IRY structural validation.

CERIS and DECivil — Instituto Superior Técnico, Lisbon — contacted for independent peer review of the Dynamic Structural Monitor methodology.