Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to view and control accessories #37

Closed
oznu opened this issue Feb 25, 2018 · 23 comments
Closed

Add ability to view and control accessories #37

oznu opened this issue Feb 25, 2018 · 23 comments

Comments

@oznu
Copy link
Member

oznu commented Feb 25, 2018

I would like to add the ability to view and control accessories exposed by Homebridge from the Config UI X interface.

homebridge-config-ui-x-accessories

This requires support in the user interface for each HomeKit service type. There are ~40 services that have ~125 different characteristics.

To enable accessory control Homebridge must be started in insecure mode using the -I flag (this allows Config UI X access, the Accessories tab won't be displayed if it's not enabled):

homebridge -I
@Green-Kite
Copy link

How can I start Homebridge with the '-I' flag if I use systemd to start homebridge?

I updated with the @next tag, restarted the RaspberryPi but it does not show the accessories tab in the Web Interface.

@SkyJohn
Copy link

SkyJohn commented Feb 25, 2018

For some reason I don't see the accessories tab in the Config UI but I can navigate to it if I type the address manually.

Also, non admin logins are still able to login and change all the settings and passwords.

@oznu
Copy link
Member Author

oznu commented Feb 26, 2018

Hi @Green-Kite

This will depend on your individual setup, if you followed these instructions you would add the -I flag to the HOMEBRIDGE_OPTS in /etc/default/homebridge like this:

# Defaults / Configuration options for homebridge
# The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others)
HOMEBRIDGE_OPTS=-U /var/lib/homebridge -I

If you don't have that file you might have to add the -I flag after the ExecStart command in your /etc/systemd/system/homebridge.service file.

After making any changes run:

systemctl daemon-reload
systemctl restart homebridge

@oznu
Copy link
Member Author

oznu commented Feb 26, 2018

@SkyJohn - Thanks for testing. My last minute change to support this running in the oznu/homebridge docker image broke insecure mode detection. I've fixed this in the latest @next release.

You will need to run the install command to update to new versions of the @next release as the UI won't prompt you to update when you're ahead of the main release stream.

sudo npm install -g --unsafe-perm homebridge-config-ui-x@next 

You're the first person to figure out the "admin" checkbox currently does nothing. I was seeing if this feature was actually being used before deciding to take the time to implement it in this fork. A non-admin user option is going to be more useful once accessory control is added, so I will include this as part of this major release.

@Green-Kite
Copy link

@oznu Thanks for your help I already did this but maybe it was the same failure that @SkyJohn had. After updating the HOMEBRIDGE_OPTS and updating with …@next I can see and control my accessories from the UI.

@SkyJohn
Copy link

SkyJohn commented Feb 26, 2018

Yup updating made the accessories tab show up for me too.

How are the accessories being organised at the moment? They just seem to be showing up as a random bunch at the moment with lights and switches all mixed together in not particular order.

@oznu
Copy link
Member Author

oznu commented Feb 27, 2018

@SkyJohn, currently the services are not ordered in any particular way. My plan is to allow you to organise them yourself using drag and drop and to possibly sort them into different rows which represent rooms (existing room information is stored in iCloud which we can't access).

I also am thinking about a "full screen mode" which could allow it to be used as a home control panel on a cheap tablet device.

@oznu
Copy link
Member Author

oznu commented Feb 27, 2018

Drag and drop support with rooms is available to preview.

You can arrange accessories by dragging them, even between rooms, and you can also arrange the room order by dragging the room by the room name element.

Don't spend to much time perfecting your layout - it's not persistent yet, and the "Add Room" button isn't working.

Drag and drop is disabled on mobile devices.

image

@oznu
Copy link
Member Author

oznu commented Mar 4, 2018

Quick update.

  • Accessory layout is now persistent.
  • Every user can customise the room and accessory layout how they wish without impacting other users.
  • A room will automatically be removed from the layout if it has no accessories.
  • Accessory layout config is stored in ~/.homebridge/accessories/uiAccessoriesLayout.json.
  • Non-admins can no longer do everything. They are restricted to viewing the status page, controlling accessories, viewing the log, and restarting the homebridge server.

And something I didn't mention before, the extra controls for accessories (such as bulb brightness, target temperature, fan speed etc.) can be accessed by doing a "long press" on the accessory icon - just like in iOS. Check the initial post in this thread to see what's currently supported.

image

@dominick-han
Copy link

Just wondering if air quality and humidity are implemented :)
If not I'm glad to help
screen shot 2018-03-04 at 1 33 42 am
BTW man, keep up the good work! Love this plugin

@oznu
Copy link
Member Author

oznu commented Mar 4, 2018

Hi @dominick-han,

I just added them in 3.0.0-16 - f2ab274.

image

@dominick-han
Copy link

Let me know if you need help developing some aspects of this Issue
Been coding with homebridge for quite a bit now

@normen
Copy link

normen commented Mar 4, 2018

I realize this is a feature some might find interesting so please don't take this the wrong way but as constructive criticism. Its just my thoughts on the topic, nothing more.

  1. Why do we need this at all? We have Siri, great UIs in all kinds of Apps on Phone, Pad and whatnot to control HomeKit itself, isn't this for controlling the HomeBridge server?
  2. Its a massive security concern. Theres a reason the HomeBridge mode where plugins can control other devices is called "insecure". This is software some people (like me) might have their door locks connected to! For good reason Apple disallows controlling locks from certain situations (e.g. from AppleTV etc.). Better make a BIG warning about this.

So yeah, I'm just saying this as it seems like a lot of work for something that might end up as a "feature creep" - the way I see it people look for something to control their HomeBridge server not the devices themselves. So features in that direction might be a better way to go?

Again and again, all just my thoughts (not even a fixed opinion) - I know that its best to use the energy when you're "in the zone" - which you certainly seem to be with this feature! 😀 And I'm well aware it's optional - thats why I thought about it, I'll probably never enable it.

@oznu
Copy link
Member Author

oznu commented Mar 5, 2018

Why do we need this at all? We have Siri, great UIs in all kinds of Apps on Phone, Pad and whatnot to control HomeKit itself, isn't this for controlling the HomeBridge server?

I'm doing this so I can control accessories from my workstation. There are plenty of iOS apps, but there are none for the desktop, even Siri for macOS does not support HomeKit. While I'm working I'd rather not stop, reach for my phone or turn off the music (so siri does not get confused) just to adjust the A/C.

This also opens up the ability for those Android users to control the home, which might be useful if you have guests and don't have a communal iPad.

It's a massive security concern.

Updating accessories still requires knowing Homebridge PIN, so it's not completely insecure, and as you say, it's optional, people who aren't running in insecure mode won't even see the Accessories tab.

@normen
Copy link

normen commented Mar 5, 2018

It sounds a bit like you did not take it as constructive criticism and start to defend yourself, theres no need for that. I didn't ask you to stop doing anything.

The problem with security (among other things) is that you offer an easy way to install plugins from a totally open repository. Anyone could put out a plugin saying "HomeKit control for (popular device)" and get into peoples systems and control them if this config UI becomes more common.

@iShift
Copy link
Contributor

iShift commented Mar 5, 2018

cool! it would be awesome if you also make http API

@SkyJohn
Copy link

SkyJohn commented Mar 5, 2018

@normen People can't already install all those homebridge plugins easily and open themselves to those kinds of exploits, Config UI X doesn't add any extra insecurity in that respect.

@oznu
Copy link
Member Author

oznu commented Mar 5, 2018

The problem with security (among other things) is that you offer an easy way to install plugins from a totally open repository. Anyone could put out a plugin saying "HomeKit control for (popular device)" and get into peoples systems and control them if this config UI becomes more common.

Unfortunately this is the case whether you are running in insecure mode or not. A malicious plugin doesn't even have to be setup in the config.json for it to cause harm. If it has the name homebridge-* and homebridge-plugin as a keyword in it's package.json Homebridge will load it, passing in the homebridge api object which allows the plugin to view the entire config.json and access the functions exposed by your other installed accessories.

Considering this, it might be good to show the GitHub star count or npm download count for a plugin which will allow the users to decide how much they trust a plugin before installing it.

@normen
Copy link

normen commented Mar 5, 2018

Exactly, when people install stuff via command line they have to put a bit more thought in it. Saying "you can disable it" doesn't work - people do not research every option they enable. If they would google couldn't make any money :) People need to be reminded about such things.

@oznu
Copy link
Member Author

oznu commented Mar 6, 2018

It's not related to "Accessory Control", but from > 3.0 all plugins installed will have their dependencies scanned for known vulnerabilities and malware from the list at https://nodesecurity.io/advisories.

Powered by nodesecurity.io's free scanning tool: https://github.com/nodesecurity/nsp.

@normen
Copy link

normen commented Mar 8, 2018

Very much appreciate the README and code additions. I don't want to whinge but I'm just thinking that if it would become very common for people to easily install something completely insecure without warning into their HomeKit system Apple will quickly call an end to all the fun and simply disallow uncertified devices :(

..and a complete RasPi distro with HomeBridge and this plugin installed is just one determined student away ;)

@oznu
Copy link
Member Author

oznu commented Mar 10, 2018

Thanks to everyone who tested this and provided their feedback.

3.0.0 is now on the latest tag, if you're currently running on the next tag you will see an update available in the UI.

Not all service types are supported, but these will be added over time based on demand and tracked in #47.

@ChristopherNeuwirth
Copy link

@oznu I keep coming back to this thread during my search, therefore the following question:

I'm looking for a possibility to access my HomeKit devices with pure read access to build a dashboard which should run on a TV (no controlling).
Is there a way to achieve this without running Homebridge in insecure mode and without installing the Config-Ui-X?

While searching the ui repository I found a web socket service for the ui but actually I am a bit lost.

I have been using HomeKit for about 4 years, currently in version 0.4.50.

Thanks for any advice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants