I have an emonHP level 3 bundle, using a Kamstrup 403 installed on the flow (order #32753, installed March this year), and I keep seeing gaps in the reported data, always on a DHW heating cycle: an example; note that detection of the DHW cycle is derived from the flow rate being higher than 18. Also note that this is an occasional issue; it’s not every DHW cycle.
The meter is installed on a straight run of pipework (see pic). It’s only the heatmeter data doing this; all other inputs seem fine over the drop-out. Where/how should I start investigating this problem?
This has the tell-tale signs of air in the system. There are a couple of threads about this on the forum. There is an effort underway to document this in an FAQ/troubleshooting section on the site, but for now I can refer you to @marko 's post here:
Thanks @Gwil! I’ll contact the installer about purging; the odd thing is the intermittency of the fault and the total absence of data (rather than flatlining or erratic readings like those in Kamstrup Multical 403 Stops Working During Hot Water Cycle (Interference?)). While I’m looking into getting the system purged, are there any logs in emonHP I can search for errors?
It appears (from the strainer orientation) that your flow is going DOWN through the meter. [edit: nope I’m looking at the strainer wrong the flow through that strainer would go from right to left]
That’s not really ideal - entrained air can take a long time to go away if it’s rising (due to bouyancy) as fast as the water is moving down (due to flowrate).
Is your static fill pressure at least 1.5 bar?
How was the system purged of air - dissolved air - when initially installed?
(questions to ask the installer)
To purge dissolved air you need to get the temperature right up to drop air out of solution, flush it into the radiators, then bleed it from the radiators. many don’t do this. Often it will EVENTUALLY work it’s way out (as enough of the dissolved oxygen rusts your radiators etc) but best to clear it in the first instance.
[edit to simplify language for those using translation software - thanks Bill]
I’ve found 3 instances of data dropout between 4:30-ish and 5:00am, though not your first example.
The electricity meter readings are unaffected, but both flow rate and temperatures are missing.
I doubt it’s the meter causing this. Is there something else happening at those times?
Another example from April 8th, with data missing between 5:18 and 6:00. Also Apr 7th - 4:34 until 5:00.
The common pattern is that data recovers at the top of the next hour.
It appears (from the strainer orientation) that your flow is going DOWN through the meter
Ah, no: it’s going up. The connections to the external pump are at the bottom of the pic.
Is your static fill pressure at least 1.5 bar?
Yes; it’s 1.9 bar.
I’ll get on to the installer next week. There are no rads in the system, so less to rust, but there is a Flamco Flexvent at the top/return of the DHW heating coil so I’m guessing that would provide an element of automatic venting, esp. when we run the 70C legionella programme once a week.
The common pattern is that data recovers at the top of the next hour
Right, I noticed this too. There’s nothing else going that I can think of; these are DHW cycles that I’ve set to run during the Cosy Octopus tariff cheap periods. One other thing I just realised was that all the dead zones start when the pump stops (going by the electricity input measurement); electrical interference from that? The recovery at the top of the hour suggests something on the emonHP itself maybe? A cron job that resets the mbus software? Anything I can/should look at? When I first noticed this I dug into the error logs on the Kamstrup LCD interface, but there didn’t appear to be any issues.
Reading subsequent better interrogated replies I think hold off on that pending looking at log files etc.
For what it’s worth if there are no rads in the system there won’t be any lovely lumps of iron to soak up oxygen and air can tend to hang around for longer. There will be an element of automatic venting form the DHW loop but the water in that loop is low in volume compared with the water in the rest of the system so you’re only purging a small portion of the system water at a time with those DHW cycles if that makes sense?
Don’t know whether I’m best to start a separate thread but I’ve also been seeing some tell tale signs of air in the last week on my installation with a Kamstrup heat meter so I’ve been checking in on the data fairly often.
Last night I had a drop out of all data, which recovered at 04:00. This included electricity meter and EmonTH. (So naturally thought of this thread)
Wasn’t a power cut as you can see that the scheduled DHW run at 03:00 occurred from the flow temps once data recovers (I can also see on my smart meter data). Don’t think I lost internet as the live electricity data for the period was captured from the CAD (albeit CAD is on wifi and EmonHP on ethernet - but for router issues I tend to not see them recover without a reboot of the router). Looked at a few other feeds on heat pump monitor and they weren’t impacted etc.
I have tried to connect locally to the EmonHP and on the disk stats its been up for 4 days 22 hours. Couldn’t get the log file to show anything and/or graph the local data (as I haven’t been able to work out how / don’t know if by default they ship configured to even store input data locally as well) - but its pretty much my first time snooping around on the local unit so I don’t really know what I’m doing there!
Only a single instance I can see at the moment, but any thoughts or guidance would be much appreciated
Mmm it looks like those times are coinciding with the diverter valve opening and moving from DWH to CHW. I wonder if the diverter valve opening and associated EMF is effecting the MBUS signal causing the heat meter to drop off.
@guyboltonking could you check the MBUS data cable and USB connection from the MBUS reader to the emonHP are separated from the 240V cable to the diverter valve.
Thanks for the reply Glyn. The USB cable wasn’t near the power line to the diverter but it was running next to an armoured cable running to an external shed. I’ve just now moved the USB cable as far away from any 240V cables as I can. Haven’t seen any dropouts for a few days, but I’ve got an alert setup in Homeassistant so I’ll check the emonhp logs as soon as it happens again (if it does).
Thanks - Did also spot that LeiChat’s feed (see Vaillant firmware thread) also had a drop out at the same time this morning so maybe it is something server side (otherwise a odd coincidence at least!)
It’s unlikely to be server side if the data comes back exactly on the hour, this indicates it’s a local issues on the emonHP or one of the meters since emonhub restarts via a conjob on the emonhp every hour.
Thanks - not aware of anything that should have been happening at the time everything fell over this morning. DHW is on time program window that doesn’t start until 03:00.
Can see suggestions in the thread that proximity to power cabling can cause issues? The cables back from the electricity and heat meters (+adapters) have been hidden in the trunking for the installation. This means that the power supply to the socket (that powers the EmonHP) and the feed to the immersion (turned off, backup for HP failure only) are also running through this section.
I take it if I get further drop outs it would be worth me looking at separating these out?
Is there an idiots guide on where best to look on the EmonHP to identify what the offending issue was that stopped it logging and reporting data? (I did try getting at the logs but couldn’t get them to display anything)
