# From simulator to real device **What it takes to put a HEART into each of the nine example products for real: the hardware we assume, where the HEART runs, which code to start from, how to build and install it, what happens at the factory, and what the owner sees.** > **For illustration only.** These pages make reasonable assumptions about each product, such as the board, the sensors and how it connects, so the steps can be concrete. Your product will differ. **None of these products has been built.** The HEART code they use is tested on computers, but has not yet run on real hardware, and the ESP32 port has not yet been compiled for a chip. Treat every page as a plan to check on your own bench, not as a tested recipe. | Product | Simulator | Where the HEART runs | Start from | |---|---|---|---| | [Birdhouse camera](Birdhouse-Camera.md) | [birdhouseSimulator](/birdhouseSimulator/README.md) | On the camera's own ESP32-S3 | ESP32 Full starter | | [Smart thermostat](Thermostat.md) | [thermostatSimulator](/thermostatSimulator/README.md) | On the hub at the boiler, beside its control firmware | ESP32 Full starter | | [Dog tracking collar](Dog-Tracking-Collar.md) | [dogCollarSimulator](/dogCollarSimulator/README.md) | Split: noticing on the collar, the API and reporting on the home base | Bare-metal C template on the collar; bridge or Python template on the home base | | [Greenhouse irrigation](Greenhouse-Irrigation.md) | [greenhouseSimulator](/greenhouseSimulator/README.md) | On the irrigation controller's ESP32 | ESP32 Full starter | | [3D printer](3D-Printer.md) | [printer3dSimulator](/printer3dSimulator/README.md) | On the printer's Linux host board, beside the firmware | Python template | | [EV charger](EV-Charger.md) | [evChargerSimulator](/evChargerSimulator/README.md) | On a communications module, beside the certified controller | `heartd`, the Rust Core's daemon, plus a small reporter you write for HEART Hub | | [Water pump station](Water-Pump-Station.md) | [pumpStationSimulator](/pumpStationSimulator/README.md) | On an edge gateway, beside the PLC | `heartd`, with Modbus, plus a small reporter you write for HEART Hub | | [Online shop server](Online-Shop-Server.md) | [onlineShopSimulator](/onlineShopSimulator/README.md) | On the server, beside the shop | Python template; `heartd` for the Playbooks | | [Pacemaker](Pacemaker.md) | [pacemakerSimulator](/pacemakerSimulator/README.md) | **Never in the implant**: on the home transmitter | The simulator's Python code, monitoring only | --- ## Three ways a HEART is placed Every product above uses one of three placements. Choosing the right one is the first design decision. | Placement | When | Examples | What the HEART can do | |---|---|---|---| | **A. Inside the product** | The product has its own microcontroller or computer, and nothing on it is safety-certified. A battery product may split it: noticing on the device, the API on a mains-powered base. | Birdhouse camera, thermostat hub, collar and its home base, greenhouse | Watch everything, raise alerts, and change what the owner allows, through the gate | | **B. Beside a controller** | A certified or proven controller already runs the safety-critical work: a PLC, a charge controller, printer firmware | EV charger, pump station, 3D printer | **Watch only, through a read-only link.** The controller and its interlocks stay in charge. | | **C. Outside, never inside** | The product is a medical implant, or any device whose software must not change | Pacemaker | Watch the data the device already sends, on a separate device. Nothing is added to the product itself. | **The rule behind all three:** a HEART never sits between a safety function and what it protects. It may watch a safety signal, but it never writes one (Part 6 of the standard). --- ## What every real device needs ### 1. Hardware the maker designs in | Part | Why | Where the standard says so | |---|---|---| | **A button the owner can press**, on the product or at its installation | Approving a physical change needs proof that a person is there. Holding it for 3 seconds is **Stop**, with no network and no login. | API Standard 6.3, Part 6 | | **A light or display** | To tell a person about a fault with no internet (escalation), and to show that a change waits for the button | Part 2, Autonomy Level A1 | | **A label inside the lid or under the base** | The device ID, the claim code and a QR code of the registration address | HEART Hub, Section 4 | | **Storage that survives a power cut** | The device ID, claim code and key, the owner key, and the last Stop | Core Standard | | **A clock source** (network time, or a real-time clock) | Signed approvals and requests are refused if they are more than 5 minutes old | HEART Hub, Section 7.2 | ### 2. The steps, in order 1. **Choose the placement** (A, B or C above), and the starting code. 2. **Write the signal table:** every value the product knows, its unit, its healthy range and its privacy level. Decide which are writable, which are physical, and which are safety signals that the HEART only reads. 3. **Write the main-job check:** one function that says whether the product is doing its job, such as "pictures are being saved" or "the pump delivers water". 4. **Connect escalation:** the light, the display, the owner's app. 5. **Build and install** it with the product's firmware or software. 6. **On the production line:** give each unit its own TLS certificate and key, make its device ID and claim code, and print the label. 7. **Test on the bench:** cause every fault for real (cover the solar panel, fill the card, unplug the sensor), and check the right fault code appears. Run [HEART-Rating](/heart-rating/README.md). 8. **Claim only what passed:** HEART Basic, at Autonomy Level A1, is the usual first claim. ### 3. What the owner experiences 1. **Unboxing.** The label inside the lid shows a QR code and a claim code. 2. **First start.** The product joins the home network (the maker's own setup app does this, as before). Reporting to HEART Hub is on only if the maker or owner turned it on. 3. **Registration.** The owner scans the QR code, signs in at heartcortex.ai with an emailed code, and types the claim code. The device's page shows **Healthy** within a minute. See the [owner's manual](../HEART-Monitor-Owner-Manual.md). 4. **Every day.** Nothing to do. The device checks its main job every 30 seconds by itself. 5. **When something goes wrong.** The light outside blinks at once, with or without internet. The page shows the fault in plain words. If the device goes silent, the owner gets one email. 6. **When a change is wanted.** A non-physical change, such as the camera's zoom, can be made from the page with an emailed code, or by a rule the owner adopted. A physical change, such as the infrared light or a valve, always waits for the button. ### 4. What to expect, honestly - **It notices; it does not repair hardware.** A HEART can say "the card is full" within 30 seconds. Someone still has to fit a new card. - **Battery devices that sleep will look silent.** A device asleep between reports cannot answer. Set its report interval longer than its sleep, or the monitor will show "Not heard from". - **An AI model is optional,** and it only explains and proposes. Every product here works fully without one. - **The standard does not certify safety.** A product's own safety case (IEC 61508, IEC 62304, UL 2594 and others) still applies. HEART adds watching and explaining on top of it, never in place of it. --- ## Gaps in today's code that these pages work around Writing these pages against the real code showed what is still missing. Each page says where it is affected. | Gap | Where | Effect | |---|---|---| | No HEART Hub reporting | `heartd`, the bridge template | A small reporter, written from the Python template's `monitor()` code, must be added | | Alerts carry a kind but no fault code | `heartd` | The reporter must add the code; HEART-Rating may mark it down | | Rules do not watch values read over Modbus | `heartd` | A small feeder must pass polled values to the host socket | | Modbus reads use function 3 only | `heartd` | The PLC must mirror its values into holding registers | | A physical change waits only 60 seconds for the button | ESP32 Full starter | Fixed in its `app_main`; a product may want longer | | Text values cannot be written | ESP32 Full starter | A mode such as "heat" or "eco" must be a number | | Change requests are answered `501 not-implemented` | Python template | The simulators answer `403 capability-not-allowed` | These are listed so they can be fixed in a coming release, not hidden.