Quick questions b4 releasing an Hass Blueprint for Milight

[soif]

First congratulations for this amazing project: I (and I shoud not be alone) was looking, since a very long time, for a way to control RGB lights (including color and brightess) from hardware remotes or switches. Thanks to your project, this now a breeze! 👍

I'm gonna soon release a BluePrint to ease controlling ANY (RGB) light , using milight remote(s). It is almost finished, but I miss some information to finish it:

1. device_id (in the MQTT topic): is this a unique ID ? I mean:

• 2 remotes of the same model will each publish a unique ID (device_id=Serial Number ID)?
• 2 remotes of the same model will each publish the same ID (device_id=Model ID) ?

.

2. "Speed Up" & "Speed Down" buttons: I can see them in the sniffer, but they are currently NOT present in the published state MQTT topic. I saw in an old issue, that someone asked it to be implemented in the MQTT payload, under "command", and that you've released it in v1.41. Is this a bug? Can we get it again? (tested in version 1.13.0)

.

3. Sometimes (i can not systematically reproduce it), the brightness parameter is not included in the MQTT payload. Is this a bug or a feature?

---

BTW: (Using default config) I get all MQTT message under a /milight/state/ topic, and not under a /milight/states/ topic. I guess this has changed in a recent version. Would you mind if I post a PR to fix all these texts ?

Also, I can confirm that the Milight B05 remote (wall switch) works like a charms with your software. Would you mind if I include it the supported device table ?

[sidoh]

Hello! Glad you've found it useful.

Two remotes will have different Device IDs -- it's something like a serial number, but it's only two bytes.

I'd need to check, but I don't think speed was ever in the state topic. It will show up under the updates topic when the button is pressed, but there's currently no tracking of the mode speed.

I'm guessing that happens when the brightness state is unknown. Bulbs don't advertise state -- the hub only knows state that it sets (or overhears from other devices).

There was actually never a default topic prior to 1.13 (see this change). I'm open to changing the default if it's breaking things, but would rather not touch it otherwise.

Great! Yes feel free to add it :)

[soif]

Thank you fo the fast answer 😎

Two remotes will have different Device IDs -- it's something like a serial number, but it's only two bytes.

Thanks for the confirmation! 👍

I'd need to check, but I don't think speed was ever in the state topic. It will show up under the updates topic when the button is pressed, but there's currently no tracking of the mode speed.

I never get any "update" topic under milight MQTT topic:

Normal? Bug? 😮
(BTW I font have any Milight Bulb, only one remote.)

I'm guessing that happens when the brightness state is unknown. Bulbs don't advertise state -- the hub only knows state that it sets (or overhears from other devices).

Fine, I've just included a workaround in the HA bluePrint, to handle payloads without brightness

There was actually never a default topic prior to 1.13 (see this change). I'm open to changing the default if it's breaking things, but would rather not touch it otherwise.

I was not suggesting to change the default topic, but rather that often in the Wiki (ie Domoticz or HomeAssistant ) you mention a milight/states/.. state topic as example, which is not the same as the current default topic...

Great! Yes feel free to add it :)

Will do!

[sidoh]

The updates topic is disabled by default because it's pretty noisy (messages are 1:1 with remote actions), but it might actually be what you want for your project. If you swap to a custom MQTT config you can enable it. some docs in the README here.

Ah gotcha, yeah that's a good idea!

[soif]

The updates topic is disabled by default

Thanks fo pointing me to this.😎
IMHO it's absolutely not clear in the Readme, nor in the MQTT setting page.

Might I suggest :

• to enhance the sentence under the "Preset" to something like (sorry for my english, i'm not english native):
  "Customize the MQTT topic patterns. Use the "Default" preset for standard configurations. (Note that the Mqtt Update Topic is not included in the default preset)."
  and/or:

• Change the MQTT topic title to "Mqtt Update Topic Pattern (not included in Default preset)"

• You might also have the JS automatically fill the field with "milight/update/:device_id/:device_type/:group_id" when the custom preset is selected.

because it's pretty noisy (messages are 1:1 with remote actions)

is it really that noisy ? Because including it in the default preset, would certainly be the simpliest enhancement 😎

Ah gotcha, yeah that's a good idea!

Would you mind if if update the readme + wiki, to change "/states/" to "/state/" eveywhere ?

[sidoh]

I hid a lot of this in the UI because it's confusing and the updates pattern is very rarely useful. Open to any way to make it more clear (adding some language seems like a good idea), but definitely want to err on the side of keeping the default experience simpler.

Yeah, it's really noisy for some use-cases -- anything that involves even moderately high throughput and has no value (most platforms care about the cumulative state, not the delta)

That'd be great! Thanks for all of the suggestions.

[soif]

Here is the Readme PR.
I intended to also update the Wiki, but i saw that you was faster 👍

[soif]

Here is the blueprint:

https://github.com/soif/hass_blueprints/tree/master/blueprints/automation/milight_remote

BTW: To make it easier for "non geek" people, it would be usefull, if you coud also display the device ID hexadecimal value (as published in the MQTT topic), next to the decimal value, in the event details column.