[Reactor] Bug when sending MQTT boolean payloads

[cw-kid]

Just noticed I have two devices in the Entities list with the same name coming from the same controller (Ezlo Plus) and I am not sure why this is ?

The device in question is called "Cabinet Light Strip (Hue)"

Using the Ezlo online API tool I did a hub.devices.list query and searching the output I can only find one device called "Cabinet Light Strip (Hue)"

This is the entry for ir, from the API Tool.

{
        "_id": "6300d20b123e4318ec576f13",
        "batteryPowered": false,
        "category": "dimmable_light",
        "deviceTypeId": "ezlo.philips_hue_lamp",
        "gatewayId": "6300d1d5123e4318ec576e99",
        "info": {
          "id": "1",
          "parent_device_id": "6300d1fb123e4318ec576e9a"
        },
        "name": "Cabinet Light Strip (Hue)",
        "parentDeviceId": "",
        "persistent": false,
        "reachable": true,
        "ready": true,
        "roomId": "62bec965123e43124ea13972",
        "security": "no",
        "status": "idle",
        "subcategory": "dimmable_bulb",
        "type": "light.controller"
    

This is what I see in the Entities list in MSR

Entry #1 -

color_temperature.value=null
dimming.level=0.64
dimming.step=0.1
power_switch.state=false
rgb_color.blue=125
rgb_color.green=141
rgb_color.red=129
x_ezlo_device.battery_powered=false
x_ezlo_device.category="dimmable_light"
x_ezlo_device.manufacturer=null
x_ezlo_device.model=null
x_ezlo_device.parent="62baddaf123e4347bb149fec"
x_ezlo_device.reachable=true
x_ezlo_device.ready=true
x_ezlo_device.room="62bec965123e43124ea13972"
x_ezlo_device.status="idle"
x_ezlo_device.subcategory="dimmable_bulb"
x_ezlo_device.type_id="ezlo.philips_hue_lamp"
x_ezlo_item.alert="select"
x_ezlo_item.dimmer=64
x_ezlo_item.dimmer_down=0
x_ezlo_item.dimmer_stop=0
x_ezlo_item.dimmer_up=0
x_ezlo_item.effect="none"
x_ezlo_item.hue=37777
x_ezlo_item.rgbcolor={"blue":125,"green":141,"red":129}
x_ezlo_item.rgbcolor_down=0
x_ezlo_item.rgbcolor_stop=0
x_ezlo_item.rgbcolor_up=0
x_ezlo_item.saturation=107
x_ezlo_item.switch=false
x_ezlo_object.id="62bade0a123e4347bb14a040"
Capabilities: color_temperature, dimming, power_switch, rgb_color, x_ezlo_device, x_ezlo_item, x_ezlo_object
Actions: color_temperature.set, dimming.down, dimming.set, dimming.up, power_switch.off, power_switch.on, power_switch.set, rgb_color.set, rgb_color.set_rgb, x_ezlo_device.device_check, x_ezlo_device.set_item_value, x_ezlo_device.set_name, x_ezlo_device.set_room, x_ezlo_device.status_check

Enrty #2 -

color_temperature.value=null
dimming.level=0
dimming.step=0.1
power_switch.state=false
rgb_color.blue=0
rgb_color.green=0
rgb_color.red=0
x_ezlo_device.battery_powered=false
x_ezlo_device.category="dimmable_light"
x_ezlo_device.manufacturer=null
x_ezlo_device.model=null
x_ezlo_device.parent=""
x_ezlo_device.reachable=true
x_ezlo_device.ready=true
x_ezlo_device.room="62bec965123e43124ea13972"
x_ezlo_device.status="idle"
x_ezlo_device.subcategory="dimmable_bulb"
x_ezlo_device.type_id="ezlo.philips_hue_lamp"
x_ezlo_item.alert="lselect"
x_ezlo_item.dimmer=0
x_ezlo_item.dimmer_down=0
x_ezlo_item.dimmer_stop=0
x_ezlo_item.dimmer_up=0
x_ezlo_item.effect="none"
x_ezlo_item.hue=61509
x_ezlo_item.rgbcolor={"blue":0,"green":0,"red":0}
x_ezlo_item.rgbcolor_down=0
x_ezlo_item.rgbcolor_stop=0
x_ezlo_item.rgbcolor_up=0
x_ezlo_item.saturation=227
x_ezlo_item.switch=false
x_ezlo_object.id="6300d20b123e4318ec576f13"
Capabilities: color_temperature, dimming, power_switch, rgb_color, x_ezlo_device, x_ezlo_item, x_ezlo_object
Actions: color_temperature.set, dimming.down, dimming.set, dimming.up, power_switch.off, power_switch.on, power_switch.set, rgb_color.set, rgb_color.set_rgb, x_ezlo_device.device_check, x_ezlo_device.set_item_value, x_ezlo_device.set_name, x_ezlo_device.set_room, x_ezlo_device.status_check

x_ezlo_object.id="62bade0a123e4347bb14a040"

and

x_ezlo_object.id="6300d20b123e4318ec576f13"

The one ending in 6f13 is the one I see listed in the Ezlo Online API Tool output.

If I search the output for "62bade0a123e4347bb14a040" its not found at all.

So I don't know what this other duplicated device is or where its come from.

These are newish Philips Hue plugin devices from Ezlo's own Hue plugin.

So then I searched the Entities list for another "Hue" device called "TV Backlight (Hue)" and I have two of those listed also.

x_ezlo_object.id="62bade08123e4347bb14a031"

and

x_ezlo_object.id="6300d20d123e4318ec576f21"

Searching again the data output from the Ezlo API tool for these two device ID's I only see one of them. The one ending in 6f21.

{
        "_id": "6300d20d123e4318ec576f21",
        "batteryPowered": false,
        "category": "dimmable_light",
        "deviceTypeId": "ezlo.philips_hue_lamp",
        "gatewayId": "6300d1d5123e4318ec576e99",
        "info": {
          "id": "2",
          "parent_device_id": "6300d1fb123e4318ec576e9a"
        },
        "name": "TV Backlight (Hue)",
        "parentDeviceId": "",
        "persistent": false,
        "reachable": true,
        "ready": true,
        "roomId": "62bec965123e43124ea13972",
        "security": "no",
        "status": "idle",
        "subcategory": "dimmable_bulb",
        "type": "light.controller"

Maybe their new Philips Hue plugin is doing something funky? But I cannot see these duplicated device ID's listed in the hub.device.list API query and I do not see two of these Hue devices in their web GUI with the same names either.

So bit confused now as to what is happening.

[toggledbits]

Since they have different IDs, it stands to reason that 62baddaf123e4347bb149fec existed at some point. Since EzloController doesn't yet do deadmarking (that's coming in this weekend's build as I said in your other thread), it would not yet be marked as a missing entity. Why the ID changed is up to Ezlo's firmware and/or your actions. Reactor just acts on what it gets.

[cw-kid]

Yeah like you say the other ID / device must of existing at one point or MSR would not of imported it.

Actually thinking about it more now, I remember I had to install and setup their Hue plugin twice, as they have no plugin upgrade process in place yet, for newer version numbers of the same plugin, they need to sort that out !

So the first version of the Hue plugin I had to remove and this deleted all the imported Hue devices off the Ezlo controller.

I then had to install their newer version of their Hue plugin and pair it with the bridge again, thus importing all the devices again with new ID's presumably.

So I think that is probably why I now have duplicated Ezlo Hue plugin devices in MSR.

OK looking forward to your new build with dead marking.

Thanks

[cw-kid]

@toggledbits

Patrick may I ask another question here please?

On the Ezlo Hue Plugin devices in their own rules engine "Meshbots" there is an "alert" option that makes the lights blink.

I don't see this "alerts" option in an MSR rules action however.

I guess its similar to the Vera controller plugins? Where sometimes you had to add support for that particular plugins functions is that correct?

When I select a Hue Plugin device in their Meshbot Action these are the options I see:

Thanks.

[toggledbits]

I PM'd you a like to upload your ezlo_inventory.json file (in logs). I can see there if anything is published that would lead to that action, or if it's "special knowledge" (i.e. kludge) in Ezlo's Reactor clone.

[cw-kid]

OK thanks I uploaded the requested file. All my rules are still in MSR so could be handy if I could use this blink feature on the Hue lights, but not mission critical.

I did look under the AltHue plugin on the Vera Plus but could not find "alert" and a forum post I read suggested it was never added by that dev.

[cw-kid]

@toggledbits

Damn looks like I won't be able to upgrade MSR anytime soon. I can no longer login to the Debian box MSR runs on for some reason. Not sure what happened and went wrong.

https://smarthome.community/topic/1015/help-please-cannot-login-to-debian-msr-box

EDIT: I've managed to fix my login problems now.

[cw-kid]

Couple of nice updates there for me !

VeraController: Ensure x_vera_device.failed and .configured are null if Vera fails to provide state for these values.
EzloController: Dead-marking and automatic removal (after delay) of entities for Ezlo devices/rooms/scenes that no longer exist (functional parity with other hub Controller objects).

I am going to update MSR now.

Thanks

[cw-kid]

Seems to be working and detecting dead devices now from the Ezlo Plus controller.

So after 24 hours it would auto remove them from MSR right.

Or I can just manually remove them now.

Cheers

[toggledbits]

@cw-kid said in Ezlo Plus - Philips Hue devices duplicates in MSR:

So after 24 hours it would auto remove them from MSR right.
Or I can just manually remove them now.

Yes.

For the alert, use the x_ezlo_device.set_item_value action with the item name and desired value:

[cw-kid]

@toggledbits

Even better thanks. I will give the alert a try.

[cw-kid]

The "alert" works I just tested it.

Thanks.

[toggledbits]

A bit of background here. Unlike Vera, which had actions separate from values (state variables) to make things happen, the Ezlo firmware uses the Z-Wave approach of modifying values as a way of stimulating action. It's not surprising they would use this model, as Z-Wave is the philosophical core of their system. There is therefore no need for separate actions, which on Vera was the byproduct of attempting to implement UPnP (and didn't quite get there).

Since actions on Ezlo are actually just item value changes, using x_ezlo_device.set_item_value, you can set the value of any item associated with a device, even if the value isn't mapped to one of Reactor's capabilities or attributes, and whatever action that may stimulate either in the firmware or on the device itself will occur.

[cw-kid]

@toggledbits

Thanks for the additional information, that is certainly good to know about.