The range is excellent. No problem there. What I absolutely dislike about them is that the modbus traffic is not ordered. It’s literally like modbus over UDP.
Let me explain. I can send a request for the power registers, and then after a timeout, send another request for the power registers (which is answered), then send a request for the voltage registers… and at this point the response to the FIRST power register call will arrive as an answer…
No you have to understand how crappy this is. There is no register number information in the reply, just the answers. There is no transaction id so it can be matched up with the original request. That is not how modbus works. So you ask for three voltage values (for each phase), and instead you receive three delayed energy values for the same thing. Causing absolute havoc.
Now the code has a very simple detection method. It varies the amount of registers (see here for when it was fixed for the ET340 rather recently, and here for the first time), so it asks for 4 registers instead of 3, so that if the response is the wrong length then you know you’ve had an out-of-order delivery.
So it works… but I still hate the entire process with every fiber in my being.
As long as you clever okes can keep the code working it will have to do.
With all the different water lines and power lines running on that yard, there’s no way I’m even going to consider digging a trench. Plus price wise the labour or machine to dig at least 200m, then ethernet cable and conduit and I’ll be very close to the price of the 2 Zigbee’s.
On any other day I would have said: Put in a Wi-Fi link, and use a TCP/IP type meter. Modbus-TCP is a much better protocol than modbus over Zigbee, at least things are ordered. But I’m not particularly enamoured with the EM24 ethernet version either.
The Zigbee setup is well tested and works. It is not very fast, of course, but it works fine.
I’m putting in a EM540 if I can find one, if not I’ll revert back to a EM24 if I can find old stock of that, when I’m at that point I’ll maybe look at the Wifi option with the ethernet EM24.
I was told “October” by one guy, and “December” by another.
The chip shortage is a real bugger-up.
Apparently there is supply of other meters. If only Carlo Gavazzi made them more similar… but every model is slightly different to the others, so none of them are drop-in replacements.
The new EM300 spec 27 is supposedly similar to the EM24… but even that is different enough that it needed to be explicitly supported. The similarity is limited to having the most common registers in the same place, but things related to measurement mode and the energy counting is stock EM300.
EM540 does have a very nice fast measurement/refresh rate of only 100ms… perhaps worth waiting/fighting for.
Here they all are, mounted in old recycled (cheap) DB boxes. For development work.
From left to right, ET112, ET340, EM340spec27, EM24, EM540.
I just have a itch to start measuring ASAP, but it’s not essential at all, so I guess I should just have a beer and get over it, then wait for the EM540 even if it only comes to our sunny shores next year. It’s not as if I have to start measuring now because I want to install solar in a month, unfortunately that’s way beyond the budget and but a dream at this stage.
In your opinion will this resolve the tripping issue with meters that a sensitive to momentary exports, or is there still too much other latency in the system?
Unlikely. Even with the faster meter the fastest pullback is probably around 2.5 seconds. And you won’t get that fast on Zigbee.
What is needed is a faster meter, and changes to the control loop in Venus, then you can get it down to around 3 seconds. But the Conlog meters still trip way faster than that.
