WIC goes back to its previous value after reboot+print

[PeaShooterR]

I forked a copy of your code and made modifications for my own printer.

By sniffering WIC Reset Utility I found that it reads 24, 25, 30, 26, 27, 34. And the 'write' command of my printer is
.78.118.116.100.98.115.106.47

I reset the values of 24, 25, 30, 26, 27, and 34 to 0. After rebooting the printer and printing a document, the second waste ink level successfully reset to 0, but the first waste ink level reverted back to its previous value.

I noticed that you also set a few other oids in line 168.
data = {20: 0, 21: 0, 22: 0, 23: 0, 24: 0, 25: 0, 59: 0, 60: 94, 61: 94}
I think the issue might be related to those additional oids.
Could you please let me know what they are and how I can find them?

Thank your for your work.

[Zedeldi]

Hi @PeaShooterR,

On my WF-7525, I am able to set the waste ink counters with just the following data:
{20: 0, 21: 0, 22: 0, 23: 0}
OIDs 20-23 are where I could see wicreset reading the counters.
This also seems to persists across reboots for me.

However, when I reset the counters using wicreset, it sent the following get requests (from ~/.wicreset/application.log):

perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.20.0.104.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.21.0.61.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.22.0.68.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.23.0.16.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.24.0.0.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.25.0.0.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.59.0.0.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.60.0.94.84.98.116.98.111.114.118.98
perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.101.0.66.189.33.61.0.94.84.98.116.98.111.114.118.98

This means that it writes (by getting 🤷) the following values:

OID	Value
20	104
21	61
22	68
23	16
24	0
25	0
59	0
60	94
61	94

By default, when your waste counters are full, wicreset allows you to use the trial key, which resets all counters to 80%.
This includes counters that are currently below 80%.

This means that, for OIDs 20 and 21, 104, 61 => 0x68, 0x3d (convert to hex) => 0x3d68 (reversed) must equal 80%.
To confirm this, you can see my docstring in reset_waste_ink_levels:

hex(int((80 / 100) * 19650)) == 0x3d68
hex(104), hex(61) = (0x68, 0x3d)

The same applies for OIDs 22 and 23, but with a different constant.

Therefore, I am unsure what the other OIDs represent, or what their significance is, unfortunately.

I believe wicreset may store data about different families of printers, which may share some common traits. Perhaps 60 and 61, both set to 94, represents 80% for a counter on another printer.

In order to troubleshoot the issue you are experiencing with your PX-047A, can you send any logs or pcap files from wicreset. Additionally, has your printer reached the limit where wicreset allows you to reset using the trial, or are you using the OIDs for where it reads the counters from? If you are able to persistently reset one counter, perhaps you could set that to 100% temporarily, then use wicreset, and see what it sends to the printer.

If we manage to get this consistently working for another model, I'd love to integrate it into the project, with a collection of Printer instances for different models.

Hope this helps,
Zack

[Zedeldi]

To add to this, from what I can see, all counters are stored in consecutive pairs, e.g. (20, 21) or (22, 23). Perhaps (59, 60, 61) are actually used together too.
In any case, it seems odd that 30 and 34 would be used for a counter together, but it would be interesting to see where these OIDs came from.

[PeaShooterR]

Based on your instructions, I set one counter to 100% temporarily, then use wicreset trial key and it successfully reset both my 2 counters to 80%.

Here's the log file:

Core::EpsonRemoteResetData Reset started. Do not turn off the printer.
RemoteControl::RESET_GUID RESET GUID: PX-047A Series 494 KEY
RemoteControl::RESET_DATA RESET DATA: 0 - 7C 7C 10 00 55 05 42 BD 21 18 00 78 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.24.0.120.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 1 - 7C 7C 10 00 55 05 42 BD 21 19 00 0C 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.25.0.12.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 2 - 7C 7C 10 00 55 05 42 BD 21 1A 00 2C 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.26.0.44.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 3 - 7C 7C 10 00 55 05 42 BD 21 1B 00 0A 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.27.0.10.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 4 - 7C 7C 10 00 55 05 42 BD 21 1E 00 00 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.30.0.0.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 5 - 7C 7C 10 00 55 05 42 BD 21 1C 00 00 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.28.0.0.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 6 - 7C 7C 10 00 55 05 42 BD 21 1D 00 00 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.29.0.0.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 7 - 7C 7C 10 00 55 05 42 BD 21 22 00 00 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.34.0.0.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 8 - 7C 7C 10 00 55 05 42 BD 21 2E 00 5E 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.46.0.94.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 9 - 7C 7C 10 00 55 05 42 BD 21 2F 00 5E 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.47.0.94.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 10 - 7C 7C 10 00 55 05 42 BD 21 31 00 00 4E 76 74 64 62 73 6A 2F REAL
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.85.5.66.189.33.49.0.0.78.118.116.100.98.115.106.47
EpsonCommonIONET::perform SNMP [READ]: 7C 7C 3A 34 32 3A 4F 4B 3B 0C
RemoteControl::RESET_DATA RESET DATA: 11 - FF REAL
Core::EpsonRemoteResetData Reset complete. Please restart the printer immediately.```

Which means wicreset changed these oids below.

OIDs	Value	Remarks
24	120	Data of 1st counter
25	12	Data of 1st counter
26	44	Data of 2nd counter
27	10	Data of 2nd counter
30	0	Data of 1st counter
28	0	REAL data of 1st counter
29	0	REAL data of 1st counter
34	0	Data of 2nd counter
46	94	Maintenance required level of 1st counter
47	94	Maintenance required level of 2st counter
49	0	?

After several reboots and printouts, I have understanded what these values means.

(24, 25, 30)stored the data of 1st counter while (26, 27, 34)stored the data of 2nd counter, I will refer to this as SHOWN data, which follows a similar algorithm as your printer (I will talk about the details later).

(28, 29)also stored the data of 1st counter but with different unknown algorithm, I will refer to this as REAL data.

Whenever a print job is received, the printer will compare the REAL data and the SHOWN data, then updates SHOWN data to the larger value.

After performing operations such as head cleaning that increase the counter, the printer increments the SHOWN data and saves it to both (24, 25, 30) and (28, 29).

[PeaShooterR]

This is how my printer stores counter data (or how wicreset calculates it):

For the 1st counter, the data is stored as (24, 25, 30).

If oid_30 equals 0, the algorithm is the same as yours, which I'll refer to the result as level_b10.

If oid_30 is not equal to 0, the counter level is calculated using the following formula:

(level_b10 + 245 * (oid_30 - 1)) / total * 100

It seems that the value 245 is a constant for different counters.
The value of my 2nd counter is 178.

I set oid_30 and oid_34 to 30 and 60.

Found wicreset is calculating 245 * (30 - 1)

Found wicreset is calculating 178 * (60 - 1)

[PeaShooterR]

Additionally, you can simply get the correct total by setting a breakpoint at wicreset.exe+105165.

At this point, the value is stored in XMM0.

[Zedeldi]

Interesting that it stores the counters across three OIDs, which are not consecutive, and the real/shown value is separated and compared for counter one.

Good to know that OIDs 46 and 47 represent the maintenance levels too. Presumably that is the same as 60 and 61 for my model.

Nicely done and thanks for sharing!
Zack