I certainly didnāt aim to curtail your enthusiasm, you are absolutely right that an emonhub interfacer would be good. My comments were purely to defer that aspect whilst focusing on the reading of modbus and your device in particular. Often it is easy to end up with a less than great interface when your focus is spread across the whole route the data takes. There will be suggestions to use MQTT, nodered emonhub emoncms directly and all have their proās and conās. but the best approach is to get the best reader code up and running and then find the best way to get that reliable data to itās destination, rather than trying to read the data in the best way to send by MQTT (to pick one at random).
My heads a bit woolly today so sorry if Iām not clear or get something wrong. AFAIK (without reading your docs pdf) a termination resister would only be needed if there were multiple devices on one bus and from what you say it sounds like there is a in-built resister that is connected by a setting, presumably with just one meter you shouldnāt need it, usually it would be the last meter in the chain that has a resister (inbuilt or added to the wiring across the 2 wires). But this can be checked in the docs, it will most likely be in there, just buried somewhere. Getting this bit wrong will not cause any damage, worse case scenario it will not work or work intermittently.
Cat 5e is ideal, at this point the worse you could do is get the 2 wires the wrong way round, again this will not cause damage, it simply wonāt work until you switch them. I only mention this as there have been instances where interpretation of A and B by some manufacturers has been at odds with the general practice, so the labels are not guaranteed to be right in absolutely every case.
If you are writing your own code, a couple of things to consider are, make each read short and reduce the timeout to a number that is adequate to read, with some wriggle room, hacving a 60s timeout on a 150millisecs read just delays moving on to the next read, if the device hasnāt responded in 200milis, itās not going to respond in 60s. Also have a small pause between reads, this is another reason block reads are better as you can allow more settle time with fewer slower reads than rattling off many rapid single reads.
This device has raise a couple of thoughts regarding my aim for universal approach in that it is the same device for both single and 3ph installs, at this point Iām inclined to have (at least) 2 templates eg āDDSD285_1phā and āDDSD285_3phā so that single phase users do not have to read/report 2 unused phases. A similar question remains about the size of the reported data, I have been lucky so far in that all the devices I have done, have had a limited number of reported values. This device has so many potential metrics to read that maybe we need ābasicā and āadvancedā templates too? Many users would only want to know the basic energy monitoring values and have little interest in what percentage of that consumption was up in the 24th harmonics (to pick one at random).
Users that have a Modbus network of half a dozen devices may not want it bogged down interrogating the indepth details of the energy supply rather than swiftly moving on to the gas meter or something else. This is where individual value reading come in handy, but IMO it doesnāt warrant the complexity and slow read rate inflicted on the bulk of the mainstream users to serve the few that want more info. This bit requires some further thought for any universal implementation, less so for a custom implementation specific to you.
The data read by the CTās on a emonPi is indeed processed by the firmware on the ATmega328p and then it is passed via serial and the Piās GPIO UART, this is then read by the āEmonHubJeeInterfacerā in emonhub and passed via MQTT to local emoncms or HTTP(S) to a remote emoncms server.
There is no additional āfirmwareā involved with your Modbus reading. The Python script will read the Modbus via the rs485 adapter, seen as a serial device eg /dev/ttyUSB0 perhaps on your emonPi?
Initially we would look at the console output by simply including some print() statments in the script, then look at getting that data out to itās destination once itās right in the console.
You do not need to try and develop your script on the emonPi, Python will run on a windows machine too. If you want to develop on a PC first, you can then just edit the port from (for example) āCOM7ā to ā/dev/ttyUSB0ā when you move it over. I do all my deving on a full size PC initially as it is faster and easier than doing it via SSH on a RPi. But each to his own, what ever you are at home with.
Looking at something you said earlier about the slaveid being ālocked as id1ā, not that it matters much to you, but for my intended system to work there must be no āid1ā on the network except when a new device is added until it is assigned another id (making room for the next new device), so I looked at your pdf and it appears the slaveid IS configurable it is register 31317 (page 70). Have you been told otherwise? or is you meter different? As a rule (in my experience so far) all Modbus devices (or maybe just meters?) start out life as id1, then they get set to a network unique id by the user.
Hopefully I will be back running on all cylinders again soon and be of more help too you, this isnāt even a proper cold, Iāve had worse hangovers, Iām just finding it impossible to concentrate or think straight at the moment, so forgive the waffle (more than usual).
