Add support for time remaining for a zone on ESP-ME3

[dacarson]

Problem

As called out in the known limitations, remaining time for a zone is not supported on ESP-ME3

Solution

Requesting the additional zone state pages, you can find out the remaining time.

Alternatives

Not support it.

Additional context

Analysing the traffic between the iOS app and the WiFi LNK module, it shows how it obtains the remaining time. Trace below.

[dacarson]

In the app, I asked it to run the 3 zones for 2 minutes each. Below is the communication back and forth that happened when I did so, until in the app I said to stop.
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"4B000102","length":4}}
{"jsonrpc": "2.0", "result":{"length":2, "data":"014B"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"4B000202","length":4}}
{"jsonrpc": "2.0", "result":{"length":2, "data":"014B"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"4B000302","length":4}}
{"jsonrpc": "2.0", "result":{"length":2, "data":"014B"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B00","length":2}}
{"jsonrpc": "2.0", "result":{"length":7, "data":"BB000401020000"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B01","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB01000176000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B02","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB02000278000000000378000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B00","length":2}}
{"jsonrpc": "2.0", "result":{"length":7, "data":"BB000401020000"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B01","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB0100016B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B02","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB02000278000000000378000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B00","length":2}}
{"jsonrpc": "2.0", "result":{"length":7, "data":"BB000401020000"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B01","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB01000161000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B02","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB02000278000000000378000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B00","length":2}}
{"jsonrpc": "2.0", "result":{"length":7, "data":"BB000401020000"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B01","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB01000157000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B02","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB02000278000000000378000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B00","length":2}}
{"jsonrpc": "2.0", "result":{"length":7, "data":"BB000401020000"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B01","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB0100014D000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B02","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB02000278000000000378000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B00","length":2}}
{"jsonrpc": "2.0", "result":{"length":7, "data":"BB000401020000"}, "id": 1}
{"id":2,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B01","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB01000143000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 2}
{"id":3,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"3B02","length":2}}
{"jsonrpc": "2.0", "result":{"length":50, "data":"BB02000278000000000378000000000000000000000000000000000000000000000000000000000000000000000000000000"}, "id": 3}
{"id":1,"jsonrpc":"2.0","method":"tunnelSip","params":{"data":"40","length":1}}
{"jsonrpc": "2.0", "result":{"length":2, "data":"0140"}, "id": 1}

[dacarson]

The 4B (QueueManuallyRunStationRequest) command queued up the manual runs. The format of the 4B command is:
4B pp zz mm
pp = page number, seems to always be zero
zz = zone number
mm = runtime in minutes

with the response QueueManuallyRunStationResponse
01 4B == (01) Acknowledge of (4B) StackManuallyRunStationRequest

As I reported in the other feature request #395 3B (CurrentZoneStateRequest):
3B pp
pp = page number (00)

And CurrentZoneStateResponse format for page 00 is:
BB 00 pg rn rm 00 00
00 = page number
pg = Program Id (00 == PGM A, 01 == PGM B, 02 == PGM C, 03 == PGM D and 04 == manual
rn = Is it running? 01 == YES
rm = Remaining zones in queue

[dacarson]

If you request CurrentZoneStateRequest with page number 01:
3B 01

The response contains the current zone and remaining time, as pointed out here:
allenporter/pyrainbird#40

I saw that the app refreshes the remaining time every 10 seconds, so there is approx. 10 secs between each value.
BB 01 xx zn s2 s1
xx = unknown, seems to be zero always
zn = current zone
s2 = seconds part 2
s1 = seconds part 1

So following the trace (2 mins per zone, polling every 10 seconds)
BB0100017600: Zone 1, 118 seconds remaining (00 76)
BB0100016B00: Zone 1, 107 seconds remaining (00 6B)
BB0100016100: Zone 1, 97 seconds remaining (00 61)
BB0100015700: Zone 1, 87 seconds remaining (00 57)
etc

[dacarson]

Probably not needed here, but you can see that page 02 contains the remaining time of the queued zones:
3B 02

Response:
BB 02 xx zn s2 s1 yy zz xx zn s2 s1
xx = unknown, seems to be zero always
zn = zone
s2 = seconds part 2
s1 = seconds part 1
yy = unknown
zz = unknown

BB 02 00 02 78 00 00 00 00 03 78 00
Zone 2: 120 seconds (aka 2mins)
Zone 3: 120 seconds (aka 2mins)

[mantorok1]

Hi @dacarson, great work. We'll try to get this included in the plugin ASAP.

[dacarson]

On further research, s2 and s1 are backwards. 13mins, 49secs for zone 1 appears as:

[1/10/2023, 2:55:42 PM] [RainBird] [192.168.1.157] Response: [187,1,0,1,61,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] [CurrentZoneStateResponse] 

[donavanbecker]

@dacarson is this resolved with v1.10.0?

[dacarson]

Yes, it is now resolved in v1.10.0. Thank you