Archived Forum

In emonHub, you need to set (or change the previous node) to Node 10, and look at the draft document https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md

You are sending this:

int power1, power2, power3, power4, Vrms, temp[6], int pulseCount; 

which I make to be 12 integers. I also wrote a more formal specification, which you need to read in conjunction with Paul's post which follows, here: http://openenergymonitor.org/emon/node/11950#comment-37981

Alternatively, you could edit the new sketch to have the same Node ID and send the same data as the old one did.

And have you seen Glyn's warning not to use the 22nd Dec image? (I assume that's the one you have as you didn't say exactly which.)

Take a look at the emonHub configuration help page for further explanation and example node decoders for each firmware version: https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md

Thanks Guys. I did look at all those links before posting. whilst I understand the basics of it. I did not understand the fully enough to edit the emonhub config. One thing that I am not sure about is the emontx3.2 discretesampling version that I am using. When changing freqs and node no in arduino the last entry in the change log is V2.0 so I assume that I am using Emontx3_2_discretesampling ver 2.0?  All the node config examples for emonhub talk about emontx3.4 versions. 

If you post the lines from your sketch that look like these (but maybe not exactly):

byte nodeID = 8;                               // emonTx RFM12B node ID

and

​typedef struct { int power1, power2, power3, power4, Vrms, temp; } PayloadTX;
       // create structure - a neat way of packaging data for RF comms

​​or a link to where you downloaded it from, we'll know exactly what you need to put in emonhub.conf. 

Here is what I have so far. But not working. Tried various options with only 1 temp etc. Did it before reading your last Robert. Just going out for a sec Will look when I get back. Thanks for your help.

Here you are Robert

You should take a look in emonhub.log as your first port of call, if emonhub finds a discrepancy between the declared expectation in emonhub.conf and the size of the packets arriving it will discard the packet and log the discrepancy. So if emonhub is discarding the packets there is no better information than emohub's perspective as to why.

That payload shown includes a "temp[MaxOnewire]" which will be an array of signed integers each 2 bytes. The other 6 variables are also all signed ints so your received packet size will be ( 6 x 2 ) + ( MaxOnewire x 6 ) which I believe could be 24 (based on memory and Roberts comment above).

If that is the case then the EmonTx v3, emonTxV3_4_DiscreteSampling.ino, v1.6+ configuration should work for you.

Paul

Could you try replacing datacodes = h,h,h,h... with datacode = h

That should decode everything apart from the pulsecount and is a good fallback in order to aid further debugging

To Paul's suggestion, I'd just add that "firmware = ...." being 3.4 won't make any difference - that's just for us humans' benefit.

OK so I am now back to this. Which is the std config for node 10

Log file looks like this. So nothing being recognised.

I should add at this point. My system consists of New Pi2 with latest shop config running Emontx3.4 on node 8 reporting correctly to emoncms.org.

Older Pi which works fine with old software running 2 emontx3.2 node 9 & 10 using firmware 3.2 version 2.0 as far as I can tell. Also 2 Emon TH .

No data reported from old Pi once new software loaded. freq and API set correctly. See above screen captures

I'm a little confused as to what you are trying to get running with what.

The thread starts out about an issue with an v3.2 emontx, but your last post states "My system consists of New Pi2 with latest shop config running Emontx3.4" and "Older Pi which works fine with old software running 2 emontx3.2" .

There's no mention of the receivers, the no mention of emonPi suggests you maybe using RFM2Pi(s) and the lack of any packets in the emonhub log could point to a serial baud mis-match as I believe the latest image is fixed to 38400 rather than "auto-baud detecting" so the wrong baud maybe causing a serial issue.

However the uncertainty over what you have set up may mean I'm missing something more basic because unless the 2 pi's are different "systems" are operating on different frequencies or different groups all nodes should be received on both "systems", if there are differences in group or frequency then interchanging them may not be straight forward.

Once again your firdt port of call should be emonhub, but you should go further back to when emonhub started or restart emonhub to get a fresh start up log. you should be able to see the "RFM2Pi" interfacer being created or see a failure message.

I have just answered another post of yours on another thread about discarded packets too, so is that another set up or is this set-up now producing packets, just not healthy ones?

Paul 

Sorry for the confusion Paul, I thought that I would try and explain what I have in case any of it was relevant. Prob best to stick it all here.

Up until a couple of weeks ago I had an older Pi with 2 X emon tx3.2s on nodes 9 & 10 + 2 X emonth on 19 & 20 freq 868 logging remotly to emoncms.org. This Pi hardwired to lan. All working perfectly. This is a large property and I also wanted to monitor a 3rd consumer unit in an outbuilding. I purchased a new Pi2 rfm69 with wifi dongle and a emon tx3.4 for this. Freq 433. I set this up on node 8 and apart from the wifi not reconnecting if the AP is rebooted. It works fine.

Having seen the new Pi firmware in action I decided to update my older Pi to run it. Purchased a new preloaded sd card. Before loading the new software I updated the Emontx3.2's to the latest discrete sampling firmware for them version 2.0 I believe(not that straightforward to tell from the arduino file apart from update list). I checked that they worked with the old Pi and they did. I loaded the new firmware and immediately lost connection to all 4 sensor nodes.

Whilst troubleshooting and looking at the logs in the working new Pi I noticed a lot of discarded frames. Hence my forum search and the post regarding this.

Whilst writing this I may have come up with the solution to the lost sensors. The old Pi runs rf12b does this not need to be set somewhere in the firmware for emontx3.2 and Pi? 

edit: ok it is set in emontx3.2 firmware but does something need to be done to the Pi software to work with rf12b

On the new image with the old rfm12b RFM2Pi, edit emonhub.conf [[RFM2Pi]] [[[init_settings]]] com_baud = 9600, it is probally currently 38400 as I wrote in last post.

As posted in the other thread, it is most likely "bitslip" causing your packet loss. This has been fixed in the lastest v3.4 firmware (>v2.1) by using a value of "300" for open-circuit rather than "0", but that fix hasn't reached the emonTx v3.2 firmware (currently @ v2.0) yet but it shouldn't be difficult to add if it's needed.

Paul

Jeez thanks, worked straight away! Spent all day looking for a problem that was fixed with that little edit. Still I think I learnt quite a bit.

Was it you who also had problems with wifi disconnecting or reconnecting as it is in my case?