Reactor-Editor / Reactor-ui-Status Errors

[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.