Download the PHP package tihloh/vendogate-php without Composer
On this page you can find all versions of the php package tihloh/vendogate-php. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package vendogate-php
Vendo Gateway PHP
Framework-neutral Composer package for securely connecting ESP8266/ESP32 vending and IoT hardware to PHP applications.
What the package owns
- device pairing and registration
- permanent device identity and bearer-token authentication over HTTPS
- heartbeat and capability reporting
- remote configuration and device profiles
- desired/reported state
- command queue, delivery, retry, ACK/failure and expiry
- idempotent sequenced device events
- replayable host event handlers
- OTA firmware metadata and channels
- device suspend/revoke lifecycle
- database migrations and cleanup
It intentionally does not contain business rules such as coin value, Wi-Fi rates, voucher creation, charging prices or customer credit. Host applications interpret generic hardware events.
Requirements
- PHP 8.2+
- PDO
- OpenSSL
- MariaDB/MySQL-compatible database
Setup
Use a random application master key of at least 32 characters. Changing it without re-encrypting stored device secrets will invalidate those secrets.
Device capabilities are stored as one JSON document in vg_devices.capabilities_json; they are not normalized into a separate capability table.
Host API examples
Consume device events
Events are inserted before handlers run. If a handler fails, the event remains unprocessed and can be replayed:
Device protocol
Default API base: /vendo/v1.
Recommended device routes:
The package provides framework-neutral endpoint classes under Tihloh\VendoGateway\Http; your application maps them to its router.
Pairing credential delivery is retry-safe: after an administrator claims a pairing, the device may retrieve device_id and device_secret repeatedly until it has persisted them and explicitly acknowledges delivery. The server clears the encrypted one-time secret only after POST /pairings/{id}/ack succeeds.
Post-pairing requests use the device secret directly as a bearer token over HTTPS:
This path has no timestamp, NTP, nonce, request sequence or HMAC requirement, so a device can communicate as soon as Wi-Fi is available. Signed-request authentication is no longer accepted.
See docs/protocol-v1.md for the wire protocol.
Local setup/recovery
The local ESP setup password is deliberately separate from server credentials. The server package never trusts the universal initial AP password.
Expected firmware behavior:
- unconfigured: universal initial AP password
- initial setup: force a new local setup password
- Wi-Fi failure: use saved local setup password
- physical reset held 10 seconds: temporary recovery AP; reset only local setup/AP password
- full factory reset: authenticated setup UI or authenticated
system.factory_resetcommand only
Maintenance
Periodically run:
Development
License: MIT.
Host-driven OTA management
Firmware releases are built from the private vendogate-firmware source repository and published as binaries plus manifest.json in tihloh/vendogate-firmware-releases. The host application renders the UI and authorizes its users; the gateway owns release fetching, validation, version/target matching, configuration, and commands.
- Call firmware->deviceStatus(deviceId) on a PHP page load. It checks the release catalog using persisted device identity and a shared five-minute cache. No ESP request or command is made, and an offline device can be checked.
- Call firmware->requestCheck(deviceId) for a manual refresh. Return its status to the frontend immediately; this does not enqueue a firmware.check command.
- Enable Update only when update_available is strictly true. Null means unknown, incompatible, or incomplete metadata, and error explains why.
- Call firmware->requestUpdate(deviceId) to queue a firmware.update command with the exact version, target, hardware model/revision, HTTPS URL, size, and SHA-256. Commands expire after 24 hours and run when the enrolled ESP next polls while idle.
- Call firmware->saveSettings(deviceId, settings) to validate/persist policy and queue config.refresh. Settings: auto_check (default true), auto_update (default false), check_interval_hours (integer 1–24), and channel (stable). Enabling auto_update requires auto_check. These settings control the ESP's own scheduler, independently of page-load/manual release discovery.
- firmware->settings(deviceId) returns the normalized policy for rendering.
Release metadata is read as a single pinned snapshot. Missing targets, checksum mismatches, unknown installed versions, and failed refreshes cannot enable Update. Public firmware binaries stay separate from private source; hosts need no GitHub source-repository credentials.
Command responses include both command_id and the legacy id alias. Configuration responses retain the nested config plus legacy top-level settings. Acknowledgements accept explicit status or the older ok boolean, including failure results.
All versions of vendogate-php with dependencies
ext-openssl Version *
ext-pdo Version *