[Open discussion] Homebridge for beginners

Hi there,

I’m the author of a few popular Homebridge plugins (see my profile). I’ve been receiving a lot of issues about my plugins. All the issues but one had nothing to do with the plugins.

The main issues have been:

• A change in Homebridge causing a warning <plugin> defines 'homebridge' and/or 'hap-nodejs' in their 'dependencies' section. Beginners don’t know what it means and they felt to report it. I’m cool with that but I don’t have the time to re-test every single of my plugins after changing a simple line on package.json
• Issues in installing plugins via config-ui (some of my plugins have system dependencies due to Bluetooth or mDNS)
• An array of config issues

I’m a freelance developer and I don’t work for any Home Automation companies. I wrote the plugins to fit my needs in order to integrate more and more devices into HomeKit. I’ve got so hooked that I’m about to release a NodeJS based alternative to HomeAssistant.

I love the Homebridge community but I feel more and more beginners are jumping onto it thanks to the efforts like the official Homebridge RPI image, Hoobs and config-ui-x. I really like the idea of more people being able to try new technologies but this is causing more and more requests coming my way. I’m cool with more people using the platform but the requests keep coming and I don’t have the bandwidth to deal with them. I’m also not planning to release any Homekit related commercial products that could somehow pay for the time spent improving the plugins.

I’m left wondering: what can we do to make the Homebridge community more user friendly?

A few ideas:

• Move away from config.json: I’ve seen sooooo many reddit posts due to invalid JSON. Let’s face it, JSON is brilliant but it is not user friendly.
• Change the installation process to stop relying on NPM (or still use NPM under the hood but make it more standard; so the plugin will work once has been installed). Right now every single plugin has a slightly different variation of the instructions on how to install. Again, not really user friendly. NPM expects a package.json hence why we install it with -g. The simple omission of that argument causes errors that are not clear to non node developers.
• Standardise the Homebridge RPI image in order to reduce the testing burden on plugin developers: we could guarantee that each plugin works on a single image running on RPI and hope it will work in any other scenario (see Docker)

Please consider this a conversation starter, I’m open to ideas on how to improve. I’m also open to collaborate further on the actual core Homebridge platform 😃

[ebaauw]

I’d like to chime in as well; these issues are very recognisable.

When I published the first version of my first plugin (Homebridge Hue), over four years ago, Homebridge mainly was a platform for developers, or at least for tech-savvy people. They could be supported adequately through GitHub, understanding their environment.

With the recent democratisation of Homebridge, fuelled mainly by @oznu’s brilliant work on Homebridge Config UI X, the Raspberry Pi and docker images, and the installation manuals, more and more non-tech-savvy people are using Homebridge. Supporting them has largely shifted from GitHub to Discord, and I’m happy to see peer-to-peer support catching on.

However, Homebridge is still a complex ecosystem, where there are all too many places for issues to occur. While I would like to provide support for my plugins, I don’t have the bandwidth, for the knowledge, to support the entire ecosystem. For me it’s essential to be able to determine quickly whether an issue is rooted in my plugin, in the system exposed by my plugin, in Homebridge or in HomeKit itself. To this extent, I’ve bundled some command-line tools with my plugins for debugging, created a dump file for Homebridge Hue (which can even be downloaded though Homebridge Config UI X), and provide extensive debug messages from my plugins.

My main challenge is that today’s users aren’t able to run homebridge -D and locate and upload Homebridge’s log file. At best they copy/paste some log messages, or provide a screenshot of Config UI X showing these. I really need the full debug log file, from the moment Homebridge has started, to the moment the issue occurs. I’ve asked @oznu for a provision to download the log file through Homebridge Config UI X, but he’s rightfully concerned about the sensitive information in the log file. See https://github.com/oznu/homebridge-config-ui-x/issues/676.

For me, in addition to the actions mentioned above, the biggest wins would be:

• A standard way to download the full log file (not the revolving one shown by Homebridge Config UI X), warning the user about sensitive data it might contain;
• A way to enable debugging (the -D flag) dynamically, per plugin. I’d create a PR for that, but I’m not into TypeScript.

Share some code between maintainers (e.g. there are amazing bits of code from @ebaauw that could easily be reused)

If you’re referring to Homebridge Lib, I’m still developing that, refactoring my plugins to use that as a base. I imagined eventually merging that into Homebridge, see also https://github.com/homebridge/homebridge/issues/1039. It would probably need to be transcribed to TypeScript first, though.

[milo526]

I very much agree on this topic. I recently started maintaining a fork of the homebridge-tuya-web plugin after which the original owner gave me access to the original npm package so I now fully maintain that plugin.

I created the fork cause I wanted to add support for a device I just bought, at the end of an evening in which I created this fork I needed to get the updated plugin to my homebridge instance and thought that the fastest way would be to push it to npm. Without actual intent I became a plugin maintainer 🙈 and created something that is now downloaded 2400+ times. A number that might seem small to some of you but of which I’m actually kind of proud 😉.

I like giving back to the community that created so many awesome plugins and such an amazing ecosystem but boy did I underestimate how much time this was gonna cost me. People are opening issues, tweeting at me, mailing me. Some with very valid issues and complaints. Some with questions on why I don’t support a device that I don’t own and for which no documentation exists.

Many of these support inquiries are completely unsolvable and require me to ask for more information, many users don’t know what GitHub is, what an issue is, or how to debug for themselves (some others are amazing human beings who help tremendously and without whom it would have been a way harder journey).

I very strongly believe that there is a tremendous shift in the technical know-how of homebridge users. I also suspect that this is strongly influenced by the fact that homebridge is easier to install and configure (if I’m not mistaken I’ve seen pre-build and pre-configured raspi’s being sold).

I also fully agree with the views that you expose, how it is great that more users are able to enjoy this “product”, I believe that “we” (as in the homebridge maintainers, plugin maintainers etc. ) should work together to create a cohesive eco-system in which we can help each other improve this ecosystem.