Archived Forum

Hello Mike, a couple of thoughts.

1. Are both the emonpi and emonth's on the same radio group and frequency, are the radio group and frequency settings in emonhub.conf on the emonPi the same? You can check this from the emonhub config editor in emoncms on your emonpi.

2. Perhaps the node decoders in emonhub.conf are incorrect leading to no nodes appearing in the emoncms nodes interface? The emonhub configuration guide here might help https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md

Do you see anything being received in the emonhub log? You can check the log again from within emoncms on your emonpi.

The firmware hex installed to a 868 emonTH is different to a 433 emonTH, having fitted your own rfm69 have you confirmed the right firmware is installed? does it confirm the frequency in the startup sequence over serial?

Whilst checking the group id, If you set "loglevel = DEBUG" in emonhub.conf and check the logs there should be some signs of packets arriving with node ids in the range 19 to 26, might take a while due to the emonTH's 60s intervals.

Unless there is a "fault" somewhere the most likely cause is that the emonpi was first used before the emonTH firmware included a "pulse" value and I believe the current emonPi update routine will not overwrite existing emonhub.conf entries. A quick check is to look for the word "pulse" on the end of the "names =" line in each emonth node in emonhub.conf [nodes], if it's not there you can either add the additional name, datacode, scale and unit for each node or just delete all your unused [nodes] entries and update the emonpi again it should pull in all the current node configurations.

Paul

after some experimenting / trial an error the problem appears to reside in the EmonTH(s) , i checked the emonhub and everything appears correct including the "pulse" . The EmonPI i am using is brand new and does show the local DS1820B Sensor plugged in / reporting data. I swapped it with another new EmonPI i had on hand and it does the same exact thing. Upon powering up a EmonTH purchased with the RFM69CW pre installed the data appeared in the proper node immediately. Im stumped.

The EmonTHs have V2.6 Firmware for 433 Mhz - and the RFM69s i purchased from the EMON online store so they should not be different. 

Mike

What other serial printed info do you see when you have the programmer connected?

Does it complete the setup? does it print any values?

Paul

Paul , 

Here is a cut / paste of what the serial monitor shows for the EmonTH(s):

00
OpenEnergyMonitor.org
emonTH - Firmware V2.60
RFM69CW Init> 
Node: 26 Freq: 433Mhz Network: 210
Detected DHT22
No DS18B20
DHT22 Temperature: 23.40C, DHT22 Humidity: 30.80%, Battery voltage: 3.00V, Pulse count: 1n
DHT22 Temperature: 23.50C, DHT22 Humidity: 29.90%, Battery voltage: 3.00V, Pulse count: 1n

Thanks, 

Mike

That print seems to show all is in order that end, it doesn't directly confirm any data has been sent but the ongoing print tells us the code isn't getting stuck waiting for the rfm to respond as is usually the case with a rfm module fault. the serial stream is the equivalent of an led flash that would normally be assumed to mean the data was transmitted unless we can prove it definitely isn't being received at the other end.

Assuming we can rule out range etc, can you show us your emonhub.conf (obscure any wan apikeys)?

Paul

Paul , 

Below is the information you requested, but no lines have been edited from the original copy in either of the EmonPI units.  

As far as distance goes they are both inside my home less than 20 feet apart so that can be ruled out . 

#######################################################################
#######################      emonhub.conf     #########################
#######################################################################
###
### SPECIMEN emonHub configuration file
### Note that when installed from apt, a new config file is written
### by the debian/postinst script, so changing this file will do
### nothing in and of itself.
###
### Each Interfacer and each Reporter has
### - a [[name]]: a unique string
### - a type: the name of the class it instantiates
### - a set of init_settings (depends on the type)
### - a set of runtimesettings (depends on the type)
### Both init_settings and runtimesettings sections must be defined,
### even if empty. Init settings are used at initialization,
### and runtime settings are refreshed on a regular basis.
### Many settings below are "commented out" as they are not mandatory and
### have been included as a template or to provide alternative options
### removing the leading # will enable the setting and override the default
### Default settings are shown as comments on the same line as the setting
### eg #(default:xyz) "xyz" is set if the setting is "commented out".
###
### All lines beginning with '###' are comments and can be safely removed.
###
#######################################################################
#######################    emonHub  settings    #######################
#######################################################################

[hub]

### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
### see here : http://docs.python.org/2/library/logging.html
loglevel = DEBUG #(default:WARNING)

#######################################################################
#######################       Interfacers       #######################
#######################################################################

[interfacers]

### This interfacer manages the RFM2Pi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,
        
        # datacode = B #(default:h)
        # scale = 100 #(default:1)
        group = 210 #(default:210)
        frequency = 433 #(default:433)
        baseid = 5 #(emonPi default:5)
        quiet = false #(default:true)
        calibration = 230V #(UK/EU: 230V, US: 110V)
        # interval = 300 #(default:0)
        # nodeoffset = 32 #(default:0)

### This interfacer manages the RFM2Pi module
[[MQTT]]

    Type = EmonHubMqttInterfacer
    [[[init_settings]]]
        mqtt_host = 127.0.0.1
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016

    [[[runtimesettings]]]
        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,
        basetopic = emonhub/
        
[[emoncmsorg]]
    Type = EmonHubEmoncmsHTTPInterfacer
    [[[init_settings]]]
    [[[runtimesettings]]]
        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,
        url = http://emoncms.org
        apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        senddata = 1
        sendstatus = 1
        
#######################################################################
#######################          Nodes          #######################
#######################################################################

[nodes]

### List of nodes by node ID
### 'datacode' is default for node and 'datacodes' are per value data codes.
### if both are present 'datacode' is ignored in favour of 'datacodes'
### eg node 99 would expect 1 long and 4 ints, unless the "datacodes" line
### was removed, then "datacode" would make it expect any number of longs,
### likewise per value "scales" will override default node "scale", the number
### of "scales" must match the number of values or frame will be discarded.

[[5]]
    nodename = emonPi
    firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
    hardware = emonpi
    [[[rx]]]
        names = power1,power2,power1_plus_power2,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

[[19]]
    nodename = emonTH_1
    firmware = emonTH_DHT22_DS18B20_RFM69CW
    hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
    [[[rx]]]
       names = temperature, external temperature, humidity, battery
       datacode = h
       scales = 0.1,0.1,0.1,0.1
       units = C,C,%,V

[[20]]
    nodename = emonTH_2
    firmware = emonTH_DHT22_DS18B20_RFM69CW
    hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:OFF)
    [[[rx]]]
       names = temperature, external temperature, humidity, battery
       datacode = h
       scales = 0.1,0.1,0.1,0.1
       units = C,C,%,V

[[21]]
    nodename = emonTH_3
    firmware = emonTH_DHT22_DS18B20_RFM69CW
    hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:ON)
    [[[rx]]]
       names = temperature, external temperature, humidity, battery
       datacode = h
       scales = 0.1,0.1,0.1,0.1
       units = C,C,%,V

[[22]]
    nodename = emonTH_4
    firmware = V1_5_emonTH_DHT22_DS18B20_RFM69CW
    hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:ON)
    [[[rx]]]
       names = temperature, external temperature, humidity, battery
       datacode = h
       scales = 0.1,0.1,0.1,0.1
       units = C,C,%,V

[[10]]
    nodename = emonTx_1
    firmware =V1_6_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:OFF)
    [[[rx]]]
       names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse #Firmware V1.6
       #names = power1, power2, power3, power4, Vrms, temp                                           #Firmware =<V1.4 (un-comment)
       datacode = h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1 #Firmware V1.6
       units =W,W,W,W,V,C,C,C,C,C,C,p                   #FirmwareV1.6
       #scales = 1,1,1,1,0.01,0.1                       #Firmware =<V1.4 (un-comment) 
       #units =W,W,W,W,V,C                              #Firmware =<V1.4 (un-comment)
       

[[9]]
    nodename = emonTx_2
    firmware =V1_6_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:ON)
    [[[rx]]]
       names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse #Firmware V1.6
       #names = power1, power2, power3, power4, Vrms, temp                                           #Firmware =<V1.4 (un-comment)
       datacode = h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1 #Firmware V1.6
       units =W,W,W,W,V,C,C,C,C,C,C,p                   #FirmwareV1.6
       #scales = 1,1,1,1,0.01,0.1                       #Firmware =<V1.4 (un-comment) 
       #units =W,W,W,W,V,C                              #Firmware =<V1.4 (un-comment)
       
[[6]]
    nodename = emonTxShield
    firmware =emonTxShield
    hardware = emonTxShield
    [[[rx]]]
       names = power1, power2, power3, power4, Vrms
       datacode = h
       scales = 1,1,1,1,0.01
       units =W,W,W,W,V
       
[[23]]
    nodename = emonTH_5
    firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
    hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
    [[[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 = emonTH_6
    firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
    hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:OFF)
    [[[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 = emonTH_7
    firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
    hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:ON)
    [[[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 = emonTH_8
    firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
    hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:ON)
    [[[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

[[8]]
    nodename = emonTx_3
    firmware =V2_3_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:OFF)
    [[[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                   
 
[[7]]
    nodename = emonTx_4
    firmware =V2_3_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:OFF)
    [[[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

Aha!

The external temperature sensor appears to be missing from the serial print, this doesn't tell us whether it is in the rf transmission or not though.

You could try

[[26]]
    nodename = emonTH_8
    firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
    hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:ON)
    [[[rx]]]
       names = temperature, humidity, battery, pulseCount
       datacodes = h,h,h,L
       scales = 0.1,0.1,0.1,1
       units = C,%,V,p

in place of your [[26]]

or if that doesn't work attach an emonhub.log that lasts at least a few minutes.

Paul

Paul , 

Attached is a copy of the file , shows nothing for node 26 only node 5 that the unit purchased with a preinstalled radio is set for. 

Mike

I think we need a longer log than that - there is only 10 s there. The emonTx only transmits once every 5 minutes.

Attached is the full file compressed , the input i am looking for is from an EmonTH not a Tx 

Mike

[Paul - pb66 - has been very busy at work recently, it might be a little while before he can look at your data and respond.]

I can see input from node 23 at 2016-02-27 12:37:03,123,  at 12:38:03,505, at 12:39:03,824 and every minute after, so the TH is definitely transmitting and emonHub is definitely seeing it. It's sending 12 bytes, so the original Node definition should be correct, and indeed appears to be so, as it looks as if the data is being handled (but Paul must confirm this).

That's about the limit of my knowledge I'm afraid.

Yes, my apologies for not answering sooner. I've not been about much at all.

I do hope you have resolved this, it looks like Node 23 is performing as expected, but there are no signs of 26. If you only had the one node working, then the probability is the node was not set as expected, I think nodes 23 and 26 switch positions would be the same but inverted, so it's easily done.

If you did have both 23 and 26 running, then it would appear the node 26 device itself is probably at fault, as 23 proves the receiver etc is all good.

Paul

Paul , 

Yes I did have both running , and I am positive i had the switches correct , as I mentioned previously i have six units that perform the same way. No input shows on the Emonpi.

Mike

"as I mentioned previously i have six units that perform the same way"

Do they all perform the same?

You mention you have 6 units that you have fitted rfm modules to, you then say you are not getting any inputs and continue to discuss node "26". You provided a log and explained "shows nothing for node 26 only node 5" closer examination showed node "23" working. it was quite reasonable to assume "23" might be the missing "26" since there was no mention of "23". Does "Yes I did have both running" mean you have just 2 running or are all 6 running?

Thrown by the statment about them being all the same but "23" and "26" are clearly different I have re read the thread and reminded of a 7th emonTH, presumablly this is "23" ?. 

the fact "23" works proves the reciever works and that emonhub is processing the packets recieved. It does look like the modules are incorrect or incorrectly fitted, I doubt all 6 could be incoreectly fitted in the same manner unless orientated 180degs out and I'm guessing you will have already visually compared the working unit to the non-working units, plus I would of expected the firmware to hang if the rfm modules were not responding at runtime.

I now wonder if the modules you have fitted are 868 as they could be configured to act as 433 modules but the physical chariteristics (antenna length and componant values) would prevent them from working "effectively" at 433, they would probally have a range extending just a few centimetres (if at all). this could explain why the firmware doesn't halt and yet no packets are recieved.

Can you provide (links to) Hi res pics of a failed device's rfm module? (2mb limit on this site) 

I think the best way for you to move forward with this is to install the rfm2pi firmware to an emonTH to create an independent test transciever,

If installed to the known good "23" emonTH the quiet mode can be switched off to see the flow of any unsuccesfully decoded packets that are recieved, (this function is not available on the emonpi).

Alternatively or additionally you can Install the firmware to a suspect (868?) emonTH to see if you are getting any transmissions after setting one of the other suspect emonTH's settings to 868MHz also,

If you do try this don't use the existing hex files as they are compiled for a 8MHz device (rfm2pi has no ext xtal) just open the firmware in Arduino IDE and "upload" direct to emonTH via usb programmer as a "uno" type 16MHz device.

Paul

[There are pictures identifying the various radio modules in Resources > Building Blocks.  (RW)]