Archived Forum

Hi Jason

The time stamp used is unix it is the number of seconds since 00:00 1st Jan 1970. The "1970 time issue" would manifest itself as an incorrect "1970" date in the leftmost column in the log file, so you are ok there.

The issue is indeed to do with the missing/blank variable or double space before the node id. From your previous post I assume you are using a JeeLink. Which firmware sketch are you using ? and which emonTx sketch are you using ? 

The variables passed depend on which sketch you are using, but the values you see are undecoded bytes so are not readable yet, emonhub is discarding the packets because the format doesn't comply with something it expects and can decode, because of the empty variable.

Paul

Just as a sidenote, if we want to avoid the problem of consecutive whitespaces, we could change this line:

-frame = frame.strip().split(' ')
+frame = frame.strip()

See split definition here: https://docs.python.org/2/library/stdtypes.html

I don't think this would bring any unwanted side-effect. Otherwise, it is always possible to strip the result of split(' ') from empty strings anyway.

I had considered something along those lines but couldn't decide which was better, the existing "fussy" code that can be a little annoyingly strict or the more "friendlier" method you suggest, the thought was there is currently no good reason for a double whitespace so as annoying as it is it maybe better than finding out you've dropped a value somewhere along the line and posted a load of rubbish to emonCMS because the byte values have been bumped along a position, so I left it as is for the time being,

Paul

I'm using a brand new emonTx v3 from the OEM shop which arrived last week (assume  emonTxV3_RFM12B_Discrete Sampling sketch, but don't know). Unfortunately I don't know what the software version is and assume that I'd have to attach a direct interface cable to determine this. Is that correct? Am I able to determine this via the RF interface from the Jeelink?

Jeelink is similar, just delivered a week ago and using the default sketch [RF12demo.13]. 

Here is a sample of the output from the Jeelink user screen command. It is showing 'bad' frames, which I assume is relatively normal and they are just interpreted interference junk rather than actual data?: 

Current configuration:
 O i15 g210 @ 433 MHz
OK  10 0 0 0 0 0 0 0 0 46 112 0 0
   ? 210 10 12 0 0 0 0 0 0 0 0 70 112 0 0
OK  10 0 0 0 0 0 0 1 0 27 111 0 0
   ? 210 10 12 0 0 0 0 0 0 53 0 244 110 0 0
OK  10 0 0 0 0 0 0 53 0 119 110 0 0
   ? 210 10 8 0 0 0 0 0 0 53 0
   ? 210 42 12 0 0 0 0 0 0 53 0 79 110 0 0
OK  10 0 0 0 0 0 0 53 0 149 110 0 0
OK  10 0 0 0 0 0 0 53 0 151 110 0 0
OK  10 0 0 0 0 0 0 53 0 27 111 0 0
OK  10 0 0 0 0 0 0 54 0 138 111 0 0
   ? 210 26 76 0 0 8 4 0 0 114 0 24 112 0 0 26 81 128 4 2 128 0 0

Thanks again, Jason

Hi Jerome,

Thanks for the reply.

I assumed that since the frame looked relatively complete that it was likely I could change the script to ignore the data, but I'd like to know what it is that I'm missing and why rather than just ignoring the space.

The other thing is that if I upgrade the software any change I make will likely have to be reintroduced.

I think I will make your change, just so I can see the monitor work with emoncms, but I really would like to know what the data I'm seeing from the emonTx actually means.

Thanks again, JW

Yes if you modify your emonHub installation, the modif will be lost next upgrade. Consider this as just a test.

I was suggesting we could integrate this modification in emonHub, but Paul is right that the root cause is the double space and this is what should be investigated.

Hi Jason.

The RF12demo.13 is still in development and changes are still being made to it over at JeeLabs, I did try loading it to a JeeLink I have a while back, but found a couple of anomalies and decided to fall back to RF12demo.12 until 13 is finalized and emonHub can then be altered for compatibility if needed.

It's too early to make permanent RF12demo.13 changes yet because then emonHub users, like yourself that have a working JeeLink could get stranded if JeeLib make a change and emonHub follows to suit without any backward compatibility, When it's finalised emonHub will almost definitely support RF12demo.13.

With that in mind it is also quite difficult to know with certainty the exact "vintage" of your RF12demo.13. If you want bleeding edge versions you could edit emonHub as suggested by Jérôme it certainly would help to test the theory and isn't that difficult to reintroduce to "updated" emonHub if needed, you could probably just add a hash (#) to what is currently line 95 of emonhub_interfacers.py so it comments out the latter half like this

frame = frame.strip()#.split(' ')

Alternatively you could upload the fully supported RF12demo.12 to your JeeLink until emonHub has support for RF12demo.13, I feel this may be a wiser choice as I'm unsure if any other differences will surface, for example I believe the RF12demo.13 also prefixes the firmware version with a new line when it prints that will cause an issue with the next version of emonHub (rc1.1)

Without the double space the data would be processed and you would see the resulting values in the logs if loglevel set to debug or info. The string you see, for examle " OK  10 0 0 0 0 0 0 54 0 138 111 0 0 " is node 10 after the initial OK and spaces, followed by 6 pairs of byte values eg "138 111", the trailing value (msb) multiplied by 256 is added to the leading value (lsb) to give you an integer and as they are signed ints, if the result is over 32768 subtract 65536 to give you a negative value.

The resulting 6 signed integers are power1, power2, power3, power4, Vrms and temp. Vrms and temp are both scaled by 100 so multiplying by 0.01 will give a value accurate to 2 decimal places, the rest are in watts.

Paul

How did you get on with this?

Something else just occurred to me. emonHub rc1.0 was designed to suit just the RFM2Pi and that board comes in 2 flavors rf12 and rf69, the rf12 version uses a version of RF12demo that doesn't prefix with "OK" and the rf69 version does prefix with "OK" as well as providing a RSSI value in brackets at the end. emonHub rc1.0 won't recognize the use of "OK" without the trailing RSSI in brackets.

This has been changed in rc1.1 to also suit rf12 devices that use stock JeeLib RF12demo ie "OK" but no no RSSI. rc1.1 is "currently being tested" and if you wish to try it you can switch to the "testing" branch of emonHub.

​cd ~/emonhub
git checkout testing

should do it, but if you have made changes ie Jerome suggestion git may object so probably best to undo the change 1st.

Paul