Emonpi low-write 9.8.25 - inputs stopped working

[Pukka (Paul)]

They would show up randomly and i would just delete them, cannot remember if they showed before it crashed, i will keep a better log over the next few days.

[borpin (Brian Orpin)]

@Pukka

just logged in and found a random input listed.

I’ve seen this before. No explanation they just stopped eventually

[borpin (Brian Orpin)]

@pb66

@borpin

I’d have expected an exception on 116 to be caught by the try catch.

Yes in a try/catch if the try fails the catch is executed, however that has been somewhat undermined by the content of the catch.

if ($connected) $log->error($e);

My point is that an exception in the client loop should always be handled (whether it logs it or not) and not propagate upwards (as the log appears to show) or is that not how it works in PHP?

try { 
    $mqtt_client->loop(); 
} catch (Exception $e) {
    if ($connected) $log->error($e);
}

For the item I linked to above, I think that perhaps it should be \Exception in the catch statement.

[Bernie_Carter]

I’ll second that, mine shows these “random” inputs as well from time to time.

Up till now I was blaming the occurance on a bad packet.

While we’re on that topic. One issue I did notice with Paul’s inputs as well as mine is that some of the input data will get truncated at random times so a reading of 110.1 may get truncated to 110.100000001. I have verified this data does not appear on the output stream of the emontx3 but does appear on the emonhub.

[pb66 (Paul)]

@Bernie_Carter

While we’re on that topic. One issue I did notice with Paul’s inputs as well as mine is that some of the input data will get truncated at random times so a reading of 110.1 may get truncated to 110.100000001. I have verified this data does not appear on the output stream of the emontx3 but does appear on the emonhub.

Can you provide more info or the emonhub.logs if it reoccurs?

This sounds like a simple float precision error but I’m not sure I understand correctly, “truncate” is to shorten without rounding, 110.100000001 could get truncated to 110.1 but not the other way round. often if a value is cast to a float eg float(110.01) it might result in a value like 110.100000001.

[Bernie_Carter]

@pb66
My bad, wrong choice of words there.

A current clip of emonhub shows the following:

2018-03-12 00:40:36,212 DEBUG    MQTT       Publishing: emon/emonpi/vrms 237.46
2018-03-12 00:40:36,214 DEBUG    MQTT       Publishing: emon/emonpi/t1 25.3
2018-03-12 00:40:36,215 DEBUG    MQTT       Publishing: emon/emonpi/t2 0
2018-03-12 00:40:36,217 DEBUG    MQTT       Publishing: emon/emonpi/t3 0
2018-03-12 00:40:36,218 DEBUG    MQTT       Publishing: emon/emonpi/t4 0
2018-03-12 00:40:36,219 DEBUG    MQTT       Publishing: emon/emonpi/t5 0
2018-03-12 00:40:36,221 DEBUG    MQTT       Publishing: emon/emonpi/t6 0
2018-03-12 00:40:36,222 DEBUG    MQTT       Publishing: emon/emonpi/pulsecount 87686
2018-03-12 00:40:36,224 INFO     MQTT       Publishing: emonhub/rx/5/values 8,9,17,237.46,25.3,0,0,0,0,0,87686
2018-03-12 00:40:36,315 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 32 32 0 0 0 0 52 96 0 32 32 0 3 160 0 32 0 0 32 224 (-104)
2018-03-12 00:40:37,024 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 2 0 8 0 96 175 36 0 42 108 0 137 224 42 68 20 192 44 78 128 (-99)
2018-03-12 00:40:41,044 DEBUG    RFM2Pi     6559 NEW FRAME : OK 5 4 0 9 0 13 0 187 92 254 0 0 0 0 0 0 0 0 0 0 0 134 86 1 0 (-0)
2018-03-12 00:40:41,047 DEBUG    RFM2Pi     6559 Timestamp : 1520815241.04
2018-03-12 00:40:41,048 DEBUG    RFM2Pi     6559 From Node : 5
2018-03-12 00:40:41,049 DEBUG    RFM2Pi     6559    Values : [4, 9, 13, 237.39000000000001, 25.400000000000002, 0, 0, 0, 0, 0, 87686]
2018-03-12 00:40:41,050 DEBUG    RFM2Pi     6559 Sent to channel(start)' : ToEmonCMS
2018-03-12 00:40:41,051 DEBUG    RFM2Pi     6559 Sent to channel(end)' : ToEmonCMS
2018-03-12 00:40:41,166 DEBUG    MQTT       Publishing: emon/emonpi/power1 4
2018-03-12 00:40:41,167 DEBUG    MQTT       Publishing: emon/emonpi/power2 9
2018-03-12 00:40:41,169 DEBUG    MQTT       Publishing: emon/emonpi/power1pluspower2 13
2018-03-12 00:40:41,170 DEBUG    MQTT       Publishing: emon/emonpi/vrms 237.39
2018-03-12 00:40:41,172 DEBUG    MQTT       Publishing: emon/emonpi/t1 25.4
2018-03-12 00:40:41,174 DEBUG    MQTT       Publishing: emon/emonpi/t2 0
2018-03-12 00:40:41,175 DEBUG    MQTT       Publishing: emon/emonpi/t3 0
2018-03-12 00:40:41,177 DEBUG    MQTT       Publishing: emon/emonpi/t4 0
2018-03-12 00:40:41,178 DEBUG    MQTT       Publishing: emon/emonpi/t5 0
2018-03-12 00:40:41,179 DEBUG    MQTT       Publishing: emon/emonpi/t6 0
2018-03-12 00:40:41,181 DEBUG    MQTT       Publishing: emon/emonpi/pulsecount 87686
2018-03-12 00:40:41,182 INFO     MQTT       Publishing: emonhub/rx/5/values 4,9,13,237.39,25.4,0,0,0,0,0,87686
2018-03-12 00:40:44,775 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 2 115 64 8 0 96 175 36 0 42 108 0 137 224 42 68 20 192 44 78 128 (-107)

[pb66 (Paul)]

Yes that’s a float precision issue, it’s ugly but it isn’t effecting the data.

in this line is shows the extended ugly floats

2018-03-12 00:40:41,049 DEBUG    RFM2Pi     6559    Values : [4, 9, 13, 237.39000000000001, 25.400000000000002, 0, 0, 0, 0, 0, 87686]

but those same values, which do not get explicitly rounded down appear correct as they are passed eg

2018-03-12 00:40:41,170 DEBUG    MQTT       Publishing: emon/emonpi/vrms 237.39
2018-03-12 00:40:41,172 DEBUG    MQTT       Publishing: emon/emonpi/t1 25.4

and

2018-03-12 00:40:41,182 INFO     MQTT       Publishing: emonhub/rx/5/values 4,9,13,237.39,25.4,0,0,0,0,0,87686

so it is only the printed entry in emonhub.log of the raw list of values that shows the float error which is fine, maybe tidied up later but it isn’t a concern. We do not want to start imposing precision levels just to make the log tidier but I will put it on the snagging list all the same

[Bernie_Carter]

Paul,

I thought it might be something of that nature since as I mentioned it’s not transmitted like that, and MQTT shows it correctly.

Bernie Carter

[danbates (Daniel Bates)]

In relation to …0000001 floating point errors… I came across this while finding a solution to an unrelated problem. Interesting to read for those inclined towards understanding binary and float maths.
I smirked at how python uses 3602879701896397 / 2 ** 55 to approximate 0.1

“15. Floating Point Arithmetic: Issues and Limitations — Python 3.10.0 documentation”

“python - Converting a float to a string without rounding it - Stack Overflow”