fixed missing "s" in datacodes

[rexometer]

Hi Glyn,
thanks for merging the last pull request so fast! :)
Found another importing issue: With adding the "L" data code here: e49fb78 "datacode" has to be changed to "datacodes".

This one is important because otherwise emonhub stops with: MainThread RFM2Pi thread is dead
I did copy&paste the error with my last pull request, sorry! That's why I also updated: conf/nodes/11 till conf/nodes/14.
Best, Elias

[TrystanLea]

Hello Elias, thanks for this, I see you have added the current and powerFactor entries but these are not present in the firmware, did you mean to include these in your pull request?

[rexometer]

Hi Trystan,
yes sorry, did'n know that new changes get also pushed to the "old" pull request.
We added current and powerFactor because it is of some interest for research institute (our office is locate at the campus of university kassel).
Not sure if this could also be the default? If yes we can do a pullrequest for the 3phase-firmware too. If not, maybe it's better if we create a new branch for the "extended" firmware?

[glynhudson]

Hi @rexometer , It's not a bad idea adding current and PF to the three-phase FW. We would accept a PR for this. As long as the additional data codes are added to the end of the RF packet structure and emonhub config it won't effect users running older FW. Note that the increased RF packet length will have a slight determinant to RF range and packet reliability, however I can see PF being very useful to monitor.

[rexometer]

Hi @glynhudson thanks for merging.

increased RF packet length will have a slight determinant to RF range and packet reliability

We did notice this as well (what is the reason? is the native RF69 mode more reliable, as the RF12-compatible mode?) and are looking for a solution. We did some successful test's with the library from lowpowerlab but that would break compatibility with existing receivers. So our idea is to send current and pF values with a separate package with another nodeID. What do you think of that?

[glynhudson]

I guess it's because sending more data via RF is more susceptible to corruption.

Yes, I think native RF69 could be slightly better. However backward compatibility is important. @TrystanLea did some testing using LowPower Labs lib and native mode a while back. I'll see if he published results anywhere.