MiLight Status Feedback with NodeMCU!

[frelev]

I just noticed the same thing (adding to group 2 and it didn´t work to change) I then selected group “all” and it started to work.
I could after this select group 2 again and it started to work as expected. Don´t know if this was just a coincidence though.

BTW, how do you add more groups than the default 4?

[fvargasfrank (Frank Vargas)]

No luck I try all the suggestion, I also try RGB but not working, When I first power this thing ON it work then it rebooted and I had to add it again and it never works after. Are there no logs?

[fvargasfrank (Frank Vargas)]

I try that but it did not work, im suing RGBWW

[sidoh (Chris Mullins)]

The logs are printed to a serial terminal. You can enable verbose logging by compiling the firmware with the DEBUG_PRINTF flag. It sounds like either you’re using a different RF config (RGB, RGBW, etc.) or your NRF is faulty or has loose connections. My setup’s stability improved dramatically when I switched to soldered connections.

[sidoh (Chris Mullins)]

You can set the device ID to whatever you want. You can only have four groups for a single device ID. That’s unfortunately a limitation of the underlying RF protocol.

[frelev]

Ah ok! Then maybe I misunderstood the feature with multiple groups.
So far I have only spoofed my old bridge which has 4 groups with 3 lights each.
This seems to work Ok but I would like to control each bulb separately, ie create 12 groups.

Can I accomplish this with this version?

[sidoh (Chris Mullins)]

Certainly possible. Not exactly painless, but doable. You have to pair your bulbs with different device IDs. Pair bulbs 1-4 with groups 1-4 of device 0x0001, bulbs 5-8 with groups 1-4 of device 0x0002, etc.

[frelev]

Thank you for clarifying this.
Should then these new device id’s be added as I UDP Gateways with different ports so they can easily be included into HASS?

[sidoh (Chris Mullins)]

Yeah, that should work.

Alternatively, you can use a light.mqtt_json component. MQTT is more reliable because it’s over TCP, and since it’s over a pre-established connection, there’s not much of a latency cost. It’s also a little more intuitive because you don’t need to map device IDs to ports.

My config looks like this:

- name: "Office Lamp"
  command_topic: milight/0x0001/rgb_cct/1
  state_topic: milight/updates/0x0001/rgb_cct/1
  <<: &MILIGHT_PARAMS
    platform: mqtt_json
    color_temp: true
    rgb: true
    brightness: true
- name: "Livingroom Lamp"
  command_topic: milight/0x0001/rgb_cct/2
  state_topic: milight/updates/0x0001/rgb_cct/2
  <<: *MILIGHT_PARAMS
- name: "Bedroom Lamp"
  command_topic: milight/0x0001/rgb_cct/3
  state_topic: milight/updates/0x0001/rgb_cct/3
  <<: *MILIGHT_PARAMS
- name: "Nightstand Lamps"
  command_topic: milight/0x0002/rgbw/0
  state_topic: milight/updates/0x0002/rgbw/+
  <<: *MILIGHT_PARAMS

[fvargasfrank (Frank Vargas)]

IF the NRF was faulty would i still be able to sniff the remote code ?

[sidoh (Chris Mullins)]

Potentially, yes. I’d double-check the connections first.

[fvargasfrank (Frank Vargas)]

thanks, I will double check everything.

[arielpod (Ariel)]

Hi! I’ve been using this for a couple of months now, it’s working perfectly. The only thing problem I encounter is this:
Whenever there is lack of electricity, when it comes back, NodeMCU won’t connect to the WiFi. I have to reconnect it manually. I don’t know where’s the problem, I guess that after the power goes on, the ESP is faster than the router, so it’s searching for a router to connect to, and it doesn’t exist (yet). Is there a way to change it in settings? Or add something in the code so that it waits a bit longer after being turned on?

[Tanto]

Hey! I have a problem I can’t seem to fix. I can control the lights perfectly fine, but somehow my HASS refuses to update the state. it also shows the following errors:

Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 49, in uvloop.loop.Handle._run (uvloop/loop.c:48426)
  File "/usr/lib/python3.6/site-packages/homeassistant/components/mqtt/__init__.py", line 232, in async_mqtt_topic_subscriber
    hass.async_run_job(msg_callback, dp_topic, payload, dp_qos)
  File "/usr/lib/python3.6/site-packages/homeassistant/core.py", line 253, in async_run_job
    target(*args)
  File "/usr/lib/python3.6/site-packages/homeassistant/components/light/mqtt_json.py", line 169, in state_received
    if values['state'] == 'ON':
KeyError: 'state'

My set up looks like:

    name: livingroomlamp1
    state_topic: "milight/updates/0x1/rgbw/1"
    command_topic: "milight/command/0x1/rgbw/1"   
    brightness: true
    rgb: true
    flash: true

at the mqtt_topic_pattern I got:
milight/command/:device_id/:device_type/:group_id
and at mqtt_update_topic_pattern:
milight/updates/:device_id/:device_type/:group_id

[garmck]

Has anyone managed to get Night Mode working within Home Assistant?

[Petrica (PetricaM)]

Hi @garmck,

There is no support in the light component for night mode however it can be easily done with a script (just use your own light id topic). Alternatively, the night mode could be setup as effect and then use an automation to forward it to the light (but is going to flicker when state changes). Do you need help for the setup?

- service: mqtt.publish
  data_template:
    topic: 'milight_gw/:device_id/:device_type/:group_id'
    payload_template: '{ "command": "night_mode" }'

[garmck]

@Petrica thanks, i managed to get it working with the following:

  - platform: mqtt_template
    name: Night Light
    state_topic: "milight/update/0x1/rgbw/1"
    command_topic: "milight/command/0x1/rgbw/1"
    command_off_template: '{"state":"off"}'
    command_on_template: '{"command":"night_mode"}'
    state_template: '{value_json.state}'

This works great, but the state_template is not working as I believe its expecting true/false.
I’ve tried:

    state_template: >
      {% if ('value_json.bulb_mode', 'night') %}
      true
      {% else %}
      false
      {% endif %}

But this doesn’t work, I’ll keep trying to figure out how to get bulb mode - night to be true.

[Sthope]

Hello @Petrica,
After reading your I post just noticed the effect’s option in MQTT json, can you show me an example how to set it up?

After enabling effect and effect_list with a listed name for the effects I use automations to forward those entries to publish the right effect topic?

[Petrica (PetricaM)]

Hi @garmck

Night mode is stateless thus it won’t publish it’s updates. As you are only trying to turn night mode on and off, the easiest way would be with a switch:

- platform: mqtt
  name: "Night light"
  state_topic: "milight/update/0x1/rgbw/1"
  command_topic: "milight/command/0x1/rgbw/1"
  payload_on: '{"command":"night_mode"}'
  payload_off: '{"state":"off"}'
  optimistic: true
  qos: 0
  retain: true

I have my lights setup as mqtt_json (except that there are FUT103 and FUT014 with rgb_cct profile) and it allows for all sort of magical things . However, when in night mode, the light shows as off thus, with automation I can include conditions that either light or the night mode (switch) for a specific light is on.

- platform: mqtt_json
  name: "Light 1"
  state_topic: 'milight_gw/state/0x1/rgb_cct/1'
  command_topic: 'milight_gw/0x1/rgb_cct/1'
  brightness: true
  rgb: true
  color_temp: true
  effect: true
  effect_list: [ 0, 1, 2, 3, 4, 5, 6, 7, 8]
  optimistic: false
  qos: 0
  xy: false
  retain: true

[Petrica (PetricaM)]

Hi @Sthope,

MiLight supports 9 effects however they are called “mode”. With the setup for the light included in the message above, the automation would be:
automation

- alias: Effect2Mode
  initial_state: True
  trigger:
    - platform: mqtt
      topic: 'milight_gw/+/rgb_cct/+'
  condition: 
    condition: template
    value_template: '{{ "effect" in trigger.payload }}'  
  action:
    - service: mqtt.publish
      data_template:
        topic: "milight_gw/{{ trigger.topic.split('/')[-3] }}/rgb_cct/{{ trigger.topic.split('/')[3] }}"
        payload_template: '{ "mode": {{ trigger.payload_json.effect }} }'

The topics used in the webpage are as following:

mqtt_topic_pattern:
milight_gw/:device_id/:device_type/:group_id

mqtt_update_topic_pattern:
milight_gw/update/:device_id/:device_type/:group_id

mqtt_state_topic_pattern:
milight_gw/state/:device_id/:device_type/:group_id

In automation/script the action part that calls for effects would be:

- service: light.turn_on
  data_template:
    entity_id: light.light_id
    effect: any from 0 to 9

I use scripts (3 categories, for day, sunset and night) that are called from automations as the scenes do not allow for templating. This way, lights can be turned on with dimming and either white light (color temp) or color leds (providing separate r, g and b values).

Color names can be used (any color from CSS Color Module Level 3) with “color_name: xx”. I’ve made an input list with all of them (however some would resolve to white light) and use the option color_name: ‘{{ states.input_select.scenes_color_name.state}}’

Random colors can be used with rgb_color: [‘{{range(1,255)|random}}’, ‘{{range(1,255)|random}}’, ‘{{range(1,255)|random}}’]

MiLight platform doesn’t support transition but can be easily done with a script:

Creating a alarm clock

Hi, Based on this post Phillips Hue Wakeup Light with fade-in I’ve made several adjustments to work with my lights (as only Hue and Lifx platforms accept transition). I use MiLight but served by a NodeMCU running this project https://github.com/sidoh/esp8266_milight_hub, not the ibox. Basically you can have as many groups as you want and loose the ibox. The performance is much better and on the gateway can be created as many lights and groups as you want (instead of buying an ibox for each gro…