sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
939 stars 220 forks source link

[QUESTION] force read state of bulbs #732

Closed othmar52 closed 3 years ago

othmar52 commented 3 years ago

First of all - thank you all for this great project!
setting things up was dead easy and worked out of the box!

I want to use milight_hub and a MiBoxer-wall-panel and another application to control a few LED-panels.
trying to read the current state of a bulb (especially on/off) can be achieved via JSON response of GET http://<milight-hub-ip>/gateways/<id>/rgb_cct/[1-4]. This basically works!

But changing any state via the wall-panel (bypassing the milight hub web GUI) causes an incorrect state response from the request above.

Steps to reproduce

  1. turn anything on via webinterface of the milight hub
  2. response reads {"state":"ON",...
  3. turn it off via the MiBoxer-wall-panel
  4. response still reads {"state":"ON",... which does not reflect the actual state

So it seems that the milight hub always returns the state which has been changed via milight hub.

Is there any way to read the actual state of a bulb from another application?

Linkenelis commented 3 years ago

Yes, wall switch and MiLicht-hub both send their state to MQTT 0x02 is the MiLight-hub 0x2227 is my wall switch note groups on the wall switch are not in sync (they are paired differently), as the wall switch has only 4 groups... As you can see the switch is not used a lot, mostly everything goes automatic or by Harmony remote.

Schermafbeelding 2021-06-12 204330

Linkenelis commented 3 years ago

Oh and if you know the id of the wallswitch, you can read it the same way GET http://MiLight-hub_ip/gateways/0x02227/rgb_cct/2

so the wallswitch has a different "id".

sidoh commented 3 years ago

Hi @othmar52,

Milight don't track their own state. espMH ends around this by keeping track of what the state should be given the commands it has issued and has seen in listen mode.

If your device is paired with multiple remotes (e.g., espMH and a physical remote) with different device IDs, the state will drift. Even if it's using the same ID, drift is still possible because espMH can miss a command that a bulb receives (this should be rare).

The easiest way to keep espMH in sync with a physical remote is to have it use the same ID as the remote.

othmar52 commented 3 years ago

@Linkenelis thank you for those hints! I did not have MQTT in my setup but now i gave mosquitto a try.
You are right, now everything gets published to MQTT and i am able to implement something that returns the last state that has been fired.

@sidoh

The easiest way to keep espMH in sync with a physical remote is to have it use the same ID as the remote.

Thank you - this seems to work as well!