Community
OpenEnergyMonitor

Community

Help with RPICT w/ Atmega Controller - WARNING Device communication error - check settings

Hi guys,

Trying to setup EmonCMS for the first time using a lechacal board RPICT7V1 V3.0 and Emonhub to send data to EmonCMS .

Managed to upload sketch to my board and got EmonCMS up and running .

However, I am not getting any inputs in EmonCMS and I believe it’s because of this error in my emonhub.log file :

WARNING Device communication error - check settings

Apart from that I am getting these lines in my emonhub log :

2020-01-14 01:26:13,821 WARNING 1 RX data length: 15 is not valid for datacode h
2020-01-14 01:26:16,288 DEBUG 2 NEW FRAME : 1578965176.29 11 0.0 0.0 0.0 0.0 0.0 0.0 0.0 226.4 203.0 205.7 238.1 204.3 223.7 230.5 0.4
2020-01-14 01:26:16,289 WARNING 2 RX data length: 15 is not valid for datacode h

Think I am close to getting this up and running but am stuck now and my EmonCMS is not getting any inputs .

Would really appreciate some help with this as I have absolutely 0 clue on how to go from here .

Thanks !

Whilst that error would also appear if you were using the wrong serial baud, it merely indicates that the 2 devices are not having a fluent conversation, in this instance it is most likely because neither is specifically designed to be compatible , ie emonhub is asking a question and it is getting an unexpected reply or more likely, no reply.

These pairs of lines tell us what the issue is

The payload of data passed over serial contains 15 numbers (excl the node id “11”) which emonhub objects to because it is configured to receive just 16bit signed integers as pairs of byte values, so 14 would represent 7 values or 16 would represent 8 values but “15 is not valid” with the current settings ie “datyacode h” which is the default for the EmonHubJeeInterfacer to be compatible with JeeLib based devices.

Looking at the data payload it would seem your device is sending normal uncoded decimal values and actually require no decoding.

You can fix this by either

  1. overriding the default detacode in the currently used EmonHubJeeInterfacer by adding datacode = 0 in the [[RFM2Pi]][[[runtimesettings]]] of emonhub.conf or
  2. changing the interfacer type to EmonHubSerialInterfacer which already uses a default datacode of 0, a potential advantage of changing interfacer type would be that all the stuff for controlling an JeeLib/RFM based RF transceiver would be taken out of play ie these settings
    2020-01-14 01:46:21,976 INFO Setting RFM2Pi frequency: 433 (4b)
    2020-01-14 01:46:22,978 INFO Setting RFM2Pi group: 210 (210g)
    2020-01-14 01:46:23,980 INFO Setting RFM2Pi quiet: 1 (1q)
    2020-01-14 01:46:24,983 INFO Setting RFM2Pi baseid: 15 (15i)
    

That’s a matter of opinion, old doesn’t always mean outdated (thankfully :grin:) v1.2 is in fact still the latest version of original emonhub, we do not know which version LeChacoal intended to be used (if any). I certainly still use and prefer this version today. Only the OEM’s “emonpi variant” has moved on and due to the numerous changes I have no idea whether the datacodes can still be set at an interfacer level since node definitions are considered mandatory. It maybe that a node [[11]] definition would be needed in that version.

2 Likes

Thanks for the detailed insights Paul, I managed to get it working after changing the interfaces to serial and now have my inputs showing up in EmonCMS, albeit no names as per the config . :+1:

For the names to be carried over from the emonhub you would need to run the OEM “emonpi variant”. Although most of the code was taken from my experimental v2 of original emonhub, it has deviated significantly from the original direction of emonhub.

The names will only be passed over using MQTT in the emonpi version so you would need a MQTT broker and potentially significantly more setting up of emoncms and reinstall emonhub (emonpi version).

If posting to emoncms.org the names are not passed over in either variant, only if self-hosting can the names be passed.

1 Like

He deleted the post, and I thought it might contain info useful for troubleshooting,
so I undeleted it. Either way, his issue was resolved, and that’s what I was after.
Guess it’s time to stop callng it a “pre-release” version, eh? :wink: :grin:

2 Likes

It did and still does, yet it still got deleted, orphaning the references to it. I have tried undeleting again without joy so here is the content of that deleted post from Rick (@Tripton).

Edit :

Retrying sometimes returns different initialization log :

2020-01-14 01:46:19,483 INFO Exit completed
2020-01-14 01:46:19,944 INFO EmonHub Pre-Release Development Version (rc1.2)
2020-01-14 01:46:19,944 INFO Opening hub...
2020-01-14 01:46:19,961 INFO Logging level set to DEBUG
2020-01-14 01:46:19,962 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2020-01-14 01:46:19,963 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2020-01-14 01:46:19,963 INFO Setting emonCMS url: http://localhost/emoncms
2020-01-14 01:46:19,964 INFO Setting emonCMS apikey: set
2020-01-14 01:46:19,964 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2020-01-14 01:46:19,965 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2020-01-14 01:46:21,974 INFO RFM2Pi device firmware version: #
2020-01-14 01:46:21,975 INFO RFM2Pi device current settings:  Offsets I: 2036.89 2038.15 2033.40 2034.42 2037.12 2041.53 2033.90
2020-01-14 01:46:21,976 INFO Setting RFM2Pi frequency: 433 (4b)
2020-01-14 01:46:22,978 INFO Setting RFM2Pi group: 210 (210g)
2020-01-14 01:46:23,980 INFO Setting RFM2Pi quiet: 1 (1q)
2020-01-14 01:46:24,983 INFO Setting RFM2Pi baseid: 15 (15i)
2020-01-14 01:46:26,010 DEBUG 1 NEW FRAME : 1578966386.01 11 0.0 0.0 0.0 0.0 0.0 -0.0 0.0 234.3 200.2 194.6 242.9 199.7 219.4 233.0 0.7
2020-01-14 01:46:26,012 WARNING 1 RX data length: 15 is not valid for datacode h

In this case it seemed it was starting but there were still no inputs added in EmonCMS

Edit - undeleted post. emonHub version is outdated. Viz:
01:46:19,944 INFO EmonHub Pre-Release Development Version (rc1.2)
BT - Moderator

Since I have never released emonhub it is still technically a pre-release :grin: . Actually in an attempt to reduce confusion I just stopped making changes to that repo when Trystan decided to launch the emonpi variant in a completely independent repo severing all ties. Since my v2 is in another branch and Trystan has also used v2 and there is now discussion about v3 I have no idea where I will go next! I have no intention of “releasing” or continuing development of v1, I strongly suspect if I pick this up again it will also be based on my v2.0 (not the emonpi variant which is also based on my v2) but as for whether that would be v2.?, v3 or v4 I have no clue, hence why I have left things as is.

As a matter of interest, which repo/branch is this?

The only real changes are to make the emonpi variant Python3 compatible.

Bear in mind this was just a PoC introducing bidirectional comms and data routing, it was never completed as I couldn’t raise any interest from OEM to test and discuss MQTT structure, it was then left to stagnate until the imminent launch of the emonpi hardware when Trystan asked for MQTT and bidirectional comms to be added to emonhub (v1.2). when I revised my request for testing and opinion on this v2 he took this code, rapidly changed it and the emonpi variant was born, I’ve not bothered going back to it since. But despite being unpolished or even unfinished it remains closer to the intended function of emonhub and it hasn’t been through the cycle of being changed and then partially changed back that the emonpi variant has so it is easier for me to continue from where I left off than learn, fix and possibly revert the emonpi variant.

The subject of logs keeps coming up and even changing the way the settings are checked. emonhub is platform agnostic (or at least it was) I run emonhub on windows too, we cannot build in any dependence on any linux only services eg journald etc. The logs have been a long standing blessing to the OEM project, they have resolved issues with emoncms, emonTx’s, emonTH’s, MQTT, serial, rfm to mention just a few, rather than cull the messages we should be expanding on them, the loglevels are there to reduce/increase logging output. For example the suggestion of removing the “Sent to channel(start)” and “Sent to channel(end)” messages is the right thing to do, but it should be understood the reason they are there is because of the vast amount of code added with no error or status logging meant when we had the “thread is dead” issues there was no info to work with to resolve the issue, as soon as I added those messages it was obvious what the issue was, it just took so long for the code to then be fixed that those messages had become essential to debugging and they remained beyond the fixes to help confirm the fix. Yes they can come out now, but had the code been written with adequate logging they would never have been added and the issue would of been resolved years sooner, perhaps before it was released? So the trend must be to make emonhub logging more verbose not less. There are other points too, but TBH I see little value in debating them. I have no control over what happens to emonpi variant of emonhub, that’s the one widely used, I understand that version is more appealing as it has more features than v1.2 but it arguably has less than my v2 and left under my control where would emonhub have been now after 5 more years of development?

[edit - Just to say it’s not all bad! There is a lot of good stuff gone into the emonpi variant too, like the additional interfacers for modbus etc. There is much stuff I would want to try and carry over from the emonpi variant but the more it diverges the bigger the task becomes and more backwards compatability is needed, regardless of whether it’s the right approach or not eg the mqtt!]

1 Like

Partly my fault. I wanted a way to get logging over a longer period while testing the Python3 version and thought it might have a wider application. I wouldn’t suggest reducing the amount of messages, especially at DEBUG level.

That’s useful to know and obvious really. I’ll bear it in mind next time that particular discussion comes up!

The thing there of course, is that you do not need to use the MQTT reporter.

Cheers

Hey guys,

A bit off topic but any way to receive data such as reactive power / apparent Power / power factor in EmonCMS?

I can see powerfactor was added in latest versions but not the other two.

Also, can this data be sent through Emonhub?

Thanks

Edit : Please disregard this post, already added them , was much simpler than I expected . Just needed to add them to the sketch and update the config to add three extra inputs !

2 Likes