MSS3110 Energy is UTC

[lclc98]

Version of the custom_component

Master branch

Describe the bug

I am currently using an MSS310, it seems that home assistant is looking for the next day after midnight, but due to the device using UTC for "Appliance.Control.ConsumptionX", it seems to miss out on the first 10 hours of my day (UTC+10). I haven't had the time to look into the code to see where the problem is caused, but I have noticed it is still going up using MQTT to listen.

[krahabb]

Hey @lclc98,
Thank you for pointing out! Here where we live around GMT that would be almost impossible to note!
I'll look at the code right away

[krahabb]

Update:
Yes my code tries to match current day by localtime while the mss310 is likely exposing those readings in UTC time and that's the misalignment you're experiencing.
My mss310 has not 'timezone' set so that's maybe the reason why it's publishing data that way (in UTC). I've now tried to set the correct timezone in the device configuration and will wait the next 'round-trip' around the timezone.
Is your device correctly set for your timezone (the configuration setting is easily read from the Appliance.System.All payload if you can check it) ?
If so then the plug is for sure publishing consumption data around UTC day change and that would be a different problem since I would have to manage the midnight 'trip' by code anyway.

I'm planning to add the ability to correctly set the device timezone in my code anyway, since when your devices are 'off' the meross infrastructure you'll have no easy way to adjust it.
There's already a bit of code in meross_device.py at around row 300 if you're in 'need' of the option or want to try it sooner than my fixes: it just misses the ability to configure the time_zone parameter in the device integration configuration UI

[lclc98]

I looked at the traces file, it seems like the timezone isn't set on my device, I will see if I can set it manually

[lclc98]

I was able to sit down and look through your code and others. Setting only timezone didn't work for me, I also had to set a variable called "timeRule". TimeRule is explained here, https://github.com/arandall/meross/blob/master/doc/protocol.md#appliancesystemtime

Meross does have an endpoint for it /v1/Rule/getTimeRuleByTz with the param "tz", but as this is a lan plugin, that probably won't work.

[krahabb]

Thank you very much: this is a very interesting info.
I'll see how to set the 'timeRule' reliably in my integration so to nicely set the appliance configuration. By the look of it those timeRule(s) would probably need to be regularly updated as soon as the calendar ticks through the daylight savings zones

[krahabb]

UPDATE:
I've setup the timeRule payload field according to your referenced info and it now looks like it is tripping correctly at midnight in local-time.
I'll check in the next couple of midnights if everything goes smoothly and then update the release.
BTW: I have a couple of mts100v3 valves (paired to my setup) and they're still exposing UTC time even tho I've updated the device with the same configuration. I hoped this fix would also fix their date/time display but no luck. If you have some other helpful hints that would be awesome!
Thank you

[sushiat]

Hi @krahabb,

I'm using a mss310 switch to monitor the power usage of my server and was going to report the same midnight issue reported here. Mine wasn't as obvious either as Irish summer time is only 1 hour off UTC and after you pushed the last version I went to the integration configuration for that device and set the device time zone to "Europe/Dublin" and thought that would be it.

I checked again now a week later and the graph is still showing a 1 hour gap from midnight to 1am with 0 increase in energy consumed even though the server has a pretty steady consumption.

Did I misunderstand/misconfigure the device or should it be working like this?

Thanks,
Markus

[krahabb]

Hey @markuskorbel ,
Sorry for my late reply but I'm a bit into another project at the moment and didn't have the time to check/debug the issue: it's on my radar anyway

See you!

[krahabb]

Hello @markuskorbel ,
I've rechecked it a bit and it looks like mine (Italy TZ UTC + 2.00 now) is working correctly with 'Europe/Rome'.
There are some 'caveats' though:

• if your device is still paired to Meross there could be some 'conflicts' between my code logic and the Meross infrastructure/app
• If not and most likely, you might miss 'pytz' and/or 'bisect' from your python environment. I didn't add the dependency as 'requested' in my code so it might fail (gracefully) when trying to compute the time zone info and not setup it correctly. I've chosen to not enforce this dependency since it looked to me it was already in place in my HA environment and didn't check further. Also, and moreover, since the timezone feature/info is not strictly necessary to run my integration I didn't want to add a 'requested' dependency when in fact it is only 'useful'. There's an 'info' log though stating the problem. I might raise it to 'WARNING' to make it clear I 'would like' to have it

[sushiat]

Hi @krahabb ,

• I have removed all devices from the meross cloud integration as well as Meross itself.
• I'm running HA from the default docker image but grabbed a console to test installing the python libraries. Looks like pytz was installed, and bisect couldn't be installed - I think it's part of the default python libraries

I did notice however that the other plug monitoring my desktop computer doesn't have the hour gap from 00:00-01:00, both were set to the same timezone setting. I didn't check the desktop that often as it often isn't running around that time whereas the server obviously is. I have re-set the timezone on the server plug to see if it fixed it.

Ah, maybe found something else just before posting this: there is a hardware/firmware difference between the two switches. The one that seems to work correctly is a mss310 2.0.0, fw 2.1.14
The one with the hour gap is a mss310 1.0.0, fw 1.1.18

Not sure what differences you encountered when it comes to these two generations of devices, but I might just switch out the server plug with another 2.0.0 switch from a device I don't care about recording the power consumption of.

[krahabb]

Hello @markuskorbel ,
Ahh well, I really didn't have the chance to test that older fw but the issue probably lies there (no other reasonable explanations tho).
I don't know if that version doesnt support local time zone energy calculations at all or if it's a protocol/configuration issue.
I remember having issues with controlling that older fws (#15) so maybe it's a protocol issue.

I'll have a look at the logic of 'midnight-energy-timezone-roundtripping' and see if I could patch it in software (this was my original intention before knowing this: #36 (comment)) but this could take some time..I'm leaving for a couple of days so I'd expect to 'push' something by the end of the week