Logon screen timeout

[eonnet]

I'm on higher 21256

screenshot from chrome

[toggledbits]

It's because you have the changes operator selected. Change is instantaneous. An infinitely small amount of time after, the value is the same as what it just changed to, so changes is no longer true.

[eonnet]

What should i choose, what i'm trying to achieve is that when dimmer level changes and stays for example 35% for 3 seconds pass the dimmer level to a http call

[eonnet]

This post is deleted!

[toggledbits]

@eonnet said in Sustained condition is missing from MSR:

What should i choose, what i'm trying to achieve is that when dimmer level changes and stays for example 35% for 3 seconds pass the dimmer level to a http call

So, you want to do something when it has not changed for 3 seconds... think about how to structure that.

[Elcid]

@eonnet, Dam I update yesterday morning, new update that evening lol.

So up date to latest 56 and the sustained is still there and set to changes.

[eonnet]

@toggledbits said in Sustained condition is missing from MSR:

So, you want to do something when it has not changed for 3 seconds... think about how to structure that.

What i'm trying to do is to import ezlo dimmer in vera and have 2 way communication. If i do action on change without sustain sometimes it goes in a loop, so i want to make sure that dimmer has reached the level and stayed on that level for couple of seconds before i send the information back to vera. In vera i'm using your virtual dimmer. But for some reason when you turn on ezlo the dimmers make a short stop for couple of hundred milliseconds somewhere in between causes a race between the two dimmers.

[toggledbits]

I understand. To repeat, you want to do something when the value has not changed for a couple of seconds. Think about how to structure that.

[Elcid]

I dont think you need sustained.
You can set ezlo dimmer > 0.
Then set a expression to grab the ezlo dimmer level.
Then in set reaction, set vera dimmer to ${{name_of_expression}},
and reset reaction set to vera dimmer to 0.

You can make the same rule in reverse for vera dimmer

Then if you turn on vera dimmer it will turn on ezlo, and if you turn of ezlo it will turn off vera.

Needs a bit more thought to follow dimming changes after that.

[toggledbits]

@toggledbits said in Sustained condition is missing from MSR:

Think about how to structure that.

Here's the general structure of the conditions. Notice there's a group with "NOT" set to invert the sense of changes in the only condition the group has.

There are condition options applied to the group (not the changes condition):

When this group goes true, it means the dimmer has not changed for 3 seconds, the rule sets, and your Set reaction should copy the value to the other device.

[Elcid]

This seems to work and stops the race condition, and there is no delay in reaponse from other device.
biuld the same rule for the other device. Both set the global expression dimming to 1 to stop the other reacting , and feeding back

[eonnet]

Thanks both @toggledbits and @Elcid. I will use the @toggledbits idea because i dont need instantaneous feedback from ezlo.

Did anybody tested ezlo with higher number of devices how it compares with Vera? i have around 50 zwave devices and when i turn on scene with multiple devices sometimes it takes 1 minute scene to complete, i get a lot of retries especially with the dimmers, the zwave network is good because the 50 devices are in 60 sqm apartment on 2 floors so 50 devices make excellent mesh 90% of the devices are mains powered.

My idea is to use Ezlo hub for zwave devices and transfer them to Control4 via HTTP calls. that is why i will use @toggledbits solution because ezlo -> Control4 is just for feedback i dont need instantaneous response, from C4 -> Ezlo i will use direct http call so that will be instant