just logged in and found a random input listed.
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);
essentially says if there is a working connection log the error, otherwise (if there is no working connection) just carry on as if nothing’s wrong.
Presumably this was done to hide all the “failed to connect” error that used to happen, but along with it has gone any useful info, unless of course it raises and exception with a working connection.
I think it would be marginally better to have something like
if ($connected) {
$log->error($e);
} else {
$log->info($e);
}
so that the errors can be seen if the “info” log level is selected. But that still doesn’t seem right to me.
This maybe just a coincidence and totally unrelated, BUT, not so long ago I installed a dropbox utility to a Pi3 and I had to remove it again as it regularly brought the Pi to it’s knee’s, I mean to the point I could barely ssh in. I don’t recall off-hand what code I used, but it certainly wasn’t anything node-red as I don’t use it.
The emonhub.log’s for the time leading up to and beyond the time of the incident (19hrs previous) would be very useful. As would your emonhub.conf nodes section.
If the “emonth1” node is correctly defined emonhub will not allow anything that doesn’t conform to that definition through. So if it is defined correctly the “rogue node input” has come from elsewhere bypassing emonhub. Otherwise a tighter definition will prevent further occurrences. But the emonhub.log (if you have it) will be more exact, ie we should see if that packet passed via emonhub and how, rather than assuming the node definition is working.
emonhub.txt (1.2 MB)
#######################################################################
####################### emonhub.conf #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### http://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
#######################################################################
####################### emonHub settings #######################
#######################################################################
[hub]
### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
loglevel = DEBUG
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
####################### Interfacers #######################
#######################################################################
[interfacers]
### This interfacer manages communication to BMW API for electric car monitoring
[[BMWi3]]
Type = EmonHubBMWInterfacer
[[[init_settings]]]
timeinverval =600
duringchargetimeinterval=60
nodeid = 28
tempcredentialfile = /tmp/bmwcredentials.json
bmwapiusername = username
bmwapipassword = password
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
[[RFM2Pi]]
Type = EmonHubJeeInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0
com_baud = 38400 # 9600 for old RFM12Pi
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
subchannels = ToRFM12,
group = 210
frequency = 433
baseid = 5 # emonPi / emonBase nodeID
calibration = 230V # (UK/EU: 230V, US: 110V)
quiet = true # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
# interval = 0 # Interval to transmit time to emonGLCD (seconds)
[[MQTT]]
Type = EmonHubMqttInterfacer
[[[init_settings]]]
mqtt_host = localhost
mqtt_port = 1883
mqtt_user = emonpi
mqtt_passwd = emonpimqtt2016
[[[runtimesettings]]]
pubchannels = ToRFM12,
subchannels = ToEmonCMS,
# emonhub/rx/10/values format
# Use with emoncms Nodes module
node_format_enable = 1
node_format_basetopic = emonhub/
# emon/emontx/power1 format - use with Emoncms MQTT input
# http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
nodevar_format_enable = 1
nodevar_format_basetopic = emon/
## [[emoncmsorg]]
## Type = EmonHubEmoncmsHTTPInterfacer
## [[[init_settings]]]
## [[[runtimesettings]]]
## pubchannels = ToRFM12,
## subchannels = ToEmonCMS,
## url = https://emoncms.org
## apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
## senddata = 1 # Enable sending data to Emoncms.org
## sendstatus = 1 # Enable sending WAN IP to Emoncms.org MyIP > https://emoncms.org/myip/list
## sendinterval= 30 # Bulk send interval to Emoncms.org in seconds
#######################################################################
####################### Nodes #######################
#######################################################################
[nodes]
## See config user guide: http://github.com/openenergymonitor/emonhub/blob/master/configuration.md
[[5]]
nodename = emonpi
[[[rx]]]
names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
datacodes = h, h, h, h, h, h, h, h, h, h, L
scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p
[[6]]
nodename = emontxshield
[[[rx]]]
names = power1, power2, power3, power4, vrms
datacode = h
scales = 1,1,1,1,0.01
units =W,W,W,W,V
[[7]]
nodename = emontx4
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[8]]
nodename = emontx3
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[9]]
nodename = emontx2
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacode = h
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[10]]
nodename = emontx1
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacode = h
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[11]]
nodename = 3phase
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[12]]
nodename = 3phase2
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[13]]
nodename = 3phase3
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[14]]
nodename = 3phase4
[[[rx]]]
names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[19]]
nodename = emonth1
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[20]]
nodename = emonth2
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[21]]
nodename = emonth3
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[22]]
nodename = emonth4
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[23]]
nodename = emonth5
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[24]]
nodename = emonth6
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[25]]
nodename = emonth7
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[26]]
nodename = emonth8
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[19]]
nodename = emonth1
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
Allows any data presenting itself as node 19 to be passed to emoncms as long as the payload has an even number of bytes (ie undefined number of ints)
[[19]]
nodename = emonth1
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacodes = h,h,h,h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
will only allow data packets that are exactly 8 bytes through to emoncms. (notice the use of “datacodes” in place of “datacode” too)
I haven’t checked the emonpi variant of emonhub’s code for this yet but, I do not know what the result is of passing a packet with more than 4 ints and reaching the point where emonhub is applying the names and scales. I do not know if it has been written to handle the error if there is no name or scale available for the 5th (and subsequent) values. Perhaps this is the cause of you loss of data??? (if it’s an unhandled occurrance). have you noticed these extra inputs previously at all?
ps the emonhub.log is too recent to show anything relating to this occurance
I have made the change in the emonhub
This would be useful too know…
Yes I have, cannot remember the names.
Can you perhaps at least remember if they overlapped your valid nodes as this one does and/or if you noticed these extra inputs around the same time as any “emonpi stops updating” events?
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.
1 Like
I’ve seen this before. No explanation they just stopped eventually 
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.
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.
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.
@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)
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 
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
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”