So, I’m pretty convinced the issue is with how Emonhub & RFM2Pi accepts injected commands from NodeRed. If I am using real world data with any decimal points, then that data causes Emonhub’s RFM2Pi to crash out.
2019-01-13 12:25:49,314 DEBUG MQTT Nodeid: 20 values: 12,25,22,498.225,0,6335.8210548683,0
2019-01-13 12:25:49,315 DEBUG MQTT 10127 Sent to channel' : ToRFM12
2019-01-13 12:25:49,513 WARNING RFM2Pi Exception caught in RFM2Pi thread. Traceback (most recent call last):
File "/home/pi/emonhub/src/emonhub_interfacer.py", line 40, in wrapper
File "/home/pi/emonhub/src/emonhub_interfacer.py", line 123, in run
File "/home/pi/emonhub/src/interfacers/EmonHubJeeInterfacer.py", line 81, in add
txc = self._process_tx(cargo)
File "/home/pi/emonhub/src/emonhub_interfacer.py", line 576, in _process_tx
for b in ehc.encode(dc,int(scaled[i])):
ValueError: invalid literal for int() with base 10: '498.225'
2019-01-13 12:25:49,666 WARNING MainThread RFM2Pi thread is dead.
2019-01-13 12:25:49,668 WARNING MainThread Attempting to restart thread RFM2Pi (thread has been restarted 2 times...
If I manually craft a string of numbers within NodeRed with no decimal point (not sure how to take a number and strip off any decimal points as a function…) and send that to emonhub/tx/20/values via MQTT then I get this log:
2019-01-13 12:24:37,407 DEBUG MQTT Nodeid: 20 values: 12,20,10,624,0,6335,0
2019-01-13 12:24:37,407 DEBUG MQTT 10105 Sent to channel' : ToRFM12
2019-01-13 12:24:37,409 DEBUG MQTT Publishing: emon/emonglcd/temperature 23.12
2019-01-13 12:24:37,410 DEBUG MQTT Publishing: emon/emonglcd/rssi -61
2019-01-13 12:24:37,412 INFO MQTT Publishing: emonhub/rx/20/values 23.12,-61
2019-01-13 12:24:37,542 DEBUG RFM2Pi 10105 sent TX packet: 20,12,20,10,112,2,0,0,191,24,0,0,s
So the reason my GLCD is still not responding is that RFM2Pi is mangling that string of numbers up as it pleases and the GLCD sees too many bits of info and rejects it?
[Edit] Using Roberts debug stetch, the GLCD doesn’t appear to pick up any transmissions from the pi on node 5, despite the TX packet 20,12,20,10,112,2,0,0,191,24,0,0,s being sent in the pi’s logs. Very odd! If I enable time signals from the pi, those do come through however, but they are not the time signals we’re now looking for, given the SolarPV sketch expects time and wattage data in the one transmission.
@alandpearson or @TrystanLea can you give your input on this, given the recent experience of the changes made? Cheers