[bticinosmarther] Activation time wrongly set from notification

[MrRonfo]

Expected Behavior

When the bridge receives a notification for a Chronothermostat in ON state, the activationTime attribute is sent in the payload specifying "when" the device itself is set to stop operating. Users can manipulate and display the activationTime value, which is exposed via the endTime channel.

Current Behavior

The activationTime is correctly sent in the notification payload (e.g. activationTime=2020-12-05T23:30:00), however the endTime channel is not populated. Log sample: 10:17:41.589 [INFO ] [smarthome.event.ItemStateChangedEvent] - bticinosmarther_module_smarther_93bb0f7c_status_endTime changed from Forever to

Possible Solution

Reason could be the binding trying to parse the activationTime as a zoned date/time, while it is not.

Steps to Reproduce (for Bugs)

1. Set the device mode to Manual specifying an endDate and andHour+endMInute
2. Change the device status from OFF to ON
3. Wait for notification from the Legrand cloud and check the activationTime in payload
4. Check OH smarther logs and Control in paperUI to see the endTime channel is not set

Context

Channel endTime I use it in my rules and is the only way the user knows when the device is set to stop.

Your Environment

OH 2.5.10 w/bticinosmarther add-on 2.5.10, running on raspberry PI 4 with openhabian (buster). Chrome 86 and OH iOS app.

[lsiepel]

I think you are right. The date is parsed as a zoned datetime (yyyy-MM-dd'T'HH:mm:ssXXX) and from your example it should be yyyy-MM-dd'T'HH:mm:ss . Relevant code is here:

https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.bticinosmarther/src/main/java/org/openhab/binding/bticinosmarther/internal/api/dto/Chronothermostat.java#L149-L168

I can fix this easily (assuming the datetime as localtime) with a check/fallback to the current behaviour, But you are the contributer of this binding, any specific reason why you did not create a PR?

[MrRonfo]

Thanks Isiepel. I just have had no time to create a PR and work on the fix, so any contribution is highly appreciated.

PS I'm also struggling to restore a workable Eclipse env with last OH3 and binding; if you're using the same, any help would be great :)

[lsiepel]

I'll create a fix as you can test it.

I use vscode, find that so much easier and better to work with: https://www.openhab.org/docs/developer/ide/vscode.html

[lsiepel]

Testfile jar for 4.x : https://1drv.ms/u/s!AnMcxmvEeupwjq5jJ8HfOrMW9mZQOA?e=cC16Wh Source is here: https://github.com/openhab/openhab-addons/compare/main...lsiepel:openhab-addons:bticinosmarter-datetime

Let me know if your tests are succesfull.

[MrRonfo]

Thanks @lsiepel. I see the jar you built is for snapshot 4.1.0, any chance to get one for latest stable 4.0.1 - for me to test it ? I'm also following your suggestion and having a look into VSCode, but it will take me some time...

[lsiepel]

you built is for snapshot 4.1.0, any chance to get one for latest stable 4.0.1 - for me to test it ? I'm also following your suggestion and having a look into VSCode, but it will take me some time

It is compatible with 4.0.x Before you add it to the jar folder, don't forget to disable the default bticinosmarter binding.

[MrRonfo]

Thanks. My fault, I didn't disable the default binding first - now yours has started fine.

However, I've also found the OAuth process used to authorize the bridge towards Legrand API has some bug (probably due to OH version change to v3 or v4). Need to better check and fix this, to be able to complete my tests...

[MrRonfo]

I've completed some tests and your patch seems to be working fine to me. I've also made other fixes to the code and manged to test everything from VSCode and local OH instance, so after your fix I'd like to push these as well.