New user experience (issues encountered)

(Chris Wilson) #1

Hi all,

Generally I would like to congratulate and thank you for creating a really nice open source hardware project. It works very well now that I have got used to the quirks, and I would like to make it even better if I can.

I would like to report some issues that I encountered as a new user, in the hope that it may help to enhance the new user experience. I’m not sure of the correct place to report them. Some relate to web pages, but those pages have no comments feature.

I know that this is an open source project and I could in theory fix some of this myself, but I’m a new user and even when I can see a problem, I don’t necessarily know the correct solution. Many are documentation-related and I don’t know if that is also open source, or where to look for the source. So I am reporting them here in the hope that someone will point me to the right place to report anything that needs to be reported elsewhere.


Each emonPi only supports one optical pulse counter, but I missed this and I think it’s not well documented:

  • The setup guide says says "optional add-on sensor for interfacing directly with utility meters and "the emonPi can … interface directly with utility meters via an optical pulse sensor.

  • The online shop page for the pulse counter does not say that only one can be connected.

  • The online shop page for the RJ45 expander page says “A 4-port RJ45 breakout board to allow multiple one-wire DS18B20 temperature sensors on RJ45 and optical pulse sensor to be easily wired to a single RJ45 bus for easy connection to the emonPi or emonTx.” It’s not clear that the “sensor” singular here is not a grammatical mistake.

I bought two but can only use one. Two would be useful for solar applications (measuring generation and export meters as well). Have you considered a 1-wire digital I/O combined with a common IRQ for the pulse counters, to enable any number to be connected?

The RJ45 Expander doesn’t make it clear that one of the four ports must be connected to an emonPi (or another expander which is), so only 3 ports are usable. When daisy-chaining, there are only 2 usable ports on each device except the last on the chain. An Ethernet patch cable (or similar?) is required to connect the expander to the Pi, and is not included, nor mentioned on its shop page. Would be nice to have it onboard, e.g. 4 sockets and 1 plug per module, and/or a larger module in the shop, so daisy chaining wasn’t necessary.


The Setup/Connect Guide says “Shut down the emonPi by holding down the shutdown button for 5 seconds”. The button on top is not it, and doesn’t appear to do very much. It took me a while to find the tiny shutdown button on the side, and a while longer to find an implement small enough to press it with. I’ve had to leave a pen in the meter cabinet in case I need to shut it down cleanly. Does it need to be so small? The shutdown menu item in the web UI doesn’t seem to do anything, so this was the only way.

The instructions to enable SSH did not work for me. The push button only toggles between two screens (and sometimes does nothing), there is no menu that I can see.

There is a strange “Node 15” under Inputs which existed on first login and which I cannot delete. All of its inputs are empty and anonymous:

On the Log Locally setup guide, if you follow the link to “Applications > Solar PV” at the top, you’ll miss the instructions on how to setup inputs and feeds, which leaves a new user woefully unprepared to actually follow the Solar PV instructions for example, which go straight into “Click on spanner icon to configure emonPi/power1.” What spanner icon, where, who?

On the Solar PV application instructions, my system does not correspond to either type 1 or type 2. I can measure generation and import separately. I could probably measure site consumption in theory, but the meter tails are so close to the bottom of the meter box that I’d struggle to install a CT on them:

Luckily I realised that the type 2 instructions would work for me anyway, and followed them.


I spent quite some time following the instructions, which was probably useful to know how things fit together, but the resulting configuration didn’t work (no data logged, reason unknown). Then later I discovered that I could have avoided all that pain by going to Setup > Device Setup and changing my device to Solar PV Type 2, which did it all for me, correctly (data was then logged, and the My Solar app worked). So the time spent setting it up manually, wrongly, was at least partly wasted.

Under Input processing, when creating a new feed, the tag seems to default to “Node emonpi”. However the steps created by Device Setup seem to be tagged as “emonpi” instead. Now I have two headings under Feeds, one called “emonpi” containing the Device Setup feeds, and one called “Node emonpi” containing my hand-written ones:

It’s not even obvious what a “Tag” is for a new user. Perhaps the option should not be there, or only for advanced users?

There is an RSSI “input” in the web interface, which I had hoped would be the Wi-fi signal strength, but it’s not (always reads 0). The signal strength must be available as it’s shown on the LCD, it would be nice to record it as well.

When constructing a virtual feed with a “source feed” step, the name of the source feed is a link which, if clicked, opens a graph of that feed in the Data viewer… and silently discards all your changes to the virtual feed!

I discovered a major issue with pulse counting when I tried to compare the results with the import CT, which is that my meter pulses for both import and export, indistinguishably. It was lucky that I decided to check this, and that I received some very valuable help on the forum. If I’d just trusted the import data then I would have been writing down nonsense for a long time before realising. This apparently happens quite often, but is not mentioned anywhere on the Optical Pulse Counter page, and I think it deserves a prominent warning.

When I tried to create a virtual feed to correct this automatically on the fly (to see if it was the problem) I get a very confusing error message:

I don’t believe that any of the feeds used in these processing steps are actually virtual.

Data viewer

If you create and save a graph with any kind of special character in the name (e.g. parentheses) then this is removed when it’s saved, but detection of an existing graph configuration then seems to be broken, so every click of Save creates a new copy of the configuration instead of replacing the existing one. Some special character support would also be nice, e.g. parentheses.

If I add a new feed to a graph, and then try to hide it by clicking on its name in the top left corner of the plot, I get a Javascript error:

I now have a graph that I cannot open (perhaps I deleted or renamed one of its feeds?), so I cannot even delete it:

The SI units in the Feeds table are displayed too close to the feed name, so they merge together. Perhaps append them with parentheses, e.g. “(kWh)” instead of “kWh”, or in a separate column?

When I graph a virtual feed, so far I always get either a useless graph that does not correspond to the input data:

Or I get a cryptic “Request error”:


That’s probably enough for now :smile:

Thanks, Chris.


(Brian Orpin) #2

The issue has been identified and a solution proposed. Problems creating virtual feed after update


(Nuno Faria) #3

got the same error with the javascript.
Its appears if you tick on the colour icon. If you click on the text it does not happen.


(Brian Orpin) #4

At the bottom of each page of the documentation you will see.

There is always room for improvement in documentation :smile:.

For specific issues / errors, the best route is to raise that issue on separate threads or on Github. It is difficult to comment on different issues within a long post.

True but equally it does not indicate you can use more than one.

From your link, the line below says

The emonPi / emonTx can support up to six temperature sensors and one Optical Pulse Sensor on a single bus.

The expansion boards come from Sheepwalk who do a board more appropriate to daisy chaining.


(Dave Howorth) #5

Doesn’t happen on my system, regardless of whether I click on the box or the text, so there must be some other difference between my system and yours and qris’s.


(Dave Howorth) #6

I agree that it’s very difficult to comment on multiple issues in one thread and it’s better to split out to multiple threads. I don’t think github is a good place to raise an issue initially, at least for noobs or indeed anybody less than an expert. It doesn’t get exposed with the same visibility and might get resolved much more quickly in the forum.

Also true, but it would be helpful to be specific. It’s on the .com site so presumably only employees can alter it?

Indeed, but again it would do no harm to add the word ‘one’ in the bit qris posted. As you point out, that is editable.

Indeed so - the SWE2. I was going to comment that daisy-chaining one-wire sensors in a star formation is not a terribly good idea anyway. Far better to daisy-chain in a single string. In which case making your own daisy chain with spacings to suit your particular requirements seems a much better approach.


(Dave Howorth) #7

This graph is interesting. How does it come to have the legend partly outside the box that encloses the graph? There’s another thread with odd legend positioning. What browser & OS are you using? (assuming you haven’t changed anything on the emon system itself).