How does Pulse counting work when you have Solar? On my Electric meter the LED is on constantly when there is excess Solar. How does Pulse counting work in that scenario.
Conversely on the Solar meter, the LED is on constantly when there is no Solar.
Do I catch the failing edge of the LED to detect a pulse?
Yes, this is how it works. However the granularity (at 1,000 p/kWh) is pretty poor. I have both CT and pulse counters on both meters and the while the pulse counters give “meter accurate” readings the CTs are far better for real time monitoring.
e.g. (ignore scales - that’s the calibration error 
)
I already have CT monitoring but I thought I’d add pulse monitoring too, so that I can ‘see’ meter readings without going out in the cold.
But the bit I am not sure about is how do I track that I haven’t lost any pulses, either in the detection or in the transmission to Emoncms. I can easily amend the sketch to increment the value of the pulse and send it somewhere. The issue I then have is how do I get Emoncms to detect that it has missed a sequence number and then correct itself.
How does Pulse counting work when you have Solar? On my Electric meter the LED is on constantly when there is excess Solar. How does Pulse counting work in that scenario.
When surplus power is being returned to the grid, your supply meter stops counting because it’s only interested in consumption. In this case, the constantly on LED indicates that the meter is not recording because the flow of energy is in the reverse direction.
Conversely on the Solar meter, the LED is on constantly when there is no Solar.
With your generation meter, a significant amount of energy flow can only occur in one direction, i.e, when your PV panels are generating. At night time, this meter will go into its standby or “anti-creep” mode during which the LED is also on constantly.
The general rule for meters with a single LED is that a chargeable event has been registered whenever the LED goes from on to off. This often equates to 1/1000 of a kWh.
Or possibly the LED will be on constantly because the standby power consumed by the inverter is seen as ‘reverse’ power. But hopefully this standby power will be below the meter’s starting current, so the meter will go into ‘anti-creep’ mode.
Either way, you don’t get pulses.
I thought that had been available in emonCMS for a long time. The standard emonPi and the pulse-counting emonTx sketches both send the accumulated pulse count, and I believe it is capable of negotiating a reset to zero at the sending end. I expect @glyn.hudson or @pb66 will fill in the details.
Yes, logging a feed using the wh_accumulator process will handle a reset, the wh_accumulator can only increase. See user guide for logging wh pulse data:
The issue I have is I am measuring a Gas Meter by watching the turning dial. So am only able to count each turn. I don’t need to accumulate them and work out the ticks per hour, like in an electric meter. So do I just send 1s to emoncms and let the Accumulator collect them? But what if the link to emoncms breaks and I’ve lost a few ticks. Hence I thought I should count the ticks locally and then send the ever increasing total to emoncms. The issue I then have is how do I work out if I should increment by Accumulator by just one or by the number of ticks missed.
My quick hack so far has been that I count the ticks locally and just publish the total to emoncms at each tick. But then on a reset or restart, I loose everything that I had counted previously.
No. The consensus opinion is you should accumulate the count at source and send the running total to emonCMS and log it there. Read again what Glyn wrote above: “logging a feed using the wh_accumulator process will handle a reset…” So if you lose a few readings (not ticks - the ticks have already been accumulated), all you have is a big step instead of a few small ones. If the count resets, the emonCMS accumulator recognises the ‘impossible’ new low count and continues adding the difference between received values from where it left off, so all you lose is any pulses not sent when the source accumulator falls over and any arriving before it recovers. (At least, that’s my understanding of the internal details.)
I can confirm that sending an ever increasing number Input to a wh_accumulator works fine. I thought the wh_accumulator was doing some fancy accumulation per hour.
