Archived Forum

The time is sent from your emonCMS server. Which server are you using? What are your timezone settings? Is the server sending the correct time?
Though at first guess it's unlikely that the GLCD sketch is to blame, it might be an idea to say which sketch you are using, so that somebody does not have to search through them all to find the one or ones that show the time when you press the top button.
What do you mean by erratic? Does the time jump about when you press the button at intervals of a few seconds, or what?

Thanks for the speedy response Robert

I'm using the 'standard' emoncms sever.

I'm also using the 'standard' sketch that was posted at the release of the emonglcd (Mk2?) modified slightly for my own use. I should mention that the sketch I'm using has been fine for a couple of years unmodified, it's only in the last couple of weeks that this problem has arisen.

I've always had the Delayed Summer Time issue where the glcd resets at 00:00 in winter time but not until 01:00 in summer time but that is not the issue here.

By 'erratic' I mean that when I press the top button I get an unpredictable time. This evening the time reported by the glcd seems to be about 2 hours 'fast' (showing 03:20 @ actual time of 01:15) but at other times of the day it can be different. The time shown by the glcd does not change when I press & hold the top button but the time displayed at different times of the day doesn't follow any set pattern, it seems to jump about randomly not always following the 2 hour 'fast' observation mentioned earlier.

If no one else has experienced this problem then I suspect it may be a hardware problem with glcd.

I'll report back if I find a solution.

It sounds as if the time message isn't getting through to your GLCD, and/or its internal clock (which keeps time between being corrected/set from the server) is getting screwed up. It could be RF interference, or another transmitter started up on the same band nearby. Does your display show the time elapsed since the last good message from the base?

A significant clue just might be "a couple of years". That is about the right length of time for a dry joint to corrode just enough to give you problems, so before you look for anything more complicated, get a good hand lens and a good light, and carefully check over as much of the pcb as you can see. If the problem goes away after you've handled it, it almost certainly is a dry joint and you've moved the surfaces enough to scrape it clean - for now!

(I remember very many years ago chasing a dry joint on an audio amplifier - only touching the case 'cured' the problem for a few weeks, it took me about 2 years on and off to find it, then 5 s to cure it.]

Hi Robert

Handling the board (even wiggling the components) made no difference. Had a good look at the circuit board but nothing obvious, all looks normal

The emon GLCD seems to receive the data from emonbase OK, it's just the clock that's not being updated so obviously the wireless connection is OK.

At reset, the clock starts at 12:00 (as determined by the sketch) & then advances normally but after the reset the clock does not get changed to the current correct time from the emonCMS server.

The data sent to the server by the emonTX all seems normal so it appears that the emonGLCD is the problem

The emon GLCD seems to receive the data from emonbase OK, it's just the clock that's not being updated so obviously the wireless connection is OK

Is it not just the time that comes from the emonBase? I thought the data came direct from the emonTx, whiich confirms the emonGLCD is receiving ok, therefore the issue is most likely to be the emonBase transmission not being received by the emonGLCD. Have you confirmed the time update is definitely being sent ?

OK, we'll rule out the dry joint.

"The emon GLCD seems to receive the data from emonbase OK, it's just the clock that's not being updated so obviously the wireless connection is OK."

Are you sure that is the case? In the normal way of things, the GLCD receives the energy/power data direct from the emonTx - it's not retransmitted by the Base, and only the time comes from the emonBase.

If you haven't modified your Base sketch, it's probably still doing that; and in that case, the problem could be anywhere in path from the server via the base to the GLCD. Is the base receiving the time from emonCMS.org? Can you verify that?

Are you sending data to emonCMS.org and is it arriving? I remember a few days ago I saw a post saying that Trystan has stopped an obsolete emonCMS server (or was it a redirection from an obsolete URL? - I can't remember now). Check with a web browser that you can send the time query using the URL that your emonBase uses and that you get the correct time back. The query string that works now is:

emoncms.org//time/local.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

and it should reply in the format:

t22,10,29

[Paul - you've done it again!]

I just took a look at your past posts to see if I could tell what emonBase you are using and see your last thread was about a month ago when you had to over-write your existing (unidentifiable) NanodeRF sketch due to a change in emonCMS server IP address. Are you sure it's worked since then ?

Paul - we're thinking along the same lines here: What's the betting the time query isn't being sent correctly?

I think the emonBase sketch is definitely the prime suspect, it's either not fetching or not relaying the time, I'm not familiar enough with the Nanode RF to hazard a guess which !

The only way to know that is to hang a serial monitor on it. You'll see the time printed every minute (in between the emonTx data) if it's receiving it from emonCMS.org.
If it's doing that, does the base have the correct nodeID for the GLCD to decode the message? If the default NodeID of the base changed when dominator reloaded his NanodeRF (or generally it isn't the one the GLCD is expecting the message from), it's now wrong and the GLCD will be ignoring the time broadcast.

NanodeRF now seems to be working as normal & serial monitor prints:

1 emontx packet rx2 {rf_fail:0,solar:0,grid :443}
3 ok | Date: Mon, 27 Oct 2014 00:45:06 GMT

4 emonbase sent
5 emonglcd: 2787

Does this make sense ? what does 2787 relate to ? it's from the "Nanode RF thread" the fetched time is around 12 hrs out by the comment time but we don't know the timezone or how old the log was when posted, but the "2787" is suspect isn't it ? 

Chris: I don't recognise that output from your NanodeRF, which sketch exactly are you using?
Paul: I think Chris is in the UK - his TZ is presently set to GMT, and his email address is at .UK ISP.

The normal format for the NanodeRF output is:

[webClient]
DHCP status: 1
IP: 192.168.1.68
GW: 192.168.1.254
DNS: 8.8.8.8
DNS status: 1
SRV: 80.243.190.58
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:1}
Time request sent
Time: t23,37,42
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&node=10&csv=14710,0,0,0,0,0,0,0,0,0,0,0,0,0
OK received
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&node=10&csv=14720,0,0,0,0,0,0,0,0,0,0,0,0,0
OK received
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&node=10&csv=14725,0,0,0,0,0,0,0,0,0,0,0,0,0
OK received
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&node=10&csv=14730,0,0,0,0,0,0,0,0,0,0,0,0,0
OK received
Time request sent
Time: t23,38,42
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:1}
OK received
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&node=10&csv=14750,0,0,0,0,0,0,0,0,0,0,0,0,0
OK received

(The emonTx sketch was the "continuous" one, with no CTs. "147xx" is the message number.)

Robert

As can be seen from my serial printout below I'm getting the same as your nanodeRF (emonBase) except I'm not receiving a time reply from the emnoncms server

Sorry, deleted posting because I left apikey visible!! (stupid boy!)

Have attached the emonBase & emonGLCD sketches I use to help you narrow down my time problem

My NanodeRF(emonBase) output is:

[webClient]

DHCP status: 1
IP:  192.168.0.2
GW:  192.168.0.1
DNS: 8.8.8.8
DNS status: 1
SRV: 80.243.190.58
Data sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:1}
Time request sent

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3386,solar:-11,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3372,solar:-12,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3386,solar:-12,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3385,solar:-13,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3374,solar:-8,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3393,solar:-11,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3375,solar:-11,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3375,solar:-12,powerC:0}

emonTx data rxData sent: /api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=&json={rf_fail:0,grid:3373,solar:-11,powerC:0}
OK received
Time request sent

But no Time: txx,xx,xx printout

Why, in your Nanode sketch, have you set your APIkey to

char apikey[] = "/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=";

You can see in your print that it's sending a garbled message to post the data - "/emoncms3/api/post.json?" is not a legal APIkey - (but somehow it appears to be parsed correctly when posting data), but the same "/emoncms3/api/post.json?" is being sent to the time server as well, and I strongly suspect that's choking on it and refusing to send back the time. You need to correct that and then see if the time server responds.

I replaced my true apikey with the xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx to avoid my key showing for the purposes of this discussion.

My actual sketch contains the proper key & hence is communicating with the emoncms server.

All my printouts that contained my actual apikey I changed for the reason i mentioned above

My data is being sent correctly except the time

Yes, I appreciate that about "xxx...", but what about the pre-amble with emoncms3 etc? That must not be part of the APIkey. Read again what I wrote above.
Here is the settings part of my NanodeRF sketch that produced the listing I posted above.

// ethernet interface mac address, must be unique on the LAN
static byte mymac[] = { 0x42,0x31,0x42,0x21,0x30,0x31 };

// 1) Set this to the domain name of your hosted emoncms - leave blank if posting to IP address
char website[] PROGMEM = "emoncms.org";

// or if your posting to a static IP server:
static byte hisip[] = { 192,168,1,10 };
// change to true if you would like the sketch to use hisip
boolean use_hisip = false;

// 2) If your emoncms install is in a subdirectory add details here i.e "/emoncms3"
char basedir[] = "";

// 3) Set to your account write apikey
char apikey[] = "1db5ae7fd006b80f54f6664d198bb5a2";

That's a false APIkey of course, but there is NO rubbish on the beginning. You can see your correct APIkey on emonCMS Input API Help. That doesn't have "/emoncms3...." on the front and neither should you have it in your sketch.

In the original sketch line 253 and line 265 both assemble URL strings, the 1st for posting data and the second to retrieve time, in your sketch the 1st appears to be edited but not the second. Was this "fix" to resolve a data posting issue ?  if so the "fix" should be moved to code common to both parts, copying the working edit over to the non-working string may work to test the theory but probably not good coding practice. 

Paul

Robert

followed your's & Paul's advice but still no time being updated from the server.

When I compare your nanodeRF printout above of:-

Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:1}
Time request sent
Time: t23,37,42

with mine today after your sketch mods & Paul's suggestion:-

"In the original sketch line 253 and line 265 both assemble URL strings, the 1st for posting data and the second to retrieve time, in your sketch the 1st appears to be edited but not the second. Was this "fix" to resolve a data posting issue ?  if so the "fix" should be moved to code common to both parts, copying the working edit over to the non-working string may work to test the theory but probably not good coding practice."

All works apart from the time update!!

[webClient]
NanodeRF_Power_RTCrelay_GLCDtemp_mine_27_10_2014
DHCP status: 1
IP:  192.168.0.2
GW:  192.168.0.1
DNS: 8.8.8.8
DNS status: 1
SRV: 80.243.190.58
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:1}
Time request sent

emonTx data rxData sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:0,grid:-230,solar:617,powerC:0}
OK received

This was received around 10:20 after the suggested sketch mods

The "Time request sent" print suggests it reaches that point ok and the lack of a "Time :" print means it's not getting past the "if reply begins with 't'" test.

If you add another option to my_callback to print any other reply you maybe able to determine what if anything is being returned. So before the very last } you could add something like

else

{

  Serial.print("Error: incorrect reply received -> ");
  Serial.println(line_buf);

}

and see what comes up.

Paul

Paul

I modified my_callback as below:

static void my_callback (byte status, word off, word len) {
  int lsize =   get_reply_data(off);
 
  if (strcmp(line_buf,"ok")==0)
  {
    Serial.println("OK received"); ethernet_requests = 0; ethernet_error = 0;
  }
  //else
  //if(line_buf[0]=='t')//'t'
  //{
    Serial.print("Time: ");
    Serial.println(line_buf);
    
    char tmp[] = {line_buf[1],line_buf[2],0};
    byte hour = atoi(tmp);
    tmp[0] = line_buf[4]; tmp[1] = line_buf[5];
    byte minute = atoi(tmp);
    tmp[0] = line_buf[7]; tmp[1] = line_buf[8];
    byte second = atoi(tmp);

    if (hour>0 || minute>0 || second>0)
    {  
      char data[] = {'t',hour,minute,second};
      int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;}
      rf12_sendStart(0, data, sizeof data);
      rf12_sendWait(0);
    }
  //}
 
      else

    {

      Serial.print("Error: incorrect reply received -> ");
      Serial.println(line_buf);

    }

}

This is what I get back even when I REM'd out the else if(line_buf[0]=='t')//'t'

[webClient]
NanodeRF_Power_RTCrelay_GLCDtemp_mine_27_10_2014
DHCP status: 1
IP:  192.168.0.2
GW:  192.168.0.1
DNS: 8.8.8.8
DNS status: 1
SRV: 80.243.190.58
Data sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:1}
Time request sent

emonTx data rxData sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:0,grid:3044,solar:-11,powerC:0}

emonTx data rxData sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:0,grid:3056,solar:-13,powerC:0}

emonTx data rxData sent: /input/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:0,grid:3063,solar:-11,powerC:0}
OK received
Time: ok
Error: incorrect reply received -> ok

It seems to be ignoring the block:

char tmp[] = {line_buf[1],line_buf[2],0};
    byte hour = atoi(tmp);
    tmp[0] = line_buf[4]; tmp[1] = line_buf[5];
    byte minute = atoi(tmp);
    tmp[0] = line_buf[7]; tmp[1] = line_buf[8];
    byte second = atoi(tmp);
    if (hour>0 || minute>0 || second>0)
    {  
      char data[] = {'t',hour,minute,second};
      int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;}
      rf12_sendStart(0, data, sizeof data);
      rf12_sendWait(0);

Does this help?

Chris

A little! it tells us it's not getting past the "if reply begins with 't'" test because the reply doesn't begin with 't' so either the sketch isn't asking the right question or emonCMS isn't giving the right answer, whilst not concrete, I think it's probably the sketch as no-one else has posted an issue in this area. 

If you change the existing "Time request sent" line so it reads

Serial.print("Time request sent: "); Serial.println(str.buf);

we can then see the string being sent.

Paul

If "ok" appears to be coming back following a request for the time, then surely either (a) your sketch is sending not the time request but something the server is interpreting as data to be stored, or (B) nothing has come back and you're looking at the previous response.
I don't believe the callback is at fault. I think the problem is your "APIkey" string.

Looking at your sketch as originally posted, line 99 is:
char apikey[] = "/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=";
That is WRONG. It should only be:
char apikey[] = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
(obviously with your correct APIkey in there).

Looking down the sketch at the line where the normal energy data is sent and reconstructing the message by hand, starting at line 201 you send:
"emoncms.org/api/post.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=
&json={rf_fail:0,grid:GGG,solar:SSS,powerC:CCC"
which ties up exactly with what you actually send - and that is wrong because the APIkey (as you have programmed it, in bold) repeats part of the server URL and the text "apikey" is sent twice.

Doing the same with the time request starting at line 271, you are sending:
emoncms.org/time/local.json?apikey=/emoncms3/api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json=
This now is totally wrong.

Can I suggest you send that string by pasting it into the address bar of your web browser, of course using your correct APIkey, and send it.

And then send this:
emoncms.org/time/local.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
again of course using your correct APIkey. In the first case, I expect nothing. In the second, you should see the time reported.

Does this explain the point I'm trying to make about how you have entered your APIkey in the sketch?

Paul

carried out yor suggested mods & un REM'd if statement if(line_buf[0]=='t') & got this, but only once @ about 23:25:-

Time request sent
/time/local.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Time: t00,23,56
emonGLCD temp recv: 2525

thereafter got this:-

Time request sent
/time/local.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Obviously the "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" are to hide my apikey from view

Weird!?

Chris

Well thats a good'ish response I'd say. except it appears the server is still on BST so the time returned is 00:23:56, almost 24 mins past midnight and that has been successfully relayed to the emonGLCD as it seems to have replied with a rather toastie 25.25°C, but why only once I'm not sure.

I think it's supposed to update every 60 seconds which seems a bit frequent maybe it's meant to be every 60mins, try Roberts suggestion of using the url in your browser and see if you get a response every time.

I've tried this url in my browser several times and got the correct response every time with my apikey

http://emoncms.org/time/local.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Have you set the correct timezone on your emoncms.og account ?

Paul, can you get any response with the faulty string that Chris is sending by virtue of the corrupt APIkey? I couldn't. That makes me think the server is not responding, which is exactly as I would expect.

Paul, Robert

I tried all your suggestions last night & I'm now getting a time response from the server.

However, the time is not getting posted correctly to emonGLCD.

Last night there was a time difference of about 5 hours; when the server time was showing 01:00 my emonGLCD time was showing as 20:00ish ( after the initial startup time of 12:00 given by the sketch)

This morning the emonBase printout shows:

Time request sent
Time: t09,43,47 - which is correct for my time zone UTC+00:00 (GMT)
emonGLCD temp recv: 2525

but the emonGLCD is showing a time of 20:46!

I attached both emonBase & emonGLCD sketches to see if you can help pin down the difference in times

Robert - I hadn't tried the previous string as I had assumed it was a "cut and paste" error when masking apikey

Chris
Hopefully Robert will be of more help to you here but to me the char tmp[] ={line_buf[1],line_buf[2],0}; line looks a bit funky, it looks like it is in effect multiplying the hours value by 10, but I could be wrong.

Maybe add another print statement to see what the NanodeRF is actually sending,

In the next block after "char data[] = {'t',hour,minute,second};" you could add something like

Serial.print("Actual time values sent are ");
Serial.println(data);

Paul

The sketch I'm using is the original one supplied by openenergy monitor for use with the nanodeRF (emonBase) & it was working until quite recently.

I think the problem may have originated around the time Trystan deleted an old server? thinking it was obsolete.

Having now got the emonBase to receive time from the server (thanks largely to you & Robert) I now need to find out why emonGLCD is not being updated with server time received but instead is updated with an odd time that doesn't appear to be related to the server time as explained above.

If I reboot the emonGLCD the time shows 12:00 (the start time read from the sketch).

On receipt of the first server time of t13,44,00 the emonGLCD time displayed changed from 12:02 to 20:46; almost exactly 7 hours difference between the two times!

So the emonGLCD time was updated from emonBase but not correctly (my TZ is still UTC+00:00)

Being a newbie at coding, I'm lost as to know what to do to resolve this without changing my TZ!!

Many thanks again for all your help Paul

PS

As an experiment, I changed my TZ to UTC-07:00.

The server issued the correct time of t07,08,47 & my emonGLCD changed from 12:00 (startup time) to

20:08!! so it's not the server time 'shifted' that's being sent to emonGLCD so where is this 'odd' time coming from?? - curiouser & curiouser!

Chris

When the serial output from the NanodeRF prints " Time: t00,23,56 " it is printing the time received from the server, then it changes it to the required format to send out to the emonGLCD, we do not know what it actually transmits, which is why I suggested that last print statement. either the transmitted time will be correct, meaning the emonGLCD is at fault or the transmitted time will be incorrect pointing the finger at the NanoeRF, if the emonGLCD is correctly displaying the incorrect transmission it can also be removed from suspicion.

Paul

It may just be coincidence, but unlikely. Have you noticed that aside from that one first successful time setting, every time you set the emonGLCD time it seems to result in a time between 8 and 9pm ie always starts "20" regardless of the current time?

This line in the emonGLCD sketch always sets the time to 12:00 at startup:-

RTC.begin(DateTime("Dec  8 2011" , "12:00:00")); //start up software RTC - this time will be updated to correct tme from the interent via the emonBase

When the emonBase reads the first time txx.xx.xx from the server only then does the emonGLCD change to the 20:00 time but I don't know where this time comes from

Chris

Which is why you need to establish what is actually being transmitted.

From a post some way back by Paul:
"Hopefully Robert will be of more help to you here but to me the char tmp[] ={line_buf[1],line_buf[2],0}; line looks a bit funky, it looks like it is in effect multiplying the hours value by 10, but I could be wrong."
I think that line is OK. The '0' in tmp[2] is a terminating NULL. Remember it's C string.

But when it comes to transferring the time from the Nanode to the GLCD, I too am a bit puzzled by that. I'll look into that later (I may not be able to look until Friday or Saturday) but on the face of it, there's a mismatch in aligning the received data to the time variables.

Paul

This is the result of your suggestion:-

      Serial.print("Actual time values sent are ");
      Serial.println(data);

Time request sent
Time: t21,56,45
Actual time values sent are t8-Y
emonGLCD temp recv: 2481

Time request sent
Time: t22,10,48
Actual time values sent are t0Y

Time request sent
Time: t22,16,06
Actual time values sent are tY
emonGLCD temp recv: 2493

Time request sent
Time: t22,21,07
Actual time values sent are tY
emonGLCD temp recv: 2493

I'm none the wiser!

Incidentally, I've noticed that when the emonGLCD receives its first time txx,xx,xx from the server it changes the displayed time from 12:00 to 20:00 but also when the displayed time passes 20:59 it then resets to 20:00 rather than 21:00

Printing data[ ] as a string (which is how print will interpret it, because it is defined as type char), was never going to be helpful. Except for the 'signature' 1st character ('t'), it is bytes of data, not printable characters.

You need something like:
for (i=0; i< sizeof(data); i++)
Serial.print((int)data[i]);

N.B. I've not tested that!

On the face of it, at a quick look (disclaimers!), in your GLCD sketch you should have (line 68):

typedef struct { byte hour, mins, sec; } PayloadBase;
PayloadBase emonbase;

to tie up with the mapping of the time as bytes to the data[ ] array in line 303 of your Base sketch.

ok that wasn't quite how I expected that to print, (apologies for the misdirection and thanks for the correction RW) still learning c myself too. the intention was sound though,it would still be good to see what is actually being transmitted, so I would try Roberts revised print statement, unless you try editing the payload format in the GLCD 1st and it fixes it of course.

Paul

Hmmm...

Looking at a working emonGLCD sketch that was derived from one published a year or two ago, the code that decodes the time and sets the internal clock is:

if (node_id == BASENODE)
{
  RTC.adjust(DateTime(2012, 1, 1, rf12_data[1], rf12_data[2], rf12_data[3]));
  last_emonbase = millis();
}

That is taking the 2nd, 3rd & 4th bytes of the received message and using those (byte) values to directly set the real-time clock. That code is consistent with the way the time is transmitted by the NanodeRF. I'm beginning to think you're a victim of a 'copy-and-paste' mistake by someone who didn't realise that the Nanode sends bytes, not integers of two bytes.

Made changes as suggested to:-

typedef struct { byte hour, mins, sec; } PayloadBase;
PayloadBase emonbase;

as suggested to my emonBase & my emonGLCD but problem still remains:-

Time request sent
Time: t15,35,17
Actual time values sent are t#Y

Time request sent
Time: t15,50,41
Actual time values sent are t2)Y

Time request sent
Time: t16,01,37
Actual time values sent are t
%Y

Time request sent
Time: t16,30,32
Actual time values sent are t Y

Chris

Is there a way to resolve this Robert?

This is way out of my depth from a coding perspective!
 

Hmmm...

Looking at a working emonGLCD sketch that was derived from one published a year or two ago, the code that decodes the time and sets the internal clock is:

if (node_id == BASENODE)
{
  RTC.adjust(DateTime(2012, 1, 1, rf12_data[1], rf12_data[2], rf12_data[3]));
  last_emonbase = millis();
}

That is taking the 2nd, 3rd & 4th bytes of the received message and using those (byte) values to directly set the real-time clock. That code is consistent with the way the time is transmitted by the NanodeRF. I'm beginning to think you're a victim of a 'copy-and-paste' mistake by someone who didn't realise that the Nanode sends bytes, not integers of two bytes.

I'm starting to lose the plot as to where you are now in terms of changes. Can you post the Nanode and GLCD sketches as they stand?

These are the current sketches I'm running which gives the result below:

Time request sent
Time: t21,41,51
Actual time values sent are t)3Y
emonGLCD temp recv: 2525

Chris

Here is my analysis of your present situation.

In the Nanode, you know the time is being received correctly, as a null-terminated ASCII string, viz: "t21,41,51" and is stored in the variable line_buf. (Line 292 of your sketch, Chris.)
The character array tmp, also destined to become an ASCII string, receives the hours element when it is created and initialised. line_buf[0] ('t') is ignored, line_buf[1] ('2') goes into tmp[0], line_buf[2] ('1') goes into tmp[1], and tmp[2] gets the value 0, which is the terminating null for the string. This is then fed into the standard library function atoi( ) and the string is interpreted as a number, and the number 21 (0x15, ASCII character "NAK") is stored in the single byte variable hour.

Now that tmp has been created, the byte variable minute has to be processed slightly differently. Here, tmp[0] receives directly line_buf[4] ('4') and tmp[1] receives directly line_buf[5] ('1'). tmp[2] still has 0 in it. Again, atoi( ) converts this to the number 41 (0x29, ASCII character ')' ).

Likewise, the byte variable second gets the number 51 (0x33, ASCII character '3' ).

Given that it's not midnight (presumably we can afford to miss that as all-zero values also probably mean a failure somewhere) then (in Line 303), the character array data[ ] is created and initialised with the values 't', hour, minute and second into elements 0 - 3 respectively. This character array is not being treated as an ASCII string, so it does not need a terminating null. Its value is byte 0 - 0x74 (the character 't'), byte 1 - 0x15, byte 2 - 0x29, byte 3 - 0x33.

This array is then sent to the RFM12B and transmitted to the emonGLCD. I hope you can see now why printing the string transmitted results in meaningless characters some of the time. All ASCII characters below 0x20 are non-printing, so most hours and the first third of minutes and seconds result in something non-printable, there's no terminating null so anything in memory following those wanted bytes is also printed, as far as the next null.

In the GLCD, at line 155, the received array is copied into the struct emonbase. Looking at the top of the file, emonbase is a variable of type PayloadBase (line 68). As it was, this was three integers. An integer is two bytes, so the received array mapped into it thus:
byte 0 ('t') - the high byte of hour, byte 1 (0x15) - the low byte of hour.
byte 2 (0x29) - the high byte of mins, byte 3 (0x33) - the low byte of mins.
So hour has the value 0x7415, minute has the value 0x2933. What sec got is anybody's guess, it is what happened to be in memory before the variable was put there. I need not say those are not what was wanted.

As it now is, things are much better, but still not right - but the solution should be clear:
emonbase is now three bytes, so the received array mapped into it thus:
byte 0 ('t') - hour, byte 1 (0x15) - mins, byte 2 (0x29) - sec. We have the 't', which we don't need, and there's nowhere for byte 3 (the transmitted seconds) to go.

There are two solutions (MUTUALLY EXCLUSIVE!). Either you can make the emonBase match what the GLCD is expecting, or vice versa. So either:
change line 68 in the GLCD to
  typedef struct { byte junk, hour, mins, sec; } PayloadBase;//was int hour
and never use junk (Actually, if you want, you can test that it is the character 't' to be sure you have a time), or
change line 303 in the Nanode to
  char data[] = {hour,minute,second};
i.e. don't send the troublesome 't' in the first place.
There's a third possibility, which would involve more unnecessary complication that would allow you to send integer values, but as the biggest number is 59, well within the range of a byte variable, we'll ignore it.
And there's a fourth possibility: In the GLCD, forget (remove) the struct emonbase and replace line 159 with the equivalent from my post just two posts up this thread. That picks the bytes out of the received data directly, not going through any intermediate variables.

Chose the  char data[] = {hour,minute,second};  option in the NanodeRF sketch Robert & that did the trick

All that hassle over a little 't'!!!

Many thanks again to both Robert & Paul

Robert

Although you managed to sort out the 'time' problem for me I have another issue which concerns the original sketch for the emonGLCD.

I've been trying to find a copy of the original sketch for the v1.3 circuit board.

I can't be exactly sure of what sketch I uploaded over 2 years ago but every sketch I've tried to upload recently has failed; the most recent with errors:

Arduino: 1.0.6 (Windows 7), Board: "Arduino Uno"
C:\Users\User\Desktop\Arduino 1.0.6\Arduino\libraries\glcdlib\GLCD_proxy.cpp: In member function 'void GLCD_proxy::sendLCDMessage(byte)':
C:\Users\User\Desktop\Arduino 1.0.6\Arduino\libraries\glcdlib\GLCD_proxy.cpp:183: error: no matching function for call to 'rf12_sendStart(int, byte [66], byte&, int)'
C:\Users\User\Desktop\Arduino 1.0.6\Arduino\libraries\jeelib/RF12.h:93: note: candidates are: void rf12_sendStart(uint8_t)
C:\Users\User\Desktop\Arduino 1.0.6\Arduino\libraries\jeelib/RF12.h:95: note:                 void rf12_sendStart(uint8_t, const void*, uint8_t)

This was the main reason I used your modification to the nanodeRF sketch as I was unable to upload any  of the more recent sketches to the emonGLCD (some seemed to employ graphic icons in the coding).

Some of the older sketches have variations in the coding so I can't be sure which is closest to my original sketch.

I'm not sue if the above errors are library issues relating to the most recent jeelib/RF12 library not being  compatible with early sketches.

Your insight would be much appreciated

I think you could be right to suspect a lib mismatch, A change was made in the use of "rf12_sendNow" replacing "rf12_sendStart" there is a reference to a JeeLib issue (no longer accessible) in the glcd sketches commit history.

Paul

Thanks for that Paul

Chris

There was indeed a problem with JeeLib - it was locking up. There's a very long thread here:
http://openenergymonitor.org/emon/node/1051,
and the really interesting bit starts at
http://openenergymonitor.org/emon/node/1051#comment-9816

Basically, you need to get a new copy of Jeelib
( [Edit 3] or maybe not - see this thread: http://openenergymonitor.org/emon/node/3850 )
(remember you can't leave the old copy, else the compiler is likely to find and use it, the best trick if you feel a need to keep it is to Zip it and then delete the original), and I'd suggest you look at the latest sketches from GitHub and use the RFM12 functions that they use.

So you need to replace your lines 164-166

int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;} // if ready to send + exit loop if it gets stuck as it seems too
rf12_sendStart(0, &emonglcd, sizeof emonglcd); // send emonglcd data
rf12_sendWait(0);

with what the HomeEnergyMonitor sketch does:

rf12_sendNow(0, &emonglcd, sizeof emonglcd);
rf12_sendWait(2);

Then compile with that. I'm pretty sure the receive side is unchanged, but it's best to check.

[Edit]
And check the current Nanode sketches while you're at it!
For a reason I can't explain, the current Nanode sketches DON'T have that change done. I can't think of a good reason why not, does anybody know?

[Edit 2]
A PM comment from Paul to me suggested that you really ought to change the time data sent from the NanodeRF to the GLCD to be the same as the current "OEM Standard", so that should you ever have to reload with a current sketch again, you won't fall foul of this particular problem again.
(That's bytes, with the 't' being sent by the Nanode but ignored at the GLCD end, i.e. use my 4th suggestion there).

Robert

Following our discussion via PM I have now uploaded my original emonGLCD sketch & the old time problem has reappeared but not in the same way as before.

I used the original libraries with the original (attached) sketch from 2012 so as to avoid any problems with the newer jeelib

I've tried your mods suggested in earlier posts but I can't get the time function to work & I'm at a loss as to what to do next

I've attached both sketches (emonGLCD & NanodeRF[emonBase])

I think you didn't understand what I wrote to explain the problem - or you didn't realise that the C language is zero-based - meaning that you count from zero, not one. Have another read of my post of 5/12/2014, and follow through what is being sent from the Nanode and what is being received by the GLCD.

In the GLCD, you're looking for Hours, Minutes and Seconds in rf12_data[1], rf12_data[2], rf12_data[3]. Note you're NOT looking at rf12_data[0].

In the Nanode, you are sending:
  char data[] = {hour,minute,second};
i.e. you're sending hour in the 0th byte, minute in the 1st and second in the 2nd. So with the "standard" OEM data packet, you need that 't' that's commented out.

Robert

"I think you didn't understand what I wrote to explain the problem....." is true; as mentioned previously, I'm not a programmer, not even close.

I do try & decipher code but only for my own purposes not for the sake of improving my programming skills.

I don't write/change code frequently enough to become skillful.

I've managed to get the correct time sent to my GLCD thanks to your & Paul's help for which I must thank both of you again.

Refering back to my PM to you regarding correcting the time  to display in correct 24 hour format ie 09:05 NOT 9:5 that currently displays on my GLCD could you assist with what code & where I should place in the part of the sketch below.

I think it should take the form:

if (time in hours < 10)

{

Serial.print("0");

Serial.print(time in hours);

Serial.print(":");

}

else

Serial.print(time in hours);

Serial.print(":");

& the similarly for the 'time in minutes' - but without the Serial.print(":");

but because I can't fathom the full code below, I'm unsure as to where it needs to be inserted & the relevant code that holds the 'hours' & 'minutes' that needs to be included for the 'time in hours'

void draw_page_two()
{
  glcd.clear;
  glcd.fillRect(0,0,128,64,0);
 
  glcd.setFont(font_clR6x8);
  glcd.drawString_P(2,0,PSTR("Current Time:"));
               
  DateTime now = RTC.now();
  char str[20];
  char str2[5];
  itoa((int)now.hour(),str,10);
  strcat(str,":");   
  itoa((int)now.minute(),str2,10);
  strcat(str,str2);
               
  glcd.setFont(font_helvB14);          //big bold font   
  glcd.drawString(2,10,str);  

  glcd.refresh();
 
}

Your comments would be appreciated

Chris

Sorry, I'm not going to have time to look at this just now. I'll look later.

Well, I tried your suggested solution and immediately hit a problem - it appears that the sketch became too large and the result was completely not what I (or you) anticipated.

To get around this, I've made the time formatting into a function (so it exists once only) and called it from the two places where you originally wrote the time. Because that's all a bit complicated, here's a new display.ino file.

Robert

Thanks for the sketch display.ino, a real improvement over the original except I've noticed that the GLCD display goes blank after about 15 mins but the Red LED's are still ON; also page 2 doesn't display at this same time.  The only way to get the display back is to reset the GLCD.

I've compared the current display.ino with the previous one but can't see what might be causing this effect.

Any suggestions?

Chris

Possibly a memory leak! The GLCD sketches are so tight on memory, that anything like that isn't a surprise to me. I left mine running with the standard Solar PV sketch for longer than that and didn't see a problem. Is you main .ino file still the same? I'll try the last one you posted later.
[Edit: I appear to have an inconsistent set, so I need the full set of files for your GLCD]

I've attached the current sketch I'm using - My_latest_emonGLCD_SolarPV_15_12_2014.ino, that works fine (except for the rubbish time format) It has a compiled size of 21,398 bytes

I copied & pasted your display.ino into that sketch (after having REM'd out my original display.ino sketch) which I then renamed: My_latest_emonGLCD_SolarPV_18_12_2014.ino.

This is the version that's causing the blank display. It has a compiled size of 22,084 bytes

I'm obviously using different versions of the libraries - compiled size is 22,228 bytes for me. It's been running more than 1 hour so far (but with no incoming data), and is still OK.

I see you have reverted to using

// if ready to send + exit loop if it gets stuck as it seems to
int i = 0; while (!rf12_canSend() && i<10) {rf12_recvDone(); i++;}
rf12_sendStart(0, &emonglcd, sizeof emonglcd); // send emonglcd data
rf12_sendWait(0);

to send the temperature back to the base. That was the source of much trouble and widespread lock-ups of the GLCD earlier this year, and those lines have now been replaced by

//send temperature data via RFM12B using new rf12_sendNow wrapper -glynhudson
rf12_sendNow(0, &emonglcd, sizeof emonglcd);
rf12_sendWait(2);

I suggest you do that change and see if it effects a cure.

Found the problem.  When I re-connected the PSU to the GLCD the blank screen issue never returned.

It seems that the problem only occurs when obtaining power for the GLCD from the USB connection? but why the delay  before the screen goes blank?

"Found the problem." I'm not sure I believe that! - unless the problem is with your programmer or computer. The FTDI and the USB power pins are wired in parallel. I think you're up against the sendStart problem, which always was unpredictable. I strongly recommend you do the above change.