Smanar / Domoticz-deCONZ

deCONZ plugin for Domoticz (Zigbee application)
GNU General Public License v3.0
36 stars 26 forks source link

Danfoss Ally Thermostat: Able to change heatsetpoint but it is not used #79

Closed johnsprogs closed 3 years ago

johnsprogs commented 3 years ago

When I change the heatsetpoint in Domoticz the new value is accepted, but not used. When asking for it, the right new value is given back, but the display on the thermostat keeps showing the old set heatsetpoint, nor is the valve opened or closed accordingly.

The Domoticz log:

2020-12-09 12:52:38.467 (Zigbee) onCommand called for Unit 6: Parameter 'Set Level', Level: 19.0, Hue: 2020-12-09 12:52:38.467 (Zigbee) Send Command /api/8BB8256E5B/sensors/3/config with {'mode': 'auto', 'heatsetpoint': 1900.0} (0 in buffer) 2020-12-09 12:52:38.467 (Zigbee) Making Request : http://127.0.0.1:80/api/8BB8256E5B/sensors/3/config with params {'mode': 'auto', 'heatsetpoint': 1900.0} 2020-12-09 12:52:38.534 (Zigbee) onMessage called 2020-12-09 12:52:38.534 (Zigbee) ### WebSocket Data : {'config': {'battery': 85, 'displayflipped': False, 'heatsetpoint': 1900, 'locked': False, 'offset': 0, 'on': True, 'reachable': True}, 'e': 'changed', 'id': '3', 'r': 'sensors', 't': 'event', 'uniqueid': '14:b4:57:ff:fe:76:a9:12-01-0201'} 2020-12-09 12:52:38.535 (Zigbee) ### Update device (Zigbee - Thermostat) : {'BatteryLevel': 85, 'nValue': 0, 'sValue': '18.69'}, IGNORED , no changes ! 2020-12-09 12:52:38.535 (Zigbee) ### Update device (Zigbee - Thermostat) : {'BatteryLevel': 85, 'nValue': 0, 'sValue': '19.0'} 2020-12-09 12:52:38.547 (Zigbee) ### Update device (Zigbee - Thermostat) : {'BatteryLevel': 85, 'nValue': False, 'sValue': 'False'}, IGNORED , no changes ! 2020-12-09 12:52:38.483 Error: (Zigbee) Connexion problem (1) with Gateway : 400

While testing with a RESTClient I found out that the 'mode': 'auto' parameter is not supported by the Danfoss Ally. It's that parameter that generates the 400-error in the last line (I think). So that parameter should not be given. If I leave that out, everything is OK and the display on the Ally shows the new set value.

Any way I can fix that myself, or is it something for the next update?

Furthermore the new heatsetpoint is given with one decimal. Not neccesary, but the Ally doesn't seem to bother. And why is there a Hue: parameter at the end of the first line? Fortunatly it's ignored in the rest of the process.

Thanks in advance for your effort.

Smanar commented 3 years ago

While testing with a RESTClient I found out that the 'mode': 'auto' parameter is not supported by the Danfoss Ally. It's that parameter that generates the 400-error in the last line (I think). So that parameter should not be given. If I leave that out, everything is OK and the display on the Ally shows the new set value.

Lol thx for bug search, I will make something immediatly

Furthermore the new heatsetpoint is given with one decimal

it s old need to check, but will remove it too, useless

Smanar commented 3 years ago

Ok can you try this file ? Then delete the "mode" widget and the "heatsetpoint" widget And reload the plugin, hardware/deconz/update.

A little explanation. Now the plugin search for field "mode" and heatpoint" at startup, so as the "mode" is not present, it will not re-create the "mode" widget, but it will create the "heatpoint" one. When you send the command it will check if the widget "mode" exist, and if not, send only "heatsetpoint"

johnsprogs commented 3 years ago

I would love to try your file... if I only could find it... Am I missing something? I'm new to this github stuff...

Smanar commented 3 years ago

The easy way, use a text editor and replace the contain (only the file plugin.py is modified https://github.com/Smanar/Domoticz-deCONZ/blob/beta/plugin.py), but will provoke problem later when you will want to update the code naturaly. Else if you have used git command to install it.

johnsprogs commented 3 years ago

Succeeded to update the plugin with the git pull way, removed the mode en heatsetpoint widgets and updated the hardware.

After updating in Domoticz the log writes:

2020-12-09 22:47:32.815 (Zigbee) Classic Data : --left some stuff out-- '3': {'config': {'battery': 85, 'displayflipped': False, 'heatsetpoint': 1900, 'locked': False, 'mountingmode': None, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '21755a30cd98448af4f9f76632554dbb', 'lastseen': '2020-12-09T21:09Z', 'manufacturername': 'Danfoss', 'modelid': 'eTRV0100', 'name': 'Thermostat', 'state': {'errorcode': None, 'lastupdated': '2020-12-09T21:42:59.126', 'mountingmodeactive': False, 'on': False, 'temperature': 2133, 'valve': 0, 'windowopen': 'Closed'}, 'swversion': '01.02.0008 01.02', 'type': 'ZHAThermostat', 'uniqueid': '14:b4:57:ff:fe:76:a9:12-01-0201'}, '4': {'config': {'battery': 85, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '2188439b76579c3e5b87ff83717cf61f', 'lastseen': '2020-12-09T21:44Z', 'manufacturername': 'Danfoss', 'modelid': 'eTRV0100', 'name': 'Thermostat', 'state': {'lastset': '2020-12-07T15:46:42Z', 'lastupdated': '2020-12-09T16:05:47.604', 'localtime': '2020-12-09T17:05:41', 'utc': '2020-12-09T16:05:41Z'}, 'swversion': '01.02.0008 01.02', 'type': 'ZHATime', 'uniqueid': '14:b4:57:ff:fe:76:a9:12-01-000a'}}

It reads the data: 2020-12-09 22:47:32.832 (Zigbee) ### Device > 3 Name:Thermostat Type:ZHAThermostat Details:{'errorcode': None, 'lastupdated': '2020-12-09T21:42:59.126', 'mountingmodeactive': False, 'on': False, 'temperature': 2133, 'valve': 0, 'windowopen': 'Closed'} and {'battery': 85, 'displayflipped': False, 'heatsetpoint': 1900, 'locked': False, 'mountingmode': None, 'offset': 0, 'on': True, 'reachable': True} 2020-12-09 22:47:32.833 (Zigbee) ### Update device (Zigbee - Thermostat) : {'nValue': 0, 'sValue': '21.33', 'BatteryLevel': 85}, IGNORED , no changes ! 2020-12-09 22:47:32.833 (Zigbee) ### Device > 4 Name:Thermostat Type:ZHATime Details:{'lastset': '2020-12-07T15:46:42Z', 'lastupdated': '2020-12-09T16:05:47.604', 'localtime': '2020-12-09T17:05:41', 'utc': '2020-12-09T16:05:41Z'} and {'battery': 85, 'on': True, 'reachable': True}

But later on there is a message: Can't update unit 3 and 4. But it still gets the right data from the websocket:

2020-12-09 23:08:24.017 Status: (Zigbee) ### deCONZ ready 2020-12-09 23:08:24.017 Status: (Zigbee) ### Found 1 Operators, 4 Sensors, 2 Groups, 0 Scenes and 0 others, with 0 Ignored 2020-12-09 23:08:24.017 Status: (Zigbee) ### Device GROUP_All(Zigbee - All) Not in deCONZ ATM, the device is deleted or not ready. 2020-12-09 23:08:24.068 Status: (Zigbee) Launching websocket on port 8088 2020-12-09 23:08:24.006 Error: (Zigbee) Can't Update Unit > 3 (sensors) Special part 2020-12-09 23:08:24.006 Error: (Zigbee) Unknow device type ZHATime 2020-12-09 23:08:24.006 Error: (Zigbee) Can't Update Unit > 4 (sensors) : {'BatteryLevel': 85} 2020-12-09 23:08:26.122 (Zigbee) onMessage called 2020-12-09 23:08:26.122 (Zigbee) ### WebSocket Data : {'e': 'changed', 'id': '3', 'r': 'sensors', 'state': {'errorcode': None, 'lastupdated': '2020-12-09T22:08:26.080', 'mountingmodeactive': False, 'on': True, 'temperature': 2024, 'valve': 8, 'windowopen': None}, 't': 'event', 'uniqueid': '14:b4:57:ff:fe:76:a9:12-01-0201'} 2020-12-09 23:08:26.122 (Zigbee) ### Update device (Zigbee - Thermostat) : {'nValue': 0, 'sValue': '20.24'}

End of story: No new heatsetpoint device is made in Domoticz. The temperature widget, the one I didn't remove still recieves the right values. If you want more info from the log, or want me to try something, just let me know.

For your info: the RESTClient results of device 3: { "config": { "battery": 84, "displayflipped": false, "heatsetpoint": 1800, "locked": false, "mountingmode": null, "offset": 0, "on": true, "reachable": true }, "ep": 1, "etag": "341a8a5f8e4c38e7c1e2a92bafe25510", "lastseen": "2020-12-09T22:09Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Thermostat", "state": { "errorcode": null, "lastupdated": "2020-12-09T22:21:26.002", "mountingmodeactive": false, "on": true, "temperature": 1973, "valve": 7, "windowopen": null }, "swversion": "01.02.0008 01.02", "type": "ZHAThermostat", "uniqueid": "14:b4:57:ff:fe:76:a9:12-01-0201" }

Device 4:

{ "config": { "battery": 84, "on": true, "reachable": true }, "ep": 1, "etag": "f38530b4c166a703bf9e85a756f36d1c", "lastseen": "2020-12-09T22:29Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Thermostat", "state": { "lastset": "2020-12-07T15:46:42Z", "lastupdated": "2020-12-09T22:06:53.380", "localtime": "2020-12-09T23:06:47", "utc": "2020-12-09T22:06:47Z" }, "swversion": "01.02.0008 01.02", "type": "ZHATime", "uniqueid": "14:b4:57:ff:fe:76:a9:12-01-000a" }

johnsprogs commented 3 years ago

Experimented a bit more. I deleted the plugin hardware (and doing so all Zigbee devices too) completely out of Domoticz and made a new one. But now no devices were made at all. Then I reverted to the previous version (1.0.15) by copying back the old py-files and updated again. Now I got all of my devices back. Then I replaced the py-files again with the new ones, without removing the existing devices in Domoticz. Everything works fine again now, exept... the heatsetpointsetting.

When changing the heatsetpoint the log reads:

020-12-10 09:56:34.117 (Zigbee) Calling message handler 'onCommand'. 2020-12-10 09:56:34.118 (Zigbee) onCommand called for Unit 7: Parameter 'Set Level', Level: 19.0, Hue: 2020-12-10 09:56:34.118 Error: (Zigbee) Device not ready : 7

The (Zigbee) Send Command and (Zigbee) Making Request are (as far as I can see) not executed.

When I turn the knob on the thermostat the new set value is shown in the heatsetpointwidget, so there is a connection.

I hope you have enough information to be able to have another look at it.

johnsprogs commented 3 years ago

I changed 2 lines in the old (working) plugin.py (starting at line 283):

        #thermostat situation
        if _type == 'config':
            _json.clear()
            if Devices[Unit].DeviceID.endswith('_heatsetpoint'):
              # _json['mode'] = "auto" (commented out)

_json['heatsetpoint'] = Level * 100 elif Devices[Unit].DeviceID.endswith('_mode'): if Level == 0: _json['mode'] = "off" if Level == 10: _json['mode'] = "heat" if Level == 20: _json['mode'] = "auto"

retreive previous value from domoticz

                   IEEE2 = Devices[Unit].DeviceID.replace('_heatsetpoint')   

ORIGINAL IEEE2 = Devices[Unit].DeviceID.replace('_mode','_heatsetpoint')

Hp = int(100*float(Devices[GetDomoDeviceInfo(IEEE2)].sValue)) _json['heatsetpoint'] = Hp

For this moment, it solved my problem but not your's, I'm afraid.

If you want me to do some more testing, just let me know. I will be glad to help you.

Smanar commented 3 years ago

Was my fault, fields are in "config" not in "state", have corrected the code again, you just need to go in plugin folder and type git pull

I have tried too ignore the zhatime sensor, but idk how domoticz will react.

On normal way you don't need to change the "mode" management, as domoticz will no create the "mode" widget, (not present on JSON.

johnsprogs commented 3 years ago

I'm afraid I messed things up. As I had modified the plugin myself, git pull didn't work anymore. Got it working again but then the pull merged the new version after the existing plugin.py, making it twice as large. Trying to resolve that, Domoticz got nervous, got that running again, but git pull now does nothing at all anymore. Reverted to the stable plugin that I changed myself earlier, and after some fiddling got it all working again. A'm afraid I will have to stick with that...

Smanar commented 3 years ago

Don't worry ^^. If you have problem with the plugin, just delete the folder, and restart from scratch https://github.com/Smanar/Domoticz-deCONZ#installation

There is no danger, nothing is stored on the plugin folder, you just need to keep the folder name, else you will need to restart domoticz and can loose your previous devices (different folder name mean different hardware for domoticz, so different devices)

Or you can just download the files and upload then in the folder.

johnsprogs commented 3 years ago

OK, I will have a try tomorrow.

johnsprogs commented 3 years ago

Succeeded! Deleted the 'old' stuff, restarted Domoticz, pulled in the new version, restarted Domoticz again, added the deCONZ-hardware, and now I got only two Ally devices: Temperature and heatsetpoint. No 'mode' one. Works now without a glitch. Many thanks on behalf of myself and other Ally users.

Smanar commented 3 years ago

Thx to you ^^, without the device I can do nothing without return and test.

I will make the beta official this WE, I think, changes are rely usefull.

johnsprogs commented 3 years ago

Just wait a few days, if you like. There might be an issue I've encountered when I first tried it. In "config" there is a setting called "locked": false. When I got it just out of the box, after pairing, I couldn't get the heatsetpoints going, not even by using the RESTclient. I noticed that the "locked" setting read null. After changing it to false with the RESTclient, things started going. Problem is that I'm not sure if that was the real reason, because I already fiddled a lot with it. But here is the good news: Thanks to your effort, knowing that they could be used in Domoticz, I ordered another two, which will be here at the beginning of next week. Now that I know where to look for, I can test again with two new ones. If it is really a problem, you could perhaps take it into account before making the beta official. I can imagine that other thermostats might have a similar setting. When set to true, you can stil change the heatsetpoint with the RESTclient or Domoticz, but you can't change the setting anymore by changing the knob. If you are enthousiastic about it, a widget for thermostates that support it, to change the locked-setting in Domoticz?

johnsprogs commented 3 years ago

Another small issue, but I don't know if that is coming from Domoticz or the plugin: When changing the heatsetpoint with the little pop-up screen, or by turning the thermostat-knob, the value in the upper right corner of the widget is changed accordantly. But the pop-up screen is not. When opened again, it still shows the previous setting. You have to go to another tab, than back to the utilities tab, to update it. In daily life only annoying when you are testing, but now you are still at it, and when the fix is easy...

Smanar commented 3 years ago

Ha yep the "lock" setting is too prevent children change it. The "null" value can be a bug, but from deconz api code, not the plugin, on some device this setting is displayed on the devive itself no (and can be changed on it too) ?

For your second issue, you are right, I think it s from domoticz itself. I m making an issue on domoticz forum to be sure. https://www.domoticz.com/forum/viewtopic.php?f=6&t=34838

Smanar commented 3 years ago

And if you are using the beta version, you dn't need to use a REST client to change the setting, you can use domoticz itlsef.

On "custom" you will have a "deconz" page, go on sensor tab and you can set the thermostat setting.

johnsprogs commented 3 years ago

Found it. Again, thanks for your effort!

johnsprogs commented 3 years ago

I just recieved the 2 thermostats and paired them by using the deconz page on custom. They paired without a glitch, and the new made widgets operated flawlessly without any hassle, despite the 'locked' setting being undefined. Then set the 'locked' to false, just to be sure. Problems solved, thanks a million! Now I put them all 3 in one box. I want to know how precise their temperature measurement is. LOL...

johnsprogs commented 3 years ago

Al read temperatures within 0.1 degree (Celsius), which is nice, I think...

Smanar commented 3 years ago

But it s precise ? by curiosity, you have compared with real temperature sensor ? The temperature close the TRV can't be the real temperature.

johnsprogs commented 3 years ago

I'm fully aware that the temperature close to the TRV is not the real one. Therefore I put the three of them in a box, before mounting them. I didn't compare them with a 'real' temp sensor. I was just curious in howfar they would agree with each other. One of these days, I'm going to mount them. Enough of fooling around, time for them to get to work!

The only problem that is left, is some communication error:

2020-12-20 03:31:50.845 Error: (Zigbee) Can't Update Unit > 4 (sensors) : {'BatteryLevel': 71} 2020-12-20 03:34:03.004 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 89} 2020-12-20 04:32:16.537 Error: (Zigbee) Can't Update Unit > 4 (sensors) : {'BatteryLevel': 72} 2020-12-20 04:34:34.444 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 90} 2020-12-20 05:32:41.962 Error: (Zigbee) Can't Update Unit > 4 (sensors) : {'BatteryLevel': 71} 2020-12-20 05:35:05.924 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 90} 2020-12-20 05:36:06.493 Error: (Zigbee) Can't Update Unit > 6 (sensors) : {'BatteryLevel': 76} 2020-12-20 06:33:07.211 Error: (Zigbee) Can't Update Unit > 4 (sensors) : {'BatteryLevel': 71} 2020-12-20 06:36:36.998 Error: (Zigbee) Can't Update Unit > 6 (sensors) : {'BatteryLevel': 76} 2020-12-20 06:46:03.098 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 88} 2020-12-20 07:33:32.527 Error: (Zigbee) Can't Update Unit > 4 (sensors) : {'BatteryLevel': 71} 2020-12-20 07:37:07.553 Error: (Zigbee) Can't Update Unit > 6 (sensors) : {'BatteryLevel': 76} 2020-12-20 07:46:34.624 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 90} 2020-12-20 08:37:38.034 Error: (Zigbee) Can't Update Unit > 6 (sensors) : {'BatteryLevel': 76} 2020-12-20 09:34:03.208 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 89} 2020-12-20 09:38:08.502 Error: (Zigbee) Can't Update Unit > 6 (sensors) : {'BatteryLevel': 76} 2020-12-20 10:34:34.540 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 90} 2020-12-20 10:38:38.985 Error: (Zigbee) Can't Update Unit > 6 (sensors) : {'BatteryLevel': 76} 2020-12-20 11:35:05.876 Error: (Zigbee) Can't Update Unit > 8 (sensors) : {'BatteryLevel': 90}

I haven't found a clue yet what might cause this errors. Is something trying to PUT a value to BatteryLevel? Anyway, it doesn't seem to disrupt the normal communication to and from the thermostats, so I can live with it...

Smanar commented 3 years ago

Ha yes, strange. It mean the plugin don't find the device in domoticz base.

You have the json for the device 4 / 8 or 6 ? Why it work for temperature and not battery ?

There is no other logs just before ? (Normal log and error log are not exactly timed)

johnsprogs commented 3 years ago

I have searched in the logs for events or other things which might interfere with the thermostats, but couldn't find any clues. I made some screenshots, maybe they might give you some ideas:

The printout from the REST-client: "3": { "config": { "battery": 71, "displayflipped": false, "heatsetpoint": 1000, "locked": false, "mountingmode": null, "offset": 0, "on": true, "reachable": true }, "ep": 1, "etag": "e2d0bf24c9e8fc8d0a54f06bf5aef2ed", "lastseen": "2020-12-21T06:43Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Thermostat", "state": { "errorcode": null, "lastupdated": "2020-12-21T10:20:17.197", "mountingmodeactive": false, "on": false, "temperature": 1862, "valve": 0, "windowopen": "Closed" }, "swversion": "01.02.0008 01.02", "type": "ZHAThermostat", "uniqueid": "14:b4:57:ff:fe:76:a9:12-01-0201" }, "4": { "config": { "battery": 71, "on": true, "reachable": true }, "ep": 1, "etag": "73905a4910a1d401582ba01e21b41c01", "lastseen": "2020-12-21T10:38Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Thermostat", "state": { "lastset": "2020-12-07T15:46:42Z", "lastupdated": "2020-12-21T04:42:05.528", "localtime": "2020-12-21T05:41:57", "utc": "2020-12-21T04:41:57Z" }, "swversion": "01.02.0008 01.02", "type": "ZHATime", "uniqueid": "14:b4:57:ff:fe:76:a9:12-01-000a" }, "5": { "config": { "battery": 74, "displayflipped": null, "heatsetpoint": 1500, "locked": false, "mountingmode": null, "offset": 0, "on": true, "reachable": true }, "ep": 1, "etag": "3f2e8959406f2078acc5a020ae98640e", "lastseen": "2020-12-21T10:42Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Thermostat 5", "state": { "errorcode": null, "lastupdated": "2020-12-21T10:09:38.318", "mountingmodeactive": false, "on": false, "temperature": 1608, "valve": 0, "windowopen": "Closed" }, "swversion": "01.02.0008 01.02", "type": "ZHAThermostat", "uniqueid": "84:2e:14:ff:fe:5e:3e:d5-01-0201" }, "6": { "config": { "battery": 74, "on": true, "reachable": true }, "ep": 1, "etag": "3f171f630b0e38e18f5d54615f8b1884", "lastseen": "2020-12-21T10:42Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Time 6", "state": { "lastset": "2020-12-16T22:25:32Z", "lastupdated": "2020-12-21T10:28:41.229", "localtime": "2020-12-21T11:28:32", "utc": "2020-12-21T10:28:32Z" }, "swversion": "01.02.0008 01.02", "type": "ZHATime", "uniqueid": "84:2e:14:ff:fe:5e:3e:d5-01-000a" }, "7": { "config": { "battery": 90, "displayflipped": null, "heatsetpoint": 1300, "locked": false, "mountingmode": null, "offset": 0, "on": true, "reachable": true }, "ep": 1, "etag": "e3fc1eec940a5866e9ada0436d75e94a", "lastseen": "2020-12-21T10:42Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Thermostat 7", "state": { "errorcode": null, "lastupdated": "2020-12-21T10:15:09.848", "mountingmodeactive": false, "on": false, "temperature": 1606, "valve": 0, "windowopen": "Closed" }, "swversion": "01.02.0008 01.02", "type": "ZHAThermostat", "uniqueid": "84:2e:14:ff:fe:5e:3e:ce-01-0201" }, "8": { "config": { "battery": 90, "on": true, "reachable": true }, "ep": 1, "etag": "3b513edf059cb468b87b820be75863c7", "lastseen": "2020-12-21T10:42Z", "manufacturername": "Danfoss", "modelid": "eTRV0100", "name": "Time 8", "state": { "lastset": "2020-12-17T16:38:41Z", "lastupdated": "2020-12-21T10:42:05.328", "localtime": "2020-12-21T11:42:00", "utc": "2020-12-21T10:42:00Z" }, "swversion": "01.02.0008 01.02", "type": "ZHATime", "uniqueid": "84:2e:14:ff:fe:5e:3e:ce-01-000a" }

The thermostats as listed in Domoticz in the custom -- DeCONZ tab:

Domoticz Custom

And as listed in the devices list:

Domoticz 2

Looking at it, I think it's the ZHATime-thingy that's causing the trouble...

Smanar commented 3 years ago

Exactly, my fault, missing some code

https://github.com/Smanar/Domoticz-deCONZ/commit/798d1276ce1f2872c6f7dbf2c30321a510237b4d#diff-08655555cc53ca79554ba180d1ae7e6ebe5c9b0a25e1772ce248fdd8b83dab34

Can you try with adding this line , or update the file if you are using the beta branch ?