Eindelijk overgestapt op de Hue gradient lampen, maar nu blijkt dat Homey vanuit de Philips Hue app enkel statische scenes kan starten.
Er is een Duits topic met dezelfde vraag: Dynamische Scenen starten “HUE” - API V2
Na het achterhalen van mijn LocalUserID (of App Key) heb ik onderstaande http request in logic gebouwd:
Dit geeft een error ivm een “self signed certificate”.
API v2 werkt echter alleen via SSL poort 443 (dus https).
Via de API Debugger werkt deze command wel gewoon.
Hier het stuk van de Philips Hue Developers site:
The Hue API can currently be accessed over HTTP on port 80 and HTTP over TLS (HTTPS) on port 443. For security reasons HTTP access to the API will be disabled in a future firmware release. This section explains the differences and how to upgrade to HTTPS.
To use HTTPS properly, the client has to validate the Hue Bridge certificate against the Signify private CA Certificate for Hue Bridges. This is typically done by adding the CA cert into the key store trusted by the HTTP client, or for some HTTP clients by adding it as an input parameter when setting up the HTTPS connection. The CA certificate is shown below in PEM format.
-----BEGIN CERTIFICATE-----MIICMjCCAdigAwIBAgIUO7FSLbaxikuXAljzVaurLXWmFw4wCgYIKoZIzj0EAwIwOTELMAkGA1UEBhMCTkwxFDASBgNVBAoMC1BoaWxpcHMgSHVlMRQwEgYDVQQDDAtyb290LWJyaWRnZTAiGA8yMDE3MDEwMTAwMDAwMFoYDzIwMzgwMTE5MDMxNDA3WjA5MQswCQYDVQQGEwJOTDEUMBIGA1UECgwLUGhpbGlwcyBIdWUxFDASBgNVBAMMC3Jvb3QtYnJpZGdlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEjNw2tx2AplOf9x86aTdvEcL1FU65QDxziKvBpW9XXSIcibAeQiKxegpq8Exbr9v6LBnYbna2VcaK0G22jOKkTqOBuTCBtjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUZ2ONTFrDT6o8ItRnKfqWKnHFGmQwdAYDVR0jBG0wa4AUZ2ONTFrDT6o8ItRnKfqWKnHFGmShPaQ7MDkxCzAJBgNVBAYTAk5MMRQwEgYDVQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2WCFDuxUi22sYpLlwJY81Wrqy11phcOMAoGCCqGSM49BAMCA0gAMEUCIEBYYEOsa07TH7E5MJnGw557lVkORgit2Rm1h3B2sFgDAiEA1Fj/C3AN5psFMjo0//mrQebo0eKd3aWRx+pQY08mk48=-----END CERTIFICATE-----
The other part of the certificate validation is checking that the common name on the certificate matches the bridge id of the bridge you are trying to connect to. This is typically done by using the bridge id as hostname and adding a custom resolver that resolves it to the IP address, or by injecting a custom hostname verifier into the HTTPS client which checks that the server principal name matches the bridge id.
In this example it is assumed that the CA certificate above is stored in a file called huebridge_cacert.pem. Furthermore the , and should be replaced by the actual values for the respective bridge.
First, this is an example curl command line request to retrieve the list of lights using plain HTTP:
curl http://<ipaddress>/api/<username>/lights
The equivalent request on HTTPS would then be:
curl --cacert huebridge_cacert.pem --resolve "<bridgeid>:443:<ipaddress>" https://<bridgeid>/api/<username>/lights
Older Hue Bridges currently still use self-signed certificates (instead of signed by Signify’s Hue Bridge CA). Handling those requires different logic, but we intend to update all bridges to receive Signify signed certificates so that no differentiation has to be made. To check if your bridge still has a self-signed certificate, you can run the following openssl command to inspect the certificate subject and issuer:
openssl s_client -showcerts -connect <ipaddress>:443
You should see that the Common Name (CN) of the Subject always matches the bridge id as expected, however in case of self-signed certificates you would see that the Common Name of the Issuer also equals the bridge id.
Until these bridges are updated, you need to handle the logic of trusting self-signed certificates at first connection. In other words you need to pin (with the bridge-id) the certificate on first connection with the bridge (“trust on first use”) and check upon later contacts with the same bridge. For development/testing purposes, you can disable certificate validation (e.g. using the curl –insecure command line argument).
Web browsers do not have access to the root certificate of the Hue Bridges. This means that in case you would access the bridge using a browser (e.g. going to https://) the browser will complain that the connection is not secure due to the fact that the certificate has not been certified by a trusted third party, and will ask you whether you want to continue and trust the certificate.
Workaround!!
Via het “get” command in de debugger heb ik ook een (volgens mij recent toegevoegde) lijn code gevonden, namelijk: “auto_dynamic”: false.
Ik zeg, recent toegevoegd, omdat ik ondertussen 10-tallen topics online heb gevonden op bijvoorbeeld reddit en domoticz van gebruikers die tegen hetzelfde probleem aan lopen. Maar niemand die deze oplossing nog heeft gevonden.
Bovendien is het een verborgen “setting” die niet geactiveerd kan worden via de app.
Daarom denk ik dat hij toegevoegd is met 1 van de laatste updates en wellicht binnenkort via een software update ook beschikbaar komt in de app.
Ik zal de oplossing posten in het internationale topic.
