Energy meter daylight savings issue

[Vitch612]

Not sure if this should be posted here or on the original Sonoff integration. When using SonoffLAN 3.5.2 with an ewelink energy meter the reset time of the counter is only correct during half of the year when daylight saving time changes occur. At the time of setting up the power meter my utc offset was +3 and it is now +2 however the energy meter integration still operates on the assumption that it is +3.

Following is the device's configuration in .storage/sonoff/myemail@host.com which shows a timezone of +3.

    {
      "name": "Power Meter",
      "deviceid": "1001d95406",
      "apikey": "a9ff46b8-4056-4507-86f7-a62115757dca",
      "extra": {
        "uiid": 32,
        "description": "PSF-X67",
        "itCredential": "JGQkCTmQlMUKSJJT",
        "brandId": "59e0dbc25c1af3a660cc1ac0",
        "apmac": "d0:27:03:29:67:df",
        "mac": "d0:27:03:29:67:de",
        "ui": "功率检测插座过载告警",
        "modelInfo": "5ae946f8583ae7fb0c3e5a69",
        "model": "PSF-B67-GL",
        "manufacturer": "深圳酷宅科技有限公司",
        "chipid": "005C006F",
        "staMac": "48:55:19:5C:00:6F"
      },
      "brandName": "coolkit",
      "brandLogo": "",
      "showBrand": false,
      "productModel": "PSF-X67",
      "tags": {
        "m_7dca_vitc": "on",
        "rate": 40000,
        "disable_timers": []
      },
      "devConfig": {
        "timerCount": "16/28"
      },
      "settings": {
        "opsNotify": 1,
        "opsHistory": 1,
        "alarmNotify": 1,
        "wxAlarmNotify": 0,
        "wxOpsNotify": 0,
        "wxDoorbellNotify": 0,
        "appDoorbellNotify": 1
      },
      "devGroups": [],
      "family": {
        "familyid": "64a9426c33139d0008b71231",
        "index": -3,
        "members": []
      },
      "shareTo": [],
      "devicekey": "983fa056-256c-4f1b-8d15-1bc32280a981",
      "online": true,
      "params": {
        "bindInfos": {},
        "version": 8,
        "demNextFetchTime": 1699826400000,
        "timeZone": 3,
        "sledOnline": "off",
        "ssid": "TP-LINK-MAISON",
        "bssid": "00:00:00:00:00:00",
        "fwVersion": "3.5.0",
        "staMac": "48:55:19:5C:00:6F",
        "rssi": -47,
        "init": 1,
        "alarmType": "pcv",
        "alarmVValue": [
          -1,
          -1
        ],
        "alarmCValue": [
          -1,
          -1
        ],
        "alarmPValue": [
          -1,
          -1
        ],
        "switch": "on",
        "startup": "on",
        "pulse": "off",
        "pulseWidth": 500,
        "power": "606.30",
        "voltage": "231.34",
        "current": "2.74",
        "oneKwh": "stop",
        "uiActive": 60,
        "hundredDaysKwh": "get",
        "endTime": "2023-11-01T23:09:23.130Z",
        "startTime": "2023-11-01T23:05:38.707Z"
      },
      "isSupportGroup": false,
      "isSupportedOnMP": true,
      "isSupportChannelSplit": false,
      "deviceFeature": {}
    },

I have tried changing the offset to +2 in this configuration file but it gets overriden on hass restart.

My question here would be how do change this timezone setting to, ideally a string defined timezone, or to a correct integer offset? I did not manage to figure out where the original configuration from which this sonoff configuration file is generated is stored.

[tonki486]

Chiming in to say I've noticed the same behaviour as well. I chalked this up to be an issue on Sonoff's end with them not setting the time correctly, even when we correct the time within the app by adjusting time zone in the settings. I ended up generating energy consumption data directly within Home Assistant with Riemann integrations as a workaround. The values are no an exact match to what the app reports, but it's close enough.

[Vitch612]

Hello @tonki486 thank you for your input. I am currently trying to avoid the path you have taken, possibly out of OCD behaviour and stubbornness, but there's also a good rationale to prefer avoiding chunks of an application running outside of its framework as this reduces service potential availability should any of the components stop working as well as it complicates maintenance and future evolutions. From what I have seen the issue is mainly that the time offset in the sonoff json file is defined as an integer. I am unfortunately not familiar enough with home assistant to easily point to the part that is generating the config file I have mentionned as well as the part that uses the information form this config file to determine the time offset. I am not sure how much AlexxIT has dug into the code nor if he'd have the time or will to check it out, but this seemed like a good place to ask a question about this issue as it makes more sense to have such a fix on SonoffLAN level rather then hope Sonoff's original integration authors to fix it.

[AlexxIT]

I don't think this can be fixed from Hass side. Because the energy is collected in a cloud.

[lordwizzard]

@AlexxIT Thank you for looking at the issue. It doesn't surprise me, that it is a eWeLink problem. Some things are just out of one's control. Appreciate the hard work that that you and the SonoffLAN group in support of this HACs add-on do!!

[Vitch612]

Hello, @AlexxIT and @lordwizzard, thank you both for your efforts looking into this. If the timestamp in ewelink is off by an hour this could be fixed on the sonoff plugin side. We can get the hard offset (which does not cater for daylight savings) from the file: {HASSMAINFOLDER}\config.storage\sonoff\{user@mail.com} from that json we extract the value of data-> {powermeterentryinthedevicesarray} -> params -> timeZone and then compare it to the actual current offset on the local system and correct the timestamps from within the plugin before inserting them into the db. I would gladly volunteer for this but python is not my strongsuit and HASS architecture is still murky to me.

The only issue that this integration level approach creates is that whenever the daylight saving change occurs there will either be a one hour gap or a one hour overlap. not sure what the best way to tackle this would be and this still seems better than having every day's average off by an hour.

The alternative to modifying the samples timestamps from the sonoff plugin that could eliminate the gap and overlap from that previous option would be to alter home assistant main code to account for this offset when handling energy samples however this feels to me like a much more complicated objective to achieve especially when those samples can have already been processed into statistical averages and counters. To illustrate my lack of comfort with the platform: I am still trying to figure out a way to manually alter the energy samples in the database and then reprocess the statistical averages. so far all my attempts led to same averages being recomputed and i can't figure out where the data used for those is coming from since my altered samples seem to be ignored.