RF collision concerns

[pb66 (Paul)]

@Jerome

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.

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).

@Jerome

I’ll need to add an InfluxDB module to EmonHub

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.

@Jerome

I’ve been peeking in the code and there’s a few things I’d like to improve already.

Of that I have no doubt

@Jerome

Which code version should I start from if I want to use EmonHub on a Raspberry Pi with a vanilla Raspian? GitHub - openenergymonitor/emonhub: Python service linking and decoding input to MQTT & Emoncms, branch emon-pi ?

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.