EmonHub Development

Tags: #<Tag:0x00007f16a6602b10>

(Daniel Bates) #65

EDIT: I posted this not fully differentiating in my mind emonhub and emonbase. I understand emonhub software runs on emonbase.

Can I make another suggestion regarding RF.
As much to make a record of fact there’s been issues with 433Mhz RF in noisy environments. (I’m also predicting noise issues for a setup I’m soon building).

  1. To design for a easy transition between Wire and RF for each connected device, using 4-wire single-core telephone cable.
  2. In the case of RF to have sent 3 sets of data each time for the 3 most recent packets, 30 seconds worth for 10s updates: this could be an optional mode perhaps, although if this route was taken I’d see advantage in making it default unless there’s a battery consumption issue.
    -A: to have memory on the sending side so the 3 most recent packets can be stored and sent each interval, applies to node sensors and the emonTx.
    -B: to have emonhub parse the received information correctly relative to timestamps, and bulk upload if necessary.
    -C: emonhub made sensitive to version information from transmitting devices. Such that received information can be parsed correctly from legacy and future devices. Also, future devices could communicate two-way with emonhub for settings and modes, in which case version recognition could be useful again.

Does that make sense? I think each step is quite simple to implement.

(Paul) #66

We also need to be sure that scaling cannot trip up on infinity, nulls and NaN’s etc, or any non-numeric values that might sneak in.

see Discarding RX frame 'unreliable content'? - After Upgrade to latest version 9.8.28