Support Adaptive Lighting

[normen]

The latest homebridge versions support adaptive lighting, this should be supported by the plugin.

[Zer0x00]

The latest homebridge version does not support adaptive lighting but the beta version since 1.3.0-beta.19. I've created a branch (https://github.com/Zer0x00/homebridge-milighthub-platform/tree/adaptive_lighting) for that matter, I would suggest that we merge it when the function arrives in the master-branch release.

//Edit: My adaptive lighting implemantation is defective yet, will fix it.

[Zer0x00]

@normen I'm not done yet with the implementation but the remaining bits should be only nice-to-have's.

Could you test if my implementation works correctly?

[normen]

Wow, cool. I won't be able to really test this in my home setup too soon. Also I don't have only RGBW lights, none with different white shades - should it work with those too? Anyway, I'll put it on my list.

Btw, if you want I can give you admin access to this repo - by now most of the code is yours anyway 🙂

[Zer0x00]

Oh, that's sad to hear.. you have to do an upgrade to RGB+CCT bulbs! :) (I'm using FUT103 GU10 bulbs in my entire home, don't regret it so far.. can recommend them but if you want sth brighter you can look at the FUT106 bulbs.)

The code base is right now a huge mess imho.. caused by me 😂 I'm planning to do a rewrite if I've fixed the last remaining thing on my list (replicating the behaviour of the milight hub when changing color temperatures, currently the hub sends a correction value back via backchannel if some off-values are set.. don't know how to describe this better, see this issue). Admin access would be very welcome for this project! Thanks for your trust!

Would you be fine to change the project to semantic versioning after the rewrite?

[normen]

Thinking about it I do have 4 large RGB+CCT panels in my sound studio but I didn't extend the whole Homebridge stuff to the studio yet.. Maybe thats a good reason 😁

As for versioning - sure, is there any other way of versioning? 😉 I just kept the whole plugin in "beta" as usually theres some point where a lot of users come in and shape the software in one way or the other. But for some reason that didn't really happen here 🤔 Maybe its just working too well out of the box or people think a light bulb should cost 40$ 😁

[normen]

Did a lot of changes, cleanups and documentation, I'll leave the 0.5 version to your adaptive lighting patch though. Then after a grace period I guess its finally time for a 1.0 release. 🙂

[turbidWaters]

Thank you very much for the effort to make this plugin.

I see that support for adaptive lighting is being worked on for this plugin. Would you have a release date in mind? I have many milight bulbs and strips, and I look forward to it.

I have been using homebridge-mqtt for this so far and was planning to move to homebridge-mqttthing as it supports multiple services in a single accessory. This way I will be able to add support for "effects" as well, using a tv accessory as an additional service. Perhaps add the night mode as well (lower than 5% brightness put the bulbs into "night mode"). I was also evaluating the move to homebridge-mqttthing as there is support for adaptive lighting. While I have a dummy light bulb accessory created in homebridge-mqttthing, I haven't used it on a real bulb yet.

Currently how I have worked around adaptive lighting and the "flashing" issue when turning on a bulb or strip on a lower brightness setting than it was when it was turned off earlier is: 1. capture "on" requests from homebridge-mqtt and apply a certain color temperature depending on what the current time period is. I have 5 modes. I do this by using node-red. I use a "wait" node to capture all the characteristics that the home app has set along with the "on" command. If only an 'on' and 'brightness' request is received then the color temperature is set to one of the 5 presets depending on time of day. I also use the "transition" parameter to ensure that the lights are always set to zero brightness before turning off so there is no flashing when - for example - i use a button on my ikea remote that has 4 presets of brightness levels, and some tasmota buttons that control the power to the lights while they also control on/off of the lights when the power relay is "ON" (this way switch presses dont turn off the relay but instead turn on/off the relevant milight using mqtt commands to the milightbub). Nodered updates homekit via homebridge-mqtt, the current status of the bulb. It is better to store the last brightness value and set that as the "brightness" when only the "On" characteristic is received. I haven't been able to do that.

On a related note, I just wanted to share that, I am able to capture color temperature requests from the home app (via homebridge-mqtt and nodered) when using the color temperature slider in the home app. Its when using siri the home app sends Hue and Saturation, rather than ColorTemperature. For this I have setup nodered to deliberately change a hue and sat request to a 'color_temp' request before sending it to the milight hub - though only for two settings "warm while" and "cold white" because they are consistent in the hue and sat values that siri requests. For intermediate temperature settings I have no solution.

Thanks again for making this plug-in.

[normen]

Thanks for the info, no release date planned. Thanks for the detailed info, most of the issues you talk about (flashing, temperature vs hue/sat etc) are pretty much solved in this plugin. For effects - theres no equivalent in HomeKit and I'd like to avoid hack-y workarounds with additional switches etc. But you can simply use this plugin together with an MQTT plugin which would only give you the "FX" switch while this plugin does the rest.

[turbidWaters]

Thank you for the response. Yes, I agree hack-y workarounds must be avoided, now that the plug-in has been build so elegantly. Look forward to adaptive lighting support.

[Zer0x00]

@turbidWaters Could you give the pull request under #14 a try and report any bugs?

[turbidWaters]

@turbidWaters Could you give the pull request under #14 a try and report any bugs?

Hi @Zer0x00 thank you for bringing my attention to this. Sorry Somehow I have not seen this earlier. Apologies!

Also, Im sorry, but can you help me understand how I can use #14?

[Zer0x00]

@normen Would it be possible for you to release https://github.com/normen/homebridge-milighthub-platform/pull/14 as a beta release?

[normen]

@normen Would it be possible for you to release #14 as a beta release?

Sorry for the delay, done.

[Zer0x00]

@turbidWaters Could you give v1.1.0-beta.1 a try?

[turbidWaters]

@turbidWaters Could you give v1.1.0-beta.1 a try?

Thanks. Just got a chance to install it. Will test it during this week and come back

[turbidWaters]

I had it installed for 3 days. While I did not see the logs or check mqtt values, I could say that the Colors were quite different from the adaptive lighting I have on the Philips hue bulbs (running thru deconz2, over the homebridge-hue plugin). One more thing I noticed is that the bulbs wouldn't turn off from the home app instead they would go to 1 pc. I switched off the "avoid flicker" settings and all other optional settings that could make the bulbs go to 1pc brightness instead of turning off. Using Siri to give a command to make the bulb zero percent makes the Home app UI go to zero but the bulb remains at 1pc (or 5pc, as with these bulbs both are the same). However when i use the slider in the Home app to turn it down to zero pc, it does switch off - note however again, that this needs to be done slowly. I am not sure if this is because of my network or mqtt or the hub's settings. Will check more thoroughly this week using debug options on mqtt.

If there is scenario you would like me to test or a series of scenarios you have a list of, please do let me know, as it looks like it's best to test it scenario by scenario.

And one more thing that I don't understand: I reverted back to the latest release but the adaptive lighting option in the home app is still there for these bulbs.

Will get back a week

[turbidWaters]

Frankly I've been struggling to understand how things are working now. So I decided to remove the plug-in fully and reinstall it. But after I have reinstalled it, none of the aliases are being shown in HomeKit.

I have tried removing / reinstalling and other options like setting it up as a separate bridge. Mqtt(nodered) works when accessed directly though. I am failing to see what I'm missing as I haven't changed anything accept upgrade the version of homebridge.

The next thing I'm going to try in my desperation to get my lights back into HomeKit is to install a fresh instance of homebridge with just this plugin and hope it works. In the meanwhile if someone can see what's the issue here please do give me a pointer.

[normen]

Frankly I've been struggling to understand how things are working now. So I decided to remove the plug-in fully and reinstall it. But after I have reinstalled it, none of the aliases are being shown in HomeKit.

I have tried removing / reinstalling and other options like setting it up as a separate bridge. Mqtt(nodered) works when accessed directly though. I am failing to see what I'm missing as I haven't changed anything accept upgrade the version of homebridge.

The next thing I'm going to try in my desperation to get my lights back into HomeKit is to install a fresh instance of homebridge with just this plugin and hope it works. In the meanwhile if someone can see what's the issue here please do give me a pointer.

It might be because HomeKit caches the names somehow. You could try deleting your homebridge caches at ~/.homebridge/persist and see if that suffices. Otherwise you might have to rename your lights so they get picked up as new ones.

[turbidWaters]

Thanks you for the instant response.

I have actually removed the instance of the child bridge ans reinstalled it. I also used the settings in homebridge ui-x to manually delete the accessory so that any cache is deleted.

I removed the "bridge" from HomeKit via the home app and then re paired it (after deleting the bridge in Homebridge and then reinstalling it again) as well. Still there are no logs for either new aliases or old ones and there are no logs in homebridge (for this plugin) when I use the milighthub browser interface to control the lights or mqtt (nodered) to control the lights.

But all other logs about this plugin in homebridge are normal, like plugin start up etc.

I then forced "use http" Though the following lines are logged, none of the lights are getting added to homebridge.

DEBUG: Querying /settings [11/28/2023, 11:55:34 PM] [Bedroom] DEBUG: GET: /settings

I even tried downgrading homebridge to 1.6.1 , still the same.

Next I'm going to try installing a fresh instance of homebridge as another service. Fingers crossed

[normen]

If theres no logs for this plugin at all, are you sure its installed properly? Maybe its installed in another path or you have your homebridge configured with a different settings file?

[turbidWaters]

Yes yes there logs. What I meant to say is that there are no logs for any new alias detected. The rest of the logs such as plug in registered, started, mqtt messages, using mqtt server etc are all there.

[turbidWaters]

I'm now confirming that I have created a new instance of homebridge in a separate machine and installed just this plugin and I have got the exact same results as I have been getting in my regular setup. It's perplexing.

I even tried downgrading to version 1.11.0 on the milight. Still same results.

Here are the logs from the new install (which are actually no different from the existing install):

---

'''11/29/2023, 1:19:56 AM] [HB Supervisor] Starting Homebridge with extra flags: -I -P /var/lib/homebridge/node_modules --strict-plugin-resolution [11/29/2023, 1:19:56 AM] [HB Supervisor] Started Homebridge v1.7.0 with PID: 10485 [11/29/2023, 1:19:56 AM] Loaded config.json with 0 accessories and 2 platforms. [11/29/2023, 1:19:56 AM] Loaded 0 cached accessories from cachedAccessories. [11/29/2023, 1:19:56 AM] --- [11/29/2023, 1:19:56 AM] Loaded plugin: homebridge-milighthub-platform@1.0.0 [11/29/2023, 1:19:56 AM] Registering platform 'homebridge-milighthub-platform.MiLightHubPlatform' [11/29/2023, 1:19:56 AM] --- [11/29/2023, 1:19:56 AM] Loading 2 platforms... [11/29/2023, 1:19:56 AM] [CommonMiLightHub] Initializing MiLightHubPlatform platform... [11/29/2023, 1:19:56 AM] [CommonMiLightHub] Initializing child bridge 0E:CE:3A:5C:62:B8 Setup Payload: X-HM://0024BI53ZQQZD Enter this code with your HomeKit app on your iOS device to pair with Homebridge:
┌────────────┐ │ 513-48-831 │
└────────────┘
[11/29/2023, 1:19:56 AM] Homebridge v1.7.0 (HAP v0.11.1) (Homebridge AD6C) is running on port 51779. [11/29/2023, 1:19:57 AM] [CommonMiLightHub] Launched child bridge with PID 10496 [11/29/2023, 1:19:57 AM] Registering platform 'homebridge-milighthub-platform.MiLightHubPlatform' [11/29/2023, 1:19:57 AM] [CommonMiLightHub] Loaded homebridge-milighthub-platform v1.0.0 child bridge successfully [11/29/2023, 1:19:57 AM] Loaded 0 cached accessories from cachedAccessories.0ECE3A5C62B8. [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: DidFinishLaunching [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: Querying /settings [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: GET: /settings [11/29/2023, 1:19:57 AM] Homebridge v1.7.0 (HAP v0.11.1) (CommonMiLightHub) is running on port 48640. [11/29/2023, 1:19:57 AM] [CommonMiLightHub] Using MQTT server at debhb [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: Connected to MQTT server [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: Registering for MQTT messages on status/milighthub/CommonMiLightHub/+/+/+ [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/4 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/1 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/8 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/2 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/5 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/3 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/0 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/7 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x1/fut089/6 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x2/rgb_cct/1 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x2/rgb_cct/2 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x2/fut089/0 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x2/rgbw/2 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x3/rgb_cct/1 [11/29/2023, 1:19:57 AM] [CommonMiLightHub] DEBUG: MQTT Message: status/milighthub/CommonMiLightHub/0x3/fut089/0 [11/29/2023, 1:20:07 AM] [CommonMiLightHub] DEBUG: Querying /settings [11/29/2023, 1:20:07 AM] [CommonMiLightHub] DEBUG: GET: /settings

[normen]

Hm, thanks, can you post the config (without passwords) as well.

[normen]

Might also have to do with the ESP config, it stores the config in eeprom so even if you changed the software it might have kept some settings

[turbidWaters]

Could be. I have two hubs, both the hubs are behaving the same though. Now, I just made a new hub and restored a backup from an existing one. Same results. I even created new aliases. Still they aren't appearing in HomeKit. How can I debug this?

[turbidWaters]

I flashed a fresh nodemcu with ver 1.10.9 and created new aliases. It's working now. However I am facing another issue. Adjusting the brightness from the home app slider doesn't work, as expected. Sometimes the slider stays where it's dragged but doesn't actually adjust the light bulb. Sometimes it comes back to a previous position. However hitting the bottom of the slider turns off the bulb and hitting the top (only at times) takes it to 100.

@normen Thanks for the tip about esp retaining the data

[turbidWaters]

Ok, I see if I update the firmware from 1.10.9 to 1.11.2 then it deletes all the aliases from homebridge.

I guess there are some fundamental differences between the two. Even the backup file for 1.10.9 is a .json while it's a .bin for 1.11.2

Perhaps I haven't read release notes properly. Will do that tomorrow. For now im glad I got the lights back into hm. Will have to add back all the automations and button actions too tomorrow.

[turbidWaters]

Further update. Today I flashed a fresh milight-hub and added it to the plugin in a fresh homebridge install.

On firmware greater than 1.10.9 the plugin is not detecting any aliases. If aliases were added in HomeKit prior to the update to 1.11.2 then the firmware update to 1.11.2 deletes the lights in HomeKit on sync.

I hope I'm doing something wrong here but I'm not able to put a finger on it. My guess is that it's something to do with the issue "paged aliases #801".

So I have reverted back to 1.10.9 on my milight hubs and I have a spare one for any further testing.

[normen]

Hey, thanks for investigating, thats very valuable info and should help getting this to work again (as well as providing a workaround for other users for now - downgrade the milight hub). I don't know when I get around to really looking into this though, lets hope its a small fix.

Edit: Putting the original breaking PR here for reference: https://github.com/sidoh/esp8266_milight_hub/pull/801

Edit2: Looks like we have to get the settings, check the version, get the new /aliases rest endpoint in case its above 0.10.9 and then page through that in case its more than one page /sigh 🙄... (Actually just the existence of the old array should be enough of a version check)

[normen]

I published a 1.0.1-beta2 with a possible quick fix (yes, lower than the last beta because it has none of the adaptive lighting changes) - can you try if that one fixes the issue on the latest milight hub?

Edit: Also lets move the discussion of this problem here: https://github.com/normen/homebridge-milighthub-platform/issues/16

[turbidWaters]

Thanks for this quick response!

I can test. Can you please guide as to how to get this beta installed? And if you have a list of any test cases, please do share. I will anyways test a few scenarios once I get around installing 1.0.1 beta1

[normen]

Thanks for this quick response!

I can test. Can you please guide as to how to get this beta installed? And if you have a list of any test cases, please do share. I will anyways test a few scenarios once I get around installing 1.0.1 beta1

npm install -g homebridge-milighthub-platform@1.0.1-beta2

It should simply find the aliases again, nothing more to test. I don't know if the check for the new hubs works, so running in debug mode for a log would be nice.

[turbidWaters]

Thank you Im assuming you meant beta1 not beta2 and going ahead

[turbidWaters]

I'm getting this error when I add a new alias:

12/1/2023, 5:41:07 AM] [Homebridge UI] Homebridge log truncated by hbuser. [12/1/2023, 5:41:12 AM] [OLDMiLightHubPlatform] DEBUG: Querying /settings [12/1/2023, 5:41:12 AM] [OLDMiLightHubPlatform] DEBUG: GET: /settings [12/1/2023, 5:41:12 AM] [OLDMiLightHubPlatform] DEBUG: GET: /aliases [12/1/2023, 5:41:22 AM] [OLDMiLightHubPlatform] DEBUG: Querying /settings [12/1/2023, 5:41:22 AM] [OLDMiLightHubPlatform] DEBUG: GET: /settings [12/1/2023, 5:41:22 AM] [OLDMiLightHubPlatform] DEBUG: GET: /aliases TypeError: Cannot read properties of undefined (reading 'toString') at /var/lib/homebridge/node_modules/homebridge-milighthub-platform/index.js:138:168 at processTicksAndRejections (node:internal/process/task_queues:95:5) [12/1/2023, 5:41:22 AM] [OLDMiLightHubPlatform] Child bridge process ended [12/1/2023, 5:41:22 AM] [OLDMiLightHubPlatform] Process Ended. Code: 1, Signal: null

Firmware - 1.11.2 nodemcuv2 Plugin - homebridge-milighthub-platform v1.0.1-beta1

[normen]

No I meant beta2, I made a small fix already. However, now its beta3, can you test that please, there should be some more logging output about what aliases are received. Step 1 already seemed to work, it reads from the new aliases list. :)

[normen]

The issue with milight-hub v 1.11+ should be fixed in version 1.0.1 which is now on NPM. That still has nothing to do with adaptive lighting though, that branch doesn't have the changes yet :)