Archived Forum

Hi Jan

The logging you attached only tells us you have a lot of invalid stuff being picked up on the network, probably noise looking at the rssi values.

Can you set "quiet = true" in emonhub.conf and provide a better log with some info on what is or isn't happening, please sort the line wrapping or attach a .txt file rather than an unwrapped text block please.

Can you also confirm which sketch you are using with a url for it and have you confirmed any thing is happening on the v2 using the IDE's serial console after uploading the sketch?

Paul 

hi Paul,

tnks for quickly replay. yes, i set up the "quiet=true" option like  your advised. here you are a short cut from about  last 5 log mins, see att. i hope its right so

the sketch i have downloaded yesterday here
https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV2...

rg

jan

[There is no need to copy your post 3 times - please READ the top forum topic on the right. Duplicates deleted.]

i have compiled new sketch with the option "#define RF69_COMPAT 1"

There's an error in the sketch - #define RF69_COMPAT 0 appears twice. Delete one of those and ensure the remaining one is set as you require.

(It does not give an error at compile time, and if you have only changed the first occurrence, the emonTx will lock up and not transmit anything. That might explain the meaningless noise you see. I've flagged the problem to Glyn.)

Unfortunately the log still doesn't show any useful info, setting "quiet = True" roughly translates to "tell the rfm2pi module to discard any packets starting with a question mark" So either emonHub isn't sending that command, it isn't reaching the rfm2pi or the rfm2pi is ignoring the command.

None of these possibilities can be determined from a list of bad packets that shouldn't be there, you need to either scroll back to find relative info or better still reboot, this will empty the logs on a read-only OS and when the Pi has rebooted get the emonhub.log from the start to where there are only "DEBUG RFM2Pi Discarding RX frame 'unreliable content'?" entries (only the non-DEBUG RFM2Pi Discarding RX frame 'unreliable content'? stuff is useful), this should show whether the serial connection is ok ( I assume it is as you receive data albeit bad data) it will hopefully show the settings and whether there is a response to the "q1" command.

Just to be sure, I assume you have set the quiet mode in [interfacers][[RFM2Pi]][[[runtimesettings]]] in emonhub.conf.

Are you using the default rfm69pi firmware? have you used any update/upgrade routines from within emoncms? (If you haven't - don't as the emonpi image may try to write the emonpi firmware to the rfm69pi, I'm not sure if or how it has been safeguarded against at the moment) 

Paul

hi Paul,

tnks for your help. indeed there two entries about rf69.  i have compiled a new sketch. the nodes still inactive but the emonhub logs indicated  new information. i have attached the new emonhub.log and emonupdate.log . i hope its more suitable information in the files. tnks

sorry for dublicated posting

rg jan
 

Some info from the log

Line 10 - "2015-09-09 05:17:45,429 INFO MainThread Setting RFM2Pi quiet: 0 (0q)" tells us emonhub does not consider "quiet" as set, 0 is false, 0q is the command to be sent to the rfm69pi saying "turn quiet mode off" 

Line 23 - "2015-09-09 05:17:48,573 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz" tells us the current configuration and the absence of a trailing "1q" tells us quiet mode isn't currently set.

Line 32 - "2015-09-09 05:17:49,023 DEBUG RFM2Pi acknowledged command: > 0q" in emonhub logging the acknowledgment from the rfm2pi, of receiving the command "0q"

Line 33 - "2015-09-09 05:17:49,131 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz" shows that command was ignored confirms quiet mode is still inactive as there is still no trailing "1q"

EDIT - The issue seems to be emonhub is not processing the "quiet = " setting.

So it looks like an issue in the rfm69pi firmware, is also causing the lines 36 to 47 show the "usa" command "1p" is not recognised by the firmware and therefore printing the help text. that setting is for the emonpi only (AFAIK)

Line 51 - "2015-09-09 05:17:53,352 DEBUG RFM2Pi 8 NEW FRAME : OK 10 0 0 0 0 0 0 16 0 (-18)" shows node 10 is arriving at emonHub...But

Line 52 - "2015-09-09 05:17:53,388 WARNING RFM2Pi 8 Scales ['1', '1', '1', '1', '0.01', '0.1', '0.1', '0.1', '0.1', '0.1', '0.1', '1'] for RX data : [0, 0, 0, 0, 0, 0, 16, 0] not suitable" tells us it has been rejected because the 12 scales do not fit the 8 values. Try setting "scales = 1, 1, 1, 0.01", this should work if the correct "datacodes = h, h, h, h" are set as the payload for that sketch is power1. power2, power3, voltage(x100), all signed ints.

Correcting the node meta in the [nodes] section of emonhub.conf should get you some data flowing but it looks like there are some issues in the rfm69pi firmware too.

Paul

Thanks Paul,

that seemed to be the trick. The node 10 is now active.

i used followed config:

  nodename = emonTx_1
firmware = ""
hardware = ""
    [[[rx]]]
       names = power1, power2, power3, power4                                        
       datacode = h   
scales = 1,1,1,0.01
units = W,W,W,V

rg

jan
    

No problem.

The configuration looks good, it's ok use "datacode =" in place of "datacodes =" to define every variable the same datacode. Why have you called the AC voltage value power4 ?

You could also delete the "calibration = 230V #(UK/EU: 230V, US: 110V)" or similar line from the rfm2pi settings in emonhub.conf to remove the attempt to set the emonpi to use mode to tidy up the starting but it's not essential.

Paul