Tag: Artificial Intelligence

Why Universities Need a Real IoT Lab, Not Just Another Embedded Lab

I still remember a meeting with a group of lecturers, where I asked a simple question.

“Why do we really need an IoT Lab in universities?”

I paused for a moment.
Because deep down, I already knew the answer.

Most universities already have something they proudly call an IoT lab. Rows of ESP32 boards. Arduino kits. LEDs are blinking happily. LCD screens displaying temperature values. Students smile because something lights up.

And yet, something feels incomplete.

This is not IoT. This is just the beginning.

This blog is not meant to criticise universities. I have spent years inside them. I was once a lecturer designing syllabuses, labs, and assessments. This comes from care. From concern. From watching students graduate with confidence in embedded programming but struggle the moment systems become real, connected, and dependent upon.

This reflection is based on a recent lecture I delivered on the need to establish a proper IoT Lab in universities, one that reflects how systems are actually built, deployed, and trusted today.

Embedded Systems Taught Us How to Build Devices

Let me be very clear.

Embedded systems are important. They are foundational.

Students need to learn how to program microcontrollers. They need to understand sensors, actuators, interrupts, memory, and power consumption. All of that matters.

An embedded system is usually a standalone device. It senses something. It controls something. It logs data into local storage.

There is nothing wrong with that.

In fact, embedded systems are still used today in places with no connectivity. Remote areas. Harsh environments. Offline conditions.

But here is the problem.

Once the data is captured, someone has to physically go to the site, connect a laptop, download the data, return with it, and process it manually.

I have seen this happen too many times.

Two technicians. One vehicle. Hours of work. Just to retrieve data that could have been transmitted automatically.

I always ask myself… why are we still doing this in 2026?

Connectivity Changes Everything

The moment a device is connected to the internet, everything changes.

Data no longer waits for humans to come and collect it.
It flows.
It moves.
It becomes alive.

This is the moment embedded systems evolve into the Internet of Things.

Now we can monitor systems remotely.
Now we can detect failures early.
Now we can see battery levels dropping before devices die silently.
Now we can act before complaints arrive.

And yet, most university labs stop just before this moment.

Students are taught how to blink LEDs, but not how to send data reliably.
They learn how to display values, but not how to secure data in transit.
They build devices, but not systems.

And systems are what the real world depends on.

A Real IoT Lab Must Teach Technology Layers

IoT is not a single skill. It is a stack.

In my lecture, I stressed that a proper IoT Lab must expose students to multiple technology layers, not in theory, but through hands-on work.

Layer 1: Hardware and Firmware

This is where universities are already strong.

Sensors. Controllers. Actuators. Firmware logic. Power management.

Students should continue learning this well.

But they must also understand that this is just one layer.

Layer 2: Connectivity and Protocols

This is where gaps start to appear.

Students must learn how data travels.

Wi-Fi. Cellular. LPWAN.
Bluetooth. ZigBee. RFID.
MQTT. CoAP. REST. HTTP.
LoRa. NB-IoT. Sigfox.

Not as a list to memorise.
But as choices with consequences.

Which protocol suits low power?
Which network works for long range?
What happens when connectivity drops?

Without this understanding, troubleshooting becomes guesswork.

Layer 3: Platform and Middleware

This is the heart of IoT.

Devices do not talk directly to dashboards. They talk to platforms.

An IoT platform manages devices.
Authenticates them.
Stores data.
Provides APIs.
Handles scale.

This is where students should learn about device identities, data ingestion, databases, and analytics pipelines.

This is also where they start to understand why platforms like FAVORIOT exist in the first place.

Not to replace learning.
But to enable it.

Layer 4: Analytics and Visualisation

Dashboards are not the end goal.

They are the beginning of understanding.

Students should learn how data evolves from descriptive charts to deeper insights.
They should see patterns.
Spot anomalies.
Ask better questions.

This prepares them for real projects, not demos.

Security Must Exist Across All Layers

Security cannot be an afterthought.

Devices must be authenticated.
Data must be encrypted.
Platforms must be protected.
Applications must be hardened.

Most labs barely touch this.

And yet, this is where real systems fail.

When Systems Break, Knowledge Is Tested

I often tell students this.

The real test of IoT knowledge is not when everything works.

It is when something breaks.

Data stops arriving.
Dashboards go blank.
Alerts do not trigger.

At that moment, students panic if they only know how to code LEDs.

But students who understand layers start asking better questions.

Is it the device?
Is it the network?
Is it the platform?
Is it the visualisation?

This is the mindset a real IoT Lab must build.

Research, AI, and the Future of IoT Labs

Universities are not just about projects. They are about research.

To do meaningful research, students need data. Lots of it. Clean data. Continuous data.

IoT Labs enable this.

Once data flows reliably, students can apply machine learning.
They can explore pattern recognition.
They can experiment with predictive models.

Today, this also means understanding edge AI.

Inference running on devices.
Decisions made locally.
Latency reduced.
Systems are becoming smarter as they operate.

This is where IoT Labs naturally evolve into AIoT Labs.

And this is where universities must go.

This Is a Call to Universities, Lecturers, and Policymakers

If we want graduates who can build real systems, not just academic projects, we must change how we teach IoT.

IoT Labs must move beyond embedded programming.
They must teach architecture, trade-offs, and responsibility.
They must reflect how systems are deployed outside campus walls.

I believe universities can do this.
I believe lecturers want this.
I believe students deserve this.

But it requires intention.

It requires investment.
It requires collaboration with the industry.
It requires courage to redesign labs that have been unchanged for years.

If you are a lecturer, start asking what your lab is missing.
If you are a dean, ask whether your graduates can troubleshoot real systems.
If you are a policymaker, ask whether our talent pipeline matches national ambitions.

And if you are a student reading this, ask yourself one question.

Am I learning how to build a device… or how to build a system people can trust?

I would love to hear your thoughts, experiences, and struggles in building or teaching IoT.
Drop a comment. Let’s talk.

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.

When Data Leaves the Country, Control Leaves With It

A personal reflection on why I insisted on an Enterprise IoT Platform with on-premise deployment

There are moments in a founder’s life when you stop talking about features.

You stop talking about dashboards.
You stop talking about protocols.
You even stop talking about scale.

And you start talking about control.

This was one of those moments.

I remember sitting quietly after one of our internal briefings, staring at the whiteboard filled with arrows, boxes, and deployment diagrams. Everyone had left the room. The air was still.

Why am I pushing so hard for this Enterprise Plan?
Why does this feel heavier than just another pricing tier or feature release?

Then it hit me.

This was not about software.
This was about sovereignty.

And once you see it that way, you can never unsee it.

From owning a kitchen to owning the whole restaurant

For years, I used a simple analogy when explaining IoT platforms.

If you are on a shared cloud platform, you are like a chef renting a kitchen. You can cook. You can serve. But you do not own the space. You follow house rules. You live with limits.

The Enterprise Plan is different.

It is not about owning the kitchen anymore.
It is about owning the whole restaurant.

The building.
The keys.
The doors.
The data flows.
The servers are sitting quietly in your own premises.

When you own the restaurant, no one tells you when to close. No one caps how many customers you can serve. No one decides where your ingredients come from.

That is the mindset behind the Enterprise IoT Platform.

The moment I realised cloud is not always the answer

For a long time, cloud felt like the default answer to everything.

Fast.
Flexible.
Convenient.

I believed in it. I still do, for the right use cases.

But over the years, as I spoke to large organisations, city operators, government agencies, and critical infrastructure owners, a pattern kept repeating itself.

“We don’t want our data outside the country.”
“We need to know exactly where the servers are.”
“We cannot afford external dependencies for this system.”
“This data is too sensitive.”

At first, some people dismissed these concerns as paranoia.

I did not.

Because when you are dealing with traffic lights, water systems, energy grids, and public safety sensors, paranoia is just another word for responsibility.

What happens if the platform is outside the country and something goes wrong?
Who takes control when connectivity is lost?
Who answers when an entire city goes dark?

These are not theoretical questions. These are operational nightmares waiting to happen.

Data sovereignty is not a buzzword when infrastructure is involved

Data sovereignty sounds abstract until you put real consequences next to it.

Imagine a critical infrastructure monitoring system managed by a platform hosted overseas. One day, there is a major failure.

Power outage.
Network disruption.
Access blocked.

The local operators are standing there, staring at blank screens, unable to take control because the system that runs their infrastructure is not physically within reach.

That is unacceptable.

This is why on-premise deployment matters.

Not because it sounds serious.
Not because it looks impressive in a proposal.

But because control must stay with those who are accountable.

This thinking shaped every part of the Enterprise IoT Platform plan.

AI made the stakes even higher

If IoT data is sensitive, AI makes it explosive.

AI models learn from data.
Patterns.
Behaviours.
Weak points.

When AI touches critical infrastructure data, the question is no longer just “where is my data?”

It becomes “who understands my system better than I do?”

That was the turning point for me.

If AI is going to sit on top of IoT data, then the data must never leave the country.

This is not about fear.
This is about governance.

Every country I speak to says the same thing, whether it is Malaysia, Indonesia, the Middle East, or Europe.

“We want AI. But we want our data at home.”

The Enterprise Plan was designed to respect that reality.

Unlimited API is not a luxury; it is a survival

One detail that often gets overlooked is API limits.

People ask me, “Why unlimited API? Isn’t that excessive?”

Let me paint you a picture.

A manufacturing line monitors machines every second.
One sensor. One data point per second.
Multiply that by hundreds of machines.
Multiply again by shifts, days, months.

Suddenly, 500,000 API calls per day is not generous. It is restrictive.

The Developer Plan has limits because it should. It is built for builders, experimentation, and controlled scaling.

But enterprise environments do not experiment. They operate.

If you throttle data in an industrial environment, you are not saving costs. You are introducing blind spots.

Unlimited API is not about indulgence.
It is about continuous visibility.

Two very different enterprise realities

As I refined this plan, two clear deployment models kept emerging.

1. The white-label service provider model

Some organisations do not want to sell hardware.
They want to sell managed IoT services.

They do not want to build a platform from scratch. That path is expensive, slow, and painful.

So they white-label the Enterprise IoT Platform.

Their brand.
Their customers.
Their business logic.

They plug in their agricultural sensors, industrial devices, and vertical solutions, and run everything on their own enterprise platform.

Thousands of customers.
One controlled system.

I have seen how powerful this model can be when done right.

2. The smart city and government deployment model

Then there are cities.

Cities are different.

They already have many solutions. Parking. Flood sensors. Air quality. Lighting. Waste.

The problem is not a lack of data.
The problem is fragmentation.

Every system has its own dashboard. Its own vendor. Its own silo.

Local councils want a single platform, deployed on-premises, where everything comes together.

In some cases, councils cannot do this alone.

That is where state-level deployment makes sense.

One enterprise platform owned by the state.
Local councils connect their data.
Data stays within the country.
Visibility scales across regions.

It is pragmatic. It is cost-aware. It respects sovereignty.

This is bigger than one platform

As I reflect on this journey, I realise something.

The Enterprise IoT Platform is not just a product decision.
It is a philosophical stance.

It says:

You should own your data.
You should control your infrastructure.
You should not outsource accountability.

In a world rushing towards convenience, this is a reminder that responsibility still matters.

A quiet call to builders, cities, and leaders

If you are building systems that people depend on, ask yourself one simple question.

When things go wrong, who truly has control?

If the answer is unclear, it might be time to rethink how your platform is deployed.

I did.
And that rethink led us here.

I would love to hear your thoughts.
Where do you draw the line between convenience and control?
Share your reflections in the comments.

Why We Want Students to Struggle a Little When Learning IoT

I want to be honest with you.

Every time I walk into a university or polytechnic to talk about IoT, I already know the answer before I ask the question.

“What platform are you using for your final year project?”

The answers come fast. Almost automatic.

One particular platform. That has …
A mobile app.
Lots of YouTube tutorials.
GitHub samples.
Forums everywhere.

I nod. I smile.

I’ve heard this story many times.

And then comes the follow-up question.

“Why that platform?”

The answer is almost always the same.

“Because it’s easy.”
“Because there’s a mobile app.”
“Because seniors used it.”
“Because everything is already there.”

At that moment, a quiet thought always crosses my mind.

Easy today, but are you ready for tomorrow?

This blog is not about criticising students. Far from it.

It is about explaining why I believe students need to struggle a little when learning IoT. And why Favoriot was built the way it is.

The Comfort Trap Students Fall Into

I understand why students choose platforms that feel comfortable.

You connect a sensor.
Data appears on your phone.
You show it to your supervisor.
Demo done.

No need to build dashboards.
No need to understand protocols.
No need to worry about servers or data pipelines.

It feels good.

But comfort can be deceptive.

I asked myself, are we training students to build IoT systems, or are we training them to click buttons?

In many universities, IoT projects are still treated as extended embedded-system exercises.

Arduino.
ESP32.
Blink an LED.
Trigger a relay.

Nothing wrong with that.

But IoT is not just about making something move.

IoT is about data travelling.

From sensors.
Through networks.
Into platforms.
Across dashboards.
Into decisions.

If students never see that journey, they never really understand IoT.

The Chicken and Egg Problem Nobody Talks About

Let me share a frustration I rarely say out loud.

Favoriot is still new compared to global platforms.

Students don’t know us because there are fewer tutorials.
There are fewer projects online.
There are fewer YouTube videos.

And because of that, students don’t choose us.

Then I stop and think, how do you ever break this loop?

No users means no content.
No content means no discovery.
No discovery means no users.

Classic chicken and egg.

This is why I spend time going to universities.
Why I accept invitations to serve on industry advisory panels.
Why I keep introducing Favoriot in syllabus discussions.

Not because I want students to use Favoriot blindly.

But because someone has to be the first builder.

“But, Sir, Favoriot Has No Mobile App”

I hear this a lot.

And yes, for a long time, Favoriot did not have its own mobile app.

But here’s something many students don’t know.

There are MQTT mobile clients on Android and iOS.
They already have dashboards.
You configure them.
Connect to Favoriot.
And instantly see live data on your phone.

When I explain this, I see faces change.

“Oh… we didn’t know that.”

That sentence tells me everything.

Sometimes adoption is not about missing features.
It is about missing awareness.

And that is on us.
We need to explain better.
Show better.
Document better.

The Part Students Rarely See: The Full IoT Stack

This is where I get passionate.

IoT is not one skill.
It is many skills stacked together.

When students use platforms that hide everything, they only learn the top layer.

Here’s what real IoT demands.

Hardware
Sensors. Microcontrollers. Power. Battery life.

Connectivity
MQTT. CoAP. REST. WiFi. Cellular. LPWAN.

Platform
Device management. Ingestion. APIs. Storage.

Visualisation
Dashboards. Alerts. Rules.

Analytics
Understanding what happened. Why did it happen? What might happen next? What action to take?

Security
From device firmware to cloud access.

I sometimes ask myself, how can someone troubleshoot what they never learned existed?

Why I Don’t Believe in “No-Code IoT”

This may sound unpopular.

But I don’t believe IoT can be fully no-code.

IoT is physical.
It touches hardware.
It touches networks.
It touches real environments.

You need to understand flows.
You need to debug failures.
You need to trace where the data stops.

If there is no data on the dashboard, is it the platform’s fault?

Or is the sensor dead?
Is the firmware corrupted?
Is the network unstable?
Is the battery empty?

If everything is hidden, you don’t know where to look.

That’s dangerous.

PaaS Is Harder, and That’s the Point

Favoriot is closer to a platform than an app.

Some people say it’s harder.
They are right.

But difficulty is not a flaw.
It is a teacher.

When students use a platform that requires them to configure devices, protocols, dashboards, and rules, they are forced to think.

Why did I choose MQTT here?
Why is my data not arriving?
Why does this alert trigger late?

Those questions build engineers.
Not button-clickers.

Analytics Is Where IoT Becomes Meaningful

I always remind students.

Collecting data is not the goal.
Understanding data is.

IoT analytics moves in stages.

First, you look back.
What happened?

Then you ask why.
What caused it?

Then you look ahead.
What might happen next?

Finally, you decide.
What should I do about it?

This is why we built Favoriot Intelligence inside the platform.

Not as a separate system.
Not as an external tool.

One pipeline.
End-to-end.

Data comes in.
Insights come out.
Actions happen.

This is where IoT starts to feel alive.

AIoT and the Future Students Will Walk Into

Things are shifting fast.

AI is no longer optional.
Edge intelligence is becoming real.

Models trained in the cloud.
Inference pushed to devices.
Decisions made closer to reality.

Students who only learned drag-and-drop dashboards will struggle here.

Students who understand flows, stacks, and constraints will adapt.

That difference matters.

Why I Care So Much About This

People sometimes ask why I spend so much time with universities.

The answer is simple.

I have seen graduates enter the industry confused.
Overwhelmed.
Afraid of real systems.

I don’t want that.

I want students who can walk into a telco, a factory, a startup, or a smart city project and say,

“I don’t know this tool yet, but I understand how IoT works.”

That confidence changes careers.

Practical Tips for Students Learning IoT

Let me leave you with a few honest tips.

Learn beyond your demo
A working demo is not the finish line. Ask what breaks when conditions change.

Trace data end-to-end
Always ask where data starts and where it stops.

Understand at least one protocol deeply
MQTT, CoAP, or REST. Know how it behaves when networks fail.

Build dashboards yourself
Dragging widgets teaches more than screenshots.

Make something fail on purpose
Turn off WiFi. Drain the battery. Observe what happens.

Learn one platform properly
Not ten platforms shallowly.

Document your struggle
Others learn from your mistakes.

A Quiet Invitation

If you are a student reading this and you feel slightly uncomfortable right now, that’s good.

It means you are growing.

If you are a lecturer, consider whether your students are learning embedded systems or IoT.

And if you are one of the early builders willing to share your Favoriot project, you are not just building a system.

You are building a community.

Someone has to be first.

I hope you’ll be one of them.

I would love to hear your thoughts, your struggles, or your stories.
Leave a comment. Let’s talk.

We Gave Our Favoriot IoT Platform Away for Free—Here’s What Actually Happened Next

A quiet, honest story about how Favoriot found its way

I remember the early days of Favoriot very clearly.
It started with a simple belief. If we make it free and easy, people will come. They will build. They will stay.

So we did exactly that.

We built the platform.
We opened the doors.
We told the world, “Come in. Try it. It’s free.”

And people did come. Students. Lecturers. Curious engineers. Friends I met during talks at universities. I would personally invite them. Sometimes I would even hand out complimentary access codes for a full year of the Beginner Plan.

I thought to myself, this is how adoption works.

But something felt off.

When subscribers were not really users

On paper, the numbers looked comforting.
Subscribers were growing. Accounts were created. Dashboards were viewed.

But deep down, I knew something was missing.

Why are so many accounts quiet?
Why do I see logins, but no devices connected?
Why do dashboards stay empty?

That was my first hard lesson.

A subscriber is not always a user.
And a user is not always a builder.

Many people came just to look around. They clicked. They browsed. Then they left. Some even won vouchers but never built a single IoT project.

It hurt a little. Not because of revenue. But because I wanted Favoriot to be used. I wanted it to matter.

The wrong assumption about behaviour

I used to think users would log in every day, tweak dashboards, run experiments.

Reality taught me otherwise.

A typical IoT builder behaves differently.

Once the device connects and the data flows, they step back. They look at the dashboard occasionally. They only return when something breaks or when the project evolves.

Students behave differently, too.

They come intensely during one semester. Final year project season. Late nights. Panic. Excitement. Then, silence.

And to make it harder, many of them already knew other platforms. Some popular. Some free. Some are recommended by seniors.

Favoriot was often an unfamiliar name.

So ,how do you enter the education space when choice is already wide open?

Teaching before selling

I stopped pushing plans and started focusing on learning.

We introduced public IoT training. Beginner. Advanced. Mastering IoT.
Lecturers started attending. Some became trainers themselves. They went back to their universities and taught students using what they learned.

That felt good.

Then we went a step further.

Professional certificates.
Either embedded into the curriculum or offered as short intensive training. Students could finish the course and receive a certificate, or sit for an exam and earn a more formal credential.

Interest grew. Enquiries came in.

But adoption was still slow.

Universities move carefully. Curriculum changes go through committees, boards, and senate meetings. Nothing moves overnight.

I had to learn patience.

Labs instead of just logins

That’s when we bundled everything.

Not just software.
Not just subscriptions.

We created labs.

An IoT Lab with devices, Beginner subscriptions, training, and ready-to-use kits like indoor air quality monitoring.

An AIoT Lab with more advanced tools. Edge devices. Developer Plan access. Machine learning features. Analytics. A space for research, experimentation, and deeper thinking.

Suddenly, Favoriot was no longer just a platform.
It became an environment.

That changed the conversation.

Why Favoriot stayed a platform, not an app

People sometimes ask me, why not make Favoriot simpler? Why not hide everything?

Because IoT is not simple.

If everything is hidden, nothing is learned.

Favoriot is a Platform-as-a-Service by choice. Builders can see the flow. Devices. Protocols. Data ingestion. Visualisation. Rules. Actions.

When something fails, they learn how to troubleshoot.

When they graduate, they carry understanding, not just button-clicking habits.

That’s the skill that survives in the real world.

The restaurant analogy that finally made sense

One day, while explaining our plans, I caught myself using a food analogy. And suddenly, everything clicked.

The Free Plan is peeking into a restaurant.
You look at the menu. You walk around. Then you leave.

The Lite Plan is tasting the food.
You sit down. You try a dish. You smile.

The Beginner Plan is a full meal.
You are satisfied. You build. You complete your project.

The Developer Plan owns the kitchen.
You cook. You create menus. You serve your own customers.

The Enterprise Plan owns the whole restaurant.
You decide everything. Security. Scale. Who gets served and how.

When I explained it this way, people finally nodded.

Overseas users and a quiet mystery

Here’s something that still amazes me.

Favoriot has users from more than 130 countries.
Yet most revenue comes from Malaysia.

How did they even find us?

Blogs.
E-books.
Social media posts.
YouTube. TikTok. Facebook groups.

They came. They explored. Most stayed free.

And that taught me another lesson.

Free users overseas were often explorers. Platform shoppers. Comparing interfaces. Looking around.

Not every visitor is ready to commit.

And that’s okay.

Personas matter more than pricing

Over the years, I stopped blaming pricing.

Instead, I studied personas.

Browsers.
Tasters.
Builders.
Integrators.
Operators.

Each one needs a different message.

Each one enters the journey at a different door.

And that was the missing piece all along.

Partners instead of long walks alone

I also realised something else.

We cannot do everything ourselves.

We do not have endless arms and legs to reach every market.

So we shifted.

System integrators.
Hardware partners.
Domain experts.
Universities.

They already speak the language of their customers. We just give them the kitchen.

That felt right.

AI as my late-night thinking partner

I will admit this honestly.

AI changed how I think.

When I was in corporate life, clarity came from meetings, workshops, and committees.

Today, clarity comes at night. Quietly. One question at a time.

I talk.
I reflect.
I get challenged.

Not every suggestion is usable. But every session sharpens my thinking.

Sometimes, you just need a friend who listens without ego.

Community as the long game

Lately, I spend more time on LinkedIn.

I see students from India proudly showing their projects. Some use other platforms. Some barely send data to the cloud.

I comment. I encourage. I invite.

“Try Favoriot.”
“Show us your project.”
“We will feature your story.”

Because visibility matters.

When builders are seen, they stay longer.

And when they grow, they remember.

This journey is still unfolding

Go-to-market favoriot

Favoriot did not arrive here overnight.
It took years of confusion, wrong assumptions, quiet learning, and small corrections.

But today, the path feels clearer.

Free curiosity has a place.
So does tasting.
So does building.
So does owning the kitchen.

If you are just browsing, welcome.
If you are ready to build, stay.
If you want to serve others, let’s talk.

And if you are a student building your first IoT project somewhere in the world, remember this.

The platform you choose today might become the one you trust tomorrow.

I would love to hear your thoughts.
Where are you in this journey?
Peeking, tasting, cooking, or running the whole place?

Leave a comment. Let’s talk.

Favoriot: AI Agents Not Needed Now

Do Favoriot need to develop an AI Agent feature?

Short answer? No, Favoriot does not need full AI Agent automation right now.

And yes, what you have today is more than enough for the market you are serving.

Let me explain this the way I usually reason with myself.

I asked myself this quietly

“Do customers really want systems that act on their own…

or do they want systems they can trust?”

When I sit with city operators, facility managers, engineers, or even researchers, one thing keeps coming up.

They are not asking for autonomy.

They are asking for clarity.

They want fewer surprises.

They want earlier signals.

They want confidence before taking action.

That matters.

What Favoriot already does well

Right now, Favoriot Intelligence does something very important and very rare.

It learns patterns from real operational data

It surfaces what looks unusual

It feeds those insights into a Rule Engine

And then… it stops

That stopping point is not a weakness.

It is a design choice.

The system says,

“Here is what changed.

Here is why it matters.

You decide what to do next.”

That is precisely where trust is built.

Rule Engine + ML is not a compromise

Some people frame this as:

“Rule Engine now, AI Agents later.”

I don’t see it that way.

I see it as:

ML decides what deserves attention

Rules decide what action is allowed

This separation is powerful.

Why?

Because rules are:

  • Auditable
  • Explainable
  • Governable
  • Aligned with SOPs and regulations

And ML is:

  • Adaptive
  • Pattern-driven
  • Good at spotting drift and anomalies

Together, they form a human-in-the-loop intelligence system, not a black box.

That is exactly what enterprises and public sector teams are comfortable with today.

Do customers actually want AI Agents?

Here’s the uncomfortable truth.

Most organisations say they want AI to “automate everything”.

But when you ask one more question…

“Are you okay if the system shuts down equipment on its own?”

“Are you okay if it triggers evacuation automatically?”

“Are you okay if it changes operating parameters without approval?”

The room goes quiet.

What they really want is:

  • Earlier warnings
  • Better recommendations
  • Fewer false alarms
  • Less manual rule tuning

Favoriot Intelligence already delivers that.

Where AI Agents actually make sense later

I’m not against AI Agents. Not at all.

But their place is conditional, not universal.

AI Agents make sense when:

  • Policies are mature
  • Actions are reversible
  • Risk is low
  • Trust has been earned over time

For example:

  • Automated report generation
  • Recommendation ranking
  • Suggesting rule adjustments
  • Proposing actions for approval

Notice the word: suggesting, not executing.

That is a natural evolution path.

Not a starting point.

Strategically, Favoriot is in the right place.

By keeping:

  • ML for learning and insight
  • Rules for control and action

Favoriot positions itself as:

  • Reliable
  • Safe
  • Deployable today
  • Acceptable to conservative sectors

Smart cities.

Utilities.

Campuses.

Critical infrastructure.

These sectors do not reward “full autonomy” first.

They reward predictability and confidence.

My honest conclusion

If I had to answer this as simply as possible:

Favoriot does not need AI Agents to be valuable.

Favoriot Intelligence with ML-driven rules is already the right solution for today.

AI Agents can come later, carefully, selectively, and with guardrails.

Right now, Favoriot is doing something more important than automation.

It is helping people think earlier, not react later.

And that, in my book, is real intelligence.

Lessons Learned in Building FAVORIOT’s IoT Ecosystem

The story of FAVORIOT mirrors the word in that image, FAILURE, not as an end but as a teacher.

It began with a fall.
When FAVORIOT was first founded, the dream was bold — to make Malaysia a producer of IoT technology, not just a consumer. But reality was harsh. Funding was scarce, and few believed that a local IoT platform could compete with global giants like AWS or Azure. There were moments when the lights almost went out.

Then came acknowledgement.
The team looked in the mirror and admitted that building a platform alone was not enough. They needed to build an ecosystem. An IoT movement. Training, community, developers, partners, the entire value chain. It was not about selling software anymore. It was about empowering people.

Next was investigation.
What went wrong in those early pilots? Why were customers hesitant? FAVORIOT analysed every feedback, every failed proof of concept, and every lost deal. They realised the issue was not the technology but trust, awareness, and readiness.

So they began to learn.
They turned lessons into playbooks, products, and courses. They trained universities, upskilled engineers, and worked hand in hand with students and enterprises to show that IoT was not rocket science. Every workshop, every certification, every hands-on project became a step towards mastery.

Then came understanding.
The mission became clearer. Build Malaysia’s own IoT backbone for data sovereignty and local innovation. FAVORIOT was not just a platform; it was a bridge between learning and real-world application, between local talent and global opportunity.

With clarity, they began to realign.
FAVORIOT expanded globally, partnering with system integrators from Indonesia, the Philippines, India, and Canada. The vision grew into “25 countries by 2025.” They built the Fayverse, a galaxy of innovators orbiting the same belief that local technology can shine on the world stage.

And finally, they evolved.
FAVORIOT became more than a company. It became a story of resilience. A proof that falling is not failure. Staying down is. Every setback became a stepping stone. Every obstacle, a teacher.

From falling to flying, that is the real story of FAVORIOT.

Overview of FAVORIOT C0mplete Brand

💡 Brand Strategy

Brand Substance

Purpose:
To empower nations, universities, and innovators to build their own IoT ecosystems — achieving technological sovereignty and nurturing the next generation of IoT creators.

Vision:
To make FAVORIOT the world’s most trusted IoT platform that helps nations become producers, not just consumers, of technology.

Mission:
To simplify IoT adoption through education, local partnerships, and accessible platforms — enabling anyone, from students to enterprises, to build impactful smart solutions.

Values:

  • Empowerment: We lift others to build.
  • Collaboration: We grow together through partnerships.
  • Integrity: We stand for transparency and trust in every connection.
  • Curiosity: We explore, learn, and innovate with heart.
  • Resilience: We pivot, persevere, and keep moving forward.

Positioning Strategy

Audience:
Universities, startups, system integrators, and governments seeking IoT independence and real-world learning platforms.

Competition:
Global IoT hyperscalers (AWS IoT, Azure IoT, ThingsBoard) — but FAVORIOT differentiates by offering a local, sovereign, and education-driven ecosystem that’s made by Malaysians, for the world.

Difference:
FAVORIOT bridges education and enterprise — combining IoT training, certification, and deployment in one platform. It’s not just about data; it’s about developing people, institutions, and nations.

Brand Expression

Brand Persona

Brand Voice:
Warm, insightful, humble yet confident. Speaks like a mentor or friend who believes in your potential to create something great.

Brand Communication

Core Messaging:
“Let’s build the IoT world together.”
(Reflects collaboration, empowerment, and shared growth.)

Storytelling Framework:
Stories center around:

  • Empowering students and educators.
  • Real IoT impact on communities and industries.
  • Favoriot’s journey — from survival to global partnerships.
  • The vision of a Producer Nation and the rise of the Fayverse.

Brand Taglines:

  • “Empowering Nations to Build Their Own IoT Ecosystem.”
  • “Let’s Build the IoT World Together.”
  • “From Learners to Leaders in IoT.”

Visual Expression

Brand Identity:

  • Logo: Stylized “F” circuit path on magenta circle
  • Color: Official magenta #B90083 (symbolizing creativity, boldness, and human warmth)
  • Typography: Rounded sans-serif — modern yet approachable
  • Mascot: Faybee (symbol of teamwork and energy)
  • Personas: IoT Man and IoT Queen

Brand Presence:

  • Platforms: favoriot.com, Medium, LinkedIn, YouTube, Spotify podcasts
  • Ecosystem: Universities, startups, and global partners in 10+ countries
  • Tone: Storytelling-driven, people-first, optimistic, and visionary

❤️ Summary

FAVORIOT is more than an IoT platform — it’s a movement.
A story about how local innovation can grow into a global ecosystem.
It represents Malaysia’s dream of becoming a Producer Nation, built on collaboration, purpose, and belief in our own capabilities.

Why Favoriot’s Vision to Democratize IoT Matters

What if the future of technology wasn’t just controlled by a handful of giants, but built by thousands of creators everywhere?

That’s the vision we carry at Favoriot. Not a future where IoT is locked away in labs, hidden behind paywalls, or restricted to enterprises with deep pockets. But a world where every student, every startup, every dreamer with an idea can create, test, and scale their own IoT solutions.

I often ask myself, why should the power of IoT belong to only a few?

The truth is that IoT has the potential to transform every aspect of our lives, from smart cities that breathe with data, to farms that thrive with precision, to factories that learn and improve with every machine cycle. However, the doors to building IoT are often closed by complexity, cost, and exclusivity.

That’s why Favoriot exists.

IoT Shouldn’t Be an Exclusive Club

I’ve been in the tech industry long enough to know this: many brilliant ideas die before they even take their first breath. Why? Because the entry barrier is too high.

I’ve seen students with incredible IoT project ideas get stuck because they couldn’t afford expensive platforms. I’ve watched startups burn months trying to stitch together incompatible systems, only to give up before their product reached the market.

I thought to myself, what if we could change that narrative? What if we could open the gate wider?

Favoriot’s vision is simple yet powerful — to democratize IoT. To build a platform that doesn’t intimidate but empowers. One that invites creators instead of scaring them off.

Building More Creators, Not Just More Users

Most platforms are designed to create more users. But Favoriot is designed to generate more creators.

That difference matters.

Being a user means consuming what someone else has built. Being a creator means shaping the future, solving your own problems, and building solutions that matter to your community.

At Favoriot, we want a high school student in Johor to build a smart agriculture project that could feed her village. We want a startup in Manila to prototype a healthcare monitoring device without relying on investors for funding. We want universities in Africa to launch IoT labs that not only teach theory but also create real projects that positively impact lives.

This is not about numbers. This is about empowerment.

The Favoriot Platform: More Than Just Tech

Yes, Favoriot is a platform. It’s a cloud-based IoT engine that connects devices, collects data, and helps you make sense of it. But to me, it’s more than that.

It’s a bridge.

A bridge between ideas and reality. Between imagination and execution. Between a world where IoT is for the privileged few and a future where IoT belongs to everyone.

When we built Favoriot, we made a conscious choice: simplicity, openness, and accessibility. No vendor lock-ins. No hidden traps. Just a space where your IoT journey can grow from blinking an LED to managing a smart city.

I smiled when one of our users once told me, “Favoriot is like training wheels for IoT — it helps us ride until we’re ready to pedal on our own.”

That’s exactly how I see it.

A Vision Rooted in Humanity

For me, democratising IoT is not just about technology; it’s also about empowering people. It’s about humanity.

Imagine if every farmer could monitor their crops in real time. Imagine if every doctor in rural areas had access to patient data at their fingertips. Imagine if every student, regardless of their location, could create something that addresses real-world problems.

That’s the kind of future I want to see.

I know it won’t be easy. Change never is. There will always be resistance from those who benefit from keeping technology closed, complicated, and expensive. But I also know this — the world has always moved forward when ordinary people were given extraordinary tools.

Why Now?

Because the world cannot wait.

IoT is no longer a buzzword; it’s the nervous system of modern life. From the cars we drive to the homes we live in, from the energy grids that power us to the health systems that save us, IoT is everywhere.

But here’s the catch: if only a few can create, then only a few will shape that future. And that, to me, is unacceptable.

We need diversity. We need creativity. We need more voices, more perspectives, more hands building solutions. And that only happens when IoT is democratized.

Closing the Gap Between Dream and Reality

Every time I see a young innovator upload their first data stream into Favoriot, I feel a surge of hope. It’s not just data flowing into the cloud — it’s dreams taking shape.

Every time a small business uses Favoriot to track their machines and reduce downtime, I see a glimpse of the future economy.

Every time a teacher tells me their students used Favoriot to complete a project that once felt impossible, I’m reminded of why we started this journey.

The gap between dream and reality doesn’t have to be wide. Favoriot is here to close it.

The Future We Want to Build

I don’t just want to build a successful company. I want to create an ecosystem. A movement. A community of creators who believe that IoT is not just for the rich, the powerful, or the technically elite.

I want Favoriot to be remembered not just as a platform, but as a turning point. The moment when IoT stopped being a privilege and began to become a right.

I thought to myself, maybe the true legacy of Favoriot isn’t the platform we built — but the creators we inspired.

And that’s a future worth fighting for.

Leading LLMs of August 2025: Who’s Winning the AI Race?

If AI progress felt like a sprint in 2023, by 2025, it looks more like a rocket launch. Models aren’t just improving year by year—they’re leaping ahead month by month. What we thought was “cutting edge” last quarter is already yesterday’s news.

Here’s the reality: the global LLM market is surging toward $105.5 billion in North America by 2030. That’s not a forecast—it’s a signal. AI is no longer a novelty; it’s infrastructure.

But with so many options, which models actually matter right now? Which ones are shaping the way businesses, developers, and researchers use AI today?

I’ve rounded up the 10 large language models making the most significant impact in August 2025. Each one has its own unique personality, strengths, and trade-offs.

1. OpenAI – GPT-5

ChatGPT 5 is the next step in OpenAI’s journey, moving beyond GPT-4.5’s strengths to deliver a model that feels sharper, more adaptive, and more transparent in its reasoning. Where GPT-4.5 leaned heavily on pattern recognition, ChatGPT 5 combines that fluency with stronger deliberate reasoning, giving it the ability to break down problems with more structure and clarity.

It is also built to integrate more smoothly into real workflows. From handling long-form context with greater accuracy to providing clearer explanations of its answers, ChatGPT 5 is less about simply generating text and more about acting as a reliable partner. The model handles multimodal input—text, images, audio, and video—with greater fluidity, making it useful across industries from education to enterprise automation.

Like its predecessor, ChatGPT 5 remains proprietary, available through subscriptions or enterprise licensing. But for teams that want both conversational polish and deeper reasoning ability in one package, ChatGPT 5 has quickly become the new reference point.

2. DeepSeek – The Open-Source Challenger

China’s DeepSeek R1 took the AI world by storm with 671B parameters in a Mixture-of-Experts setup. By May 2025, their DeepSeek-V3 was leading the open-source leaderboard, proving that open models can compete head-to-head with proprietary giants.

The magic? 30 times cheaper than OpenAI’s o1 and 5 times faster. It thrives in reasoning-heavy tasks like math, coding, and scientific simulations. And with RAG integration, enterprises can plug it into sensitive datasets while maintaining control.

If you want open-source power with enterprise-level results, DeepSeek is redefining the game.

3. Qwen – Alibaba’s Efficiency Master

Alibaba’s Qwen 3 family is quietly powering industries across Asia. Their standout, QwQ-32B, rivals GPT-4o and DeepSeek in reasoning and coding while requiring far less compute.

With 32K context windows, Apache 2.0 licensing, and a parameter range from 1.8B to 72B, Qwen has become one of the most accessible and widely adopted LLM ecosystems. Already, over 90,000 businesses use it for gaming, consumer electronics, and enterprise workflows.

Qwen proves you don’t need hyperscale resources to compete at the highest level.

4. Grok – Elon Musk’s Conversational Rebel

Built by xAI and integrated into the X platform, Grok 3 feels different. It’s witty, fast, and plugged into real-time information.

With Think, Big Brain, and DeepSearch modes, it breaks down problems and pulls fresh data directly from the web and social feeds. Trained with 10x the compute of Grok 2, it’s designed for speed and trend awareness.

If your world demands live analysis, news tracking, or instant customer interaction, Grok brings something truly unique.

5. Llama – Meta’s Open-Weight Titan

Meta’s Llama 4 arrived in April with two flagship versions: Scout and Maverick. Both are natively multimodal, handling text, images, and short video, and they boast 256K token context windows.

The openness of Llama remains its secret weapon. Businesses and researchers can run it on their own terms, tune it to specific workflows, and avoid vendor lock-in.

If freedom and flexibility matter most, Llama is the open-source heavyweight to trust.

6. Claude – Anthropic’s Reflective Thinker

Anthropic’s Claude 4 Sonnet is like the careful colleague who always double-checks their work. Its extended thinking mode allows the model to pause, reflect, and refine outputs before committing.

With a 200K-token context window, it handles long documents with ease, making it a natural fit for legal analysis, compliance-heavy industries, and coding projects that need extra accuracy.

If reliability is more important than speed, Claude delivers consistency and thoughtfulness.

7. Mistral – Small but Mighty

Sometimes you don’t need a massive model—you need one that’s fast and affordable. Enter Mistral Small 3.

With 24B parameters, Apache 2.0 licensing, and speeds up to 150 tokens per second, it’s optimised for low-latency applications. The kicker? You can run it on a single GPU or even a MacBook.

For startups and lean businesses, Mistral proves that small models can pack a punch.

8. Gemini – Google’s Reasoning Powerhouse

Google’s Gemini 2.5 is pushing boundaries with a 1M-token context window. That means it can process entire books or databases in one shot.

It’s multimodal, handling text, images, and code, and comes with self-fact-checking to reduce hallucinations.

It’s proprietary, so data compliance matters, but if you want enterprise-grade multimodality and serious reasoning, Gemini is one of the most advanced options on the market.

For those preferring open weights, Google’s Gemma 3 (1B–27B) brings much of the same reasoning strength in a lighter package.

9. Command R – Cohere’s Enterprise Specialist

Cohere isn’t trying to win the hype war—it’s focused on enterprise workflows. Their Command R+ offers 128K context windows, built-in citations, multilingual coverage, and retrieval-augmented generation.

It excels at policy manuals, compliance-heavy industries, and multilingual customer service. And for companies needing control, Command A is open-sourced at 111B parameters with 256K context support.

For enterprises where accuracy and compliance come first, Cohere is a trusted partner.

10. Falcon – The Middle Eastern Power Play

From the Technology Innovation Institute (TII) in Abu Dhabi, Falcon has emerged as one of the strongest open-weight LLMs outside the US, China, or Europe.

The latest version, Falcon 2, boasts multilingual capabilities, optimised efficiency, and open-access licensing. It’s trained on a diverse dataset with an emphasis on global inclusivity, making it particularly strong in Arabic and other underrepresented languages.

What makes Falcon stand out is its mission: bringing AI sovereignty to regions that often depend on Western or Chinese tech. By providing a robust open-source model, Falcon gives governments, universities, and enterprises across the Middle East a homegrown alternative.

If AI diversity and regional sovereignty are important to you, Falcon is an LLM worth watching closely.

Closing Thoughts

Ten models. Ten different approaches to the future of AI.

  • OpenAI and Gemini lead with polished, proprietary power.
  • DeepSeek, Qwen, Llama, and Falcon prove open-source can compete and even outpace.
  • Claude and Cohere focus on reliability and compliance.
  • Mistral and Grok carve out niches in speed, agility, and personality.

The bigger question isn’t “Which is the best?” but “Which one is the best fit for you?”

AI in 2025 is not a single path—it’s a crossroads with ten directions. And whichever road you choose, the destination is changing how we work, build, and think.

Now I’d love to hear from you. Which of these ten models do you think will dominate the AI race by 2030—and why? Share your thoughts in the comments.