The emonPi shield is an ATmega328 (with Arduino Uno serial bootloader) based energy monitoring shield for the Raspberry Pi, in addition to doing energy and temperature monitoring on board it also has a RFM69 radio transciever module for receiving and sending data to other wireless nodes. The software running on the emonPi shield is a combination of the RFM12demo example using JeeLib RFM69 driver developed by JeeLabs and the energy monitoring and temperature monitoring code seen on the emonTx V3 using the EmonLib energy monitoring library. Data generated by the emonPi shield and received/sent from the RFM69 network is transferred to the Raspberry Pi via the internal serial port (/dev/ttyAMA0) using JeeLib packet format: space seperated byte value string used by the JeeLabs RFM12demo example.
On the Raspberry Pi the serial port that connects to the emonpi shield is read by emonhub, from emonhub's perspective the emonpi shield appears as any other wireless node. Node data read from the serial port looks like this:
OK 10 0 100 0 200 0 100 (emonTx V3 data received via rfm69i transceiver)
OK 5 0 1 0 2 0 3 (emonpi shield data generated on the shield)
The source of the data is distinguished by the node ID, which is the first number after the OK. Every number after the OK and the nodeid is a byte value 0 - 256.
Why byte value string?
The origin of the reason data is received from RFM12demo as a byte value string is that structures are used to build the RFM packet on the wirless nodes. Using structures makes it possible to send data with much fewer bytes than sending data as a string. A typical structure definition on the emontx looks like this:
typedef struct { int power1, power2, power3, power4, Vrms, temp; } PayloadTX;
In the emonTx structure every variable happens to be an 2 byte integer so the first 2 bytes of the payload will be power1, the next two bytes power2 and so on. When the rf payload data is received by the RFM transciever its just a series of bytes which then need to be converted back to their real values. This series of bytes is the space seperated byte value string sent from the emonPi shield to the Raspberry Pi serial port which is then decoded by emonHub.
The byte value string is decoded back into real values in the EmonHubJeeInterfacer in emonHub according to the decoder specification in emonhub.conf
[[15]]
nodename = EmonPi
firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
hardware = emonpi
[[[rx]]]
names = power1,power2,pulseCount,Vrms,T1,T2,T3,T4,T5,T6
datacode = h
scales = 1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01
units = W,W,"",V,C,C,C,C,C,C
[[[tx]]]
The real values are then made available via an internal bus for other emonhub interfacers to use.
The MQTT Interfacer published the node data to the mosquitto MQTT server running on the emonpi. The topic string contains the nodeid and specifies that its received (rx) data.
topic csv values
emonhub/rx/10 100,200,300
emonhub/rx/15 1,2,3
The MQTT Interfacer also subscribes to topics starting with:
emonhub/tx/#
The topic emonhub/tx/nodeid is used to send data from emoncms or other applications on the emonpi back up to the emonpi shield or the rfm network, designed to be used for control.
The emonPi LCD script subscribes to the emonhub/rx/# topics directly in order to print the power values to the emonPi LCD display.
The emonpi will have the low write version of emoncms that's running locally enabled by default rather than needing to be enabled as was the case in the previous raspberrypi sd card image.
Even if the local emoncms is not used for storing data it can be used for emonhub configuration and checking the data received from the emonpi shield and rfm network.
The local emoncms can now be used for editing the emonhub.conf file via the browser and viewing the emonhub.log to check for errors. This is intended to reduce the need to SSH into the raspberrypi.
The local emoncms subscribes to the emonhub/rx/nodeid messages published by the emonhub MQTT interfacer via the Modules/nodes/nodes_mqtt_process.php script or emoncms-nodes-service script. This script also reads the nodename, firmware, hardware and variable names and units from emonhub.conf which is used to provide this information in the nodes interface.