Homebridge Plugin

Hi @ToWn3r

It looks like Go is not in your path. Make sure it is by adding the following lines to your ~/.bashrc file:

PATH=$PATH:/usr/local/go/bin
GOPATH=$HOME/golang

Alternatively, you can alter the build command like this:

cd pixlet && PATH=$PATH:/usr/local/go/bin GOPATH=$HOME/golang make build

1 Like

:see_no_evil:

Idk where that is :frowning:

The file would be /home/pi/.bashrc. By default, ls does not show hidden/dotfiles, so the file prefixed with a period does not show. you can use ls -a to show them.

If the file doesn’t exist you can create it with those lines and it will be fine.

Alternatively, you can avoid ~/.bashrc and alter the build command instead like this:

cd pixlet && PATH=$PATH:/usr/local/go/bin GOPATH=$HOME/golang make build

1 Like

Getting closer!
Getting a permission denied

pi@ToWn3r-Pi:~ $ cd pixlet && PATH=$PATH:/usr/local/go/bin     GOPATH=$HOME/golang make build
rm -rf build/out
go run render/gen/embedfonts.go
failed to initialize build cache at /home/pi/.cache/go-build: mkdir /home/pi/.cache/go-build: permission denied
make: *** [Makefile:14: embedfonts] Error 1

If you’ve ran the command with sudo it might have changed permissions on your cache directory.

sudo chown -R pi /home/pi/.cache 

and then try the build again. Just make sure all of the directories are owned by the pi user that you are running as.

1 Like

Perfect! After running the following I think it was built.

sudo chown -R pi /home/pi/.cache

sudo PATH=$PATH:/usr/local/go/bin GOPATH=$HOME/golang make build

1 Like

Great, now you can run mv pixlet /usr/local/bin/ and pixlet will be in your path and available to the Homebridge plugin.

[Tidbyt] Could not locate the pixlet CLI. Make sure it is installed and in your PATH.

Is pixlet actually there? What does ls -lah /usr/local/bin/pixlet show?

What does this show?

> pixlet render --help

If you are unable to run the render above, what does the $PATH show when you run env?

Hi @ToWn3r

From your last screenshot, it looks like you’ve moved the entire pixlet source folder into /usr/local/bin. What we wanted to do was move the built binary there instead.

Move the source back to your home directory

> sudo mv /usr/local/bin/pixlet /home/pi/pixlet

Build pixlet:

> cd /home/pi/pixlet 
> sudo PATH=$PATH:/usr/local/go/bin GOPATH=$HOME/golang make build
> sudo mv pixlet /usr/local/bin/pixlet

Ahh i think i figured out the missing step.
After sudo PATH=$PATH:/usr/local/go/bin GOPATH=$HOME/golang make build
I had to cd /home/pi/pixlet/build/out then sudo mv pixlet /usr/local/bin/pixlet

1 Like

I’ve built this out a bit more here:

I’ve just released v0.5.0 of the Homebridge Plugin with a new feature: Background Pushes!

When configuring a Custom App, you can now enable the Push To Background option.

Additionally, if you’ve enabled the Refresh on Startup option, the initial updates will be pushed to the background to avoid the first-run pile up effect.

PS - To add this feature, I’ve implemented this useful new feature in v1.0.0 of the node-tidbyt client.

2 Likes

I have my own workflow to push stuff to my Tidbyts but this seemed to be a nice alternative for doing it myself. However, it appears to me that my Tidbyts not only have their own device id, but also their own api tokens, even though I am managing them from the same device. So, this Homebridge plugin doesn’t work for me because it assumes that all Tidbyts have the same api token.

Edit: According to Tidbyt | Dev, this is by design:

Each API key is scoped to a specific device and is valid for one year. If a key is compromised, the device that it’s associated with must be reset.

Hi @franklin!

Thanks for your interest in the Homebridge plug-in. Good catch regarding the API keys! I totally missed that. I’ll publish an update that stores the API key at the device level instead.

Great! I look forward to your update! :slight_smile: I understand your assumption though, that API tokens would be account specific and not device specific. I don’t see why we would need a device ID if API tokens are already device specific. Probably some technical debt.

I’ve just published version 0.6.5 which adds true multiple device support!

I’ve adjusted the configuration schema to accommodate an API key per device, but it will require that you re-enter your API key for your original device under the Devices section before the plugin is usable again. Sorry for the inconvenience.

As a side note, I’m happy to report that the plugin is now Verified by the Homebridge team.

Version 0.7.0 has been published which adds support for device-specific custom applications.

  • Apps defined in the “Custom Apps” section inside of a device section will only be installed on that single device.
  • Apps defined in the “Custom Apps” section outside of a device are global apps and will be installed on all devices.

There’s no way yet to surface information from HomeKit accessories, like temperatures, right?