Suggestion for device conditions

[randy]

Hello everyone. Rich invited me to look at the Alpha and to offer suggestions as development progresses. While it is in the early stages, I likely will have little to offer as I am not a developer or programmer, but I do pay attention to how it works.

I like the new responsive design. Here I am using Chrome on a desktop, but it behaves the same with Edge or Explorer. I haven't looked at Safari yet. There is a minor problem, but I suspect it may affect other items as development progresses.

Here it is at minimum ~ 475 pixel width all looks good.



as it expands to the next size ~ 700 pixel width all is still well



at the next jump to ~ 930 pixels the And IF becomes corrupted




At maximum ~1120 pixel width the problem remains.



One little nit to pick that has caused confusion on HS3 is a device's condition. I notice they are carried over into HS4



The phrase "This device had its set" doesn't belong. It confuses users who believe that it is predicated on having just been set.

I would suggest:

• This device has been/for at least...
• This device has a value equal to...
• This device has a value not equal to...
• This device has a value greater than...
• This device has a value less than...

Also the word "Trigger" should be replaced with "Condition" on the Conditions


I expect my comments to mostly relate to look and feel, usability, ambiguity, confusion, etc. It is doubtful I will have much to offer from a dev perspective.

I am trying to keep up with the discussions.

[rjh]

Good information, and I have seen the corruption on the select list, still working on a fix for that.

I will look at adding the naming changes, seems to make sense.

[dcorsus]

rjh JLDubz

As far as I can tell, I can create an AbstractTriggerType and override the "CanBeCondition" and set it to true and now this object can be used as Trigger AND Condition.
Is there an option to ONLY use it as a condition?

I have triggers such as: track changed, status changed ....
and conditions such as isPlaying, hasTrack,

I tried to create two instances of AbstractTriggerType, one built around my triggers and the other around my conditions. The conditions now nicely show up when you select some condition BUT they still show when you are setting the initial trigger.

I had some users ask me in HS3 to fix this, and I think they suggested some trick. Is there a proper way to do this in HS4?

Thanks,

Dirk

[jvm]

Since you're looking into triggers / conditions, one that creates a problem is the sequence . . .

If (Dimmer #1's central scene device registers a single tap)
and (Dimmer #1's light device has a value of X (or less than X, greater than X, not equal to X, etc. etc.))
Then Do Action

This sequence has an unpredictable result depending on dimmer - in Z-Wave, a single tap means "last value" so when the trigger occurs, depending on the dimmer, the condition line might evaluate the value of X as it existed before the transition or it might be the post-transition value. I think this depends on whether the Dimmer first completes the transition, then reports its new value X followed by reporting the central scene value which causes the trigger, or if it reports the central scene value first, in which case, the Condition may be evaluated with the X value existing pre-transition. From observation, it seems my HomeSeer WD-100's with firmware 50.4 transition then report the new X then the central scene tap, so the condition is based on the "new" value, while other dimmers report the central scene, then transition, then follow by the new X value, so the condition is based on the "old" value X as the event doesn't wait for the new X.

I image there must be some way to at least warn the user when a device value condition follows a single-tap central scene trigger. Maybe even have a check box on the trigger that says "wait until new device value reported before continuing." It would be helpful to the user not to have to figure this out by trial / error / forum searching.