Building IoT Solutions with Favoriot (eBook)

Building IoT Solutions with Favoriot | eBook Announcement
F
favoriot
Get the eBook
New eBook Announcement · 2026 Edition

Building IoT Solutions with Favoriot

A practical guide for the connected world, created for builders who want to move from IoT theory to real systems, real dashboards, real data, and real action.

PDF Digital eBook format
$1.99 On sale price
IoT Architecture to action
Practical IoT Guide
Building IoT Solutions with Favoriot
A Practical Guide for the Connected World
Dr. Mazlan Abbas
CEO & Co-founder, FAVORIOT

From connected devices to meaningful decisions.

Building IoT Solutions with Favoriot is a practical guide designed for developers, engineers, students, lecturers, and decision-makers who want to build Internet of Things systems that work beyond classroom demos and isolated prototypes.

The book explains how complete IoT solutions are designed, built, and scaled using the Favoriot platform. It covers the full IoT flow, from understanding system architecture and connecting devices to managing data streams, building dashboards, and setting intelligent rules that trigger action.

Instead of staying at the surface level, this guide focuses on the real work behind IoT. It helps readers understand how data becomes visibility, how visibility supports decisions, and how decisions can improve operations in smart cities, agriculture, healthcare, industrial monitoring, and more.

A clearer path to building IoT systems.

Understand IoT solution architecture Learn how devices, connectivity, platforms, dashboards, rules, and applications work together as one complete system.
Connect devices and manage data streams See how sensor data can be captured, sent, structured, stored, viewed, and prepared for better decision-making.
Create dashboards that support action Move beyond beautiful charts and learn how dashboards can guide response, monitoring, and operational improvement.
Explore real-world IoT use cases Apply the concepts to smart cities, agriculture, healthcare, industrial systems, education, and operational monitoring.

Built for people who want to build.

01

Students

For learners who want to create IoT projects with practical value and a stronger project story.

02

Developers

For builders who want a direct way to connect devices, send data, and create applications.

03

Lecturers

For educators who want to teach IoT with hands-on examples linked to real industry needs.

04

Decision-makers

For leaders who want to understand how IoT turns operational data into better visibility and action.

Start building IoT solutions with more confidence.

Get the eBook today and use it as your practical companion for understanding, designing, and deploying connected systems with Favoriot.

Get the eBook Now

I Used AI to Write My Latest eBook. Here’s What Actually Happened.

Let Me Be Honest With You

The eBook you are looking at right now, Mastering IoT and AIoT with Favoriot, was built with AI. Not just assisted by AI. Built by it. And I think that is worth talking about honestly, because the story of how this book came together tells you more about where we are with AI than any think piece I could write.

Here is the confession: most of the infographics inside were generated through ChatGPT. The eBook itself was assembled using Claude Cowork. I pointed it at my folder of infographics, and it categorised them, selected the best visual style, and structured everything into a coherent ladder from awareness to mastery. And the post you are reading right now? Claude is pushing it automatically to this blog.

I did not type all of this. AI did a significant part of the heavy lifting.

So Why Am I Telling You This?

Because I think the dishonest version of this story, the “I wrote a book” version with no footnotes, does everyone a disservice. We are at a moment in technology where the tools are genuinely extraordinary, and pretending otherwise is a form of intellectual cowardice.

But here is the thing I want you to sit with: the book is real. The frameworks inside it are real. The five rungs, Awareness, Foundations, Methodology, Production, and Mastery, those came from twenty-plus years of watching IoT projects succeed and fail. They came from UTM, CELCOM, MIMOS, from REDtone IoT, from every Favoriot deployment where a client came to us six months too late because they had skipped Rung 2.

The AI did not invent the Build-Readiness Ladder. I did. The AI helped me package it.

And I think that distinction matters enormously, not just for me, but for anyone trying to figure out how to use these tools without losing themselves in the process.

Every Buzzword Wave Brings the Same Temptation

I have been in IoT long enough to remember when “digitisation” was the buzzword that made executives nod without understanding. Then it was “big data.” Then “Industry 4.0.” Now it is AI everywhere. Each wave brings the same temptation: to let the tool become the story instead of the outcome.

What I tried to do with this eBook, and what I try to do with every piece of content I create, is stay anchored to the practitioner’s reality. Not theory. Not a showcase of what the technology can do in a lab. What actually ships. What actually fails. What the team on Rung 3 needs to hear at 11pm when their deployment is fighting them.

That is what I hope the five rungs give you. A ladder you can put your weight on.

Here Is Exactly How the AI Toolchain Worked

I want to be specific because I think the specifics are useful.

The infographics came first, from ChatGPT. I gave it the concepts, the frameworks, the key messages, and it generated visuals that I reviewed and curated. Some were brilliant on the first attempt. Some took five iterations. A few I threw out entirely because they were technically wrong, and that is the part that requires a human who actually knows IoT. The tool has no idea whether MQTT is correctly positioned in an architecture diagram. I do.

Claude Cowork then looked at the full collection, forty-three diagrams, and did something I genuinely did not expect it to do well: it read the logical progression across them. It understood that the Awareness diagrams should open the book, that the Production use cases belong after the methodology chapter, that the Data Storytelling infographic is the bridge between Rung 4 and Rung 5. It organised the ladder better than my first draft did.

Is that intelligence? I do not know. But it was useful, and I am not going to pretend it was not.

What AI Cannot Do

If you are an IoT practitioner reading this, the lesson is not “use AI to write your book.” The lesson is that your expertise, your hard-won, field-tested, scar-tissue knowledge, is the thing AI cannot generate. It can package. It can structure. It can format and distribute. But the rung-by-rung logic inside this eBook? That came from doing this work for two decades.

That is what I want to give you. Not a showcase. A ladder.

Now It Is Your Turn

Download the eBook. Start at the rung that makes you uncomfortable, that is always the right one. And if you want to talk through where you are standing, find me on LinkedIn or drop me a message through Favoriot.

The tools changed. The climb has not.

What rung are you on right now, and what is keeping you there?

The Day I Realised I Was Becoming a Human FAQ

There was a time when I actually felt proud every time someone asked me about Favoriot.

Each question felt like a small victory.

It meant people were noticing.
It meant the story was spreading.
It meant our work was reaching somewhere beyond our small team.

Someone would message me.

“What exactly is Favoriot?”
“Is it just a dashboard?”
“Can it connect to this device?”
“How is it different from AWS IoT or ThingsBoard?”
“Do you support AI?”
“Can students use it?”
“Is it for smart cities, or factories, or farms?”

And every time, I replied.

Patiently.

Sometimes through WhatsApp.
Sometimes through LinkedIn messages.
Sometimes through emails that arrived late at night.

Okay, Mazlan… this is good, I told myself.
It means people are interested.

So I kept answering.

Again.

And again.

And again.

Until one day, after probably the hundredth explanation, I suddenly paused.

I stared at my laptop.

Then I asked myself a question that hit me harder than I expected.

Wait… am I building a technology platform… or am I becoming a human FAQ?

That was the moment something clicked.

A small but powerful realisation.

This was not really about repeating answers.

It was about something deeper.

Energy.

Focus.

And scale.

Because if the story of Favoriot only lives inside my head, then every explanation will depend on me personally.

And that is not scalable.

That night, I realised something important.

When people keep asking the same question, it is not a problem.

It is a signal.

A signal that your story is not documented clearly enough.

A signal that your knowledge is trapped inside conversations.

A signal that your platform needs a voice that can speak even when you are asleep.

That was my first aha moment.

The Emotional Side of Repeating Yourself

Let me be honest.

There were moments when I felt tired.

Not angry.

Not irritated.

Just mentally drained.

Imagine explaining the same thing dozens of times.

Sometimes, even after giving a talk or presentation.

For example, after speaking at events like The Star Cybersecurity Summit, where I was invited to share thoughts about IoT systems, AI, and the future of connected technologies, people would still approach me afterwards and ask the exact same question.

“So… what exactly does Favoriot do?”

Part of me almost laughed.

Did I not just explain that on stage for half an hour?

Then another voice in my head replied.

Relax Mazlan. Every audience is new.

Every listener hears things differently.

Every person arrives with a different level of understanding.

Some are engineers.

Some are students.

Some are policymakers.

Some are just curious.

And none of them is wrong for asking.

That was my second realisation.

Repetition is not the enemy.

Confusion is.

If people keep asking the same question, it simply means the explanation has not reached them in a form they can digest.

And that responsibility sits on my shoulders.

The Turning Point

One evening, while replying to yet another email asking the familiar question, I suddenly stopped typing.

I leaned back in my chair.

Why am I answering this privately again?

Then another thought appeared.

Why not answer it publicly once… and let it help hundreds of people instead of one?

That thought changed everything.

Instead of seeing repeated questions as interruptions, I began seeing them as content ideas.

Every repeated question was actually a signal about what people wanted to understand.

If five people ask the same thing, it deserves an article.

If ten people misunderstand a feature, it deserves a tutorial.

If customers keep comparing Favoriot with other platforms, it deserves a structured explanation.

That was the moment I started writing more seriously on IoT World.

Not random thoughts.

Not marketing slogans.

But clear explanations.

What exactly is the Favoriot Insight Framework?

How Favoriot moves from raw data to meaningful decisions.

Why IoT is not just about dashboards.

How universities can build AIoT labs.

Why local councils struggle with smart city projects.

How system integrators can deploy IoT faster.

Each question became an article.

Each doubt became a story.

Each confusion became clarity.

And slowly, something magical happened.

Instead of repeating myself endlessly, I started sending links.

“You might want to read this article.”
“This explains the architecture clearly.”
“This post shows the use case.”

The conversation immediately became deeper.

People no longer start from zero.

They started with understanding.

Building Something Bigger Than Myself

But something else happened, too.

After publishing several articles, people began asking another question.

“Is there one place where we can read everything about Favoriot?”

I smiled when I heard that.

Alright, Mazlan… now the next step is obvious.

That was when the idea of a Favoriot Resources Page was born.

Not a marketing page.

Not a product brochure.

But a knowledge hub.

A place where people can explore the ecosystem properly.

A place where they can learn at their own pace.

On that page, anyone can now explore:

What Favoriot really is
Tutorials and technical guides
Real IoT project challenges
Case studies and architecture explanations
The Favoriot Insight Framework
AI and IoT integration concepts
Videos and learning materials

I wanted it to feel like a digital campus.

Because Favoriot is not just software.

It is an ecosystem.

And ecosystems require structure.

They require stories.

They require documentation.

Without those elements, people only see fragments.

With them, people see the full picture.

The Hidden Lesson for Founders

Many startups face this same challenge.

We assume people understand our product.

We assume our website is clear.

We assume our explanation is good enough.

Most of the time, it is not.

People are busy.

They skim.

They scan.

They make assumptions.

And sometimes those assumptions are completely wrong.

So when people keep asking the same question, the worst reaction is frustration.

The better reaction is curiosity.

Ask yourself:

Why is this still confusing?

Which part of my explanation is missing?

How can I make this easier to understand?

Repeated questions are feedback.

Free feedback.

Valuable feedback.

And if you listen carefully, they tell you exactly what your audience needs.

When the Story Finally Clicked

After writing consistently and building the Resource page, I noticed something interesting.

My explanations became sharper.

Writing forces you to think clearly.

When you write publicly, your ideas become structured.

And suddenly the narrative becomes easier to communicate.

People begin to see the bigger picture.

They understand that Favoriot is not just a tool.

It is a framework.

It is an ecosystem.

It is a learning platform.

It is an AIoT foundation.

Without structure, that sounds confusing.

With structure, it becomes powerful.

The Resource page helped me connect the dots.

From devices to cloud ingestion.

From data streams to analytics.

From rule engines to AI insights.

From dashboards to decision intelligence.

That clarity changed everything.

The Unexpected Reward

Today, people still ask questions.

Of course they do.

And I welcome them.

But the feeling is different now.

Instead of feeling drained, I feel grateful.

Because each question tells me that someone is curious.

Someone is exploring.

Someone wants to understand.

And now I have something meaningful to share.

Not just an answer.

A pathway.

When someone tells me,

“I read your Resource page, and now I understand what Favoriot is.”

That feels incredibly satisfying.

More satisfying than closing a sale.

Because understanding builds trust.

Trust builds relationships.

And relationships build ecosystems.

The Aha Moment

Looking back, I now see that the repeated questions were never the problem.

They were actually guiding me.

They were telling me exactly what needed to be documented.

Exactly what was needed was clarity.

Exactly what was needed was storytelling.

And once I finally organised all that knowledge into structured content, something powerful happened.

The pressure disappeared.

The message became scalable.

And the story of Favoriot could travel further than my own voice.

That was my real aha moment.

When people stop depending on your explanation and start learning from your ideas, you know something meaningful has been built.

Favoriot is not just about connecting devices.

It is about connecting understanding.

And that journey started with a simple realisation.

Sometimes, the most annoying repeated questions are actually the best teachers.

Now I am curious.

Have you ever experienced the same situation in your own journey?

People asking the same question again and again?

What did you do about it?

Did it frustrate you, or did it push you to build something better?

FAVORIOT Resources

From Classrooms to Critical Operations: The Truth About Favoriot’s Enterprise Role

They Thought Favoriot Was Just for Students.

I Let That Misunderstanding Linger for Too Long.

I need to admit something first.

This one is on me.

For years, people have come up to me and asked a question that always makes me pause.

“Dr Mazlan, is Favoriot only an education platform?”

Every time I hear that, I smile politely. I explain. I clarify. I move on.

But deep inside, I talk to myself.

How did we let this idea stick for so long?
Why didn’t we tell the story better?

Let me do this properly here. Slowly. Honestly. From the heart.

Because Favoriot was never born as an academic toy. It was never designed to live only inside labs, classrooms, or final-year projects. Favoriot was built as an enterprise IoT platform for real deployments, real operations, real risks, and real consequences.

Education came later. And it came for a reason.

Favoriot Was Built for the Real World First

When we started Favoriot, the vision was very clear.

Factories. Warehouses. Farms. Buildings. Cities.
Sensors are sending data every second.
Dashboards that people depend on, not admire.
Alerts that wake someone up at 3 a.m. because something is wrong.

That was the intention.

An enterprise IoT platform is not glamorous. It is not flashy. It does not impress with demos alone. It needs to survive power outages, unstable networks, noisy data, and human mistakes.

That is the world Favoriot was designed for.

Air quality monitoring, indoor and outdoor.
Gas detection in agriculture and manufacturing.
Cold chain and warehouse monitoring.
Energy usage. Environmental sensing. Operational visibility.

These are not student exercises. These are systems people rely on to protect assets, livelihoods, and, at times, lives.

And yes, many of these implementations cannot be publicly shared. Clients trust us with their data and their operations. Confidentiality is part of doing real work.

Ironically, that silence made people assume nothing was happening.

Maybe that’s where the misunderstanding started.

The Real Problem Was Never the Platform

Here is the uncomfortable truth.

The biggest challenge in IoT is not platforms.
It is not sensors.
It is not cloud infrastructure.

It is people.

Or more specifically, the lack of people who truly know how to build an IoT solution end-to-end.

Back in 2017, we offered a free plan. We thought adoption would be instant.

It wasn’t.

People signed up.
Then they stopped.
Nothing moved.

And I remember thinking“Why is no one using it?

The answer hurt a little.

They didn’t know how.

They knew dashboards from presentations.
They knew buzzwords from conferences.
They knew how to connect one sensor, sometimes.

But building a full solution?
Designing data flows?
Handling failures?
Understanding why data behaves badly in the real world?

That knowledge gap was huge.

From 2017 to 2022, I saw it everywhere. Universities. Startups. Even some companies. Everyone wanted IoT. Very few knew how to build it properly.

Why We Walked into Education

So we made a decision.

Not a pivot. Not a retreat. A foundation.

If people cannot build IoT solutions, no platform will ever matter.

I remember asking myself:
Do we complain about the talent gap, or do we help close it?

That is when we started working closely with educators. Training lecturers. Creating step-by-step tutorials. Supporting students not to pass subjects, but to understand systems.

That is why Favoriot content online often looks educational.

Not because we are an education-only platform.
But because education was the missing piece in the ecosystem.

We were not selling theory. We were teaching how to connect sensors, send data, manage devices, handle failures, and make sense of messy reality.

Education was not the destination. It was the on-ramp.

Two Worlds. One Platform.

Here is what many people missed.

While all this educational work was happening in public, Favoriot was quietly working with industry in parallel.

Two tracks. Same platform.

On one side, students and lecturers are learning how to build.
On the other, enterprises deploying systems that run daily operations.

The platform did not change.
The expectations did.

Students learn to make things work.
Enterprises demand that things not break.

That dual role was never a conflict. It was a strength.

Education feeds industry.
Industry validates education.

Yet we did not tell that story clearly enough. And for that, I take responsibility.

The Irony of Global Adoption

Here is another irony that few people realise.

Favoriot users come from all over the world. When someone subscribes, they build whatever they want.

We do not always know what devices they connect.
We do not always know what systems they deploy.
We only see data flowing.

Some of the most interesting use cases are completely invisible to us.

And that is exactly how a real platform works.

No hand-holding. No spotlight. Just infrastructure doing its job.

But again, silence creates assumptions.

If people don’t see it, they think it doesn’t exist.

This Is Not Just About Favoriot

This reflection is not only about correcting a misunderstanding.

It is about how we, as a country and as a community, think about capability.

We love importing solutions.
We love buying finished systems.
We rarely invest in learning how they are built.

Then we wonder why we depend on outsiders for everything.

IoT is not magic. It is engineering. It is discipline. It is patience. It is experience.

Platforms like Favoriot matter only when people know how to use them properly.

That is why education and enterprise must never be separated.

What I Wish People Would See

I wish people would stop asking whether Favoriot is for education or industry.

It has always been both.

Education builds builders.
Industry needs builders.

One without the other collapses.

Sometimes I ask myself:
If we had focused only on selling enterprise solutions, would the ecosystem be stronger today?

Honestly? No.

Without talent, platforms die quietly.

A Personal Reflection

I have spent my life in technology. Telecom. IoT. Smart systems. Startups.

The pattern is always the same.

People rush to buy tools.
Very few invest in learning how to use them well.

Favoriot’s story is a reminder to me, too.

Technology without understanding is decoration.
Understanding without real deployment is a fantasy.

We need both.

My Message to Educators

Do not treat IoT platforms as demo tools.

Treat them as environments where students learn responsibility.

Teach failure.
Teach troubleshooting.
Teach why things break.

That is how builders are formed.

My Message to Industry

Do not dismiss platforms you see in universities.

Those environments are where your future engineers are learning.

Support them. Challenge them. Hire them.

You will thank yourself later.

My Message to Policymakers and Leaders

If you want digital capability, stop funding only deployments.

Fund learning.
Fund training.
Fund local platforms and ecosystems.

Ownership starts with understanding.

And Finally, My Message to You

If you are reading this and you once thought Favoriot was “just for education”, I hope this piece helped.

If you already knew the bigger picture, help me tell the story better.

Because platforms do not build ecosystems.
People do.

And ecosystems take time, patience, and honesty.

I’m still learning that myself.

What about you?

Have you seen similar misunderstandings in your work or industry?
Drop your thoughts in the comments. I read them all.

Why Becoming a Producer Nation Still Keeps Me Awake at Night

There was a moment some time ago when I paused in the middle of a talk and looked around the room. Not because I forgot my slides. Not because I lost my train of thought.

But because something heavier crossed my mind.

I was surrounded by capable people. Young engineers. Curious technologists. Lecturers who cared. Students who wanted to build something meaningful.

And a question whispered quietly in my head.

What kind of future are we actually preparing them for?

That question refuses to leave me. It follows me into meetings, classrooms, and late-night reflections. It comes back whenever I see another imported system being installed, another local prototype ignored, another talented graduate settling for work that barely scratches their potential.

This is not about blaming anyone.
This is about being honest with ourselves.

The comfort trap we rarely talk about

Let me say this plainly.

Being a consumer nation feels safe.

You buy what already works.
You rely on someone else’s research.
You avoid the pain of early failure.

There is no embarrassment in using technology built elsewhere. We all do it. I do it too. The problem begins when using becomes the end of the story.

When a country only consumes, it slowly forgets how to create.

Companies no longer need deep technical teams.
Jobs no longer demand strong problem solvers.
Graduates are hired, but not challenged.

And when skills are not demanded, they are not rewarded.

I have watched this cycle quietly repeat itself.

Low demand for advanced skills leads to low salaries.
Low salaries keep household income stuck.
And national ambition stays trapped in speeches instead of results.

I often ask myself, what is the point of producing bright graduates if the economy only needs users?

What changes when a nation chooses to build

A producer nation changes the conversation entirely.

Instead of asking, “What can we buy faster?”
It asks, “What can we build better?”

The moment local companies start developing their own products, something shifts inside the system.

Skills suddenly matter.
Experience becomes valuable.
Talent is no longer replaceable overnight.

Companies compete for people who can design, test, deploy, and maintain real systems. Salaries rise not because someone demands it, but because value is being created on the ground.

This is how strong economies grow. Quietly. Patiently. Through capability, not dependency.

I remind myself often that a producer nation is built by people who are willing to be uncomfortable first.

The painful truth about local innovation

Here is where the story becomes uncomfortable.

Most local startups do not fail because their ideas are bad.
They fail because nobody buys from them early enough.

There is a fragile phase every builder faces.
The search for the first ten customers.

Without those early believers, there is no runway. No learning loop. No chance to improve.

And this is where I sometimes feel uneasy.

We encourage innovation.
We fund research.
We celebrate prototypes.

Yet when it is time to adopt, trust disappears.

I catch myself thinking: why do we support people in building, but hesitate to stand beside them when they are ready?

Without local adoption, many promising efforts fade away. Not loudly. Quietly. One by one.

Universities are not broken. Expectations are.

For years, I have heard the same complaint repeated.

“Universities are not producing commercial products.”

That statement misses the point.

Universities were never meant to be factories.
They are meant to be places where thinking goes deep.

They excel at long-term exploration.
They are strong at building early prototypes.
They train minds, not sales pipelines.

The problem starts when we expect universities to sprint like startups.

I often tell myself, you do not ask a marathon runner to win a 100-meter dash.

When companies bring real, long-term problems to universities, something powerful happens. Research becomes grounded. Students work on issues that matter. And ideas mature with purpose.

The missing bridge between lab and market

There is a wide gap between a working prototype and a product that survives in the field.

Many people underestimate this gap.

A system that works in a lab has not yet faced real users, harsh environments, unreliable networks, or unexpected behaviour. This is where companies must step in.

Universities build understanding.
Companies build resilience.

When they work separately, both struggle.
When they move together, progress accelerates.

This bridge was not built overnight. It takes patience, shared goals, and trust.

Why the first believer matters most

Every global success begins at home.

Before the world trusts you, someone local must.

That is why early adopters matter so much. Especially large organisations and government bodies.

Being the first customer is not charity.
It is leadership.

It gives builders confidence.
It creates reference stories.
It signals belief.

Belief, more than marketing, opens doors beyond borders.

Why I chose to build instead of complain

At some point, reflection was not enough.

I asked myself a harder question.

If I believe in building local capability, what am I personally doing to make it happen?

That question led me to Favoriot.

Favoriot was never about flashy dashboards.
It was about enabling builders.

A place where students move beyond demos.
Where startups test ideas without fear.
Where organisations grow solutions they understand and own.

I wanted a platform that supports responsibility, not just visibility.

A quiet piece of advice I return to often

Do not wait for perfect systems.
Do not wait for perfect policies.
Build anyway.

To students
Choose projects that solve real problems.

To universities
Work with companies that think beyond short grants.

To companies
Invest in local capability, even when it feels slower.

To decision-makers
Adopt local solutions early, not after they succeed elsewhere.

My invitation to you

If you believe our future depends on building, not just buying.
If you believe talent deserves meaningful challenges.
If you believe local solutions deserve real trust.

Then take one step.

Support a local product.
Adopt a local system.
Encourage someone who is trying.

And if you are looking for a place to start building, experimenting, and growing with confidence, explore Favoriot.

Not as software.
But as a choice.

I would love to hear your thoughts.
Are we ready to move from comfort to courage?

Crafting Impactful Final Year Projects: A Guide

I’ve sat on many evaluation panels over the years.

Different universities. Different rooms. Different faces.

But strangely, the pattern is always familiar.

Students walk in carrying posters, prototypes, sometimes with wires still exposed, sometimes with boxes made from recycled lab scraps. They look nervous. Excited. Hopeful. Tired.

And almost every presentation begins the same way.

“This project is about…”
“The objective of this project is…”

I sit back in my chair and quietly think to myself, Ah… here we go again.

Because at that moment, something important is missing.

The Moment Evaluators Lean In or Tune Out

When I evaluate a Final Year Project, I’m not hunting for perfection. I’m not expecting commercial-grade products. I’m not counting how polished the slides are.

I’m listening for one thing.

Do you understand why you built this?

Many students rush straight into objectives, features, and functions. But they forget to set the stage. They forget to frame my mind.

Without a background.
Without a problem that feels real.
Without a pain point that matters.

And when that happens, evaluators start asking questions not because the project is weak, but because the story is unclear.

Help me care first, I always think. Then help me understand.

Start With Pain, Not Purpose

The strongest projects I’ve seen don’t start with what was built.

They start with what hurts.

A system that fails silently.
A manual process that wastes hours.
A safety issue nobody notices until it’s too late.
A data gap nobody talks about.

When students explain the background clearly, something shifts. The room wakes up. The evaluator’s brain starts connecting dots.

Only after that does the objective make sense.

Because now, the solution has a reason to exist.

Scope Is Not a Weakness

Another thing I notice again and again.

Projects that look “complete,” but aren’t honest about their limits.

Students are afraid to admit constraints. Limited time. Limited budget. Limited access to hardware. Limited skills.

But here’s the truth.

A clear scope shows maturity.

When you explain what you chose not to build and why, you’re telling me you understand trade-offs. You understand reality. You’re not pretending.

That impresses evaluators more than pretending everything is done.

The Story of Struggle Matters More Than the Result

Some of the most memorable presentations weren’t the ones that worked perfectly.

They were the ones where students said:

“We tried this. It failed.”
“So we changed this.”
“It broke again.”
“Here’s why we finally chose this approach.”

That tells me you didn’t just follow a tutorial. You wrestled with the problem. You learned where things break.

And that’s exactly what real engineers, builders, and problem solvers do.

Architecture Is Not Just a Diagram

I’ve lost count of how many times I’ve seen architecture diagrams that don’t reflect reality.

Devices sending data to nowhere.
Networks are magically working.
Platforms floating without context.

When I ask, “Where does the data go next?”
Silence.

Architecture is not an artwork. It’s a thinking tool.

If you can’t explain how data moves from device to network, from network to platform, from platform to application, then you don’t fully own your system yet.

This is where supervisors play a big role. And this is where students must slow down and really understand what they are drawing.

Prototypes Don’t Need to Look Pretty

Some students apologise for their mock-ups.

“Sorry, sir, this is just a box.”
“Sorry, sir, we used old parts.”

I always smile.

Because that’s not what I’m judging.

What excites me is when students act out real scenarios. When they simulate how users interact. When they demonstrate behaviour, not just hardware.

I still remember sitting inside a car to experience a student-built parking system. That wasn’t about polish. That was about empathy.

The Question That Makes Everyone Nervous

Then comes the part that always makes students laugh nervously.

“So… who would buy this?”

Suddenly, the room gets quiet.

Many students talk about the cost of components. Few talk about customers. Fewer talk about value.

I’m not expecting a full business plan. I’m testing awareness.

Do you understand that solutions exist to be used?
Do you know who benefits from what you built?

Because a project that solves a real problem for a real group of people already has more value than one that only looks good on demo day.

When Systems Break, Thinking Is Revealed

The most important questions often come at the end.

“What happens if the system fails?”
“How do you troubleshoot this?”
“What would you check first?”

These answers reveal everything.

They show whether learning happened.
They show whether the student truly built the system or just assembled it.

In team projects, I watch carefully. Everyone should understand their role. Everyone should be able to support each other. Silence from team members tells its own story.

Forty Years of Change, One Pattern That Remains

I’ve watched student projects evolve from the 1980s until today.

Better tools. Better access. Better exposure.

Yet one problem remains.

Projects restart from zero every year.

Limited budgets force repetition. The same sensors. The same ideas. The same level of impact.

Imagine if universities treated projects as living systems.

One cohort builds the base.
The next improves it.
Another adds data analysis.
Another adds intelligence.

That’s how meaningful systems grow.

Especially in IoT, where data collected over time becomes more valuable than the device itself.

My Advice to Students and Educators

If you’re a student, remember this.

Your project is not judged by perfection.
It’s judged by understanding.
Clarity.
Honesty.
Growth.

Tell the story of your problem.
Explain your decisions.
Show your struggles.
Own your limits.

If you’re an educator or supervisor, help students see beyond grades.

Teach continuity.
Teach systems thinking.
Teach them to build on each other’s work.

Because the real world doesn’t reset every semester.

And the most important lesson a Final Year Project can teach is not how to build something that works.

It’s how to think when things don’t.

The Moment the Smart City Dashboards Stopped Impressing Me

There was a time when I was impressed by command centres.

Rows of screens.
Maps glowing in neon colours.
Charts are moving in real time.
Operators are pointing at dashboards like air traffic controllers.

It looked powerful.
It looked serious.
It looked… convincing.

But one day, standing quietly at the back of the room, I caught myself thinking something uncomfortable.

If one screen goes dark, who notices?
If the data contradicts another system, who decides?
If something breaks at 2 a.m., who actually understands what is happening?

That was the moment the screens stopped impressing me.

Because cities are not run by visuals.
Cities are run by clarity.

And clarity does not come from dashboards alone.

How Cities Slowly Accumulate Silos Without Realising It

Most local councils chose not to fragment.

Fragmentation happened to them.

Projects arrived one by one.
Budgets were approved year by year.
Each initiative solved a real problem at the time.

Flood monitoring came first.
Then air quality.
Then lakes.
Then traffic.
Then parking.

Each project was justified.
Each vendor delivered.
Each system worked.

Individually.

What nobody planned for was the moment when all these systems would need to speak to each other.

So the command centre slowly became a collection of disconnected truths.

Each dashboard told its own story.
None of them told the whole truth.

When a Dashboard Is Mistaken for a Platform

I often hear this sentence.

“Yes, we already have a smart city platform.”

Then I look closer.

What I see is usually a visual layer.
A presentation surface.
A beautifully designed window.

But behind it, there is no device management.
No rule engine.
No action triggers.
No real-time orchestration.

Just data being shown.

And showing data is not the same as running a city.

A true platform does not just display.
It listens.
It reacts.
It remembers.
It connects.

Two Types of Data That Rarely Shake Hands

Cities live in two data worlds.

The first world is structured, administrative, and familiar.

Assets.
Licences.
Collections.
Population data.
Facilities.

This data is critical. It reveals the city’s shape. It is refreshed periodically and often lives inside systems branded as urban observatories.

The second world is restless.

Sensor data.
Live streams.
Alarms.
Failures.
Spikes.
Drops.

This is IoT data.
It does not wait politely.
It arrives when it wants.
It demands attention.

The mistake happens when we treat both worlds as if they behave the same way.

They do not.

GIS and Digital Twins Without Real-Time Truth

Many councils have strong GIS platforms.

Layers upon layers of insight.
Maps that tell stories about people, land, and risk.

Some go even further with digital twins.
Virtual representations of buildings, roads, and infrastructure.

I admire these efforts.

But without live sensor input, these systems are frozen in time.

They show structure.
Not behaviour.

A city is not just where things are.
It is how things change.

Without IoT data, even the most beautiful digital twin is only a photograph, not a mirror.

Why an Integrated IoT Platform Is Not Optional Anymore

At some point, cities reach a tipping point.

They stop asking for new dashboards.
They start asking better questions.

Why did flooding worsen after that traffic upgrade?
Why does air quality dip only in specific zones?
Why do alarms trigger too late?

These questions cannot be answered inside silos.

They require correlation.

This is where an integrated IoT platform matters.

Not to replace everything.
But to connect everything.

A layer where data from rivers, rain, air, traffic, parking, and buildings can coexist.
A place where patterns emerge.
A place where decisions are supported, not guessed.

This is the role of IoT middleware.
This is where platforms like FAVORIOT were designed to sit.

The Fantasy of One Platform to Rule Them All

Every city dreams of simplicity.
Every vendor dreams of being central.

The idea of one master platform controlling everything is seductive.

But reality is less romantic.

Platforms are built with different goals.
Vendors protect their niches.
Legacy systems do not disappear quietly.

Trying to force everything into one system usually creates resistance, delays, and disappointment.

Cities do not need domination.
They need coordination.

The Quiet Risk Nobody Likes to Talk About

There is a dangerous sentence I hear too often.

“We don’t mind. Let the vendor manage everything.”

It sounds efficient.
It sounds hands-off.

Until the day the council asks for raw data.
Or integration rights.
Or historical access.

And discovers they cannot.

No API.
No export.
No control.

That is vendor lock-in.
And by then, it is too late to complain.

A smart city without data ownership is not smart.
It is dependent.

Procurement Is the Real Smart City Strategy

Smart cities are not won in control rooms.

They are won in procurement documents.

When councils specify openness.
When they demand interoperability.
When they insist on owning their data.

That is when cities protect their future.

Technology can always be upgraded.
Contracts are harder to undo.

Integration Is an Act of Maturity

I no longer believe in replacing everything.

I believe in respecting what already works.
Connecting what matters.
Opening what was once closed.

Legacy platforms should remain.
Specialised systems should continue.
But data must flow.

Sometimes that means managing two or three core platforms instead of one.

That is not failure.
That is realism.

Why I Keep Writing About This

I am not chasing trends.
I am chasing calm.

Calm operators.
Calm decision-makers.
Calm cities that respond instead of react.

When systems are integrated, nights are quieter.
When data is shared, trust grows.
When platforms cooperate, leaders sleep better.

If you are building a smart city, pause before asking for another screen.

Ask instead:
Can this system talk?
Can it share?
Can it last?

If this reflection sounds familiar, I would love to hear from you.

What have you seen in your city?
Where did silos slow you down?
What worked when integration finally happened?

Drop your thoughts in the comments.
Let us learn from each other and build cities that truly understand themselves.

Smart Cities in Malaysia – Between Beautiful Documents and Real Implementation

There is a kind of silence I remember very clearly.

Not the silence of an empty room.
But the silence appears when too many slides are shown, too many big words are used, and too few honest questions are asked.

I was sitting in yet another Smart City presentation. Everyone was talking about master plans, KPIs, ISO standards, indicators, and rankings. The slides looked polished. The diagrams were neat. The language sounded confident.

Yet inside, a quiet question kept repeating.

Who will take care of this after the launch?
Who will wake up when the system fails?
Who will face the public when citizens are angry?

Those questions rarely appear on slides.

And that, for me, is where the real Smart City problem in Malaysia begins.

Why We Talk About Smart Cities at All

Smart Cities are not about technology.

They are about people.

They are about parents stuck in traffic every morning.
Children breathe unhealthy air.
Small business owners suffer when flash floods arrive without warning.

I often say this, and I truly believe it.

The final goal of a Smart City is very simple.

People can live healthier lives.
People can live happier lives.
Cities can run without constant chaos.

That’s it.

Not rankings.
Not awards.
Not plaques on office walls.

Yet somewhere along the way, we lost that simplicity.

When Everyone Wants to Be “Smart”

Today, almost everyone wants the Smart City label. Some go further and call themselves “AI Cities”.

I usually smile when I hear that.

Which AI?
Where is the intelligence?
Or is it just a new signboard?

Many systems branded as AI are simply basic automation. This is not a technology problem. It is a misunderstanding.

What troubles me more is this.

Some cities work quietly, building systems that actually function, yet receive no recognition because they never submitted an application. Others receive recognition early simply because they know how to fill out forms.

That’s when we learn a hard truth.

Recognition does not always reflect maturity.

From 30,000 Feet to 3 Feet

To be fair, Malaysia does have a solid Smart City framework.

On paper, it makes sense.

At 30,000 feet, there is the national master plan.
At 3,000 feet, there are state-level blueprints.
At ground level, around 3 feet, there should be detailed action plans for local councils.

Everything looks structured.

But in reality, many councils are stuck somewhere in between.

Some are still writing plans.
Some are experimenting with pilot projects.
Very few are running systems consistently, day after day.

Not because they don’t care.
Not because they are lazy.

But because something fundamental is missing.

Delivery structure.

Command Centres That Feel Empty

I have visited many command centres.

The name sounds powerful. Command centre. It feels important.

But once inside, the scene is often the same.

CCTV screens.
Live video feeds.
A few officers are watching.

That’s all.

I quietly ask myself.

Where is the data integration?
Where is the analysis?
Where are the decisions driven by this data?

A command centre should be the brain of the city.

Not just its eyes.

Imagine traffic data, air quality, noise levels, parking systems, citizen complaints, legacy databases, all connected and analysed together.

First, we know what has happened.
Then, we understand why it happened.
Next, we anticipate what might happen.
Finally, we know what action to take.

This is where technology truly matters. Not to impress, but to guide decisions.

The Challenges We Rarely Admit

Since around 2015, I have seen the same issues repeat.

Budget That Is Never Enough

Local councils are not money-making machines.

They rely on limited revenue sources. Assessment taxes. Parking fees. Licenses.

With limited funds, choices become limited too.

Projects that generate revenue or reduce costs often get priority. Long-term social impact projects struggle to survive.

Risk-heavy concession models usually favour large companies with deep pockets. Smaller local players, often full of ideas and energy, get pushed aside.

Sometimes I ask myself quietly.

Do we really want local ecosystems to grow?
Or are we just choosing the easiest path?

Projects Without Guardians

This one hurts the most.

Many Smart City projects are launched with excitement. Press conferences. Posters. Promotional videos.

A year later, the system is silent.

No maintenance.
No monitoring.
No clear ownership.

The project becomes a white elephant.

Not because the technology failed.
But because no one was assigned to take care of it.

Skills Gap Is Real

Smart Cities demand new skills.

Data management.
IT infrastructure.
Commercial thinking.
Long-term contract handling.

Many council officers come from strong urban planning backgrounds. They are good at what they do.

But we cannot expect them to suddenly manage complex digital systems without proper support.

This is not an individual failure. It is a structural one.

Fragmented Governance

For solution providers, one simple question often becomes complicated.

Who should we speak to?

Without a clear focal point, discussions lose direction. Time is wasted. Trust slowly fades.

One Answer I Strongly Believe In

If there is one thing that matters most, it is not technology.

It is a Delivery Unit.

A dedicated team.
Given authority.
Given responsibility.
Given continuity.

This unit becomes the caretaker of the entire Smart City lifecycle.

From strategy.
To execution.
To daily operations.
For long-term maintenance.

When this unit exists, everything changes.

Communication becomes clear.
Ownership becomes visible.
Projects do not get abandoned.
Citizens start feeling real benefits.

Smart City stops being a document.
It becomes a service.

Why I Still Have Hope

I am not writing this out of frustration.

I am writing because I still believe.

I believe our local councils are capable.
I believe our local talent is strong.
I believe technology is just a tool, not the answer.

What we need is the courage to admit weaknesses and the wisdom to build the right structure.

Smart City is not a race.
It is a responsibility.

If we want public trust, we must start taking care of what we build.

And it begins with one honest question.

Who will make sure this city still works tomorrow morning?

If this piece made you pause and think, I would love to hear your thoughts.
Leave a comment. Let’s talk.