HW definition for PRO1/PRO380 energy meter
-
Hi,
I am struggling to create YAML file (in /etc/hw_definitions) for my PRO1-Mod energy meter.Is anybody able to share theirs? At least one parameter (let's say Voltage, register address 5000), so I can better understand the principles of this HW definition YAML file.
My intension is to use it through Node-red, hence I don't have the luxury of debugging the communication though Mervis IDE.
Thanks!
H. -
After I've played with it for a while, I found this post which strongly discourages the "custom evok device" way and advice to use node-red approach instead (through node-red-contrib-modbus).
Based on information from this guide I've started to experiment with communication through /dev/ttyNS0, unfortunately, I am getting timeouts when any message is sent.
I'll post the final solution once I succeed, as I believe this must be a piece of cake to connect, but there is probably some stupid error I am not seeing right now.
-
@HonzaS Did you make it working?
-
@tomas_hora: It works somehow, read further what I mean by somehow. But first let me share this small guide, so anybody else can benefit from it (wouldn't it be great to have it on UniPi KB?):
In order to get info from PRO1/PRO380 energy meter in Node-RED you'll need:
- Connect everything properly trough RS485 line (in my case Neuron L203 <=> PRO1 <=> xS11)
- Using DIP switches on L203 and xS11: switch on terminator resistor on both ends of RS485 and change the baud rate to 9600 and parity to Even (as PRO1 cannot do anything faster than 9600 bps).
- Configure Modbus ID on PRO1 (I've used 101 in my case).
- Optional in case you have xS11 or other Modbus device: Configure Modbus ID on xS11 (I've used 5 in my case).
Software part
- Download and use official UniPi image with Node-RED
- Optional in case you have xS11 or another extension: Enable it in evok.conf by uncommenting proper lines and don't forget to add information about baud rate and parity - Open Node-RED and install node-red-contrib-serial-modbus library (or you can use node-red-contrib-modbus one, which is more complex, yet more powerful as well).
- Add Modbus-Serial In node and configure it accordingly:
- Create a simple flow to get the values:
[ { "id": "383d6eea.dbaec2", "type": "tab", "label": "Modbus", "disabled": false, "info": "" }, { "id": "4d5ae639.855088", "type": "modbusSerial in", "z": "383d6eea.dbaec2", "port": "f7aabf02.b9fda", "slaves": "101", "start": "20498", "count": "2", "dtype": "holding", "period": "10", "topic": "energy_meter", "name": "", "x": 120, "y": 100, "wires": [ [ "b1147fac.29b03" ] ] }, { "id": "d382f138.d56c", "type": "debug", "z": "383d6eea.dbaec2", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": true, "complete": "payload", "targetType": "msg", "statusVal": "payload", "statusType": "auto", "x": 790, "y": 80, "wires": [] }, { "id": "b1147fac.29b03", "type": "function", "z": "383d6eea.dbaec2", "name": "Convert to float", "func": "var msgalt = {payload: msg.payload.readFloatBE(0)};\n\n\nreturn [ msg, msgalt ];", "outputs": 2, "noerr": 0, "initialize": "", "finalize": "", "x": 460, "y": 100, "wires": [ [ "d382f138.d56c" ], [ "bbf909bc.60a118" ] ] }, { "id": "bbf909bc.60a118", "type": "debug", "z": "383d6eea.dbaec2", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": true, "complete": "payload", "targetType": "msg", "statusVal": "payload", "statusType": "auto", "x": 790, "y": 160, "wires": [] }, { "id": "f7aabf02.b9fda", "type": "modbusSerialConfig", "z": "", "port": "/dev/ttyNS0", "baud": "9600", "data": "8", "parity": "even", "stop": "1", "name": "Modbus serial" } ]- Deploy the flow and in the debug tab, you should see messages with the active power: in this case it's about 30 mA (the first message is raw output, the second message is converted with readFloatBE(0) function):
Whee, now you should be able to read any register you want :)
To answer fully to @tomas_hora : I am having trouble with lots of timeouts (as you can see from the image above) - about 70% of requests end up as timeouts. And this is the ONLY application/flow running on my Neuron at this time. This issue is happening with node-red-contrib-modbus library as well - even when you set timeout as high as 5 seconds, you still get this insane timeout rate.
As I am not an HW guy, my guess is that the Modbus gets somehow overloaded by something, because when you access Neuron directly through the web interface, you can see that all RO on xS11 are reacting with 1-2 seconds delay compared to the state when Node-RED is not reading anything from the serial port.Unless you have a better idea where the glitch might be, I am going to experiment with ditching xS11 for a moment. The next thing I could think of is to keep energy meters on separate RS485 bus (through some 3$ USB converter) - in order not to slow down and jeopardize the traffic between Neuron and xS11.
-
Hi @HonzaS,
the problem is that there are effectively two processes accessing the same serial port, which by definition is not possible. One process is the Evok communicating with the xS11 and another process is the Node-RED communicating with the energy meter.You have to combine these two under one "hood". Configure the energy meter as a custom prototype in Evok, or disable the xS11 in Evok and read it via Node-RED.
Best regards,
Martin -
You are absolutely correct sir!
Thanks a lot for your help - now it works like a charm. I've used Neuron's RS485 for communication with xS11 and separate USB dongle with CH340C chip (a bargain really, $2.7 from CZ shop) for communication with PRO1 energy meter through the same Node-RED setup getting data from /dev/ttyUSB0.
It's a pity that I cannot edit my previous post ^^ - feel free to edit it with a big warning that you cannot combine multiple processes on one serial (which is absolutely logical, but for us: HW newbies not obvious).
