2020-06 Update:Please note, this project is archived and no longer being maintained. I no longer use Homebridge. There are a number of forks which may provide you a better more up-to-date experience. Two of which I have found with significant improvements are listed below.
Supports RGB http(s) devices on the HomeBridge Platform and provides a readable
callback for getting and setting the following characteristics to Homekit:
Update your configuration file. See below for examples.
Configuration
Structure
The following is an overview of the structure of your HTTP-RGB accessory.
Both powerOn and powerOff can either be a string or an object. If a
string is provided it is filled in as the url and the body will be blank.
Most devices will be ok with the string option.
The purpose of powerOff/powerOn for an RGB light is not to physically power
or de-power the device (as then how would it respond to further commands?), but
to set the LED color to black (for powerOff), and restore the color (for
powerOn). Your backend device should already be doing this. This is just
a convenience function so that your HomeBridge knows this device can turn off
or on.
Additionally, both brightness and color share the same structure (with the
exception that the color structure allows for a .brightness variable), they
can either be a string or an object. If it is a string, it is filled in
as the status and the other fields are left blank. When this is the case, you
can only read the settings, you may not change them.
This normally will not occur, however, you may not want your application to
display a "brightness" slider to the user. In this case, you will want to
remove the brightness component from the config.
Interfacing
All the .status urls expect a 200 HTTP status code and a body of a single
string with no HTML markup.
I needed a way to control my blinksticks from
HomeKit/HomeBridge. After developing this package, I had to have a backend in
the event someone's HomeKit/HomeBridge is on a different server, or in my case,
there are 4-5 different Raspberry Pi's running blinksticks around my house.
Why 'better'?
As we all know, the word 'better' is subjective, so why put it in the title? I
decided to call it 'better' because it is intended to be a 'better' example of
how to code, not in the way of a 'better' or more feature-rich project.
There's thousands of projects on github that are just thrown together, half-
working, or abandoned and I wanted to make sure that my little contribution to
the open-source movement gave more than just code.
The 'better'-project goals are to make sure there is documentation, tests, code
and style standards. While I may have missed a few spots, my intention is to
ensure that those exist. There is value in documentation, style and testing;
and I want to serve as an example to younger (or newer) coders that may be
trying to hack apart this project.
请发表评论