Johor, made
observable.
Three practical AIoT ideas that turn physical signals into useful decisions for local businesses and visitors, using FAVORIOT’s four AI capabilities.
Independent concept proposals • Requirements checked 14 November 2026
Proposed pilots and targets, with no claimed deployments or achieved results.
A local problem.
A credible path to impact.
The official site asks for practical AI-enabled solutions that can be tested and implemented in Johor. These proposals address three of its four problem statements, with the fourth shown for completeness. Official brief
Eligibility and entry context
The homepage welcomes Johoreans and people based in Johor aged 18 or above, in teams of 3–5. The organiser’s announcement also specifies Malaysians; confirm nationality and mixed-team rules in the official FAQ or with the organiser before registering.
Submissions run from 11 November to 15 December 2026. Selection is 16–22 December, the top 20 are announced on 23 December, the online bootcamp is 9 January 2027, and the physical bootcamp is 16–17 January in Johor Bahru, with the finale on 17 January.
The homepage links to project-video submission. Verify the video duration, format, consent terms and any further requirements in the current FAQ and registration form. Official FAQ · Official terms
Four published problem statements
- SME Readiness for JS-SEZ Industries Digital and ESG integration for SME participation.
- Renewable Energy Adoption Pathway Help Johor businesses choose and adopt renewable energy.
- Talent for JS-SEZ Industries Connect people, skills and employers. Not the primary theme of these proposals.
- Connecting visitors in Johor Help visitors discover small leisure and educational operators across the ETS line.
The site frames visitor discovery beyond the city, rather than crowd monitoring alone. Jejak Johor therefore combines local listings and rail-corridor discovery with IoT availability signals.
What the official assessment rewards
| Published assessment area | Evidence to prepare |
|---|---|
| Problem & Impact | A clear local problem, its root causes and quantified community impact. Bring interviews and a baseline. |
| Solution & Technology | A practical response and a defensible technology choice. Show why sensors and AI help. |
| Feasibility | A realistic Johor implementation plan, with stakeholders, costs and site constraints. |
| Team & Communication | A collaborative, capable team committed to deployment. Show responsibilities and next steps. |
Assessment areas are published on the challenge homepage; the preparation guidance is our interpretation. No official numerical weights are stated there.
Three routes from
signals to local value.
Each blueprint has its own user, decision, hardware and validation plan. All three use Faybee, AI Reporting, MCP and built-in ML, with clear boundaries around custom development.
ReadyFactory
Turn shop-floor evidence into supplier readiness.
Explore build plan → 02 Measured demand + adoption decisionSolarFit Johor
Help businesses decide whether solar fits their day.
Explore build plan → 03 Tourism, hospitality + MICEJejak Johor
Connect rail visitors with smaller local experiences.
Explore build plan →ReadyFactory
Turn shop-floor evidence into supplier readiness.
A small Johor manufacturer collects machine runtime and energy evidence, then shares a traceable operational improvement pack with prospective supply-chain partners. The pilot tackles one part of readiness: reliable digital records and energy visibility. It does not certify ESG compliance or qualify a supplier.
People and pilot
Proposed pilot: one fabrication or packaging SME in Kulai or Pasir Gudang, with its owner and maintenance lead. Interview three SMEs and one buyer before finalising the evidence pack; no partner commitment is assumed.
Prototype hardware
| Component | Qty | Planning allowance |
|---|---|---|
| ESP32 + power supply | 1 | RM50–90 |
| Isolated Modbus energy meter + RS485 interface | 1 | RM160–300 |
| Temperature probe + vibration sensor | 1 set | RM80–180 |
| Enclosure, cabling and reference checks | 1 set | RM110–230 |
Total: RM400–800 . Illustrative planning allowances, not supplier quotations. Excludes platform plan, taxes, travel and specialist work beyond the stated allowance.
Architecture and data flow
Aggregate vibration locally into one-minute RMS; send energy, temperature and runtime every 60 seconds. Buffer during outages and preserve original timestamps on replay.
device: machine-01 | power_w, energy_kwh, temperature_c, vibration_rms_g, run_state, quality_flag
Begin with unsupervised clustering of power, temperature and vibration summaries to separate operating patterns. Ask the technician to review clusters; a cluster is not a diagnosed fault. Compare with a simple threshold baseline before using a model to support inspection.
From bench to working prototype
Define the buyer’s evidence needs
Record one machine boundary, shift schedule, production counts and the buyer’s required evidence fields. Obtain site permission and agree who can see the data. Keep financial and customer records outside the pilot.
Connect and validate
Have a qualified installer fit the meter. Ask Faybee for ESP32/Modbus connectivity guidance, then test firmware against the current ingestion documentation. Compare a one-hour kWh delta with a reference meter and record any bias.
Build the operational view
Create a dedicated project, application, group and machine device. Use MCP to inspect the hierarchy before provisioning missing resources. Configure power, temperature, energy and data-freshness widgets; add technician-reviewed thresholds.
Learn operating patterns
Gather at least two weeks of representative shifts. Follow the shared ML workflow below with the proposed input features. Hold out the latest shifts, review every flagged interval with the technician, and retain thresholds if ML adds no useful evidence.
Explain and assemble
Create an Analytics dashboard for kWh, runtime and kWh per unit using a verified production-count source. Generate an AI Report in Asia/Kuala_Lumpur; request gaps, anomalies and limitations. Check every reported number against exports.
Test supplier usefulness
Use an authorised MCP assistant to retrieve the named machine’s latest shift streams and show timestamps. Export a one-page readiness pack plus underlying data. Ask a buyer to rate evidence completeness and actionable clarity.
MCP query to try
For machine-01, retrieve streams for the last completed shift in Asia/Kuala_Lumpur. Summarise missing intervals, kWh delta and threshold breaches. Cite device and timestamps; do not change any resources.
AI Reporting brief
Explain energy use and unusual intervals for this shift. Separate measured readings, inferred operating patterns and missing data. Do not claim ESG certification or financial savings.
Demonstration and measurable acceptance targets
In a five-minute proposed demonstration, run a low-voltage motor normally, add a safe load, and replay a clearly labelled historical unusual interval. Show ingestion, the threshold alert, the reviewed ML result, a read-only MCP query and the checked AI report. Disconnect Wi-Fi briefly to demonstrate buffering and stale-data labels.
| Evaluation | Proposed acceptance target |
|---|---|
| Data coverage | ≥95% of expected one-minute intervals over 7 days |
| Meter agreement | ≤5% error in kWh delta against the reference over a matched test |
| Operational value | Technician confirms ≥80% of flagged review intervals are useful, with all flags counted |
| Buyer usefulness | At least 3 of 4 evidence fields accepted by one interviewed buyer |
These are proposed prototype targets, not achieved results or official challenge scoring thresholds. Keep failed tests in the evidence log.
Timeline, assumptions and limits
Build plan: Weeks 1–2: buyer interviews, permission and bench build. Weeks 3–4: install, baseline and submission evidence. Weeks 5–8: review clusters, refine the pack and repeat tests.
Two weeks may miss rare failure modes, and vibration mounting affects readings. No predictive-maintenance accuracy, emissions reduction or procurement acceptance is assumed. Production counts require an operator entry or separate integration.
SolarFit Johor
Help businesses decide whether solar fits their day.
A business compares its measured daytime load with explicitly modelled solar generation, then receives an explainable shortlist of next steps for a qualified solar provider. This is an adoption decision tool, rather than another energy dashboard or an automatic investment recommendation.
People and pilot
Proposed pilot: one daytime business in Senai or Iskandar Puteri, its facilities manager and an independent solar installer. Validate the owner’s budget, tenancy constraints and decision barriers before choosing an option.
Prototype hardware
| Component | Qty | Planning allowance |
|---|---|---|
| ESP32 gateway + RS485 interface | 1 | RM80–140 |
| Isolated Modbus energy meter | 1 | RM160–300 |
| Optional light sensor + temperature sensor | 1 set | RM40–100 |
| Enclosure, supply and installation allowance | 1 set | RM220–460 |
Total: RM500–1,000 . Illustrative planning allowances, not supplier quotations. Excludes platform plan, taxes, travel and specialist work beyond the stated allowance.
Architecture and data flow
Read meter values every minute, preserve cumulative kWh, and calculate 15-minute averages on a trusted gateway or analysis service. A low-cost light sensor indicates relative conditions; it is not a calibrated solar irradiance instrument.
device: site-main | import_power_w, import_energy_kwh, temperature_c, light_lux, quality_flag
Use built-in time-series forecasting on hourly demand, initially with a simple supported model. Train on several representative weeks and test on the latest week against a same-hour-last-week baseline. Solar yield, tariff calculations and roof suitability sit in a separate, explicitly built scenario module.
From bench to working prototype
Understand the adoption barrier
Interview the owner about daytime operation, available roof rights, cash constraints and desired payback. Collect permissioned bills and opening hours. Confirm current tariff and programme rules with an installer before presenting any investment case.
Measure the load safely
Use a qualified electrician for a mains meter, or start with a low-voltage bench rig. Ask Faybee to explain RS485 ingestion and stale-data troubleshooting. Verify power and energy units against a reference and identify missing readings.
Create a site data pipeline
Use MCP to inspect or provision an isolated SolarFit hierarchy. Store minute readings and configure power, energy and freshness widgets. Build an Analytics dashboard with hourly load totals; distinguish measured grid import from estimated total load if existing PV is present.
Forecast and compare
Train a time-series model using the shared workflow and test on a later week. Keep calendar effects visible. If history is too short or forecast error exceeds the baseline, use the measured load profile and say that forecasting is not validated.
Build the adoption scenario
Implement a separate calculator using installer-supplied hourly PV estimates and owner-approved tariff inputs. Compute self-consumption as sum(min(load, PV)) for equal intervals. Show assumptions for capital cost, maintenance and exports; do not treat a light-sensor reading as PV generation.
Create an explainable brief
Generate an AI Report of the measured Analytics dashboard. Attach the separately checked scenario calculation as its own evidence sheet. Use a read-only MCP query to verify peak hours; ask the installer to review the recommendation and the owner to select a next step.
MCP query to try
Retrieve hourly site-main demand for the selected baseline week. Identify missing periods and the five highest measured demand hours, with units and timestamps. Do not infer solar yield or change equipment.
AI Reporting brief
Describe the measured daytime demand and data gaps. Explain the ML forecast limitations. Do not invent tariffs, solar output, grants or payback; those belong in the separately verified scenario sheet.
Demonstration and measurable acceptance targets
Show the same measured business load against two labelled hypothetical PV sizes, then change tariff and capital-cost assumptions in the separate prototype calculator. Show the resulting self-consumption and simple-payback sensitivity alongside an AI report of actual load. Explain why roof inspection and a provider quotation remain necessary.
| Evaluation | Proposed acceptance target |
|---|---|
| Data coverage | ≥95% of expected intervals over 14 days |
| Forecast value | Lower hourly MAE than same-hour-last-week on a held-out week |
| Calculator correctness | Self-consumption and annualised savings match an independent spreadsheet within 1% |
| Adoption value | One owner can explain the trade-off and agrees a documented installer follow-up |
These are proposed prototype targets, not achieved results or official challenge scoring thresholds. Keep failed tests in the evidence log.
Timeline, assumptions and limits
Build plan: Weeks 1–2: owner interview, bills and metering. Weeks 3–4: load collection and a labelled scenario for submission. Weeks 5–8: longer history, forecast validation and installer review.
Indicative solar profiles are simulations until backed by a site study. Grid import alone cannot recover total demand where existing PV is unmetered. Roof structure, approvals, financing and current regulations need specialist review; there is no promised payback or guaranteed adoption.
Jejak Johor
Connect rail visitors with smaller local experiences.
A rail-corridor discovery guide combines verified listings for small leisure and educational operators with permissioned occupancy signals. Visitors see whether an experience is open, how fresh its availability signal is, and how to contact the operator. Focus on Kluang and Segamat as proposed pilot towns; confirm rail services before publication.
People and pilot
Proposed pilot: three small museums, craft workshops or community experiences near rail-accessible towns, together with a visitor-information partner. Start with five visitor interviews and operator consent; no tourism partnership or booking integration is assumed.
Prototype hardware
| Component | Qty | Planning allowance |
|---|---|---|
| ESP32 + Wi-Fi power supply | 2 | RM100–180 |
| Paired infrared entry/exit sensors | 2 sets | RM80–180 |
| Enclosures, cabling and mounts | 1 set | RM100–200 |
| QR signage + manual-count calibration | 1 set | RM70–140 |
Total: RM350–700 . Illustrative planning allowances, not supplier quotations. Excludes platform plan, taxes, travel and specialist work beyond the stated allowance.
Architecture and data flow
Count direction locally using paired beams and publish anonymous five-minute aggregates. Operators correct drift after manual checks and update open status. Never collect faces, device identifiers, medical details or visitor identities.
device: venue-01 | entries_5m, exits_5m, occupancy_estimate, open_status, manual_capacity, quality_flag
Cluster five-minute visitor-count patterns into quieter and busier operating periods after manual review. Group entry can distort beam counts. Use clusters for operator planning only, with simple occupancy rules powering the initial guide; predictions require longer data and independent testing.
From bench to working prototype
Make small operators discoverable
Interview visitors and operators about opening hours, language, access and last-mile transport. Create a consented directory with leisure or educational activity descriptions, contact links and verified rail-access information. Do not invent reviews or promise live train times.
Install anonymous sensors
Ask Faybee for guidance on publishing five-minute ESP32 counts. Mount paired beams and compare against manual counts during quiet and busy sessions. Let operators correct occupancy; record capacity as an operator-set value rather than a safety certification.
Publish an operational view
Create a device per venue under a dedicated project. Use MCP to inspect the hierarchy and retrieve recent streams. Add freshness and open-status widgets; suppress a numeric availability claim when the latest report is older than ten minutes.
Build the discovery layer
Implement a separate visitor webpage and protected backend that reads only approved aggregate fields. Join those fields to the curated directory. Filter by activity, town and accessibility information; show contact-to-confirm where capacity is uncertain. Keep all API keys off the public page.
Learn and explain patterns
Use the shared ML workflow for reviewed count clusters. Create an Analytics dashboard for footfall and missing intervals, then generate an AI Report for operators. Any multilingual visitor copy needs its own translation and review process; Faybee is the team’s platform guide.
Test the complete visitor journey
Ask five visitors to find a suitable lesser-known activity and contact its operator. Use an authorised MCP query to trace a displayed count back to source timestamps. Test sensor outage, closed venue, stale status and erroneous negative counts before the demonstration.
MCP query to try
Retrieve the latest aggregate streams for the three pilot venues. Return reported open status, occupancy estimate, quality flag and timestamp. Mark data older than ten minutes as stale; do not recommend a venue from missing data.
AI Reporting brief
Summarise the pilot venues’ measured footfall and reporting gaps for this week. Separate observed counts from reviewed cluster labels. Avoid claims about revenue, visitor satisfaction or tourism impact without survey evidence.
Demonstration and measurable acceptance targets
Use two tabletop doorways and a third clearly labelled replay feed. Walk through the sensors, update a venue’s status, and find a craft activity from a mock rail-arrival page. Disconnect one sensor to show its availability becoming unknown, then compare the source stream with an MCP response and the operator report.
| Evaluation | Proposed acceptance target |
|---|---|
| Count quality | ≤10% absolute count error over at least 100 manually observed passages |
| Freshness handling | 100% of scripted stale or offline cases show unknown availability |
| Discovery usability | 4 of 5 visitors complete the activity-finding task within 2 minutes |
| Operator value | All 3 pilot operators verify listing accuracy and usefulness of the weekly report |
These are proposed prototype targets, not achieved results or official challenge scoring thresholds. Keep failed tests in the evidence log.
Timeline, assumptions and limits
Build plan: Weeks 1–2: visitor interviews, listing consent and sensor tests. Weeks 3–4: guide prototype, calibration and submission video. Weeks 5–8: operator trial, usability testing and report refinement.
The guide is not a crowd-safety system or booking guarantee. Beam counts drift with groups and re-entry. Rail schedules, opening hours, accessibility and last-mile information require direct verification; increased visits or spending remains an outcome to measure after launch.
A build schedule that respects
the challenge calendar.
This is a proposed schedule from 14 November 2026, not an organiser-mandated delivery plan. A representative prototype can support the December submission; field validation continues only if site access, team capacity and selection allow it.
Choose one primary problem statement, secure permission, interview users and establish a bench-to-cloud data path. Attend relevant November workshops.
Collect a baseline, create the core dashboard and test the custom application. Capture both successful and failed cases, with simulated data labelled.
Record the problem, working prototype and next pilot step. Check the official video requirements and link accessibility, then submit before the stated deadline.
Selection runs 16–22 December. If selected, extend the evidence, join the 9 January online bootcamp and prepare for the 16–17 January physical programme.
Suggested team responsibilities
For a five-person team, assign a local problem and partner lead, a hardware and connectivity lead, a platform and data lead, an application and ML lead, and an evidence and pitch lead. In a three-person team, combine partner work with evidence, hardware with platform, and application with ML. Agree who maintains the pilot after the event.
Map each project to the official assessment
| Assessment | ReadyFactory | SolarFit Johor | Jejak Johor |
|---|---|---|---|
| Problem & Impact | SME interviews, missing-record baseline, useful buyer evidence | Owner decision barriers and measured daytime load | Visitor discovery failures and small-operator visibility |
| Solution & Technology | Traceable meter records, reviewed clusters and reporting | Demand measurement, tested forecast and transparent scenarios | Curated rail-corridor listings plus fresh anonymous signals |
| Feasibility | One machine, safe installation and a willing owner | One site, approved data and installer review | Three consented listings, count calibration and a protected backend |
| Team & Communication | Maintenance handover and evidence-pack owner | Facilities handover and explicit financial assumptions | Operator listing ownership and a tested visitor journey |
Source notes and verification
- Johor Innovation Challenge official homepage : retrieved directly on 14 November 2026. Reviewed the problem-statement context, focus areas, eligibility, submission window, programme timeline and four assessment areas, including the page’s embedded problem details.
- Biji-biji Initiative organiser announcement : corroborates the four areas and identifies Malaysian participation. Where nationality wording differs from the homepage, confirm with the organiser rather than treating the broader wording as permission.
- FAVORIOT Platform Documentation : reviewed the ML setup, Faybee analysis, Analytics report workflow and MCP sections. Subscription names differ from the pricing page; feature access and quotas require account-level confirmation.
- Four Ways of Using AI With FAVORIOT : current vendor explanation of the distinct roles of Faybee, AI Reporting, MCP and built-in ML.
- Official FAVORIOT MCP guide : client and proxy setup, authorised key configuration and resource access. Use the current client-specific instructions; no credentials belong in this webpage.
- FAVORIOT pricing : verify the live subscription and quotas before purchasing. No platform price or free ML entitlement is assumed here.
The official FAQ and terms are linked for the entrant’s final checks; their detailed rules are not reproduced as verified findings here. The uploaded logo was unavailable at /mnt/data/Favoriot Logo(2).png, so this file uses a plain text FAVORIOT wordmark. This independent concept page is not an organiser endorsement or a production monitoring application.