Archived Forum

Welcome, Mike,

Is it possible to monitor 3 EmonTX Low Power Temperature Nodes?

Yes, in principle.

How do I keep the 3 monitoring nodes from transmitting on top of each other?

That's the problem! There's a long thread currently ongoing that revolves around this difficulty and the emonGLCD http://openenergymonitor.org/emon/node/1051.  One suggestion in that thread to alleviate (not solve) the problem is to transmit at intervals that are related by prime numbers. I suggest you keep a watch on that thread.

Is it possible to have the nodes only transmit in response to a message from the Raspberry Pi system?

Yes, but you either need to keep the node fully powered and receiving (which means a very short battery life) or you need to turn on and listen when a request to transmit is expected, or of course supply mains power.

How long would the batteries last for each node if they are waiting for a message from the Raspberry Pi base station?

I believe it is days (depending of course on the battery capacity). These's some data about this on Jeenode I think.

Ultimately I would like to add a monitor for the heating system to see when it is cycling and interface to a weather station.

See here http://openenergymonitor.org/emon/node/1906 for the weather station. What you do for the heating system depends on what it will tell you!

(p.s. Do you want mikeHF7 or shall I kill it?)

You could do something like this...

Have the Raspberry Pi (presumably mains powered) transmit a message every 5 seconds or so.

Have the emonTxs wake up at what ever interval you want and then listen for the next transmission from the Pi (max 5 secs)

Have each emonTx wait a different time after the Pi transmission, say 100ms, 200ms and 300ms and then transmit their own message.

This way the average time emonTx will be on for will be slightly over 2.5s and there will never be any collisions. If you make the emonTx transmit interval something like 5 minutes the average power will be very small.

In most temperature applications the temperature value does not change very often.  It really depends on what you want to monitor but if its around a house ie: room temp, outside air temp etc these are not going to change much over the course of 5 seconds.

I have been working on a sketch myself for a temperature node using a thermistor.

Currently the node sits in low power mode for 10 seconds, wakes up reads the temperature, if the temperature has changed greater than +/-0.2°C or it has been longer than 1 hour since the last transmission to the base station it sends the value.

I have been using ACK's with all my sketches to make sure data gets to the base station.  Occasionally something weird may happen where it can take a good few attempts.

I also agree using a strategy of using prime numbers as intervals.  Its a strategy I have used in the past on other comms systems based on RS232/485 etc.

these are not going to change much over the course of 5 seconds

That's why I suggested 5 minutes, The prime number approach is good but it won't guarantee no collisions like the timeslot approach above would.

Apologies Martin, I didn't mean to knock your suggestion, only offer another alternative based on what I have been working on myself.

I'm not sure how bad the collisions are getting on my setup.  I have two nodes, one sending every 15mins and the other is the temperature node which is going to send at different times based on my previous description.  Using ACK's and retries seems to make sure the data makes it through.  I would agree its more a brute force method.

I thought you were interpreting my post as suggesting transmitting every 5 seconds, sorry StuntMonkeh if that wasn't the case or if I sounded snappy - didn't mean to.

Do you possibly have a range issue rather than anything to do with collisions?

Don't worry no offense caused.  I think at some point writing I got my wires crossed and I understand now why you wrote what you did.  I understand how your solution works.

I was more alluding to the fact that temperatures don't often change very frequently so you don't always need to keep sending them in general not specific to your solution.

I don't think I have a range issue, the temperature node is in the room next door and the gas meter is outside no more than 10 metres away from the base.  There is nothing foil backed in the construction of the walls.

If I run the temp sensor serial output it will fail fairly regularly at the first attempt, say 1 in 10.  I have seen it go to 7 retries once but then be fine.

Its probably my dodgy soldering skills!

One point worth mentioning - it doesn't affect anything either of you (StuntMonkeh or MartinR) have said - is that the RFM12 library allegedly does a rudimentary check that the band is clear before it starts to transmit. However, that will only work provided both transmitters can hear each other.

Dear All,

Thank you for the information.  Now all I have to do is wait for the modules I need to be back in stock.

FYI http://openenergymonitor.org/emon/node/1051 is 404.

Thanks again.

Mike

PS Yes, you can kill MikeHF7.

that the RFM12 library allegedly does a rudimentary check that the band is clear before it starts to transmit

This is how it should work, but it doesn't. This is a long known bug in the Jeelib code.

BR, Jörg.

Been running 2 x temperature funky sensors and 3 x emontx with emonrf and emonglc for a couple of months. When monitoring the rf space with jeenode i found more transmissions from neighbours (propably) home alarm system network than from my emon network devices. The funky sensor 3v battery seems to be ok for good few months even with led blinking, everything else has a psu connected

There has been some dropouts in the network but those have been always related to restarting one device and not resetting emonrf, besides a few times wiht adsl being down. Emoncms is ever so good as it allows to see how often data gets received. Anyway my system is not mission critical, all heating steering components are independent of emon, hardwired together and are operating independently and redundant to each other - even though tuned to work together and monitored with emon.

Emonglc stability is another issue... Had initially a lot of issues with it failing when 1-wire sensor connection was not ok. Then just bite the bullet and implemented watchdog timer reset and use emontx to store all the needed data.