Php Gpio Laravel Package

Product Decisions This Supports

• "Should hardware control live in our Laravel app?" — This package is the cheapest possible experiment for answering that question. It wraps the Linux sysfs GPIO files (/sys/class/gpio/export, direction, value) in a small PHP API, so a feature like toggle a relay, read a door sensor, blink a status LED, or power-cycle a fan can be built inside an existing Laravel codebase in an afternoon instead of standing up a new service in another language.
• Prototype-tier use cases it genuinely unlocks: kiosk/edge appliances (signage players, self-service terminals), lab or workshop instrument controllers, access-control or cabinet-lock demos, environmental monitoring dashboards (with an external sensor reading), and internal "smart rack / smart cabinet" tools where the operator is also the developer.
• Build vs. buy: There is nothing to buy here — MIT-licensed, no vendor, no per-device fee. The real decision it informs is buy/build the boundary: a thin PHP wrapper (this package plus your own adapter interface) versus a dedicated hardware agent (Python gpiozero/lgpio, a libgpiod command wrapper, or an MQTT/ESPHome relay board) behind a REST or MQTT contract. The package makes the "PHP does it directly" option concrete and cheap to falsify.
• Roadmap input: Treat any positive spike result as evidence of demand for hardware features, not evidence that this library belongs on the roadmap. The correct roadmap output is usually "add a hardware-abstraction service" with the PHP edge as a client — this package tells you whether the feature is worth that investment.
• Risk-register input: A dependency whose last release is July 2013 is a maintenance and security liability by default. Its presence should trigger an explicit decision (accept for prototype / replace before production) rather than silent inheritance.
• Scope decisions it constrains: No PWM in a meaningful sense, no I2C/SPI, no reliable edge-triggered interrupts, no real-time timing guarantees, Raspberry Pi only. Knowing this up front kills feature requests (motor speed control, precise pulse counting) that would otherwise be discovered mid-sprint.

When to Consider This Package

Consider it when:

• The deliverable is an internal prototype, demo, or feasibility spike and shipping speed matters more than longevity.
• Your stack is already PHP/Laravel and the team has no Python or embedded capacity to spare.
• You are on a legacy Raspberry Pi OS image where the sysfs GPIO interface is still enabled, and you control the physical device and its OS image.
• The I/O needs are simple binary in/out at human-perceptible speeds (relays, LEDs, buttons polled at low frequency), not timing-sensitive protocols.
• You can accept no upstream fixes and are willing to vendor/fork the ~handful-of-classes codebase into your own repo rather than depend on Packagist.

Look elsewhere when:

• The device is customer-facing, safety-relevant, or remotely fleet-managed — an unmaintained 2013 library plus a deprecated kernel interface is not a production foundation.
• You are on modern Raspberry Pi OS (Bullseye/Bookworm and later), where sysfs GPIO is deprecated or disabled; you need libgpiod/character-device access instead, which this library does not speak.
• You need PWM, I2C, SPI, hardware interrupts with low latency, debouncing, or concurrency — PHP's process model and sysfs polling will not deliver these.
• You need non-Pi hardware (generic SBCs, ESP32, industrial PLCs) or a uniform API across device types.
• You have security/compliance obligations: this pattern typically requires the web process to be in the gpio group or run as root, and a compromised web app can then actuate physical hardware. That is a real threat-model conversation, not a footnote.
• Alternatives to evaluate in the same spike: Python gpiozero/lgpio sidecar behind HTTP or MQTT, a libgpiod CLI wrapper invoked from Laravel, or off-the-shelf networked relay/IO modules — all give you a cleaner contract and a live upstream.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed, small PHP library that lets our existing Laravel application drive the GPIO pins on a Raspberry Pi — meaning we can demonstrate a hardware-connected feature (a relay-controlled device, a sensor-backed dashboard, a locked cabinet or kiosk) using the team and stack we already have, with zero license cost and no vendor commitment. That makes it an excellent two-to-four-week feasibility spike, not a platform choice: the library has had no release since 2013 and relies on a Linux interface that current Raspberry Pi operating systems are phasing out, so it carries maintenance and security risk and would need replacing before anything ships to customers. Recommendation: approve a time-boxed spike to validate demand and produce a working demo, with a pre-agreed exit criterion — migrate to a small dedicated hardware service (or a maintained libgpiod-based agent) before any production commitment.

For engineering: A thin, dependency-free wrapper over sysfs GPIO — no interfaces, no DI, no events, no test seams, PHP 5-era style. Wrap it behind your own GpioDevice contract from day one so the spike's code survives the eventual swap. Operational notes: the PHP-FPM user needs gpio group membership and udev rules (do not run the web server as root), there is no concurrency or debounce support, and sysfs edge detection is poll-based and unreliable — assume anything needing sub-100ms timing is out of scope. Vendor the source rather than relying on a package that hasn't shipped in twelve years.