New name ?

[lafrech]

There's discussion about a new name for the OEM Gateway.

I think my idea was that OEM is OpenEnergyMonitor and emon is emonCMS but this is stupid: emonTX, emonTH, etc. I should have thought twice...

From https://github.com/Jerome-github/oem_gateway/pull/21#issuecomment-39520401

• emonGateway - closest to the existing name
• emonGW - matches the TX TH CMS etc
• emonHUB - probably the simplest descriptive name

Any thought, anyone ?

[Dave-McCraw]

Do we ever want to process the inputs between Listener and Dispatcher?

The overall architecture of emoncms has been to perform manipulation of the inputs solely there, but it occurs to me that the difference between forwarding to emonCMS:node and emonCMS:input modules (#20) would be accommodated nicely by accommodating processing capabilities in this gateway (rather than two different modules of the gateway that are almost identical).

On top of any in-memory processing, I was considering allowing the MySQL-buffered version of this gateway to expose the inputs for pre-processing by "third parties" before marking them for onward dispatch. This would allow you to dispatch to systems other than emonCMS amongst other things.

I'm torn, because while it would probably be best to avoid having two places where we do similar things, I also believe in the principal of separation of concerns. If I designed the system from the ground up, processing inputs, storing the outcome in data feeds, and visualisation of feeds would be the domain of separate systems to allow us to make improvements to different aspects more freely.

To answer the question specifically, my preference would be emonGateway because I think it's hard to intuit the purpose of emonHub, and "gateway" certainly accommodates pre-processing if we choose that route.

Telling people they want the emonBase (Pi) running emonGateway to connect their nodes to local and remote emonCMS installations is fairly simple?

[lafrech]

My favorite name option is emonGateway as well.

I started with a rework of the RPi module of emonCMS, until I realized it would be better to have it separated:

• it can be used without emonCMS
• any new feature can be used without having to modify the GUI (emonCMS)

Since I wanted to keep all features, including the use of emoncms GUI to set the parameters, I designed this twisted Interface class, to allow for different interfaces to be added (why not a GUI, even remote, through a port).

I hate nothing more than effort [|duplication], and I expected the python gateway to be a replacement for the php one. At that time, it was a php script launched through cron. It's been improved since then, and it is still the reference implementation on the emonCMS/RPi solution.

I'm happy if the python gateway is a core part of the project, thus concentrating development efforts. This is why I always try to keep it generic. One more reason to care about the name, and choose one that makes it sound like the natural choice (along with the installation instructions and the packaging).

I think @TrystanLea and @glynhudson may have a say about the name. (Do they get notified if I @ them ?)

I wouldn't mind transferring the repo to the OEM repo. Or share write access. I started the repo as mine because I wanted to prove the concept before bothering them to open a new one.

[Edit: pushed Ctrl+Enter accidentally...]

[TrystanLea]

emonGateway sounds great, although I also like oem_gateway as its got traction, what we all know so far. but OEM has another meaning for people new to the project. original equipment manufacturer but then we use short hand oem so much what does it matter.

I think its great if you want to continue to administer the repo Jerome, credit to yourself is clear and you can maintain its coding standards that way, ie my last pull request :)

[pb66]

Originally I prefered emonGateway but on https://github.com/Jerome-github/oem_gateway/pull/21#issuecomment-39520401 it was considered inaccurate, surely the term will fit even less as time moves on and features get added, emonHUB is vague enough to cover alot of ground for intance as you move into controlling heating etc gateway no longer works as well,

Also if you have a large installation or multiple sites terms like "ground floor hub" and "first floor hub" or "holiday home hub" all make sense and each hub will work independently, if there is a power outage or comms outage the back-up data for that site is on that sites hub, where as multiple gateways sounds confusing especially if they are bidirectional and distributing commands from the powergen module or red-node etc.

I think using "gateway" now maybe the equivalent of using "oem" back then, made perfect sense at the time but short lived. The name doesn't need to be too technically accurate its main aim is to identify it as an essential part of the emon suite that handles the delivery of data to it's intended target. Users that want a more in-depth description will read-up on it regardless of how much the name gives away.

[Dave-McCraw]

OK, I like hub too, in terms of explaining it in documentation

You need an emonBase and it can either be:

• lite option: nanodeRF through to emoncms.org
• a Pi and run the emonHUB software on it

[lafrech]

I didn't know the term OEM.

emonHUB is fine for me.

I tagged v1.0. I suggest we use major.minor.revision like this (from http://en.wikipedia.org/wiki/Software_versioning):

the major number is increased when there are significant jumps in functionality such as changing the framework which could cause incompatability with interfacing systems, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed.

I realized a bit late I forgot to add a --version feature. I did it and created 1.0.1. I guess no (first) release is perfect. (The bug trackers also attests that...)

Dave, tell me if that is fine for debian packaging.

I also created a dev branch for the new stuff.

Let's say we agree on the new name for version 1.1.

[lafrech]

Following up on versioning, the version is now printed in the log file. This will help when users copy their log file to show an error.

[Dave-McCraw]

Hi,

Sorry, for some reason I missed that you had discussed actual tags and not just the tag policy - my bad :facepunch:

I just started an issue in emonhub/emonhub#1 to discuss pulling together a v1 release with the new name there. (I'm not sure what you prefer in terms of having a dev branch here or maintaining in a new common area).

I think it would be nice to do a couple of things from the word go, mainly internals such as rebranding the buffers to dispatchers. That way we start with a clean slate and don't have a major refactor as one of our first updates to the "new" system?

[lafrech]

Let the new name be... emonHub.

[albertovm]

I have Emonhub/EmonPi and did configure OEM Gateway to send data from Arduino directly to my Raspberry USB. I had 3 issues:

1) /var/log/oemgateway is deleted all the time automaticallyy. 2) localhost url do not updates Nodes directly, but inputs. 3) node sent from Arduino is just "5", and in serial I have "5", but in URL I have 5.0 and data is sent to a wrong place.

• Does I really need to do this special configuration and execute OEM Gateway or it can be done directly from EmonPi?
• Is possible to solve the node number problem?

Thanx a lot!

[pb66]

Hi albertovm

The place to get support for emonhub and emonpi is the openenergymonitor forum. Support for usersstill using oem gateway is also provided

Please start a thread on the forum and we will be happy to help there.

Paul

[albertovm]

Thanks a lot!

http://openenergymonitor.org/emon/node/11247