Hi,
I have been using the following set-up since begin 2014 with success:
1 emontx v2 in the attic
1 emontx v2 in the cellar
1 ubuntu v14.04
1 jeenode USB
Suddenly the set-up stopped receiving information from the attic and as I was still running the old oem_gate way software I decided to "upgrade" to the newer emonhub rc1.2. After installing this and with a lot of problems configuring the emonhub.conf I managed to get the jeenode USB set-up to work. My next step would be to switch to the newer Jeelink (v3c) with the new RFM69CW as the receiver is better. And here my problem begins. The new Jeelink is running the rf12demo.12 version and as such is sending "ok" and the module number and the information. But emonhub does not like that :(
2015-12-22 12:16:37,014 DEBUG 43 NEW FRAME : 1450782997.01 OK 10 97 0 0 0 0 0 1 1 143 93 171 0 (-47)
2015-12-22 12:16:37,014 WARNING 43 Discarded RX frame 'non-numerical content' : ['OK', '10', '97', '0', '0', '0', '0', '0', '1', '1', '143', '93', '171', '0', '(-47)']
2015-12-22 12:16:46,072 DEBUG 44 NEW FRAME : 1450783006.07 OK 11 240 0 0 0 0 0 3 0 196 94 0 0 (-93)
2015-12-22 12:16:46,073 WARNING 44 Discarded RX frame 'non-numerical content' : ['OK', '11', '240', '0', '0', '0', '0', '0', '3', '0', '196', '94', '0', '0', '(-93)']
I have searched the forum a lot and found several users reporting the same problem and the solution was to use the emonhub rc1.2...but...that is the version I am using...or...at least this is reported in emonhub.log each time the soft is started.
To give you full details find below my emonhub config :
[SerialDirect]]
Type = EmonHubSerialInterfacer
[[[init_settings]]]
com_port = /dev/ttyUSB0 #USB
com_baud = 57600
[[[runtimesettings]]]
#pubchannels = ToEmonCMS,
#subchannels = ToRFM12,
#basetopic = emonhub/
#calibration = 230V #(UK/EU: 230V, US: 110V)
#baseid = 10 #(emonPi default:5)
#quiet = false #(default:true)
#datacode = h
[nodes]
# List of nodes by node ID
# 'datacode' is default for node and 'datacodes' are per value data codes.
# if both are present 'datacode' is ignored in favour of 'datacodes'
#[[99]]
[[10]]
nodename = emonTxShield1
firmware = emonTxShield
hardware = emonTxShield
[[[rx]]]
names = CT1, CT2, CT3, CT4, Volt, Temp
datacode = h
#datacodes = h, h, h, h, h, h #RFM2Pi
scales = 1,1, 1, 1, 1, 0.1 #RFM2Pi
units = W, W, W, W, V, C #RFM2Pi
So please help as this "simple" upgrade is taking way to much time and I do not know what to do next.
Re: emonhub rc1.2 'non-numerical content'
Sorry to hear to are having troubles, emonhub v1.2 is indeed a direct replacement for oemgateway and had you been using the OEM RFM2Pi board the transition would have involved installing emonhub and editing your apikey, that's it, done!
Emonhub is also totally able to use either a jeenode or jeelink without problem, however I do not know how easy the transition could be as I do not know exactly how the JeeNode was previously configured. If it is using a standard rf12demo sketch v11 or v12 then again the transition should also be straightforward and painless, only the additional edit of the "com_port = /dev/ttyAMA0" to the correct ref eg /dev/ttyUSB0 depending on how the jeenode is connected.
There is/was no mandatory need to define any nodes (you can but don't have to)
The main source of your troubles could be the use of the "serial-direct" method of connecting non-rf OEM nodes and other "non-Jee" type devices directly via the EmonHubSerialInterfacer rather than the EmonHubJeeInterfacer which is recommended for all Jee (RFdemo) based devices as it has the ability to manage the settings and more importantly it understands the payload returned by the Jee devices using the RFdemo.
The non-numeric content warnings you see are because of the "OK" and the bracketed rssi value at the end, these are normally handled appropriately by the "Jee" interfacer prior to confirming everything else is numeric only.
The EmonHubJeeInterfacer is the direct equivalent of the oemgateway's rfm2pi listener, renamed Jee to include the JeeNode and JeeLink.
Be wary of the JeeLink firmware, even if it does report v12 it may be a very late "different" v12, When I ordered my own JeeLink for testing emonhub, they were not yet available with the rfm69 fitted but I contacted the shop and got one by special order, that arrived with v13 installed which when I enquired was installed to all JeeLinks at that time, since then I have found v13 has vanished from the JeeLab repo and there are conversations on their forum about the latest JeeLink firmware and what version it (v12) actually is. If there is any doubt just reinstall the latest v12 RFdemo or the RFM2Pi firmware to be confident of what you have.
So start with changing the interfacer "Type =" to revert to the "stock" emonhub.conf, using the correct port ref and report back with some log if it doesn't work as expected.
Paul
Re: emonhub rc1.2 'non-numerical content'
Thanks Paul,
Btw Merry Christmas to you all.
I got it working now. I removed all I could find on emonhub and did a clean reinstallation.
So that is solved...now for the next step...I configured also the emonhubmqttinterface but I get an Error Unable to create 'MQTT' interfacer : 'Module' object has no attribute 'emonhubmqttinterfaces'
Is this due to the fact that RC1.2 has no MQTT?
Any idea to get this working?
Can I install RC2.0 on my ubuntu server?
Thanks in advance
Re: emonhub rc1.2 'non-numerical content'
Merry Xmas to you :-)
You are right v1.2 doesn't have MQTT, there is a skeleton MQTT "reporter" out there somewhere, It was actually the need for bi-directional and routable data streams to fully utilize MQTT that instigated the v2.0 emonhub branch, since v1.2 is a simple single stream design sending everything to all the reporters without any configurable routing.
However although the v2.0 "experimental" branch did tackle both those requirements, ironically there is a bit of a hole in the MQTT code in that branch as that was where the development lost traction when deciding the best format for the MQTT topic trees and payloads.
emonhub is intended to be cross-platform and that branch should definitely run "ok" on ubuntu, "ok" meaning there should be no platform issues, but it is a rough "proof of concept" hence the "experimental" label and at best, a bit rough round the edges. I cannot say it will definitely be trouble free but the "emon-pi" variant is heavily based on it and that seems ok. If you do use it I would be keen to hear any feedback as I hope to get back into it in the new year.
Paul
Re: emonhub rc1.2 'non-numerical content'
Hi,
Sure I want to help to test. I am not a linux guru but I am willing to experiment and help.
Can you give me a link to start from as for me the information and branches seems scattered around?
Herbert
Re: emonhub rc1.2 'non-numerical content'
What is the end goal for which you need MQTT?
The "emon-pi" variant does have MQTT but it is not a direct replacement for oemgateway, think of it as "emonhub's cousin", simplicity, reliability and buffering are the trade off for MQTT, whereas v1.2 is a direct replacement with improved features and reliability but MQTT is not integral,
v2.0 was never completed and I cannot really recommend it's use, if it better suited your needs and were able to "fix it up" you are welcome to use it but it was never intended for production and there are no guides or discussions to help you. My comment re feedback was out of interest for any useful info that may help development of the next version, it doesn't strictly need "testing" as that version won't get released.
Paul