finnkauski / lighthouse Goto Github PK

Is your feature request related to a problem? Please describe.
This basically relates to the fact that the bridge as of now is not fully tested because we need to mock request calls to a bridge with our own bridge somehow in order to be able to test.

Describe the solution you'd like
This could be implemented in the form of a bridge tester struct that spins up its own thread and listens to requests on a given port and responds with premade json files.

Describe the bug
Installation through cargo fails when trying to install `ssdp

To Reproduce
Steps to reproduce the behavior:

1. On a clean system, install rust
2. cargo install lighthouse

Expected behavior
Lighthouse installs

Screenshots

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /Users/rik/.cargo/registry/src/github.com-1ecc6299db9ec823/ssdp-0.7.0/src/lib.rs:2:1
  |
2 | #![feature(ip)]
  | ^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `ssdp`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lighthouse v0.1.0`, intermediate artifacts can be found at `/var/folders/gr/m4fhyk7j7ssd3_tpqldwck100000gn/T/cargo-installqGbpBl

Desktop (please complete the following information):

• OS: MacOS 10.15.3

Additional context
Is it possible to change the version of ssdp that this depends on? or should I simply install ssdp from src?

Is your feature request related to a problem? Please describe.
Configurating bridges from the existing constructors is a bit cumbersome. Ideally we'd have a more convenient storage format.

Describe the solution you'd like
Implement some type of toml storage for the bridge and implement custom construction (most likely from serde::Deserialize. This is required if we decide to keep the Bridge.target field as it has to be created from IP and token at initialisation of Bridge.

Describe the bug

   Compiling ssdp v0.7.0
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/ssnover/.cargo/registry/src/github.com-1ecc6299db9ec823/ssdp-0.7.0/src/lib.rs:2:1
  |
2 | #![feature(ip)]
  | ^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `ssdp`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

To Reproduce
Steps to reproduce the behavior:

1. Switch compiler to stable.
2. Go to root of repo and run cargo build.

Expected behavior
Successful build on stable.

It looks like the ssdp crate itself requires a nightly compiler to build. I've had success with using mdns for discovery use cases, unfortunately it doesn't look like the Hue Bridge supports MDNS (based on keeping an eye on my Wireshark window for a couple minutes). It looks like the ssdp crate is no longer maintained, since it hasn't seen an update in 2 years, but there are other crates with more recent updates like ssdp-client if you'd be open to switching the dependency out.

I could spend some time this weekend trying to prototype with a different SSDP client and see if I can get it working.

Is your feature request related to a problem? Please describe.
Ideally we would be able to use light groups as well as individual lights.

Describe the solution you'd like
Ideally we could have another structure of some kind where we store lights akin to:

pub enum LightEntities {
  Light {...},
  LightStrip {...}
}

LightGroup { 
  name: String,
  lights: Vec<LightEntities>
}

Describe alternatives you've considered
There are a few ways to implement this. Unclear yet what to do specifically.

Is your feature request related to a problem? Please describe.
The crate needs better documentation. Things like the top level of the crate are not documented. It also needs some doctest type stuff in the examples as part of the documentation.

The documentation on lighthouse emacs do say "Please read the installation guide on lighthous". but there isnt a installation guide for installing lighthouse.

I'm making a very simple repl for lighthouse and it seems that after sending any command I have to call HueBridge::scan to get updated state. If that's right it would be usefull to have it public. Thanks!

Describe the bug
When using lighthouse with Hue Lightstrips the JSON response parsing fails, as Lightstrips don't have the "swconfigid" and "productid" fields.

To Reproduce
Steps to reproduce the behavior:

1. Connect lighthouse to Hue Bridge
2. $ lh on

3. Could not collect information about the system: error decoding response body: missing field swconfigid at line 1 column xxx

Expected behavior
Lightstrips should be recognised as lights

JSON response
Example of JSON response for light strip

"5": {
    "capabilities": {
      "certified": true,
      "control": {
        "colorgamut": [
          [
            0.6915,
            0.3083
          ],
          [
            0.17,
            0.7
          ],
          [
            0.1532,
            0.0475
          ]
        ],
        "colorgamuttype": "C",
        "ct": {
          "max": 500,
          "min": 153
        },
        "maxlumen": 1600,
        "mindimlevel": 25
      },
      "streaming": {
        "proxy": true,
        "renderer": true
      }
    },
    "config": {
      "archetype": "huelightstrip",
      "direction": "omnidirectional",
      "function": "mixed",
      "startup": {
        "configured": true,
        "mode": "safety"
      }
    },
    "manufacturername": "Signify Netherlands B.V.",
    "modelid": "LST002",
    "name": "xxx",
    "productname": "Hue lightstrip plus",
    "state": {
      "alert": "none",
      "bri": 1,
      "colormode": "xy",
      "ct": 396,
      "effect": "none",
      "hue": 7790,
      "mode": "homeautomation",
      "on": false,
      "reachable": true,
      "sat": 160,
      "xy": [
        0.4764,
        0.4087
      ]
    },
    "swupdate": {
      "lastinstall": "2020-03-04T13:57:09",
      "state": "noupdates"
    },
    "swversion": "5.130.1.30000",
    "type": "Extended color light",
    "uniqueid": "xxx"
  }

Desktop (please complete the following information):

• Hue Bridge Version: BSB002 | 1939070020
• Lightstrip Version: LST002 | 5.130.1.30000

I would be willing to fix this and write a PR, any pointers on how to go about this? Maybe as simple as dropping the "swconfigid" and "productid" from the Light struct?

Is your feature request related to a problem? Please describe.
It's easier to use and install different versions for a user of the project

Describe the solution you'd like
Add this project to crates.io so one could just use cargo install lighthouse ;-)

Greetings Chris