[Feature Request] Add support for transition time

[5iver]

[Feature Request] Add support for transition time

[cdjackson]

I will take a look at this soonish as I'll use this as an example of adding configuration into this binding...

[cdjackson]

This is implemented, but doesn't fully work due to the following issue (eclipse-archived/smarthome#4910). This appears to cause the wrong type to be passed into the handler which causes ClassCast exceptions.

[5iver]

Thank you! I had seen it available for my bulbs but did not test it. I'll wait now for the fix :). I could be remembering incorrectly, and haven't looked at the ST DTH to confirm, but I thought there was a separate OFF and ON transition time available in ST...

[cdjackson]

Yes - I think both are implemented. There are from memory 4 or 5 settings. The binding polls the device to see which ones it supports and then makes them available for configuration. Not all will probably work at the moment, but you should get all settings available if the bulb supports them - let me know, but be careful as the linked bug can render the thing unusable if you save the configuration!

…

On 13 Jan 2018, at 15:48, Scott Rushworth ***@***.***> wrote: Thank you! I had seen in available for my bulbs but did not test it. I'll wait now for the fix :). I could be remembering incorrectly, and haven't looked at the ST DTH to confirm, but I thought there was a separate OFF and ON transition time available in ST... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ3ukvT8YquqdbkatWWket8Uwk6Apks5tKNBogaJpZM4QuQOs>.

[5iver]

Hmmm... then I was probably remembering correctly. I only see one...

... so maybe there are more that these bulbs support but aren't showing up. I'm not going to touch it until there's a PR to resolve that issue (thanks for the warning)!

[cdjackson]

Hmmm... then I was probably remembering correctly. I only see one…

Yes - you need the newest HABmin, or a future PaperUI to see the others. This one is defined in the channel-type as it’s a function of the binding - the others are defined in the channel (i.e. by the binding) as they are functions of the device and the binding will only show the ones the binding supports. This consolidation of channel configuration is new in the past few days.

[5iver]

you need the newest HABmin

O sweet... you're working on Habmin?! Is this available in a recent snapshot?

[cdjackson]

Yes - it should be available now. It just fixes channel configuration issues and adds this change to request the channel config, rather than the channel-type configuration...

[5iver]

Very cool! Habmin 2.3.0.201801131507 from 2.3 snapshot 1181 shows this...

Looks like some are duplicated (GE Link bulb).

[5iver]

Chris, should there be duplicates here? I see two On/Off Transition Time and Off Transition Time (although this looks like the label may just need to be changed to Default On Level). I still see some in version 2.3.0.201802012251 ...

Also, is there any documentation on how/where the Default Move Rate is applied? I'll go look at the code, but others may wonder too. 😉

[cdjackson]

should there be duplicates here?

No. I've not looked at this at the moment as until the normalisation issue is resolved, changing these configurations breaks the system if they get saved as the wrong type. I don't want to mess around with this until the normalisation is resolved.

is there any documentation on how/where the Default Move Rate is applied?

It's only used for move commands, not set commands. Currently I don't think there is any support in the binding for this item type.

I'll go look at the code

You'd need to read the ZigBee docs I think - not the binding code. The binding is just setting this value in the device.

[weakfl]

Chris, did you have a chance to verify that eclipse-archived/smarthome#4910 has been fixed by eclipse-archived/smarthome#5018 yet?

If not, could you please update this issue when the fix is available? I'd love to try this 😉

[cdjackson]

No - I didn’t get the chance as some other issues came up that I spent a lot of time looking at :( I will try and look at this today if I can.

[weakfl]

I will try and look at this today if I can.

Great, thanks!

[weakfl]

Chris, since #5018 has been merged meanwhile, is it now safe to change the transition time?

[cdjackson]

No - #160 seems to indicate the normalisation issue is still possible.

[weakfl]

I can now set "On/Off Transition Time" through PaperUI (dimmer channel), but it doesn't seem to have an impact.

I cannot set the "Default transition time", the setting doesn't get saved.

[5iver]

I've set the Off Transition Time and do not see any effect (and some of the labels are inaccurate too)...

          "configuration": {
            "properties": {
              "zigbee_levelcontrol_transitiontimeonoff": 0,
              "zigbee_levelcontrol_transitiontimeoff": 10000,
              "zigbee_levelcontrol_transitiontimedefault": 65535,
              "zigbee_levelcontrol_onlevel": 255,
              "zigbee_levelcontrol_defaultrate": 255,
              "zigbee_levelcontrol_transitiontimeon": 65535
            }
          },

Same for On/Off Transition Time

          "configuration": {
            "properties": {
              "zigbee_levelcontrol_transitiontimeonoff": 10000,
              "zigbee_levelcontrol_transitiontimeoff": 10000,
              "zigbee_levelcontrol_transitiontimedefault": 65535,
              "zigbee_levelcontrol_onlevel": 255,
              "zigbee_levelcontrol_defaultrate": 255,
              "zigbee_levelcontrol_transitiontimeon": 65535
            }
          },

[cdjackson]

I will look at this in a month or so. There are some labelling issues and this probably explains the apparent duplication.

[cdjackson]

Note that the latest binding should improve this issue - any feedback welcome.

[5iver]

I do not see an updated build yet on Cloudbees, but I'll test it when it gets there.

[cdjackson]

Sorry - I assumed it had built in the last 6 days, but it seems not. I’ve just kicked off a build now...

…

On 20 Apr 2018, at 21:52, Scott Rushworth ***@***.***> wrote: I do not see an updated build yet on Cloudbees, but I'll test it when it gets there. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQwDC5rBPJZhfeQEZyn-ETenzDktHks5tqkpzgaJpZM4QuQOs>.

[5iver]

Np... updated now and appears to be working well. I only see one issue, or maybe it's just my understanding of the settings. The first two parameters appear to be linked (changing one changes the other).

There is also a UI oddity where some parameters have dropdowns and some having up/down arrows. Also, it would be helpful to have the range of the settings in the label or description.

[cdjackson]

Glad it’s mostly working. There should only be 6 parameters - I’m not sure why the first one is duplicated. What is the actual device/channel that you’re showing? The UI difference is that some have an option, and therefore show the dropdown, while others don’t have options, so just show as an integer input.

[5iver]

This is the dimmer channel for a GE Link bulb.

[cdjackson]

Ok, I see where the duplication is coming from - I’ll create a PR to fix this once I work out the best option...

…

On 21 Apr 2018, at 15:33, Scott Rushworth ***@***.***> wrote: This is the dimmer channel for a GE Link bulb. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ11QcCToJ3z3qWfl9VEGb6grMOhmks5tq0NUgaJpZM4QuQOs>.

[cdjackson]

I've created #189 which should remove the duplication and then hopefully we can close this (finally ;) ).

[weakfl]

Works with my BJ relays, too. Thanks Chris.

[weakfl]

There seems to be an issue: after setting the 'Default Transition Time', the dimmer channel is now intermittently reporting a level of 100, although the relay is off.

[cdjackson]

If the dimmer is reporting this without any binding request etc, then it sounds like an issue with the dimmer? Something I think I’ve seen elsewhere is the dimmer can report a level even if the device is off - there is a separate issue about that I think, but I don’t think it’s related to this which is about configuring the device.

…

On 22 Apr 2018, at 13:55, weakfl ***@***.***> wrote: There seems to be an issue: after setting the 'Default Transition Time', the dimmer channel is now intermittently reporting a level of 100, although the relay is off. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ0gRBrDLtIwpu-tQAdFoEP3H8fZYks5trH3SgaJpZM4QuQOs>.

[weakfl]

Something I think I’ve seen elsewhere is the dimmer can report a level even if the device is off - there is a separate issue about that I think

Yes, the BJ relays are indeed reporting a level of 1 at times. This hasn't been fixed in the BJ firmware yet, but I've been able to resolve it by using a proxy item and a filtering rule.

The level 100 reporting is definitely new though. It seems only the one relay for which I've changed the transition time is affected.
I've also updated OH today, so I can't be 100% sure yet. I'll keep an eye on it to see if it happens with the other relay too...

[weakfl]

FWIW: some observations regarding the level issue:

• Only the one relay with transition time set to 0 is affected
• Setting the transition time to 10 resolves the reporting issue, but doesn't really work. The transition takes one second instead of 10 ms.

I've created #189 which should remove the duplication [...]

Duplication is fixed with the latest build.

[cdjackson]

Only the one relay with transition time set to 0 is affected

As mentioned earlier, I think this is a device issue. Maybe there's something wrong somewhere, but without more information I can't say what. At the moment I consider that it's not related to this issue as clearly the setting is working.

Setting the transition time to 10 resolves the reporting issue, but doesn't really work. The transition takes one second instead of 10 ms.

Note that the value is in 10ms steps - not 1ms steps. The default probably needs to be disabled - the issue is probably that all these settings are inter-related. I'll add an option to disable the default.

[cdjackson]

Setting the transition time to 10 resolves the reporting issue, but doesn't really work. The transition takes one second instead of 10 ms.

In fact, this is 100% correct - the time is specified in 1/10th of a second, so a value of 10 is 1 second.

[cdjackson]

The update of the config descriptions is now merged and I've just kicked off a build. Hopefully this can be closed now @openhab-5iver ?

[weakfl]

Maybe there's something wrong somewhere, but without more information I can't say what. At the moment I consider that it's not related to this issue as clearly the setting is working.

I could provide logs but I think it would just be a waste of time. I'm agreeing this is probably a device issue.

In fact, this is 100% correct - the time is specified in 1/10th of a second, so a value of 10 is 1 second.

I've set it to 1(00 ms) and it works, thanks for clearing that up.

[cdjackson]

I could provide logs but I think it would just be a waste of time. I'm agreeing this is probably a device issue.

Before you conclude on this, please look at #82 and #83. I think it's similar. In theory, I believe it's a device problem as I think that the ZigBee standards state that level and on/off state should be synchronised. My understanding of that is that a device shouldn't report OFF with a level != 0, but that said, if we see this happening on a number of devices, then we probably ought to solve it.

Please take a look at the other issues, and if you like, we can pick up the discussion there...

[5iver]

The update of the config descriptions is now merged and I've just kicked off a build. Hopefully this can be closed now @openhab-5iver ?

I'm trying to test now, but ran into a snag after updating OH to build 1263. It seems some of the dependencies for zwave and zigbee are not being installed.

Unresolved requirement: Import-Package: gnu.io

I'll let you know when I get this figured out.... or rollback.

[cdjackson]

gnu.io is just the serial driver nrjavaserial… Should be installed, but note that there is now a new dependency which is the USB serial bundle - this is more likely the problem and it only comes with the latest version of ESH/OH so you might need to update everything.

…

On 23 Apr 2018, at 20:35, Scott Rushworth ***@***.***> wrote: The update of the config descriptions is now merged and I've just kicked off a build. Hopefully this can be closed now @openhab-5iver <https://github.com/openhab-5iver> ? I'm trying to test now, but ran into a snag after updating OH to build 1263. It seems some of the dependencies for zwave and zigbee are not being installed. Unresolved requirement: Import-Package: gnu.io I'll let you know when I get this figured out.... or rollback. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ_gRta86DCyTmpueIW6EoitQvXCkks5triz0gaJpZM4QuQOs>.

[weakfl]

Before you conclude on this, please look at #82 and #83. I think it's similar. In theory, I believe it's a device problem as I think that the ZigBee standards state that level and on/off state should be synchronised. My understanding of that is that a device shouldn't report OFF with a level != 0, but that said, if we see this happening on a number of devices, then we probably ought to solve it.

Understood. I'll take a look at these issues tomorrow.

The level issue definitely seems related to the transition setting somehow. With the new setting of 1(00) ms the relay is reporting a level of 10 although it's off.

[5iver]

gnu.io is just the serial driver nrjavaserial

I had seen USB serial detection was being worked on, so that was my first stop... feature:install openhab-transport-serial got me going.

The UI looks to be cleaned up, and I got a chance to do some more thorough testing. I did not see any change in the behaviour of my bulbs after adjusting the On Level and Default move rate. Would they even be displayed if they were not supported by my bulbs (GE Link)?

I think the labels and descriptions could be improved. Including the allowed range would be a start. I never saved it, but currently the up/down arrows allow for negative numbers, and a max of 60,000. What is the Default Transition Time? I could not find any reference to it in the spec. I believe I have tried every possible combination (several times!), but I cannot get my bulbs to turn on fast, but turn off and transition slowly.

With these settings, the bulbs turn on, turn off, and transition slowly, like the Default Transition Time overrides the OnTransitionTime. Whenever Default Transition Time is set, it seems to override ALL settings.

[cdjackson]

Including the allowed range would be a start

I don't like to duplicate the data, so I don't really agree with this.

currently the up/down arrows allow for negative numbers, and a max of 60,000

That's a UI issue - I'm not sure what you propose.

What is the Default Transition Time? I could not find any reference to it in the spec.

It's the transition time that is used in the commands that are sent unless you disable it. It looks like you have not disabled it, so this will override everything and probably explains why the other settings dont work.

I'm not sure what else I can add here. If you have any ideas, then please be very specific.

[cdjackson]

As above, this seems to be fully working now, so closing. If there's any further issues, please open another specific request.