Thanks for trying it out! A couple of things could be going on here.
CreateClientTimeoutis Homey’s own timeout on a pairing/driver callback (typically ~30s).
GivEnergyInverter.connect() doesn’t just open a socket. It does a full initial poll
before resolving, that could easily runs past 30s on the first call. It’s designed to be called once at device onInitand then kept alive streaming data events. It’s not meant to run inside a Homey pairing handler.
What to do instead
For pairing, use the lightweight identity probe — it was added for exactly this case:
const identity = await ModBus.GivEnergyInverter.identify({ host: devices[0].host });
// { serialNumber, generation, modelCode }
That’s a single Modbus request and should return in a second or two. Store the host/serial, then in the device’s onInit, call GivEnergyInverter.connect({ host })
onInit has a much longer budget, and once it resolves you subscribe to ‘data’ events for live snapshots.
To see what connect()is actually doing while you debug, attach a listener before awaiting. Note you’d need access to the instance, so easier is to temporarily use the PollManager events via the returned inverter:
const inv = await ModBus.GivEnergyInverter.connect({ host }); inv.on('debug', msg => console.log('[modbus]', msg));
(Though the debug output for the initial poll happens before connect() resolves, so for early-phase diagnosis you may want to call identify() first to confirm the device is reachable at all from inside the Homey container.)
discover() without a subnet
getLocalSubnet() calls os.networkInterfaces() and picks the first non-loopback IPv4 CIDR. Inside a Homey app container that may not be your LAN subnet (it could be the app’s internal interface, or an unexpected CIDR).
Does identify()work from your app environment?
If that returns quickly with your serial, the library is talking to the inverter fine and it’s purely a “connect() does too much for a pairing callback” problem. If identify()also times out, then something about Homey’s networking is blocking port 8899 to that host and you’d need to investigate that separately.
On the update frequency, no, that is not expected. The default is a 15-second poll (with a fuller refresh every 60s). If you’re seeing multi-minute gaps, the inverter is almost certainly only responding some of the time, and I suspect the reason is because the inverter can only reliably handle one client at a time. If two clients connect simultaneously, responses get routed to the wrong client and both sides see timeouts and missing data. This is a known quirk of the hardware, documented in GivTCP and called out in the library’s README.
Thanks for trying it out. If you’ve got any other questions on the library, please use the github issues, and I’ll keep this thread for the GivEnergy Homey app 
