Testing each component to find the problem

Hi all,

I am a total noob in electronics and decided I should try to do a project for fun.

Ordered :

  • 1x fully assembled emonTx v3 
  • 1x CT
  • 1x raspberry with pre-loaded SD card and RF
  • 1x WiFi dongle

Followed this guide : https://github.com/openenergymonitor/documentation/blob/master/Applicati...

Couldn't get in raspberry pi at first but after two days of diligent googling, managed to hook it up to a monitor instead of using ssh from my laptop.(somehow putty and zenmap didn't work on my laptop) 

Now I am able to configure my Raspberry but I can't get any input at emoncms, it shows 

"No inputs created

Inputs is the main entry point for your monitoring device. Configure your device to post values here, you may want to follow the Input API helper as a guide for generating your request."

 

Steps I took to solve this problem but encounter more problem.

So I thought it's the emonTx v3 since the guide above did mention something about flashing the emonTx v3 (File > sketchbook > OpenEnergyMonitor > emonTxFirmware > emonTxV3 > RFM12B > Examples > emonTxV3_continuous_kwhtotals_noeeprom.) The emonTx v3 died! There is no light whatsoever and I thought I have burned the device. Thankfully, googled abit and realize that I indeed have the RF69 instead of RFM12. So I re-uploaded it with the "emonTxV3.4 Discrete Sampling" and got it back alive again. But this still didn't solve my original problem of not getting anything in emoncms

I figured the best way to solve this is step by step, so 

As far as I know, it's emonTx v3 (RF) to RFM69Pi - 433MHz (physical connection) to Raspberry (Ethernet - if I can't get it to work using RJ45, no point trying WiFi) to Emoncms. (Modes of communication in bracket)

How do I test whether emonTx is sending anything to the raspberry?

How do I test if raspberry is receiving anything from emonTx?

How do I test if raspberry is sending anything to emoncms? (minicom pops up abit so I am going to do some research on it)

If all of the three questions above work I guess I should have the whole thing working right?

pb66's picture

Re: Testing each component to find the problem

Assuming you are able to ssh into the emonBase and you are using the most recent SDcard image from the shop the best thing to do is take a look at the emonhub.log, But first you can confirm data arriving at the RFM2Pi by checking for a tiny green LED that flashes each time a new packet is received,(it's easy to miss even when you know it's there and working) if you are seeing a single flash every few seconds then check emonhub.log

emonhub -dl  will display recent and on going log messages until you use ctrl-c to stop.

The default loglevel may noy reveal much so I would recommend setting the loglevel to DEBUG in emonhub.conf until you are up and running.

emonhub -c will open emonhub.conf for editing ( use the rpi-rw command first if in read-only mode )

If you didn't see any flashes then try moving the emonTx closer to minimize range issues etc and confirm you have a Red LED illuminated after first powering up the emonTx for a few seconds. The emonTx will only run if there is a CT connected to channel 1 and it only checks at start up so the correct order is connect CT1 then connect AC power (or batteries/DC) confirm red LED on emonTx, wait 10-20 seconds check for occasional green flash on RFM2Pi.

Paul 

 

chuayq's picture

Re: Testing each component to find the problem

Thanks for your detailed reply ^^

I can't ssh into the emonbase as zenmap and putty didn't work for me. I hook it up to a monitor to login instead. :) I am using the pre-loaded SD card as I don't have any confident I am able to create the image myself.

The RF69Pi(Not RFM2Pi, did I get the wrong one? It's bundle in the shop) has flashed red light when I turn on the raspberry Pi B+. But the flashes is red every 10 secs, not green, that means no data is arriving right?

I used the command emonhub -c and the loglevel = DEBUG, then I ran the command emonhub -dl and I got a bunch of these.

2015-03-13 07:15:43,930 DEBUG 69 NEW FRAME: 1426230943.93 OK 10 0 0 0 0 0 0 0 0 8 92 0 0 (-50)

2015-03-13 07:15:43,933 WARNING 69 RX data length : 12 is not valid for datacodes['L', 'h', 'h', 'h', 'h', 'l', 'l', 'l', 'l']

the number just keep increasing

The emonTx v3 is 10cm away from the raspberry Pi, so I guess it's not range issue.(Anyway, how far can the signal go?)

EmonTX does have a red light on for awhile when turn on and flashes every 10secs, the CT is connected to channel 1 before I turn on EmonTx so the order should be correct, I read about this order somewhere.

The only thing different from your description is that there is no green flashes at the RF69Pi, I have stared at it for 1min and there is a slight red flash every 10 secs. The physical connection should be correct as there is a red light at startup of the raspberry Pi.

 

 

 

 

 

 

chuayq's picture

Re: Testing each component to find the problem

Did some googling and changed the nodes section back to when it first came. The error above is gone. Did a sudo service ntp restart it didn't work as the timing is still the same. Manually set the time using sudo date -s "Tue Jun 9 12:26:32 UTC 2015"

And now I got this

2015-06-09 12:27:40,101 DEBUG 166 NEW FRAME : 1433852860.1 OK 10 0 0 0 0 0 0 0 0 145 92 0 0 (-55)

2015-06-09 12:27:40,112 DEBUG 166 TimeStamp : 1433852860.1

2015-06-09 12:27:40,122 DEBUG 166 Node : 10

2015-06-09 12:27:40,131 Values : [0, 0, 0, 0, 23697, 0]

2015-06-09 12:27:40,133 RSSI : -55

LED on RF69Pi is still red every 10 secs, there is still nothing on emoncms.org

Read up that the nodes section can be ignored and no changes required from the OEM standard. I didn't quite understand what does the nodes section do or when do I need to customize it. Since I plan to get afew emonTX to one raspberry. 

pb66's picture

Re: Testing each component to find the problem

Ahha! the warning message tells me you changed the [[99]] in the "example" node to [[10]], effectively incorrectly specifying node 10's format. so because it doesn't fit (expecting 28bytes recieved 12) it's rejecting them. Change the [[10]] back to [[99]] and it should work.

I wasn't aware the led color on the rfm69pi had changed from the rfm2pi, I needn't of specified a colour in hind sight as there is only one. 

Just to recap the emontx is sending as you have a 10 second flash

The rfm??pi is receiving as the led is flashing every 10s to confirm receipt

Ranges can vary considerably depending on various factors but now you can use the RSSI values to determine best placement.

Paul

chuayq's picture

Re: Testing each component to find the problem

Thanks Paul!

I changed it back to 99 but I am still seeing "Node: 10" in my previous post? Is it because the Node represent the dip switch on emonTx? 

Anyway, since rfm69pi is flashing means it's receiving data and the log didn't say any error or warning. So I guess the problem is with raspberry Pi to emoncms.org through ethernet connection?

Any method I could pump in some fake data into raspberry pi to see whether emoncms.org is receiving anything?

Because from your post I gathered that the flash means it's receiving data. But receiving and accepting it is two different thing right? So if we can send data to emoncms.org, it will means that it is not accepting the data, if nothing goes through, it will means that this is a problem with raspberry Pi and emoncms.org

Anyway, I re-checked all my code, just in case I typed wrongly but everything seems to be in order. I have attached three picture I took just in case there is something I missed. :)

chuayq's picture

Re: Testing each component to find the problem

Just a short update: I tried pumping in data from my web browser based on the API helper webpage. It works. So I guess there is nothing wrong with my account at emoncms. The only problem is I am still not getting anything from my raspberry pi. :(

pb66's picture

Re: Testing each component to find the problem

Replacing [[10]] with [[99]] wasn't supposed to change the node id, you should still be receiving node 10, but without the example settings being applied to it.

Node 10 is now passing through emonhub and being handled with default settings.

Node 99 does not exist, therefore the example settings specified for [[99]] are redundant (hence the use of 99 for an example).

When you had [[10]] the example settings were incorrectly causing emonhub to expect something different of node 10 and when it wasn't so it discarded the frames.

From your Pics I can see you have the same apikey set for both the local and remote emoncms, that is highly unlikely to be the case, if you are running remote AND local accounts the account that isn't working's apikey is wrong in emonhub.conf. If you only have local OR remote emoncms one of the settings sections in emonhub.conf needs disabling (delete or comment out).

The led flash indicates a successful packet, every flash should result in a packet passing through emonhub to emoncms.

In emonhub.conf change loglevel = WARNING to loglevel = DEBUG and observe the packets arriving an being processed and dispatched by emonhub using the command tail -f /var/log/emonhub/emonhub.log.

The photo's have now served their purpose you should take them down as they expose your apikey, if you are not able to do that one of the mods will be able to do it for you.

[Done - RW]

Paul

EDIT - just dawned on me you are already running loglevel = debug, You should post a log excerpt .

chuayq's picture

Re: Testing each component to find the problem

Sorry for the late update, I was sick for the pass few days. And thanks for your help!

Move the entire setup to my desk, strip open the wire of an hair dryer(live and neutral pins only) and tap onto the live wire of the hair dryer.

I am getting the below before I turn on the hair dryer

2015-06-09 17:03:34,324 DEBUG 8 NEW FRAME : 1433869414.32 OK 10 1 0 0 0 0 0 0 0 218 90 0 0 (-29)

2015-06-09 17:03:34,333 DEBUG 8 TimeStamp : 1433869414.32

2015-06-09 17:03:34,339 DEBUG 8 Node : 10

2015-06-09 17:03:34,346 Values : [1, 0, 0, 0, 23258, 0]

2015-06-09 17:03:34,349 RSSI : -29

I am getting the below after I turn on the hair dryer

2015-06-09 17:03:55,627 DEBUG 8 NEW FRAME : 143869435.63 OK 10 242 253 0 0 0 0 0 0 159 90 0 0 (-30)

2015-06-09 17:03:55,635 DEBUG 8 TimeStamp : 143869435.63

2015-06-09 17:03:55,638 DEBUG 8 Node : 10

2015-06-09 17:03:55,640 Values : [-526, 0, 0, 0, 23199, 0]

2015-06-09 17:03:55,642 RSSI : -30

 

From the readings above, I guess I am indeed receiving data without error. The only problem is there is nothing posted on emoncms. Did ifconfig to get the ip and I pinged it using my laptop and it's connected, so connection is not a problem, and my network does have internet.

As you have suggested, I have commented out the local section as I believe the emoncms is on the web. I only have an emoncms account and I didn't do any additional setup. Do I need to configure it for it to receive the data?

I don't know if the images in the SD card of the raspberry is causing any problem. Do you know any link I can download the pre-loaded images? I am hoping this will solve my problem as I do not know if I have destroyed certain setup I am not suppose to without knowing it.

pb66's picture

Re: Testing each component to find the problem

The bits of you've provided to indicate the sensing and hub-to-node comms is good. I the log there should also be messages relating to the forwarding to emoncms. These should show if the data is being packaged up, addressed and sent correctly and what the response is.

The only "settings" that link the emonbase (emonhub) to emoncms.org are the url and apikey.

You can re-download the image (I believe) you have from 

http://openenergymonitor.org/files/emonSD-13-03-15.zip

or

http://oem.aluminumalloyboats.com/oem/emonSD-13-03-15.zip

Paul

chuayq's picture

Re: Testing each component to find the problem

Hey, thanks for your help again.

That's all the messages I got, and they keep repeating with every communication, just the numbers are different. I didn't see any other messages so the problem may really be me deleting some setting without knowing it, since you said there should be a log about forwarding as well.

The SD card I have only have 50MB+ space open for use despite it being a 4GB card. I believe some part is locked so people cannot tampered with the system. The links you provided needs 1.2GB worth of space, which should be completed after 18hours. Guess I need to look for a new SD card. Hopefully I can get it this weekend. :)

pb66's picture

Re: Testing each component to find the problem

If there are no error messages the chances are emonhub doesn't perceive any error's, that doesn't mean there arn't any, just that they are not obvious errors.

When emonHub starts it will create each of the interfacers (and reporters)  defined in emonhub.conf and if loglevel = DEBUG is set it will log the process, so if it attempts to create a interfacer (or reporter) it will log the attempt and  if something isn't right it will log the error, if the settings ok enough for the creation but do not work emonhub will then log an error when a problem is encountered.

So if you are sure nothing has been logged for the "emoncms" reporter then it didn't attempt it and that points to a typo or similar in that section of the emonhub.conf. In emonhub.conf [reporters] you should have

[[ unique emoncms themed name ]]

        Type = EmonHubEmoncmsReporter

        [[[init_settings]]]

        [[[runtimesettings]]]

               url = http://emoncms.org

               apikey = 32 character read write apikey 

If you are unsure about the messages at start up then just restart emonhub using emonhub -r or sudo service emonhub restart and immediately open the log using emonhub -dl or tail -f /var/log/emonhub/emonhub.log to watch the start up messages. 

If the result is not 100% obvious then report back, possibly with a log and or conf excerpt before making any drastic moves as I don't think there is anything fatally wrong at this point.

As for the "replacement" image it is not intended to be installed to the remaining space but to replace the whole SDcard content. which I don't think it is necessary just yet.

Paul  

 

chuayq's picture

Re: Testing each component to find the problem

Reporting back. :)

My Reporter is as follows:

[[emonCMS]]  <----Can I ask if I can just typed anything here right? Do I have to matched it to something?

type = EmonHubEmoncmsReporter

[[[init_settings]]]

[[[runtime_settings]]] <----Mine has an underscore in between, changed it and it works

url = http://emoncms.org

apikey = My read write apikey here, double checked it's correct :)

 

Edit: It is working now! I can't believe it's the underscore that's causing the problem. :D It's so awesome!

pb66's picture

Re: Testing each component to find the problem

Ok! The problem is due to some inaccurate info creeping into the emoncms documentation sometime ago. same issue in this "RFM2pi data not appearing in Inputs list" thread which prompted a correction back in April so not quite sure how you ended up with that, but still.

Change the "type" to "Type" and remove the underscore from "runtimesettings" and you should be all sorted.

The name of each interfacer or reporter MUST be unique, if there are duplicates the config file cannot be parsed and the "errors" will not bee seen by emonHub, other than that I would keep them short for a tidy log output and not introduce any symbols until you after you have tried and tested for a time. I am unaware of any issues and it is intended to be totally user choice but it has not been tested with anything beyond alpha-numeric and "_-" characters.

Paul

chuayq's picture

Re: Testing each component to find the problem

I got the incorrect info based on the link in my first post (https://github.com/openenergymonitor/documentation/blob/master/Applicati...) it was corrected on 30th April. I guess some part of it wasn't corrected?

Thanks for the heads up. I will keep the name short and to the point. :) After I am familiar with what's going on, I will try to send those data into a database and see how it goes. :D

pb66's picture

Re: Testing each component to find the problem

Thanks for the link, I have submitted a request for a correction.

https://github.com/openenergymonitor/documentation/pull/2/files

Paul

TrystanLea's picture

Re: Testing each component to find the problem

Thankyou Paul, chuayq, I have merged the changes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.