I just did some check and with min pulse set to 1ms it can count ~200 pulses in 10s which is 7.5kWh but when it goes to 9kWh (250 pulses in 10s) it counts just few pulses (less then 10 in 10s).
Can you please get your units right, you are totally confusing me. The unit of power is the kW, the unit of energy is the kWh.
A pulse represents a unit of energy, you have written that 10000 pulses represent 1 kWh, or 1 pulse equals 0.1 kWh.
A count of pulses over a period of time represents power, which is the rate at which energy is used. If you have the same number of pulses (10000) in an hour, the average power is 1 kW.
You should be able to reduce the min_pulsewidth to 0, or even take out the “if …” so that pulseCount++; is no longer conditional and there is no limit (except the speed of the processor and the time taken to process the interrupt) on the pulse rate? The limit on the minimum pulse width should not be necessary with an electronic switch, like your sensor; it is really only there for mechanical switches than can have contact bounce.
The boiler can run max 9kW and utility meter counts 10.000 pulses for 1kWh which is 10 pulses for 1Wh.
Changing min_pulsewidth did not helped even 0. I just uploaded firmware with pulseCount++ only in interupt and based on quick check it counted even high power. I will run it for some time and see.
So from longer perspective there are still events where it misses pulses. The utility meter is around 2-3kWh higher then emonTx values.
I just checked EmonHub Log and it returns:
Discarding RX frame ‘unreliable content’? 183 83 121 238 236 254 48 136 125 78 125 24 45 137 78 49 228 125 104 221 153 (-84)
Looks like it may drop some readings. Is it possible that it may cause the pulse losses?
@pb66 will tell you the exact meaning of “unreliable content”, but it looks to me as if that is noise or interference at a very low signal strength, and because there are not enough bytes for the message from your sketch. You should have 2 bytes for each ‘h’ value (everything except the pulse count) and 4 bytes for the ‘L’ pulse count, 26 bytes in total for the data, not counting the node number.
If it is from your emonTx, then actually no, it will not lose pulses in transmission, because the number sent is an accumulator, it continually increases forever, it is only reset to zero when the emonTx starts up.
Looks like low signal strength as opposed to low level noise / interference.
-84 dBm is fairly well “down in the dirt.”
Although, at that level, it wouldn’t take a high level of interference to mangle the data.
“Unreliable content” is any frames passed from the rfm2pi prefixed with a “?” ie any thing received but failed the crc checks.
I agree it is not likely any pulses are lost in transit as the following packet will have the running total pulsecount which will include the dropped packets contribution.