Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Emonhub Interfacer Interval setting

Sort of continuing on from the discussion about interval vs sendinterval in this thread

I happened to find a page in the guide about emonhub interfacers

and it seems that the SDS011 Air-Quality sensor interfacer uses readinterval

the SDM120 single-phase meter interfacer uses read_interval with an underscore.

As does the MBUS interfacer

as does the ds18b20 interfacer

whereas the direct pulse interfacer uses rate_limit.

and the Tesla powerwall interfacer uses readinterval again.

At the bottom of the page there are some links to other interacers so I took a gander at those too

the Modbus Renogy interfacer uses poll_interval

SMA solar interfacer uses timeinterval

the Victron VE.direct interfacer uses poll_interval

and lastly the Modbus TCP interfacer uses interval

That’s alot of different settings for essentially the same thing, the interval between iterations, reads, sends, polls etc. Not only is this confusing for the users, but with so many different settings there will undoubtedly be some errors slip into various posts and/or even docs, then it could become a right mess, the case of interval vs sendinterval is an example. I suspect this is also a significant amount or redundant code and wasted coding time since every interfacer inherits an interval setting from the core code.

Whilst these interfacers are relatively low use, it might be a good better time to correct it before it is far too late to fix. If not then this post may at least serve as documenting the different settings for different interfacers. That does of course assume that all the docs I’ve linked are correct and there are no other options.

If this does get fixed it is worth also noting that there is/was an undocumented rule of thumb to assist with settings placement. All init_settings settings were hypenated and all runtimesettings were not, so settingxyz = abc was clearly a runtimesetting whilst setting_xyz would be the same kinda setting but located in init_settings so that a simple instuction like "try setting some_option = abc" would not require detailed explanation as it is obviously an init_setting.

the interval and quiet etc are of course unhyphenated and therefore runtimesettings so one could argue that the poll_interval in the VE direct interfacer and rate_limit in the pulse counter are correct, but I question why they are init_settings and if we do need another interval in the init_settings it should ideally be (IMO) a more neutral interval_secs or similar setting in the core that can be utilised in any/all interfacers needing an init_setting interval.

1 Like

“The nice thing about standards is that you have so many to choose from.”

2 Likes

indeed, and why be picky when you can use them all ?

1 Like

And you can than always add a few more, so that the first lot don’t feel lonely.

Maybe, adding a note to the template/code explaining the convention as well as changing them to a common standard name would help?

If I’m extending somebody else’s code, I go to great pains to try to keep to the same coding style and conventions. Some people seem to think that multiple styles and conventions within the same piece of code somehow enhances it - either that or they don’t give a hoot.

Absolutely, I’m not a maintainer of OEM emonhub so I can’t call the shots on what is convention now and I cannot do any documentation as I have no idea of the direction or expected functionality, if we document what is currently coded and how it currently works it would cement the elements that need changing, so at best, could be a wasted effort if changes are made.

I would like to believe that it’s just a case of misunderstanding or being unaware of certain conventions etc but there is plenty of evidence to the contrary.

Here’s an example of me pointing out the same thing before the code was merged/released and yet my post was ignored and no changes made, the code was merged and documented. Now, one could argue it’s too late to make that very small change, but back then there was no reason to run with it.

This is just an example as I said, there are other instances where I’ve pointed this same thing out, and also the underscores, on github as well as here on the forum. But rarely (if ever?) are these comments taken onboard. This isn’t aimed at anyone in particular, just highlighting where improvement could be made.

Maybe there is no longer any convention and I should just not comment, whilst intended as a help, it is probably just seen as moaning and negative criticism.

1 Like

Then there’s the other end of the spectrum…
The one standard is: there is no standard!

1 Like

Good to know

Mea Culpa on the pulse interfacer. Just a lack of knowledge and documentation I’d suggest. I cannot remember which Interfacer I took as a template.

I think in general there is a lack of understanding of the different between the init and runtime settings and what can and can’t be changed at runtime.

The original OemGateway and early emonhub had the 2 types of settings to avoid restarting the service after every settings change, essentially anything you could change on the fly was coded to do so in runtimesettings eg changing freq on a rfm2pi board whilst settings that cannot be changed without restarting, ie only set at initial start up, eg a serial port address or (perhaps) baud were init settings.

This “choice” which isn’t always always a choice per se, is mainly in the hands of the coder and/or those with a better understanding of the implications, to the device, emonhub and to the data.

Originally these init_settings were only accessed during start up so oemg or emonhub used to need restarting to (say) change the baud of the rfm2pi interfacer. I added functionality so that rather than restart emonhub as a whole, users could restart a single interfacer by adding a hash (’#’) to comment out the Type = line, saving (which deleted the interfacer instance) and then removing the hash and saving again (which initiated creation of a new interfacer instance).

For the “experimental version” which the OEM emonhub is built from, I changed things further so that when a change to init_settings was detected, the interfacer’s in-transit data would be temporarily stashed, the interfacer deleted, a new instance created with the new settings and the retained data reunited with the new instance. So outwardly to many users there is no longer any real operation difference as emonhub can be left running for any change of settings, no need to stop the service except after updating. Yup I did say “after”. Because Python is compiled at runtime (if the source has changed) emonhub can continue running whilst the source is updated and then just sudo systemctl restart emonhub for near zero downtime.

However how much of this is intact now I have no idea and since I often see “then just restart emonhub for the (settings) changes to be picked up”, I can’t be sure whether init_settings vs runtimesettings is even a distinction anymore, ie does emonhub sometimes need restarting even for a runtime setting?

1 Like