krahabb
commented
2 months ago Hello @Fyr42 , This is always tricky ;) I'll try check the issue in the coming days but I'm very busy at the moment. Putting in the backlog...
Open Fyr42 opened 2 months ago
krahabb
commented
2 months ago Hello @Fyr42 , This is always tricky ;) I'll try check the issue in the coming days but I'm very busy at the moment. Putting in the backlog...
Fyr42
commented
2 months ago Hi
Just for the record the "official" app doesn't show
I don't know why only one of the two mss315 is buggy..
Kind regards
krahabb
commented
2 months ago The issue where the power readings are all '0' is well-known (#367 and others) but without a really clear solution. I suggest you to try power-cycle the plug (if not done already) and see if it fixes this. Back in time it appeared as if this was related to the device not being able to get its correct system time from NTP servers.
As for the wrong daily energy reset, by inspecting the trace you've uploaded I see the device exposes a bug where it does not correctly reset at midnight (after 31-03-2024 the day of DST change). It looks like, after the DST change, it kept resetting its daily energy at/around 10:58 PM GMT time which was correct during DST but it is no more now that we have +2:00 with respect to GMT. This brings the device energy reset at around 1:00 AM (CET) and then conflicts with a special algorithm in meross_lan which is in place to try correct another bug (#264) appeared on some fw/hw.
When I wrote the patch algorithm for #264 I was scared that patching could have worsened some other misbehaviors and this is an example: without the patch, I guess the plug would just reset at 1:00 AM and the statistics would likely be unaffected (even if the roundtrip time is not correct)
I still have to better check if this is the scenario but I expect that, if this is correct, you should experience again the same kind of glitch unless the plug has now started resetting exactly at midnight (local time) again.
In my reasoning, the glitch would not be seen every day since the energy reading doesn't update between 12:00 AM and 1:00 AM (roughly) because the power consumption is very low. If, by chance, the energy reading changes (increases by at least 1 Wh) during that time then you should see the wrong reset like in your issue reporting.
Fyr42
commented
2 months ago Hi,
Yes. The last two days, bug not seen, but value was in my good range, not very low. 4.06 (I stopped the panels for ~2 hours, and unplugged the MSS315, so power cycle done, and bug vanished) and 7.08 kWh for yesterday. As it's related to solar production there is no change after 20h30 on the MSS315. I have a local NTP server on my FreeBSD server, published via DHCP server. No ntp broadcast of unicast. I will trace if they use my server or not, if the MSS315 has hardcoded ntp server inside firmware.
The non buggy MSS315 is working by night, draining a battery. So the energy reading is changing, and no wrong reset. The 1 and 2 April (after the DST) this non buggy MSS315 was not working at all, with an inverter failure.
If you need deeper debug trace let me know.
Thanks for the answer : power cycle killed the bug for the last 2 days.
Kind regards,
sushiat
commented
2 months ago Two of my MSS310 plugs still do this, I added NTP server to the network and added it to the DHCP options, reset both devices but they keep on doing it every night. Anything else I can try?
krahabb
commented
2 months ago Hello @sushiat , could you try setup a 'debug tracing' for either of the mss310 so I could better understand if it's the same issue or something else?
sushiat
commented
2 months ago Tried and failed I think 😢 I let it do it's 10 minute log, started it at like 23:53 thinking that would do fine. Didn't realise the value goes to 0 at midnight, but it's like 3 minutes later it get's restored/reset. And the log ended at 02:21. Will have another go tomorrow.
krahabb
commented
2 months ago Don't worry trying catching the around-midnight failure. A plain trace at whatever time will be enough since I just have to inspect the device overall state and the trace will anyway carry the latest month consumption history and every timestamp/timezone settings useful for analysis
sushiat
commented
2 months ago Ah I forgot last night anyway, but I kept the file from the night before. But if it's still of use to you here it is: 2024-04-29_23-52-45_9f927a68096393144e266d28354f367a.csv
Version of the custom_component
v5.0.3 Firmware: 9.5.31 Hardware: 9.0.0
Configuration
Sensor_protocol http
Describe the bug
I use 2 MSS315 to measure my solar and/or battery production. One of them, at the daily reset at midnight, sends the daily value to HA. And have 2 daily reset : midnight and 1:00 AM.
I'm in Europe/Paris Timezone. Now in CEST / UTC+2 https://www.zeitverschiebung.net/en/timezone/europe--paris
The other, draining battery at this time don't show this behavior :
I have others MSS310 only one is active. You will see them in the logs
Debug log
The last part shows the value of 3769 re-injected at 00:10:11.487 with mention of "first consumption reading for new day" and again at 01:04:33 AM "first consumption reading for new day" with 0 value
config_entry-meross_lan-92466c48ad9ba657b5c0b99b268e56c3.json
Kind Regards,