My company wants to set up 20 temp/humidity sensors in our building and we’re looking for a technical solution. I’d like to use OpenEnergyMonitor, at least EmonTH and EmonHub. I saw you’ve been expanding EmonHub after I left oem_gateway. Great ! I’ve been peeking into EmonHub code to see how I could adapt it (create needed interfaces) and I found no blocker.
I’m confident with the software stack along the chain. My only concern is RF reliability. We’ll probably be using several bases to ensure no EmonTH is out of reach, so the only issue left I can think of is collisions, especially due to the number of sensors.
I’m surprised this issue doesn’t come up so much. All I found was this old thread and this one. Europe based, I noticed Paul’s advice: mix 433 and 866 to halve the problem.
As far as I can remember, and tell from EmonTH code, there is no ACK and packets are lost on collisions. Is this correct?
The collision likelihood depends on the length of the frames (I’m talking about EmonTH so that would be relatively short) and the frequency (temp and humidity are low frequency variables, so a period of 10 or 15 minutes is fine). Such a period is much greater than the frame time length, so if send times were random, collisions would be very unlikely. In practice, if I put the batteries in each device with few seconds or tens of seconds delay (like would naturally happen), and since the period is the same on each device, there should be no collision. Unless some clock drifts and two devices become perfectly synchronized, maybe?
I might be overthinking it but there could be solutions to this, like randomizing sending time a bit to at least ensure two devices don’t become synchronized. Or maybe using an acknowledged protocol in the first place?
I suppose if this was a real issue, it would have been addressed already. How come it is not? Is it just because people generally use much less sensors?
I believe that is still correct. However, I also believe there is a rudimentary mechanism in JeeLib whereby the transmitter waits if it perceives the channel to be busy. But the problem here is, the transmitter is not at the receiving location! So it won’t necessarily detect another transmitter even when the receiver can.
That is a danger. In many ways, it’s better to have the intervals not the same, then the period of time while messages overlap (and jam each other) will be short, but it might happen more often.
The penalty there will be battery life, because the sender needs to turn round and listen for the acknowledgement, either until it comes, or it gives up. I read a little about this recently on the JeeLabs website (go there and search for “RF12 broadcasts and ACKs” - I don’t have the link).
I suggest you do the sums: JeeLib runs at 49.2 kbits per second, the standard RF packet is 9 bytes plus the payload of 12 bytes - that’s a bit over 3.4 ms per unit per 15 minutes - or under 70 ms for all 20 units. Channel occupancy: 0.008%
It’s a bit different with the much bigger payload of an emonTx sending every 10s.
Thank you Robert for the answer, and for doing the maths for me.
We’ll have 20 nodes, but considering the size of the building, we’ll need several bases so the worst case is not 20 but rather 15 or so, maybe less.
With such a channel occupancy rate (0.008%) and the rudimentary “no TX when channel perceived busy” mechanism, collisions are pretty unlikely and the only issue would be two devices becoming perfectly synchronized.
Rather than setting slightly different periods, I’m thinking of adding a little random offset to the 15 minutes period, to achieve the same goal. It is probably equivalent.
I think I understand the reasons for the unacknowledged protocol (saving battery life). It seems like a reasonable trade-off.
If you are using multiple base stations then you could use a different group id for each base. This doesn’t usually help much with traffic when lots of devices are in the same airspace as the packet still needs to be fully received by each receiver before it can discard it due to being in a different group. However, since your networks may or may not be just overlapping (as opposed to high density in small area) using different group ids should improve your position as it will prevent duplication and the group id is the first thing checked in JeeLib, so the packet will be discarded quicker than fully processing the packet, freeing the reciever up sooner to receive packets with the correct group id. Since 20 emonTH’s would mostly be ok even on a single base, the additional work quickly discarding only the overlapping emonTH’s is not likely to impact receiving the right grouped payloads.
I have previously had 15 emonTH’s on a single network with no significant loss of packets even though these were fixed at the same 60s interval and only staggered in time by inserting all the batteries in quick succession (all fitted inside 60s).
If you go down the route of varying the interval, be aware of the potential impact if using phpfina (fixed interval) feeds, what you save from the clutches of collision, might potentially be lost to datapoints falling outside the ridged fixed intervals in emoncms.
Hi Paul. Yep, nice to be here. I hope we’ll choose this solution over proprietary alternatives.
Thanks for the feedback.
Yes, I plan to use a group ID per base to avoid duplication.
the packet still needs to be fully received by each receiver before it can discard it due to being in a different group
the group id is the first thing checked in JeeLib, so the packet will be discarded quicker than fully processing the packet, freeing the reciever up sooner to receive packets with the correct group id.
AFAIU, what you’re saying is that the post-processing (decoding the packet) can be cut sooner when the group ID is wrong. I would assume this is a very minor gain. I suppose the processing itself is orders of magnitude shorter than the RF frame length (3.4 ms according to Robert’s message above). Maybe I’m wrong and the microcontroller in the radio module is not that fast.
Regarding the database, I think we’ll be using InfluxDB. I’ll need to add an InfluxDB module to EmonHub. I’ve been peeking in the code and there’s a few things I’d like to improve already. I’ll keep you posted if I do so and I’ll be sure to contribute the changes.
Indeed, but every nano second counts, the sooner it can open it’s ears again, the less likely it is to miss the beginning of the next packet and it subsequently fail crc. Not all emonTH’s will be within range of each other to know to delay eg further east emonTH transmits and is picked up by the west basestation, the furthest west emonTH can still transmit without knowing the west base is otherwise occupied, so dumping the wrong packet asap can be very important when packets are overlapping. If I recall correctly, changes were made in later JeeLib revisions to dump earlier for this reason, I think the group might even be checked as the data flows in ahead of even the crc check (working from memory so I could be wrong on some finer details).
That would be a welcome addition, Ive been wanting to try influxDB for quite some time now, it was suggested as an alternative feed engine choice in emoncms too, but that didn’t materialize.
Of that I have no doubt
That is the version used on the current emonPi SD image and is the most common. I haven’t had much to do with the development of that branch, although it is heavily based on my “experimental” branch (introduces threaded interfacers, multi path routing and retains reporters/dispatchers) derived from the original emonhub we worked on together, Trystan has heavilly modified it and I still use the original version as there were reliability issues with the emonpi variant, many of which have since been attended to now.
There is a rather long discussion between Trystan and I in the EmonHub Development thread if you want to get some insight to what we already know needs attention.
I also have several other interfacers, but they are not written for the current emonpi version, more recently I have been just using the socket interfacer and custom python scripts for many different purposes (hive, owl, 1-wire, modbus, weatherwunderground, pulsecounting, tplink and a few others I’ve possibly forgotten too), Trystan and I have discussed starting up the emonhub dev again, but as yet not much has happened on that front.
As the ‘emonpi’ emonhub version is heavily modified for emonpi, wouldn’t it be a better option for Jerome to use your “experimental” branch, if the purpose of the interfacer is to write data to a influxDB?
