Archived Forum

I am interested in this as well - as I would like my EmonTX to post updates to MQTT topics (to end up in openHAB).

Oemgateway was designed to be modified for use with other destinations and emonHub is currently being developed in such a way to promote development and inclusion of "other" destinations as well as other input sources. 

However, since the default url string is constructed from an address specified in the conf file and then the data and a timestamp is attached with the necessary apikey and formatted specifically for submission to emoncms, some additional changes are required, so a new "type" class should be created.

If you post some details about your requirements eg target & formatting etc we can give you some pointers or show us what you have, you can attach copy of oemgatewaybuffer.py & oemgateway.conf or point to git repo if you have one set up.

summerboy -  natshiel is adapting the gateway software run on the Pi, that forwards the data from an emonTx (network). Your post suggests you want the emontx to connect to MQTT directly which wouldn't involve a gateway or pi so the solution would be different unless you plan to use a gateway.

Paul

Hi,

I've made some progress: I can sometimes send requests to an address of my choosing. However, the .py code has a VERY odd property where small changes will cause nothing to happen. I'm attaching my oemgatewaybuffer.py. I had to attach the output in text files because the forum would not let me submit the output in the post.

The only lines I've changed are those relating to the variables url_string and data_string. An example of the strange things that are occurring:

Line 154 of oemgatewaybuffer.py is

url_string = "10.156.45.16:8080/innovation/device/register/post.json?"

When I reboot the pi the ouput I get is in the file output1.txt

The last four lines of the output repeat several times a second

Notes: the /innovation/device/test lines are produced from the .conf file, but the data is NOT being sent there, it's being sent to the URL "10.156.45.16:8080/innovation/device/register/post.json?"

It's not weird that the send fails, because there's no http:// infront of the IP address, but this output shows that the http requests are being attempted, at least.

When I edit the url_string variable to url_string = "http://10.156.45.16:8080/innovation/device/register/post.json?", the output changes to output2.txt.

And it stops there. Any ideas as to why this is happening? I'm happy to explain anything that's confusing with my output or code (the code IS kind of messy, sorry about that)

Hi,

An update to the above response I gave: I'd like to send a request in the format

http://10.156.45.16:8080/innovation/device/register/post.json?{"uuid":"12345","user1":"120","user2":"70","user3":"13","user4":"46"}

Sorry to bump, but I'm on a tight timeline and any help would be very much appreciated!

Hi natshiel, I've been a little tied up the last few days and missed your post. the labels in the data_string make things a little less flexible. It looks like your URL is incomplete and there is some redundant code still in play.

I've quickly knocked up a custom buffer for you. I haven't tried it and I'm more accustomed to emonhub than oem gateway, but if nothing else, it should point you in the right direction.

Some assumptions have been made and are commented on in the file below. It's a very quick and very dirty fix that does no error checking or qualification beyond checking the data is numeric. there's no timestamp and the node id is ignored.

There are a couple of lines to add to the conf file as well. Sorry for the short response, but I'm off again very shortly. I hope this helps, 

Paul

I think I will be writing a custom sketch for my Arduino + EmonTX Shield as it will be sitting on an Ethernet shield and I want to post results back to an MQTT broker directly.

I have written a couple of other sketches that do this sort of direct MQTT publishing from Arduino nodes (using http://knolleary.net/arduino-client-for-mqtt/) and it works very well.

I can then decide how to use that data. A simple python script could monitor the necessary MQTT topics and publish results to an EmonCMS server in the correct format, or I can write the data to my InfluxDB database and display the results using Grafana.

I quite like the idea of decoupling the EmonTX from whatever reporting tool - and MQTT is the perfect protocol for this.

Hi pb66,

Thanks so much for your response. I've unfortunately been in a weird situation at work where I haven't had the time to work that I thought I did, or have been separated from the hardware. When I tried to run the natshiel buffer, I originally had some trouble compiling but eventually got it to work, and now I'm debugging. I have a question, though. When I turn on the R-pi and the EmonTX and nothing happens after "INFO Serial RX: > 0s INFO Serial RX:  -> 4 b," what is the reason for that? It seems to me that it's happening arbitrarily, which is almost certainly not the case, but it makes it very hard for me to debug when I don't know what's going wrong. I'll add a line for debugging output and the code will run in a totally different manner, which is really confusing to me. Do you have any advice for the debugging process?

I'll upload the changes I've made to oemgatewaybuffer.py when I next have the opportunity. Thanks in advance!

GOT IT

Or at least I'm pretty sure I do. Our server is down but all the output looks correct. Your code got me started (and pretty far, thanks!), but there were several more change that I had to make. I believe I had to update gatewayinterface, conf, and gatewaybuffer. I'll upload the files in the zip below.

Quick note: The contents of the oemgateway.conf file appear to have to be the exact same in two places, or maybe the code was just being funky. By this I mean that I changed the .conf file that I've uploaded first by sshing into the Pi and using a text editor AND by plugging the SD card into my computer and changing it there too. It seems that the two files must be EXACTLY the same.

Hope this is helpful to everyone!

I'll try to answer the questions y'all have, wish me luck on my presentation on Friday :)

Hi natshiel, 

I'm glad you got it working, that's a priority for your presentation, 

It looks like the problems you have overcome by altering the code originate from the command line used, this is normally defined in the daemon script  at /etc/init.d/oemgateway which is not included in your zip so I'm unable to check it.

When OEMG is started both the logfile and the config file locations should be specified eg

oemgateway --config-file /path/to/my/settings/oemgateway.conf --logfile /path/to/my/logfile/oemgateway.log

If the logfile location is ommited it will default to outputting the log entries to the console screen which isn't so bad, but if the config file location is ommited then it will assume it is installed with emoncms installed to the same machine and expect emoncms to provide the settings, which is why you have had to duplicate the setting in the emoncmsInterface class of the oemgatewayinterface.

you can see here OEMG is configured to use emoncms by default, comment out Line28 and uncomment Line29 and edit it to your config file location.

It's not clear why the oemgatewaybuffer.py needed further editing other than the the fact you have  edited oemgateway and pointed the main loop to the oemgatewaybuffers "send" rather than the intended "add" by using b.send(values), there by bypassing any buffer functions.

I am happy to help you resolve these issues if you want, although to do so I would recommend setting up a GitHub account for this type of thing and perhaps even look at emonHub rather than OEMgateway to build a more permanent  "add-on" bespoke solution to replace my "quick fix".

Hope it goes well Friday !

Paul

Howdy,

Quick note on why I have the oemgatewaybuffer.py using .send() instead of .add(): I purchased the ready-to-go SD card, and the main loop in oemgateway.py was exactly as I have it in the zip I uploaded, using b.send() and b.run(). The python code you sent me had a ".add()" and a ".flush()", (nearly identical to .send and .run) so I simply renamed those functions to .send() and .run() and called it a day.

In terms of a long term fix, I'll see if I can convince my employer to let me keep playing with their hardware after the presentation :)