emonGLCD time not updating

That’s really of no interest - it’s saying that you have 671 W on CT1 of your emonTx.
(You step through the message, byte by byte, with the up & down buttons. The RH side tells you where you are in the string.)

So the emonBase is not transmitting - you should be seeing something from Node 5 - but you’ll need to wait for a minute to see it, and it will disappear as soon as Node 10 transmits again.
There’s a green flash for every message received. So you should see 13 flashes per minute - 12 evenly spaced every 5 s from your emonTx, and somewhere in that stream an extra one from the emonBase, also regularly but at 1 minute intervals.

I don’t know the emonPi/emonBase/emonHub well enough to suggest what to look at next.

The 3 buttons on the RH side of my emonGLCD do nothing!
Thanks Robert (I’m out of my depth here)

They should do - I’ve absolutely no idea why they don’t.

A quick recap - is this correct?
You swapped your NanodeRF for an emonBase (= Raspberry Pi + RFM69Pi)
You’re running the “shop” SD emonCMS on it.
You’re seeing the data from your emonTx both in emonCMS and on the GLCD.
You’re not getting the time from the emonBase.
With the ‘debugger’ sketch in the GLCD, you’re only seeing transmissions from the emonTx.

Correct.
I sent the output of your sketch emonGLCD_debug to the serial port & there is no data from node 5 (emonBasePi), only node 10 (emonTx)

We need someone who knows how to make the emonBase transmit. There have been recent changes - someone pushed through a change that transmitted the emonPi’s data, I don’t know whether it’s been incorporated in the standard software, or whether that has broken the time transmissions from the emonBase, but it needs looking into.

Thanks Robert. Hopefully someone out there knows where to go from here

You did delete the hash ‘#’ at the beginning of that line, didn’t you?

        # interval =  0                         # Interval to transmit time to emonGLCD (seconds)

so that it reads

        interval =  60                        # Interval to transmit time to emonGLCD (seconds)

Bingo! that sorted it. :slight_smile: Now if it had been // instead of # I might have spotted it (told you I wasn’t a coder)
Thanks for all your help Robert

What beats my logic is why that line needed to be commented, when AFAIK, ‘0’ means don’t do it anyway. :roll_eyes:

Different programs use different characters to denote a comment. The safe way is to look for an obvious comment and see what’s being used.

e.g. Bloody Awful Set of Interpreted Commands uses a single quote ’

Since interval = 60 (seconds) could interval = 0 means the time is transmitted continously (every 0 seconds) Just a thought.
I’ve only come across REM & // for commenting out lines

So why isn’t a sensible default set - 30, 60, 300 - in the value instead of zero? I don’t know. If I’d written it, I’d have used 0 as a special value meaning ‘No transmit’.

[quote=“Robert.Wall, post:16, topic:10343”]
Bloody Awful Set of Interpreted Commands

thumbsup

Just tried setting interval = 0. The time on page 2 of the emonGLCD continues to update but time on page 1 is replaced with ‘emonBase fail’. Curiouser & curiouser

I don’t have a working emonCMS, so I can’t join in. It might be that one page (2) is not getting the time updates, but taking the time from the internal timers. Without checking, I can’t say.

But whichever, it looks like commenting the line and setting the interval to zero is wrong. It should be either commented out but with a sensible default, or not commented and 0 means “Don’t send the time”.

I agree.
I only tried setting interval = 0 out of curiousity; now reset to 60 second interval

So you’ve now got the functionality that you want to replace the NanodeRF?

It doesn’t need to be commented, it could have been omitted or set to zero.

Correct (or at least that’s how it was originally coded)

If it truly transmitted continuously, it wouldn’t be able to receive.

That would make sense. AFAIA the time would continue to tick on the emonGLCD, it just isn’t getting the correction update from the emonbase, so it could drift. That is why the recommended setting is 300, so as to just keep it in line every 5mins, even that is possibly too often.

Indeed, it originally used to be set to 300 and commented out, by default a value of zero is then set internally

1 Like

Thanks for that, Paul. It’s all pretty much as I thought. It seems like the ‘belt and braces’ approach has actually caused problems here.

I’ll point @Gwil here and suggest it is changed.

1 Like

6 posts were merged into an existing topic: emonTx v2 not passing data to nanodeRF

A post was merged into an existing topic: emonTx v2 not passing data to nanodeRF