Direct serial connection, is emonhub receiving the data?

Getting Started
1

I’m brand new here, so apologies if this is in the wrong place or if it’s a really basic question. It seems like a pretty basic question, but I’ve run out of things to try, so here I am.

I installed an emonSD image on a plain vanilla raspberry 3, and I’m trying to connect it to my arduino uno r3. The idea is to flash the arduino with emontx firmware, do a direct serial connection, and have a cheap and easy way to read a couple of current taps.

First off, yeah, I know, the arduino is 5V. For right now I’m using a resistor divider to take the arduino TX pin and bring it down to a safe range for the raspberry input.

So I’ve tried two different bits of firmware on the arduino. First of all I used the emonTXV3_DirectSerial, but that seemed like it might have been out of date, so I switched over to emonTxV3.4 Discrete Sampling. I disabled RF since I’m direct connecting.

I’ve looked into the emonhub.conf configuration, trying to get emonhub to receive the serial data that the arduino has sent it, but nothing seems to show up.

Just to verify that the raspberry is in fact getting the data, I used minicom to monitor /dev/ttyAMA0 port, and verified that it was receiving the data from the arduino. So the data is getting to the raspberry, although I guess I don’t know that it’s the data emonhub is looking for. But I don’t see any evidence that emonhub is receiving packets. Should they show up in the log? How do I know when emonpi is actually getting data?

I’m not providing any way for the raspberry to talk back to the arduino, but I don’t think it needs to. It seems like the arduino just happily blindly broadcasts.

I can give more details, logs, etc, but maybe I should just leave it at this to start with. I’m hoping it’s just something dumb and easy. Thanks for any help you can give.

2

There’s nothing wrong with that.

What you need to do is make the serial output send exactly the same format as the radio, and that’s spelled out in the data structure “payload”. If that isn’t exactly right for what emonHub expects, the entire packet will be rejected because it is “corrupted”.

If you look at (DON’T USE) the 3-phase sketch, there’s a preprocessor switch (SERIALOUT) in that to do Serial data - look at how it’s formatted in there.

What emonHub expects is spelled out in emonhub.conf.

3

Hey, look at that! emonhub is getting data!

Thanks, that definitely helped. I just needed to strip out some of the cruft the arduino was sending over. Now it’s just sending numbers, like the 3phase does, and emonhub is receiving the frames.

I still get some warnings about frames incorrect for the datacodes, but I also don’t have any CT’s hooked up to the analog inputs yet, so the numbers are garbage. Maybe I’ll hook them up to something real before I go any farther with the emonhub/emoncms stuff.

Thanks again!

4

OT, but there’s a word I haven’t heard in a long time!
Looks as it stopped your data from getting zorched.. :wink:
Ref: Hackers: Heroes of the Computer Revolution

5

Ha, didn’t know that was an old school sort of word, it’s just one of those weird things lurking in my vocabulary, don’t have any idea how it got there. Zorched on the other hand, is new to me.

6

Both were used by hackers at MIT in the late 50s and early 60s.
Zorched tranlastes roughly to zapped or blown.

7

I’m guessing the serial output is floats rather than the ints and longs that are sent over the rf connection. If you use the EmonHubSerialInterfacer rather than repurposing the “[[RFM2Pi]]” EmonHubJeeInterfacer then the default datacodes are floats and the logs will be much tidier as there will be no attempts to configure the RFM device by emonHub.

Try changing

[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400                      # 9600 for old RFM12Pi modules
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,
        group = 210
        frequency = 433
        baseid = 5                              # emonPi / emonBase nodeID
        quiet = true                            # Report incomplete RF packets (no implemented on emonPi)
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        # interval =  0                         # Interval to transmit time to emonGLCD (seconds)

to

[[SerialArduino]]
    Type = EmonHubSerialInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,
8

Alright, it took me some time, but I’ve made a little progress. I’m using the direct serial sketch instead, since it seems to do everything I need it to. I’ve got AC/AC and a CT hooked up, so the numbers actually make sense now, but I’m still getting the invalid datacode warnings.

Here’s the top part of my emonhub config, pretty much the same as paul recommended:

[[SerialArduino]]
   Type = EmonHubSerialInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 115200                         # 9600 for old RFM12Pi
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,

And here is the node description:

[[10]]
    nodename = emontx1
    [[[rx]]]
    names = power1, power2, power3, power4, vrms
       datacode = f 
       scale = 1
       units =W,W,W,W,V

And finally, here’s what shows up in the emonhub log:

2016-12-17 17:33:37,646 DEBUG    SerialArduino 71 NEW FRAME : 10 79.27 -0.33 -0.55 -0.05 125.01
2016-12-17 17:33:37,646 WARNING  SerialArduino 71 RX data length: 5 is not valid for datacode f

2016-12-17 17:33:47,686 DEBUG    SerialArduino 72 NEW FRAME : 10 78.95 -0.07 -0.12 -0.08 124.83
2016-12-17 17:33:47,687 WARNING  SerialArduino 72 RX data length: 5 is not valid for datacode f

2016-12-17 17:33:57,641 DEBUG    SerialArduino 73 NEW FRAME : 10 79.42 -0.29 0.02 -0.04 124.97
2016-12-17 17:33:57,642 WARNING  SerialArduino 73 RX data length: 5 is not valid for datacode f

Any ideas? I assume it’s still having problems with the floats, but beyond using the EmonHubSerialInterfacer and specifying datacode = f (I’ve tried d as well), I’m not sure what else to do. I guess I can try reformatting it to an integer in the sketch, but I’d rather not if I can get it working the way it is. Thanks for all the help.

9

It’s the “datacode = f” that’s causing an issue. There are 3 valid ways to do what you want

  • datacode = 0
  • datacodes = 0, 0, 0, 0, 0
  • or omit the datacode(s) entry alltogether as “0” is the default datacode for the serial interfacer.

Since you are already passing real numerical strings, no further decoding is required ie “0” datacode, The “datacode = f” is saying that incoming data will be 32bit floats, ie 4 byte values and therefore the array to decode must be a multiple of 4, which 5 is not.

10

Oh, okay, thanks. I thought datacode was telling it how to decipher the string, not a raw byte. Changing to 0 fixed it, now it’s happily reading in data. Thanks.

Maybe this ought to be added to the emonhub.conf documentation. There’s no reference to “0” datacodes in there at all. Or am I really the only one that has tried to do it this way?

11

In April of 2016 I was looking at transitioning to the emonPi variant of emonhub, but I was having trouble with a serial direct interfacer that I use. It would generate a “SerialDirect thread is dead.” message and I would have to restart my Pi running emonhub. Details here: Need help - Getting lost in all the information - want to get things working... | Archived Forum – starting with my reply to the post on April 16.

At that time, with Paul’s help, I resolved my problem by making sure the data I was sending was exactly as expected. But Paul commented that “emonhub should be robust enough not to fail due to incorrect serial data.”

My question now is: based on the thread above, it appears that emonhub is now robust enough not to fail due to incorrect serial data. True? Did someone work on this?