Apps that control hardware

What a KolHive app can control

When you build an app in KolHive, it can talk to physical devices around you. Your app can connect to Bluetooth Low Energy gadgets, reach devices on your home or office network, and read phone motion sensors. On supported Android phones, it can also send infrared remote signals.

For example, Maya Chen in Chicago can build a tracker that reads her Bluetooth heart-rate strap or checks a moisture sensor in a flowerpot. Daniel Wright in Manchester can switch a smart plug on his office network or wake his desktop PC using Wake-on-LAN. On an Android phone with an infrared blaster, Priya Shah in Toronto can build a remote control for her living room TV.

Apps never connect to hardware directly. Every request goes through KolHive, which checks what the app declared and asks for your approval first.

Bluetooth Low Energy

A built app can use Bluetooth Low Energy (BLE) as a central device. It can scan for nearby gadgets, connect, read and write payloads up to 512 bytes, and subscribe to notifications. Classic Bluetooth, audio profiles, and RFCOMM serial connections are not supported.

The app never receives a silent list of nearby devices. When the app asks to scan, KolHive opens its own device chooser on your screen. The app sees only the single device you pick and only the Bluetooth services it names in advance.

Bluetooth works in the KolHive app on Mac, Windows, iPhone, iPad, and Android. Apple devices ask for permission on first use, and Android 12 or later asks for Nearby devices permission. In a web browser, Bluetooth works only in Chrome and Edge, not in Safari or Firefox.

Devices on your local network

Your app can find and talk to devices on your local network over HTTP, WebSocket, TCP, and UDP. It can discover hardware using SSDP or mDNS and send Wake-on-LAN packets. Only private network addresses are reachable. KolHive refuses connections to public internet hosts, loopback addresses, and your device's own address.

Each app window can open up to 16 sockets at once and run four device-discovery calls a minute. HTTP responses are limited to 5 MB. Self-signed certificates are accepted only for local devices and only when the app asks.

Full local network control works on Mac, Windows, and Android. On a Mac, the system shows its Local Network permission prompt. On iPhone and iPad, HTTP, WebSocket, TCP, and .local names work, but multicast discovery (SSDP), broadcast, and Wake-on-LAN do not work. Because of that, Tom Baker in Sydney can turn on a TV by Wake-on-LAN from a Mac, Windows PC, or Android phone, but not from an iPhone or iPad.

In a web browser, local network control is relayed through one of your own signed-in KolHive devices over a direct, encrypted peer link. The first use asks for approval on that device. The traffic travels device to device without a TURN relay, while our servers carry only the small signalling messages needed to establish the link. If none of your devices is online, the app is told that no relay device is available.

Motion sensors, infrared, and location

Motion sensors work in the native apps on phones and tablets only. On iPhone, iPad, and Android, an app can read the gyroscope, accelerometer, user accelerometer, magnetometer, and barometer at up to 200 Hz. Mac, Windows, and Linux desktops report these sensors as unsupported.

In a web browser, apps use the browser's Generic Sensor API or device motion events where present, with no web fallback for the magnetometer or barometer. Safari on iPhone and iPad asks for permission before sharing sensor data.

A built app can send infrared remote codes only on Android phones that have built-in consumer infrared hardware (an IR blaster). Each pattern is limited to 1,024 pulses and 2 seconds. Infrared is not available on iPhone, iPad, Mac, Windows, Linux, or the web.

Apps can also read device location using GPS and fused location on Android or Core Location on Apple devices. This works only when the app declares geolocation and you allow it.

What works on each platform

Hardware access depends on which device you use and whether you run the native KolHive app or a web browser.

How KolHive keeps hardware access in check

Apps reach hardware through kolhive.lan, kolhive.bluetooth, kolhive.sensors, and kolhive.infrared. Every capability must be declared in the app's manifest with a specific purpose and data-use statement. Any undeclared call is refused three times over: during the install check, inside the page, and at the host level. You can read more about how KolHive checks permissions in Security review for IT.

KolHive picks the target device through its own chooser rather than letting the app scan or connect in the background. When you close or reload the app window, KolHive closes every open socket, Bluetooth connection, and sensor stream. While an app window is hidden, sensor streams pause automatically and Bluetooth connections keep running.

Before using any hardware feature, an app calls available() to check if your device supports it. This check never shows a permission prompt and returns the real reason when a feature cannot run, so the app can give you an honest message when something is not supported on your device.