Fix #628: hex values for repl arguments

[pkubanek]

Also fixed some issues with repl client for unit handling

[janiversen]

I think you forgotten to update your dev, with Pymodbus dev, before starting this PR. I see at least parts of your previous commit in this commit.

Please update your dev with the latest from Pymodbus and rebase this PR.

Btw it is a good idea to develop in a branch not named dev, because it makes it easier to do:

   git checkout dev
   git pull origin
   git checkout my_feature
   git rebase dev
   coding...
   git push 

When you develop on dev, you easily run into conflicts with Pymodbus dev (e.g. I updated your commit before merging it).

[pkubanek]

Made fix_628 branch..shall I close this PR and start a new one?

[janiversen]

It is not a demand from my side, but it might be easier for you.

[janiversen]

The CI error is something that is fixed on dev.

[janiversen]

Please look at your commit it still contains e.g. the super() change.

[dhoomakethu]

How is this helping?

From the docs Base 0 means to interpret exactly as a code literal, so that the actual base is 2, 8, 10, or 16, and so that int('010', 0) is not legal, while int('010') is, as well as int('010', 8).

[dhoomakethu]

Can you share some outputs with out this change and with this change please?
pymodbus.console >> client.read_holding_registers unit=0x1 count=0x20 address=0x30 is this something you are trying to achieve here ?

[janiversen]

I did a short review of your code, and I agree with @dhoomakethu it do look strange. Your idea is OK, but you need to work on the implementation (and solve your rebase problem).

[pkubanek]

int([str], 0) takes any sensible value as numerical. The original request was for accepting hex values. int([str], 0) accepts any value, with the cost that int('010', 0) throws ValueException - that can be handled by catching it and trying int([str]), perhaps in a function, as this is on multiple places in the code.

I am not sure about rebasing issues. I discovered problems in my previous PR (#1041), which I fixed with this. Do you want to make an extra PR for improving those?

[janiversen]

As I already told you, your problems come from the fact that you use dev to submit PRs. You need to submit a PR based on the latest dev, whether you do it in this PR or open a new PR is up to you. I gave you a recipe how to work with dev and branches for each PR.

You need to prove that your PR accept hex values without causing problems. I believe that '010' is accepted today (without having tested it), so it needs to be accepted in this PR as well.

The best way to show your changes works as expected, is to write some test cases in test/test_.py

[pkubanek]

Ok. Let's close this one, I will make two new PRs, one for fixing problems created by #1041, second to address #628, with still accepting 010 and providing tests to show that.

[janiversen]

I was not aware that there are any problems due to #1041, I suggest you solve your dev problem first. If there are problems I look forward to see a PR.

#628 is a long standing issue, so it will be nice to have that fixed.

[janiversen]

You need to address the concerns from @dhoomakethu and solve the rebase problem.

[janiversen]

Did you get your dev fixed ? We are still looking forward to see new PRs from you.

[pkubanek]

Please see #1075 for new PR.