Progress update.
I have been able to use hex values in the emonhub.conf file and have the interfacer use them. It will read the first two values, but not the third. Or if there are only two values listed, it will read the first one and not the second…
I have managed to get this working. Link to code: emonhub/EmonModbusTcpInterfacer.py at master · snerd9334/emonhub · GitHub
Not sure if you want me to do a pull request?
Don’t forget to update pymodbus:
pip install -U pymodbus
Example config:
[[ModbusTCP]]
# this interfacer retrieves register information from modbusTCP clients
Type = EmonModbusTcpInterfacer
[[[init_settings]]]
modbus_IP = 192.168.1.60 # ip address of client to retrieve data from
modbus_port = 9999 # Portclient listens on
[[[runtimesettings]]]
# List of starting registers for items listed above
register = 0x0010,0x0012,0x0014,0x004E
# nodeid used to match with node definition in nodes section below. Can be set to any integer value not previously used.
nodeId = 9334
# Channel to publish data to should leave as ToEmonCMS
pubchannels = ToEmonCMS,
# time in seconds between checks, This is in addition to emonhub_interfacer.run() sleep time of .01
# use this value to set the frequency of data retrieval from modbus client
interval = 10
[[9334]]
nodename = USR
[[[rx]]]
names = Voltage L1,Voltage L2,Voltage L3,Frequency
datacodes = f,f,f,f
scales = 0.1,0.1,0.1,0.1
units = V,V,V,Hz
Ensure you have UART Autoframe enabled:
Good work! Yes please make a PR, there a couple of things we can tidy up there.
The previous code was looking for register - 1. Your code isn’t doing the subtraction. This will break existing installations, if there are any…
I don’t know what a framer does. Will this also break deployed installations?
Hi Bruce,
The inclusion of the framer will break existing installations that are expecting the TCP server to be performing the Modbus TCP <=> Modbus RTU confusingly called in the industry (or so it would seem) TCPIP.
I’m sure the register -1 for people using integers and not hex values in their emonhub.conf file would also cause a problem.
Perhaps this would be better as a ‘new’ interfacer for Modbus RTU over IP which is what it seems to be called when using the framer?
OK, we can probably make one interfacer do both jobs. It would be a tremendous about of duplication to create another one with these small changes. The hardest part will be thinking of a good name 
Something that is obvious from the setup menu of the device would be good.
Hex values are also integers. I’m not sure why specifying a decimal value would require you to subtract one from it. Can you enlighten me?
Sounds like a plan. 
so it would seem! Could we include a boolean in the config file for the choice between using the framer or not?
I wish I could, but I couldn’t understand why it was subtracting 1 either. Initially, I thought this was for it to process the loop (limited python knowledge) but eventually realised it had nothing to do with that.
Just a thought but if using python3 this should be pip3 - not sure if it does make any difference.
The other thing is that the installer pulls this in from Debian rather pip. Installing from both locations can cause problems IIRC.
@snerd9334 @bwduncan : I do use this module a lot and happy to see yu get it work
Yes you need to make register-1 and it was a design choice of the original github author @cjthuys…
It was originally coded like that because some manufacturers do +1
as mentionned by @borpin, pymodbus is now installed via apt and from my side, the apt package works fine
Nice work getting this to work @bwduncan @snerd9334, should I merge your pull request now @bwduncan or does @snerd9334’s changes need to be integrated? I don’t have the ability to test the changes so I will just check that it does not break anything more generally. @alexandrecuer if you could confirm that you are happy with the result I will go forward with merging the pull request/s. Cheers!
Hi all,
I have added a commit to my fixes PR which allows people to use hex values as registers. This obviously doesn’t add any new functionality (you can just convert the hex value to decimal yourself) but it is fairly harmless.
I think we cannot accept the change which removes the -1 from the register number. It will break existing deployments and, again, you can work around it by adding one to the number before you put it in the config file!
I am a little sceptical about the RtuFramer change. From the pymodbus documentation:
It should be noted that although you are not limited to trying whatever
you would like, the library makes no gurantees that all framers with
all transports will produce predictable or correct results (for example
tcp transport with an RTU framer). However, please let us know of any
success cases that are not documented!
https://pymodbus.readthedocs.io/en/latest/source/example/changing_framers.html
The way I read it, it’s not expected that TCP and RTU will work together. Is it working in this case by accident? I think we can happily add a boolean to enable the RTU framer, but if there is someone who knows what is actually happening it might be useful to have them weigh in!
@TrystanLea please pull my PR.
Bruce