At this point it may be better to focus on just the temp sensor zero’s rather than the VAC, the fact the VAC was zero on one packet only is not conclusive, the VAC is measured and updated during every interval so even if there was a “glitch” it should be overwritten with the next reading, it reports 0 rather than “230” so it could be that at that particular point in time the AC wasn’t connected as the programmer was connected or something. I assume the TX is normally AC powered and there is no batteries or 5vdc mini usb or programmer attached?
With regard to the temp sensors the value of 300 is set at start up for each of the 6 variables and then the sketch goes on it’s merry way, if anything occurs to any of those variables they will never return to 300 unles the emonTx is restarted so I guess it could be a possible memory overflow or a glitch in the 1-wire library or implementation.
My original request to add the 300 fault condition was not to just add it at setup() but to change the way the value is returned, so rather than
for(byte j=0;j<MaxOnewire;j++)
emontx.temp[j] = 3000; // If no temp sensors connected default to status code 3000
// will appear as 300 once multipled by 0.1 in emonhub
in the setup() setting the values to “300” once only, the “300” should be added by the get_temperature() function so that it applies to every read of the temp sensors
int get_temperature(byte sensor)
{
float temp=(sensors.getTempC(allAddress[sensor]));
if ((temp<125.0) && (temp>-55.0)) return(temp*10); else return 3000; //if reading is within range for the sensor convert float to int ready to send via RF or value = 300 if not
}
in fact, I recommended the additional use of
for(byte i=0;i<MaxOnewire;i++) emontx.temp[i]=3010; // set all temp values to 301°c (301= never found & 300 = lost or out of scope)
in setup(), So that we could distinguish between “never seen”(301) and “gone faulty”(300) sensors. but the main “fix” was the modified function.
If this method was used the temp sensor value would only ever be zero if the temperature was actually 0 and if there was a glitch at any time the situation would be reassessed every read so that what ever value was presented is in fact current and not the result of a past incident.
This would avoid the “bitslip” which is it’s intention but it will not cure the root issue here, “something” is causing those 6 original values of 300 to vanish, reset or be set to 0.
see Re: Data loss due to RF packets getting corrupted for the original discussion about the “bitslip” issue.