Another broken link & product specificity

Hi, just noticed a couple more gotchas whilst reading up how to install my system.

Install emonPi - Guide | OpenEnergyMonitor [2] appears to be purely focussed on emonPi, but that’s where I’m sent after reading 1. Connect - Guide | OpenEnergyMonitor [1] My system is emonBase + 2 x emonTx so should I be sent to a different place?

[2] Also links to Solar PV - Guide | OpenEnergyMonitor [3] and that in turn links ( Please read the CT installation guide before installing. ) [4] to a non-existent page. The correct target should be Learn | OpenEnergyMonitor [5] I think.

1 Like

The emonBase and the emonPi run the same software - the terms are used interchangeably in the Guide. The information on that page about sensor installation is still relevant - but there’s a more specific bit about the emonTx here: Adding to an existing install — OpenEnergyMonitor 0.0.1 documentation.

Thank you for pointing this out - and you were right about the correct target. It has been amended.

1 Like

Not necessarily.

Right, but I think it would be useful to actually say that on the page, not assume that everybody knows, and to explicitly link to the emonTx page.

And are statements like “Ensure all sensors are connected before powering up” correct for the emonBase? I would expect it to be able to deal with a ‘new’ emonTx when it detects a radio signal from it.

In my case, for example, I have set up the emonBase first so I have some visibility of what the system is doing when it does it.

2 Likes

It is (sadly) a result of the focus on the EmonPi as the only solution. My Emonbase (simply the RFM Hat) is on an OrangePi and only has a version of the emonhub running on it. EmonCMS itself is sitting on a VM built on DietPi.

The SD image makes an assumption on the underlying base hardware (even the version of RPi it supports out of the box).

In my case I’m talking about products bought from the shop, not something I’ve put together myself. My comments should be read with that in mind. I don’t expect the guide to explicitly cater for every combination of homebrew systems, but I’d like to think it could attempt to deal with standard products.

@Gwil made a valiant attempt at straightening out all the documentation a while back, and the result has been a big improvement. But as a newcomer, you’re very well placed to spot all these assumptions. Please keep the comments coming in - if you ‘at’-mention Gwil, he’s pretty good at putting them right.

No, it isn’t correct for the emonBase. It applies to Atmel 328-equipped items only, because the sketches detect the sensors only at power-up. It applies to the energy and temperature end of the emonPi, and means you must power-cycle the whole thing when adding or removing one of those sensors.

2 Likes

Yes agreed, I was just saying that many of the assumptions in the documentation are not correct and can confuse when an EmonPi has not been purchased. The RFM hat is a purchasable item. :smile:

Thanks Robert. That’s what I thought but it’s good to have it confirmed. So I think the statement comes across as a little strict even for an emonPi then. It would be better to say that devices with sensors need to be power-cycled whenever changes are made to the sensors, IMHO.

If I’m not wrong, the FAQ page spells it out "My emonTx / emonTH / emonPi won’t read the new sensor that I just plugged in. How do I fix it? "

Right, but the user is not looking at the FAQ page. S/he is looking at a page that says do not power on with no sensors attached. Which is wrong.

All emonBases purchased from the OpenEnergyMonitor store run exactly the same emonSD software stack as the emonPi. Please don’t confuse this.

Most of the users purchasing an emonBase are more experienced power users, therefore we presumed they would not need such detailed hand holding setup guide. An emonBase setup guide is basically just plug in the power then follow the Setup > Connect page. I’ll see if we can improve on this by adding notes to specify when a statement refers to specially an emonPi.

So how does that work for this purchase of ‘EmonBase’?

image

It doesn’t, which is precisely my point - your statement is not correct - you might like it to be correct, but it isn’t.

It is the assumptions that cause the problem (as assumptions always do). The customer is always right…

Having spent a short time writing technical manuals, I’ve got to agree. It’s really, really hard to write something that doesn’t make assumptions, but it is absolutely to necessary do your utmost to achieve that.

As we’ve seen, failure results in confusion, and for the sake of a few words in the documentation, a lot of heartache and wasted time could have been avoided.

1 Like

Each complete emonBase which is shipped with a Raspberry Pi runs the emonSD software stack which is exactly the same as emonPi. Please don’t confuse this issue. An RFM69Pi is not an emonBase. It’s just an RFM69Pi receiver board.

The vast majority of users purchase the full emonBase, we don’t ship many RFM69Pi’s on their own.

If a user has built their own software stack and used the RFM69Pi that is not an OpenEnergyMonitor emonBase.

To avoid any confusion I have now removed the “Raspberry Pi: None” option from the shop. The RFM69Pi can still be purchased on it’s own:

https://openenergymonitor.com/rfm69pi-433mhz-raspberry-pi-base-station-transceiver/

And that is where the confusion can set in as (from the image I posted) the RFM69Pi can be bought as an 'EmonBase`. I had always believed (from the way the shop describes it) that the ‘base’ was the RFM69Pi as that is all you actually need (plus a TX or TH). The fact it could come with a Pi was an optional extra.

I’m not - I’m stating is as it looks. You are making assumptions based on your view which is an EmonBase is a complete system. I’m saying that is not how it comes across (in the shop) and is not necessarily accurate.

There are a number of threads where it is initially stated ‘I have an emonbase’ but what they describe is not that full system you describe and visa versa.

I know it doesn’t feel like it sometimes, but I think that discussions like these tend to be useful at the end of the day. It is sometimes painful getting there but that’s because it’s difficult, as Robert points out, to express detail unambiguously in writing, especially in an interactive format. But it seems to me, as a relative noob, that everybody here is working towards the goal of improving the system & products and clarifying the documentation. And it’s good when little improvements are made as a result.

2 Likes

Sorry for the non-sequitur but here’s another broken link report:

https://learn.openenergymonitor.org/electricity-monitoring/pulse-counting/gas-meter-monitoring

shows

Warning : file_get_contents(view/electricity-monitoring/pulse-counting/gas-meter-monitoring.md): failed to open stream: Permission denied in /var/www/learn/index.php on line 64

Thanks, I don’t see the warning just a blank page. What page did you find this broken page linked from?

The “Gas Metering” heading in the l.h. nav bar of ‘Learn’ for me - takes me to an almost blank page, that has the nav footer only with back & forward links…