Dear All,

Effective today, 1 September 2026, we are introducing a new structure for the FAVORIOT subscription plans.

As FAVORIOT continues to serve different types of users, from individual makers and startups to professionals and businesses, we have renamed our existing plans to better reflect how they are being used. A new pricing is also announced.

The changes are:

• Lite Plan → Maker Plan
• Beginner Plan → Startup Plan
• Developer Plan → Professional Plan

We are also introducing a NEW subscription tier:

⭐ Business Plan

The Business Plan provides another step for users whose IoT projects are moving beyond individual development and require a plan better suited for business and operational use.

If you are currently using FAVORIOT, please take a look at the new plan structure and see which plan best matches what you are building today.

View the new FAVORIOT plans:
https://www.favoriot.com/iotplatform/pricing

Manage or upgrade your subscription:
https://platform.favoriot.com/iot/subscriptions

Thank you for being part of the FAVORIOT community.

Connect • See • Act™
FAVORIOT

Crowdsourced Air-Quality Monitoring Using the FAVORIOT Developer Plan

1. Project concept

Malaysia AirWatch is a citizen-supported air-quality monitoring project. Schools, universities, community groups, businesses and individual volunteers install low-cost sensor stations at their locations.

Each station measures local air conditions and sends the readings to the FAVORIOT platform. The combined data appears on a public map showing air-quality patterns across Malaysia.

The project does not replace the Department of Environment’s official monitoring stations. It provides denser, neighbourhood-level observations that may help people identify local changes, pollution hotspots and unusual events.

The basic flow is:

flowchart LR
    A["Community sensor"] --> B["Wi-Fi or 4G"]
    B --> C["FAVORIOT"]
    C --> D["Quality checks"]
    D --> E["Public map"]
    D --> F["Alerts and analysis"]

2. Project objectives

The project should pursue five clear objectives:

1. Collect PM2.5 and PM10 data from many Malaysian locations.
2. Build a public community air-quality map.
3. involve schools, universities and citizens in environmental monitoring.
4. Detect unusual pollution patterns at neighbourhood level.
5. Create a national dataset for education, research and public awareness.

A good pilot target would be:

• 100 monitoring stations
• At least 10 states
• Urban, suburban and rural locations
• One reading every five minutes
• Six months of continuous operation
• At least 85% station uptime

3. Why the FAVORIOT Developer Plan fits

The current Developer Plan costs RM300 per month or RM3,000 per year. It includes:

• 500,000 API calls per day
• Unlimited devices
• Unlimited private and public dashboards
• Up to 30 widgets per dashboard
• Map widgets
• Device connectivity status
• Data import and export
• Edge Gateway
• Firmware OTA
• Advanced analytics and machine-learning models
• Email and Telegram notifications
• HTTP POST forwarding to external systems
• Customer accounts with designated access
• One-year data retention

These features make it suitable for a national crowdsourcing pilot. ⁠FAVORIOT pricing page

Estimated platform capacity

If each station sends one message every five minutes:

288\ messages\ per\ station\ per\ day

Theoretically, one Developer Plan can support about 1,700 stations at five-minute intervals. A safer operational ceiling would be around 1,300 to 1,500 stations, leaving capacity for testing, device management, retries and external applications.

4. Choose what the stations will measure

Required measurements

Every station should measure:

• PM2.5
• PM10
• Temperature
• Relative humidity

Temperature and humidity matter because low-cost particulate sensors can be affected by environmental conditions.

Optional measurements

Selected research-grade stations may also measure:

• Carbon dioxide
• Carbon monoxide
• Nitrogen dioxide
• Ozone
• Volatile organic compounds
• Atmospheric pressure
• Noise level

I would not put every sensor into the first version. Gas sensors can produce misleading readings without proper calibration. Start with PM2.5, PM10, temperature and humidity.

5. Build the standard AirWatch station

Recommended components

For locations without Wi-Fi, use:

• 4G LTE router or modem
• LoRaWAN gateway where local coverage exists
• Store-and-forward memory when connectivity is interrupted

Estimated hardware cost

These are planning estimates. The final cost depends on sensor model, enclosure, power and connectivity.

6. Define where sensors may be installed

Participants should place stations:

• Under a sheltered outdoor area
• Between 1.5 and 3 metres above ground
• Away from kitchen exhausts
• Away from cigarette-smoking areas
• Away from direct rain
• Away from air-conditioning outlets
• With unrestricted airflow
• Where the Wi-Fi signal is stable
• Where power is continuously available

The project should record the installation environment:

• Roadside
• Residential
• School
• University
• Industrial vicinity
• Commercial
• Rural
• Agricultural
• Coastal
• Forest-edge

Without this context, two readings may appear comparable when they are actually taken under very different conditions.

7. Create the FAVORIOT project structure

Create the following hierarchy in FAVORIOT:

Project

Malaysia AirWatch

Applications

• Community Air Quality Monitoring
• Station Health Monitoring
• Research and Analytics
• Public Air Quality Map

Groups

Groups can represent states:

• Johor
• Kedah
• Kelantan
• Melaka
• Negeri Sembilan
• Pahang
• Penang
• Perak
• Perlis
• Sabah
• Sarawak
• Selangor
• Terengganu
• Kuala Lumpur
• Putrajaya
• Labuan

For a larger deployment, create subgroups using districts or station categories.

Device naming convention

Use a consistent device ID:

MY-[STATE]-[DISTRICT]-[NUMBER]

Examples:

• MY-SGR-PUCHONG-001
• MY-JHR-JB-003
• MY-SWK-KUCHING-012

Do not use a volunteer’s name, house address or telephone number in the device ID.

8. Design the data payload

Each station should send a consistent JSON payload:

{
  "device_developer_id": "MY-SGR-PUCHONG-001@username",
  "data": {
    "pm1": 8.4,
    "pm25": 18.7,
    "pm10": 31.2,
    "temperature": 29.8,
    "humidity": 71.4,
    "latitude": 3.0321,
    "longitude": 101.6185,
    "location_type": "residential",
    "firmware_version": "1.0.0",
    "sensor_model": "PMS5003",
    "wifi_rssi": -63,
    "uptime_seconds": 86420,
    "quality_flag": "raw"
  }
}

FAVORIOT supports HTTPS, MQTT, WebSocket and CoAP for device connectivity. Each device can be given its own access token rather than sharing the account’s main API key. ⁠FAVORIOT platform documentation

9. Protect participant privacy

Exact household coordinates should not be displayed publicly.

Use two location levels:

• Exact coordinates: kept in the private administration records.
• Public coordinates: rounded or displaced by approximately 500 metres to 1 kilometre.

Public participants should see only:

• Station ID
• General area
• District and state
• Latest readings
• Historical trend
• Station status
• Sensor type
• Last update time

The registration form should explain:

• What information will be collected
• Which information will be public
• Who owns the contributed data
• How the data may be used
• How participants can withdraw
• Whether researchers may download the dataset

10. Develop the sensor firmware

The ESP32 firmware should perform these steps:

1. Start the particulate, temperature and humidity sensors.
2. Connect to Wi-Fi.
3. Synchronise the clock.
4. Allow the particulate sensor to stabilise.
5. Take several readings.
6. Remove clearly invalid measurements.
7. Calculate a short average.
8. Send the payload to FAVORIOT over HTTPS or MQTTS.
9. Confirm successful transmission.
10. Save failed readings locally.
11. Retry when connectivity returns.
12. Report station-health information.
13. Check for firmware updates.

Recommended sampling:

• Read sensors every 30 seconds.
• Calculate the median or trimmed mean over five minutes.
• Send one consolidated message every five minutes.

This reduces noise and consumes fewer API calls than transmitting every raw reading.

11. Test ten prototype stations

Do not immediately distribute 100 stations. Build ten prototypes first.

Place them in several conditions:

• Two beside an official or trusted reference station
• Two at universities
• Two at schools
• Two in residential areas
• One near a busy road
• One in a rural area

Run them for four weeks. During testing, check:

• Differences between units
• Humidity effects
• Missing data
• Sensor drift
• Wi-Fi failures
• Heat inside the enclosure
• Rain protection
• Firmware stability

Put all ten units beside one another for several days before deployment. This co-location test reveals whether one sensor consistently reads higher or lower than the others.

12. Create data-quality rules

Crowdsourced measurements require visible quality labels.

Suggested quality flags

Automatic checks

Flag a reading when:

• PM2.5 or PM10 is negative
• PM2.5 is far higher than PM10
• Temperature or humidity is outside plausible limits
• The same reading repeats for an unusually long time
• The value changes too sharply between intervals
• The station has weak connectivity
• The device clock is wrong
• Readings diverge greatly from nearby stations

A high reading from one low-cost station should be treated as a signal to investigate, not proof of a pollution incident.

13. Build the FAVORIOT dashboards

Public national dashboard

Include:

• Map of all active stations
• Latest PM2.5 readings
• Colour-coded air-quality categories
• National average
• Highest current readings
• State comparison
• Twenty-four-hour trend
• Last update time
• Explanation of the quality flags
• Clear non-regulatory disclaimer

State dashboard

Include:

• State map
• District comparison
• Hourly PM2.5 and PM10 trends
• Seven-day trend
• Active and offline stations
• Locations with unusual readings

Technical dashboard

Keep this private for administrators:

• Device connectivity status
• Wi-Fi strength
• Last message time
• Firmware version
• Sensor age
• Missing-data rate
• Battery or power status
• Stations requiring maintenance

Research dashboard

Include:

• PM2.5 versus humidity correlation
• Weekday versus weekend patterns
• Morning and evening peaks
• Urban versus rural comparisons
• Seasonal trends
• Anomaly detection
• Time-series forecasts

14. Configure rules and alerts

Create platform rules for:

Air-quality alerts

• PM2.5 exceeds the project threshold for three consecutive readings
• PM10 rises sharply within 30 minutes
• Several nearby stations detect the same increase

Station-health alerts

• No data for 20 minutes
• Device repeatedly reconnects
• Wi-Fi strength remains poor
• Sensor produces fixed values
• Firmware is outdated

Send technical alerts to the project team through Telegram or email. Avoid sending public health alerts until the measurements and interpretation method have been properly reviewed.

15. Recruit contributors

Potential participants include:

• Public and private universities
• Secondary schools
• TVET institutions
• Local councils
• Resident associations
• Environmental NGOs
• Makerspaces
• Technology companies
• Factories and industrial parks
• Farms and plantations
• Citizen scientists

Participation models

Sponsor a station

A company pays for stations to be installed at schools or community centres.

Build your own station

Universities, students and makers assemble a station using the approved design.

Host a station

FAVORIOT supplies the station while the participant provides electricity, Wi-Fi and a suitable location.

Research partner

A university supports calibration, analysis and publication.

16. Create the contributor onboarding process

Every participant follows the same steps:

1. Apply through an online form.
2. Provide the general proposed location.
3. Choose to build, sponsor or host a station.
4. Accept the data-sharing and privacy terms.
5. Receive a station ID and QR code.
6. Follow the installation guide.
7. Upload installation photographs.
8. Run the station for a seven-day probation period.
9. Pass the data-quality review.
10. Appear on the public map.

The QR code can open the public station page and display its readings, history and validation status.

17. Run a 12-week pilot

18. Pilot budget

Ten-station pilot

Internal staff time, travel across Malaysia and the development of a separate public web application would need their own allocation.

19. Success indicators

Technical indicators

• At least 85% station uptime
• At least 95% valid readings
• Less than 10% missing data
• Data delivered within ten minutes
• All stations remotely identifiable
• Firmware updates completed without visiting every station

Participation indicators

• Ten states represented during the first phase
• At least 20 partner organisations
• At least 100 active contributors
• At least five participating universities
• At least ten participating schools

Data indicators

• Six months of usable observations
• Verified co-location results
• Published data-quality method
• Monthly community air-quality reports
• At least three research or student projects using the data

20. How the project can grow

Phase 1: Ten-station technical pilot

Prove the sensor, firmware, platform and data-quality process.

Phase 2: One hundred community stations

Expand through universities, schools and resident associations.

Phase 3: Five hundred stations

Bring in local councils, corporate sponsors and environmental groups.

Phase 4: National operational network

Move to an Enterprise or dedicated arrangement when the project needs:

• Multiple administrative organisations
• Longer data retention
• Higher API volume
• Dedicated infrastructure
• Formal service levels
• Stronger data-governance controls
• Links with government or emergency systems

21. Important public disclaimer

The dashboard should carry a clear statement:

Malaysia AirWatch uses low-cost community sensors to provide local environmental observations. Its readings are indicative and may be affected by sensor accuracy, placement, humidity and maintenance. The data should not be treated as an official Malaysian Air Pollutant Index or used alone for medical, regulatory or emergency decisions. Refer to the relevant Malaysian authorities for official air-quality information.

Suggested project message

Your neighbourhood’s air should not be invisible.

Malaysia AirWatch allows schools, universities, communities and citizens to help measure the air around them. One sensor may tell us what is happening at one location. Hundreds of connected sensors can help us see patterns across the country.

Build a station. Host a station. Sponsor a community. Help Malaysia see the air we breathe.

The Gap Nobody Names Out Loud

Most final-year IoT projects die a quiet death. Not because the idea was bad, but because nobody mapped out what happens after the demo. A student builds a working prototype, presents it to a panel, gets a grade, and the device goes into a drawer. The organisation that could have used it never finds out it existed. This is not a motivation problem or a talent problem. It is a missing roadmap, and it is one of the more fixable gaps in how technical education connects to industry.

Favoriot has watched enough student projects go through this cycle to notice a pattern in the ones that do not die in the drawer. They tend to follow a similar four-stage path, whether the project is an environmental sensor network, a predictive maintenance tool, or a smart campus dashboard. Naming that path out loud is the point of this roadmap.

Stage 1: Classroom Foundation

Every real pilot starts as coursework, and that is exactly as it should be. The classroom stage is where a student gets comfortable with device provisioning, data streaming, and dashboard design on a platform that behaves the same way in production as it does in a lab exercise. A few things worth getting right at this stage:

• Build on infrastructure that will not need to be replaced later. Prototypes built on toy platforms usually get rebuilt from scratch the moment a real organisation shows interest, which wastes months of momentum.
• Document assumptions early, including what sensors were used, what data intervals were chosen, and why. These decisions get questioned again at the validation stage, and having a clear answer ready saves a lot of back-and-forth.
• Treat the grading milestone as a checkpoint, not an endpoint. A finished assignment and a finished product are two very different things, and conflating them is where most projects stall.

Stage 2: Site Validation

This is where a project either proves itself or reveals problems that never showed up in a controlled classroom environment. Moving a system onto an actual site, whether that is a factory floor, a farm, or a campus building, exposes it to conditions no lab can fully simulate: patchy connectivity, dust, humidity, or simply a device sitting somewhere nobody remembers to check on.

Favoriot’s role at this stage is largely about instrumentation and support. Project teams get help translating a working prototype into something that can run unattended on real infrastructure, along with monitoring to catch failures before they become embarrassing site visits. Validation at this stage usually answers three questions: does the system keep working without a student standing next to it, does the data it produces hold up against ground truth, and does it survive contact with an environment nobody designed for it.

Stage 3: User Feedback

A system that works technically can still fail completely if the people meant to use it never open the dashboard. This stage is easy to skip because it is less technically interesting than the previous one, but it is often where the most useful revisions happen.

Real users, whether that is a plant supervisor, a farm manager, or a facilities team, tend to ask for things a student would never think to build: a simpler alert threshold, a report formatted for a specific meeting, a mobile view because nobody at the site sits at a desk. Incorporating this feedback is what separates a project that impresses an organisation once from one that gets asked to stay.

Stage 4: Organisational Adoption

The final stage is where a pilot either gets absorbed into how an organisation actually operates or quietly winds down once the semester ends. Adoption depends less on the technology at this point and more on questions like who owns the system now that the student has graduated, what budget covers its continued operation, and whether it integrates with existing workflows rather than sitting beside them as a separate tool.

Projects that reach this stage successfully usually share a few traits:

1. A named owner inside the organisation, not just an enthusiastic contact who championed the pilot informally.
2. A clear cost picture, so continuing the system is a budget line rather than a favour someone has to keep asking for.
3. Integration with an existing decision, such as maintenance scheduling or resource allocation, rather than a standalone dashboard competing for attention.

Signals a Project Is Ready for the Next Stage

Not every project needs to rush through all four stages, and pushing one forward before it is ready usually backfires. A rough gut check for readiness at each transition:

• Ready to move from classroom to site: the prototype has run for at least a few consecutive days without manual intervention.
• Ready to move from validation to user feedback: the data being produced has been checked against a real-world reference and holds up.
• Ready to move from feedback to adoption: at least one real user has asked to keep using the system after the pilot period ends.

That last signal is worth paying attention to. It is a far more reliable indicator of readiness than any grade a panel could give.

Closing the Loop

None of this requires a student to become a business development team. What it requires is a roadmap that exists before the project starts, so momentum built in the classroom does not evaporate the moment the semester does. Favoriot supports project teams through each of these stages, from platform access through to the conversations that turn a pilot into something an organisation actually keeps running.

If a student, supervisor, or department has a project that feels ready to move beyond the classroom, reaching out costs nothing and usually clarifies which stage of this roadmap it is actually standing on.