Suppressing publication of unused emonpi data elements

emonHub
,
1

So, I’m looking at a standard EmonPi v1 setup (with the CM firmware FWIW) and would like to suppress the processing/publishing of the temperature and pulse count data. The motivation being that I’d like to look at moving to 1s update interval so that I can feed a SDM120 emulator (attached to an AC coupled battery inverter) via MQTT. Having 8x unused publishes per second seems gratuitous and untidy, although without a subscriber I suppose it may be in the margins of what Mosquitto can do… (but NB I have quite a few other things using the broker running on my OEM).

I had hoped that turning these (temp and pulse) off in the ATMega setup would suppress the values sent to EmonHub, but I still see:

OK 5 134 1 0 0 79 3 7 0 86 3 61 95 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 226 139 121 0 201 83 60 0 (-0)

(config: Settings: r0 b4 p25 g210 i5 a240.00 ac1 f50.00 k0 268.97 0.00 k1 90.90 1.20 k2 90.90 1.20 d9.85 m0 0 0 0 t0 0)

I’ve messed about changing emonhub conf file but not been able to stumble upon a way of making it skip bytes (e.g. I tried removing names and having consecutive commas, I tried using ‘0’ as a datacode to mean skip byte). So: I still get pubs to emon/emonpi/t1 etc

Anyone go any ideas? Or an experienced-based “dont worry about Mosquitto” comment.

TIA, Adam

2

You will have to delve into the front end of your emonPi and redesign the r.f. data packet to leave out the stuff you don’t want, recompile and reload the sketch, then you change the emonhub.conf entry for Node 5 (its own front end) to fit the data you are sending, and work your way along the path the data takes like that.

Is it worth the trouble? It depends on how desperate you are.

3

Thanks, @Robert.Wall ; I had wondered whether that was the answer. I’m generally dis-inclined to fork software and end up back-porting OEM changes unless desperate, which I’m not. I do anticipate Mosquitto on RPi3 wont break a sweat. It just goes against the grain of parsimony!

And then there is the question of dealing with the higher frequency measurements, as I don’t particularly want to be logging at 1s intervals and can’t see a way of using the existing inputs processing system to integrate in time chunks. I suspect a separate SDM120CT MODBUS unit is the path of least resistance. At which point I might as well run 25m of RS485 cable rather than fiddle about with an MQTT-based SDM120 emulator at the inverter end.

4

Knowing what I know, I think it is extremely unlikely that there will be any further development or indeed any changes to the emonPi front end software. So if, or more likely when, there is an update to emonCMS, you should be able to update this without affecting the front end.