Cooperative Mode for S-Miles cloud with parameter to enable / disable it. Will pause polling the inverter at appropriate times

[gendelo3]

Introduces a flag that disables polling the inverter at the 14th minute of each hour.

Likely fixes #52 more reliably than setting a higher update interval.

• run cargo clippy and fix all issues (command didn't run for me, sorry)
• run cargo fmt to format all source files

PS: I am no Rust dev + I have not included the new parameter "smiles_cooperation" anywhere for the docker config, so maybe that still needs to be done.

[gendelo3]

Hi @DennisOSRM, Could you check if the optional option works this way? Sorry, it is my first contact with Rust and it looks a bit weird to me ;)

[gendelo3]

Hi again,
I just wanted to confirm that the setup is running fine for me since then, the chosen time offsets around the polling times seem to be large enough.

[DennisOSRM]

Cool, thanks for the info! In terms of timeline I plan to put the branch on my test setup on Thursday and if nothing else comes up to merge over the weekend.

[DennisOSRM]

looking good, thanks so much for the contribution

[Matthies]

I'm pretty sure that this 'skip 14th minute' idea is not the best solution cause the cloud updates happen a lot more often, the web site just accumulates it every 15 minute.
I did some 'Wiresharking' on my HMS-800W-2T to get an idea how the HA-Add-On updates interfere with the cloud updates.
I have set HA update_interval to 55000 and captured packets from the Hoymile's IP for ~75 minutes.

HA-Updates	Cloud-Update (with Src-Port)
============	============================
7:51:17				
7:52:12
7:53:07
		7:53:29 (51543)
7:54:02
7:54:58
7:55:53
		7:56:28
7:56:48		7:57:29
7:57:43		7:58:29
7:58:38		7:59:29
7:59:33
8:00:29		8:00:29
8:01:24
8:02:19
8:03:14
8:04:09
8:05:05		8:05:31 (51544), (8:05:29 51543-FIN)
8:06:00
8:06:55
8:07:50
8:08:45		8:09:03 (51545) (8:09:02 51544-FIN)
		8:09:31
8:09:41		8:10:31
8:10:36	
8:11:31		8:11:32
8:12:26
8:13:21
8:14:16
8:15:12
8:16:07		8:16:33 (51546) (8:16:32 51545-FIN)
8:17:02
8:17:57		8:18:33
8:18:52		8:19:33
8:19:48		8:20:33
8:20:43		8:21:22
8:21:38
8:22:33
8:23:28
8:24:23
8:25:19		8:26:06 (51547) (8:26:05 51546-FIN)
8:26:14		8:26:34
8:27:09
8:28:04
8:28:59		8:29:35
8:29:55		8:30:35
8:30:50		8:31:35
8:31:45		8:32:35
8:32:40		8:33:35
8:33:35
8:34:30
8:35:26
8:36:21
8:37:16
8:38:12		8:38:37 (51548) (8:38:35 51547-FIN)
8:39:07
8:40:02		8:40:36
8:40:57		8:41:37
8:41:52		8:42:37
8:42:47		8:43:37
8:43:43		8:44:37
8:44:38
8:45:33
8:46:28
8:47:23
8:48:18
8:49:14		8:49:39 (51549) (8:49:37 51548-FIN)
8:50:09
8:51:04		8:51:38
8:51:59		8:52:39
8:52:54		8:53:39
8:53:50		8:54:39
8:54:45		8:55:39
8:55:40
8:56:35
8:57:30		8:58:12 (51550) (8:58:11 51549-FIN)
8:58:26
8:59:21
9:00:16
9:01:11
9:02:06
9:03:02		9:03:13 (51551) (9:03:12 51550-FIN)
		9:03:41
9:03:57		9:04:41
9:04:52

My conclusions are:

• Cloud update interval is 60s, first update interval after new session start even 30s
• No cloud update possible if last HA update was <30s
• After 4-5 minutes of cloud update failure a new session is started

I will now try update_interval: 45000 which should make the phases of failure shorter than 4-5 minutes.
Lets see if this makes the update session keep stable (missing 2 of 4 update of cause but who cares?).

[Matthies]

update_intervall = 45000
HA-Updates	Cloud-Update (with Src-Port)		
============	============================
15:57:50
15:58:35
15:59:21	15:59:57 (51586)
16:00:06
16:00:51
16:01:36
16:02:21	16:02:58
16:03:07
16:03:52
16:04:37
16:05:22	16:05:59
16:06:07
16:06:53
16:07:38
16:08:23	16:08:59
16:09:08
16:09:53
16:10:39
16:11:24	16:12:00
16:12:09
16:12:54
16:13:40
16:14:25	16:15:00
16:15:10
16:15:55
16:16:40
16:17:25	16:18:01
16:18:11
16:18:56
16:19:41
16:20:26	16:20:33 (51587) (16:20:32 51586-FIN)
		16:21:01
16:21:11
16:21:57
16:22:42
16:23:27	16:24:02
16:24:12
16:24:57
16:25:42
16:26:28	16:27:02
16:27:13
16:27:58
16:28:43
16:29:28	16:30:02
16:30:14
16:30:59
16:31:44
16:32:29
16:33:14	16:33:36 (51588) (16:33:35 51587-FIN)
16:34:00
16:34:45
16:35:30
16:36:15
16:37:00	16:37:36 (51589) (16:37:36 51588-FIN)
16:37:45
16:38:31	16:39:05
16:39:16
16:40:01
16:40:46
16:41:31
16:42:17
16:43:02	16:43:38 (51590) (16:43:37 51589-FIN)
16:43:47
16:44:32
16:45:17	16:45:06
16:46:03
16:46:48
16:47:33	16:48:07
16:48:18
16:49:03
16:49:49
16:50:34	16:51:07
16:51:19
16:52:04
16:52:49
16:53:34	16:54:08
16:54:20
16:55:05
16:55:50
16:56:35	16:57:08
16:57:20
16:58:06
16:58:51
16:59:36	17:00:09
17:00:21
17:01:06
17:01:52
17:02:37	17:03:10
17:03:22
17:04:07
17:04:52
17:05:38	17:06:10
17:06:23
17:07:08
17:07:53
17:08:38	17:09:11
17:09:23
17:10:09
17:10:54
17:11:39	17:12:11
17:12:24
17:13:10
17:13:55
17:14:40	17:15:12
17:15:25
17:16:10

TCP sessions of cloud update a little more stable but missed 3 of 4 updates. Not what I expected.

[m4rquez]

@Matthies have you tried logging Cloud-Updates when HA-Update isn't running? Just curious if the connection is stable in that case.

[Matthies]

@Matthies have you tried logging Cloud-Updates when HA-Update isn't running? Just curious if the connection is stable in that case.

Will do this weekend.

[Matthies]

@m4rquez I have stopped HA-update now for 30 minutes and captured communication between HMS-800W-2T and Hoymiles Cloud. As expected the cloud updates can be seen every 60 seconds, this time rock stable all within the same TCP session.
Interestingly the S-Miles Cloud Page in Plant/Dashboard/Current Power also shows a fresh timestamp every minute (coresponding to the packages I captured) but the "Current power" value is only updated every 15 minutes. And it is not an average value over the 15 minutes, just the last value before full quarter of an hour.
So I will stay at my solution doing HA-updates every 45 seconds which will allow cloud updates every ~3 minutes. Enough to get fresh power value every 15 minutes.

[DennisOSRM]

One idea that crossed my mind recently was to reimplement sending packets into the cloud from the tool itself. That has to be explored more deeply though

[Matthies]

One idea that crossed my mind recently was to reimplement sending packets into the cloud from the tool itself. That has to be explored more deeply though

Hmm. Not sure if that is possible. If I would offer cloud services for inverters, I would secure communication with some certificate protected by some private key stored inside the inverter/DTU.

[DennisOSRM]

One idea that crossed my mind recently was to reimplement sending packets into the cloud from the tool itself. That has to be explored more deeply though

Hmm. Not sure if that is possible. If I would offer cloud services for inverters, I would secure communication with some certificate protected by some private key stored inside the inverter/DTU.

Yes, sure. Yet that particular cloud service doesn't have much of that. 😉

[m4rquez]

thanks @Matthies , even with updates every 60sec, i'm missing updates in the cloud sometimes.

sending packets from the tool to the cloud sounds cool, but i'm sad, such a workaround seems to be neccessary.

when you are connected to the inverters wifi directly, it is possible to get updates of the current power in the app, i guess, every second. maybe this is another endpoint? possibly this can be used to get regular updates of the current power without disturbing cloud communication?