Changes to the EmonTH sketch so that the green light stays permanently ON if it knows it has a working connection to an emonPi

Building a little project with four EmonTH’s and an Emonbase. The compromise with the base (I guess haven’t got them yet) is that you can’t see the IP address of the pi so you can’t necessarily logon easily, and you can’t therefore confirm your emonTH’s are within range and data being picked up.

What I want to create is a sign that the emonTH signals are being picked up by the emonbase. Is it possible to change the emonTH sketch so that the emonTH green LED stays permanent ON if the emonTH signal is being picked up? (and would it be easy to do??)

Imagine a situation where an amateur was given the emonbase and four EmonTH’s to set-up in their house. They could just plug-in the emonbase to their router and then set-out their EmonTH’s where they want, knowing that if they had a solid green light on the EmonTH then they have a confirmed connection. If they didn’t have a solid then they would have to keep re-arranging until they did. They don’t have to do anything else thereafter, as a remote operator can handle the data if the emonbase was setup with a cloud emonCMS system. Does that kind of make sense?

Not worried about battery-life.

Thanks for the help.

p.s. similarly it would be nice if the emonPi displayed it’s radio connections. When you transition through the emonPi menu on the LCD screen you can see that a CT sensor and voltage sensor are connected, but confirmed connection to any EmonTH hubs would also be nice to see (I know you can always find out from the EmonCMS of the connection but…)

Your router should be able to tell you that. This is what the 3 devices I’m presently running tests on are:

No, and for two completely different but related reasons. First, the radio only works in one direction, the emonTH transmits and the emonBase receives. Second, if you then turned the radios around to receive an acknowledgement, it would cost far too much in battery life, and that’s also the reason why the emonTH doesn’t flash its LED with every transmission. There is of course an LED on the RFM69Pi piggy-back board that makes your RPi into an emonBase, and that does flash with every message successfully received.

Maybe you aren’t, but it seems that most people are. A good battery life was one of the design goals.

I look at the Inputs page in emonCMS - if it doesn’t appear there, then at the “View Log” page in EmonHub.

Thanks for your time in answering the questions.

A long battery life is a good design goal. I definitely appreciate how lean the OpenEnergyMonitor runs (both data and power consumption).

WRT the radio; I see that it would be a lot of effort and work, but would you say its theoretically possible to have the radio’s swap direction just once straight after the batteries are installed in the emonTH to give a confirmation on the LED light? (say a solid light for 10 seconds on the LED after a confirmation signal from the emonPi, followed then by normal one-way traffic and data collection starting)?

Thanks again.

Hello @SteffanCook

Should be theoretically possible, but would require that initial acknowledgment say on the first message received from the emonth by the base station and then the corresponding mechanism to detect that on the EmonTH before defaulting back to normal operation, It’s not something we are likely to get a chance to work on unfortunately but it’s a nice idea and your welcome to give it a go yourself

Probably a nice idea but I guess it goes on a long list of nice ideas. For now confirming connection on EmonCMS online is the obvious way forward.

1 Like

Ah, If we had more hours in the day :slight_smile:

I second that.

Funny how, before I retired, there did seem to be - and now they’ve evaporated…

If you’re inclined to investigate, and you are only using emonTH’s on your network, it might be worth looking at LowPowerLabs. If I understand it correctly, their system achieves low power consumption by using a very low data rate, hence very low bandwidth which allows the transmitter power to be turned right down - and that’s done interactively by exchanging signal strengths. My thinking is you could piggy-back on that exchange (initially) to confirm reception.

If you are going to switch to LPL, their message protocol is different to ours, so if you do have other OEM nodes on your network, I think you’d need to use two separate radio frequencies, or there’s going to be a good chance that there will be on-air collisions.

The LowPowerLabs looks interesting.
(RFM69 | LowPowerLab)
Lowering signal output is a nice optimisation feature with the added bonus of two-way communication at the start…I will put it on the back burner lots of other stuff to do first.

1 Like

If you do go down that route, there are going to be few people here who know LPL, and you’ll need to be very careful if you come to updating your Base, because it will be easy to overwrite your changed receiver software and restore it to the JeeLib version.