My actual code is:
CAYENNE_OUT_DEFAULT() {
// has the current request achieved a value state?
if (meterRequests[cayenneMeterRequestIndex].hasCurrentValue()) {
// retrieve the channel (-1 is a sentinel meaning "do not log")
int cayenneChannel = meterRequests[cayenneMeterRequestIndex].cayenneChannel();
// should this metric be sent to Cayenne?
if (cayenneChannel > 0) {
// yes!
const char* cayenneDataType = meterRequests[cayenneMeterRequestIndex].cayenneDataType();
const char* cayenneUnits = meterRequests[cayenneMeterRequestIndex].cayenneUnits();
// this is the value to log
float digestValue = meterRequests[cayenneMeterRequestIndex].referenceValue();
// log the value
Cayenne.virtualWrite(cayenneChannel, digestValue, cayenneDataType, cayenneUnits);
}
}
// advance to the next request (unconditional)
cayenneMeterRequestIndex = (cayenneMeterRequestIndex + 1) % numberOfMeterRequests;
}
hasCurrentValue() guards against CAYENNE_OUT_DEFAULT being invoked before the sketch has had time to acquire metrics from the electricity meter. There are four items in the metrics array (voltage, current, frequency and accumulated kWh) and each invocation of CAYENNE_OUT_DEFAULT sends exactly one of those at a time. In other words, if CAYENNE_OUT_DEFAULT sends a voltage measurement for time period T(n) then another voltage measurement will not be sent until time period T(n+4).
On the topic of trigger values and, more specifically, the sendTriggerValue() API call mentioned in the link you provided, I am not using that. I set up the trigger in the Cayenne web interface, loosely paraphrased as “if voltage exceeds 253 then send an email”.
Now I’d like to turn to the idea of a 90-per-day notification limit. I do not recall reading about such a limit before but now that I am aware of it, I’m quite happy with the idea. If grid voltage in my part of the world in any given 24 hour period gets so bad that Cayenne needs to stop after 90 emails then the first 90 will already have given me plenty of notice that my electricity provider is up to no good. If I then have to wait until either midnight or +24 hours before emails start coming in again, so be it.
But let’s test the hypothesis that hitting the 90-per-day notification limit is the cause of the emails going walkabout. The first screen shot in this thread that shows the trigger details records the trigger having fired 10172 times since it was created with a “last run” of “10/13/19 1:33pm”. The corresponding values from the second screen shot are 10189 trigger events with a last run of 10/14/19 3:12pm. That’s 17 in just over a day. Nowhere near the limit of 90. Now let’s drill into the detail:
Ignoring, for the moment, that the last successfully received email was on 8 October, let’s just assume that the Oct 13 1:33:14 trigger was the 90th of a sequence and caused the notification limit to come into effect. The question becomes, does the notification limit reset at midnight or is it a rolling 24 hours?
If it resets at midnight then all 17 triggers on Oct 14 should have resulted in emails. If it is a rolling 24 hour period then that expired at 1:33:14 on Oct 14 so the three triggers after that should have resulted in emails.
It seems to me that, no matter how this particular cake is cut, it leads back to the conclusion that somewhere between 3 and 17 trigger firings should have resulted in emails arriving. They didn’t, so I don’t see that there is any evidence to support the hypothesis that the 90-a-day limit is the explanation. I think it is far more likely that the problem will be traced to the email delivery system (which is why I keep banging-on about it).
Having said all that, I have created a new trigger via the web UI. Grid voltage has not exceeded 253 since I did that so I will have to wait until my electricity distributor starts sending me “dirty power” again before I will be able to say whether (a) the new trigger has fired and, if so (b) whether an email has arrived.
Watch this space…
