Archived Forum

What are you running software and version wise ? emonhub, emoncms? 

emonhub hub can transmit the time for emonGLCD, this could be tailored to your need if you don't run a emonGLCD.

Paul

Hi Paul, I'm running the emonSD-13-03-15 version with emonhub.  I have set the hub transmit interval to 60 seconds and am receiving that at the remote units, but I need more than the hms data.  Where is the frame formatted and what triggers the transmission?  I have noticed that the seconds are not synced with the NTP time, is always zero, and may be off by 15-20 seconds.  I can live with that, but I need  the full date string or the unix time.  I can decode that in the remote modules if necessary, and that would only extend the awake time by a ms or so.

Thanks for the quick response...

The omission of seconds predates emonhub, emonGLCD expects the data in hours & mins only.

The time is broadcast every "interval" seconds, usually set to 300 for 5min intervals. 

The time is NTP accurate if the Pi is network connected but has the seconds excluded so could be appear upto 59 seconds out.

The format of the transmitted time is set in /home/pi/emonhub/src/emonhub_interfacer.py line 620 something like 

self._ser.write("%02d,%02d,%02d,%02d,%02d,%02ds" % (now.year, now.month, now.date, now.hour, now.minute, now.second)

may work ok but the see python timedate for more info, (you will need to send year as 2 digit to keep it within 0-255)

Paul

Correction

self._ser.write("%02d,%02d,%02d,%02d,%02d,%02d,00s" % (now.year, now.month, now.date, now.hour, now.minute, now.second)

Sorry the number immediately before the trailing "s" is the node id the packet is sent to.

Paul

Thanks for that info, Paul.  I was wondering what the "00" was for, I think this means broadcast to all.  I'll tinker with that for a bit and let you know how it turns out.

I had set up a nanode to send the data I needed.  It doesn't have the range required, but the RFM69 connected to the pi can reach reliably.

Hi Paul, I almost got the fields I wanted using the following...

        self._ser.write("116,%02d,%02d,%02d,%02d,%02d,%02d,00s" % (now.hour, now.minute, now.second, now.day, now.month, now.year - 2000))

The 116 I use to conform to the original GLCD time format which the nanode still uses, the - 2000 fixes the one byte year bug for the next 85 years, and now.day instead of now.date returned no errors when emonhub restarted.  My packet sniffer reported...

OK 30 116 16 25 15 6 17 4 15           nanode packet
OK 1 116 16 25 18 17 4 15                emonhub packet 3 seconds later

Now all I need is to put dow in there and I'm golden for this little problem.

Thanks again for your help.

now.weekday() ?

self._ser.write("116,%02d,%02d,%02d,%02d,%02d,%02d,%02d,00s" % (now.hour, now.minute, now.second, now.weekday(), now.day, now.month, now.year - 2000))

results in...

OK 1 116 18 9 14 4 17 4 15

You 'da MAN!!!!

Now to change the id  to 30 and unplug the nanode.

Hi Paul, I have another question for you, I had to change line 569

           if key == 'baseid' and int(setting) >=1 and int(setting) <=26:

to        if key == 'baseid' and int(setting) >=1 and int(setting) <=31:

in order to set the baseid to 30.  Is there some reason for the limit?  I don't want to run over a land mine somewhere down the road.  As for now, all devices which receive the time are happy with it.

Once more, thanks for your help.

Regards....

Oh yes, thanks for the reminder. I also asked myself that same question sometime ago but forgot all about it. I see no reason why it would be 26 I have seen it else where but know you can use up to 30, you could probably use 31 as a baseid too but it's not ideal as that is promiscuous mode.

I guess I will change it in emonhub too :-)

Paul 

Hi Paul, the long time string is fully backward compatible with emonGLCD programs as the GLCD program just picks out data[1-3] and ignores any other data received by the radio.  It might help someone needing similar time data to help with variable rate planning and control.  I plan to use this to separate power rates, and to control my water heater, pool and irrigation pumps, hydroponics lighting, and HVAC setpoints for starters.  Also the leading byte (data[0]) can signal the receivers what type of data is being sent, such as ascii t (116) for time, or a 'u' for unix time, or 'c' for control data such as setpoint or shutdown info, or whatever the user wants for configuration.

Anyway, thanks again for the assistance, and if this isn't incorporated into the emonhub programs I will keep a copy of our changes and edit as needed for future upgrades.

Regards...

I'm glad you got it working the way you want, There are changes being made to how emonhub passes "control" data, control being a loose term for data going in the opposite direction to the existing data collection.

The sketch you are using in the emonGLCD may be an older one from the initial nanodeRF implementation, I don't think the later sketches require the "t" (forgive me if I'm mistaken I have zero glcd experience) many of the later sketches also handle other data like PV etc so I'm not sure the larger packet will suit all, It's a good idea to provide a more accurate time so maybe emonhub should offer either "legacy" or "unix" time updates.

When using these time updates to make the most of tarrifed time periods care should be taken to factor in (or not) any daylight saving. eg my economy7 period sticks to UTC so I have a UTC cron entry informing emoncms (via emonhub) of the period changes. If I were to use local time (ie legacy glcd type updates) it would out by an hour all summer.

Thanks for feeding back, it all helps with shaping emonhub.

​Paul

Historically, emoncms.org has sent an ASCII string "tHH,MM,SS". The Nanode checks for the 't' and retransmits 4 bytes: 't', hours, mins, secs. However, whilst the "HomeEnergyMonitor" sketch expects this (but ignores the "t", responding by virtue of the Base NodeID), the "SolarPV" sketch expects two integers: hours & mins.

[To quote someone else: "That's the beauty of standards, there are so many to choose from!"]

My local provider uses local time to set the tariff, so having rpi handle the messy dst details saves a lot of pain in the programming.  Perhaps another switch in emonhub.conf to select the format could be implemented to allow user selection.  Something like 'time_format = pv' or 'time_format = +ymd' or just default to hms as you do for other config settings.

BTW, emonhub greatly simplifies configuration of emoncms.  Great job on this.  It would be nice if all switches and their limits were listed in the .conf file in the comments section, but now that I know where to look I can tinker with it.

Paul - I am going through a similar exercise as James (above) except I only want to add just the seconds for now.  I made the changes to the .py file, but there was no change to the “broadcasting time” line in the emonhub log file.

I shutdown and restarted the emonPi and the changes appeared as expected.  Is there an easy way to cause the emonHub to see .PY file changes?

Jon

No, with python the changes will only get picked up as the program (or module) is initialized but you don't need to reboot the Pi, just use " sudo service emonhub restart " at the command prompt, depending on it's workload etc it can be quite slow to restart (when you are watching it) as it will try to ensure outstanding jobs are completed before stopping.

Paul