If a Coordinator is present in the device list, AddDevicesFromJSON will
fail catastrophically, which shouldn't happen. Therefore, make sure only
EndDevices are considered during add. Also updated the tests to check
for this.
Added a device descriptor for failed adds. This will help with
identifying which device failed (and perhaps, why).
The server used to use the hap default PIN, but using a fixed PIN is not
secure. A random PIN is now generated on first run and displayed to the
console (or journal), similar to how homebridge does it. It can also be
specified explicitly by the user in the config file.
It looks like Go has adopted 15s TCP keepalives as a default for _all_
TCP connections, which is quite dumb if you ask me.
https://github.com/golang/go/issues/48622
For the HAP server's side, it degrades iOS battery life significantly by
waking the device every 15s to respond to these packets. In the case as
a normal MQTT client, it increases traffic on top of the 60s keepalive
we've already set at the application layer. In both cases, the solution
is to just explicitly disable TCP keepalives.
Upgrade hap to the latest version that contains the fixbrutella/hap#36.
For devices that we have no idea how to handle, i.e. no services or
expose entries were processed, we return ErrUnknownDeviceType and skip
it during AddDevicesFromJSON(). This prevents a device from showing up
where HomeKit says it's not supported.
Also had to rename the existing DEBUG consts to DEVMODE, so as to not
confuse the two. DEVMODE is meant for developers and cannot be enabled
on-the-fly, whereas debug mode is for users to check that the bridge is
working, MQTT messages are received etc.
Update logging is throttled to avoid spurious messages for uncoalesced
MQTT updates and motion sensors. On my network with 10 devices, an
update is logged every 1-2 minutes on average.
So far Z2M state updates were only boolean (the device `state` on/off),
but after introducing `brightness` values, Z2M state updates may not be
recognized/acknowledged. Unmarshalled Z2M numeric values are always
float64, but updates sent out via MQTT might not be. As a result, the
values may not directly equal and may never match.
To solve this, cast the outgoing expected value into a float64 to
compare against the received Z2M value, which is already a float64.
Devices that have not received an update since a fixed timeout (24 hrs
for now), based on its last_seen time, will be marked as "not
responding" in the Home app. With this I can identify which devices are
unreachable or dead.
Also needed to upgrade hap with the fix for brutella/hap#30, or the
entire bridge will stop working.
