# Emonhub Interfacer Interval setting **URL:** \ **Category:** emonHub\ **Created:** [12 January 2021 13:25 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501 "2021-01-12T13:25:38Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [12 January 2021 13:25 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/1 "2021-01-12T13:25:38Z")
Sort of continuing on from the discussion about interval vs sendinterval in this thread > [@Newbie having trouble with emoncms.org](https://community.openenergymonitor.org/t/newbie-having-trouble-with-emoncms-org/16403/7): > > This appears to be the same for me. Anyone have any ideas how to send to [emoncms.org](http://emoncms.org) every 10 seconds? I happened to find a page in the guide about [emonhub interfacers](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#reading-from-a-sdm120-single-phase-meter) and it seems that the [SDS011 Air-Quality sensor interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#sds011-air-quality-sensor) uses `readinterval` ![image](https://community.openenergymonitor.org/uploads/default/original/3X/6/9/692cf4b77e110c1422adf2cdb80d62716511faab.png) the [SDM120 single-phase meter interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#reading-from-a-sdm120-single-phase-meter) uses `read_interval` with an underscore. ![image](https://community.openenergymonitor.org/uploads/default/original/3X/3/6/3697b2e75aa18f29075f9b50eee0b2ded3d66133.png) As does the [MBUS interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#mbus-reader-for-electric-and-heat-meters) ![image](https://community.openenergymonitor.org/uploads/default/original/3X/c/6/c6cec9bc6ec24e30ca5227bf53d36515fa12359e.png) as does the [ds18b20 interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#direct-ds18b20-temperature-sensing) ![image](https://community.openenergymonitor.org/uploads/default/original/3X/9/5/95472df6d7b477314b77ff84b2ddef9ebe06540e.png) whereas the [direct pulse interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#direct-pulse-counting) uses `rate_limit`. ![image](https://community.openenergymonitor.org/uploads/default/original/3X/4/c/4cd089fc1e85cd4fe75eb530a2d2eb39603e4d00.png) and the [Tesla powerwall interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#read-state-of-charge-of-a-tesla-power-wall) uses `readinterval` again. ![image](https://community.openenergymonitor.org/uploads/default/original/3X/1/0/10c7a28046cd96d59c9199643a63dd9ee8b53ada.png) 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](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#modbus-renogy) uses `poll_interval` ![image](https://community.openenergymonitor.org/uploads/default/original/3X/c/8/c8895952eea7100a4fd0fc194fcac93ece5098f4.png) [SMA solar interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#sma-solar) uses `timeinterval` ![image](https://community.openenergymonitor.org/uploads/default/original/3X/7/f/7fead4fd0fbad609607939c43f38c6dee359a406.png) the [Victron VE.direct interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#victron-vedirect-protocol) uses `poll_interval` ![image](https://community.openenergymonitor.org/uploads/default/original/3X/4/f/4f994776cbcb253f3572e296b8a1d9f8cecc40ad.png) and lastly the [Modbus TCP interfacer](https://guide.openenergymonitor.org/integrations/emonhub-interfacers/#modbus-tcp) uses `interval` ![image](https://community.openenergymonitor.org/uploads/default/original/3X/e/6/e6372143d649761f022ecbe20ee3a9914da82f7e.png) 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. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [12 January 2021 13:40 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/2 "2021-01-12T13:40:35Z")
“The nice thing about standards is that you have so many to choose from.” ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [12 January 2021 14:04 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/3 "2021-01-12T14:04:10Z")
indeed, and why be picky when you can use them all ? ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [12 January 2021 14:16 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/4 "2021-01-12T14:16:49Z")
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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [12 January 2021 14:57 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/5 "2021-01-12T14:57:44Z")
> [@Robert.Wall](#): > > Maybe, adding a note to the template/code explaining the convention **as well as** changing them to a common standard name would help? 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. > [@PowerWall Data Integration](https://community.openenergymonitor.org/t/powerwall-data-integration/14948/10): > > I’d be inclined to say that would be a good idea, it seems many, if not all service status output’s for emonhub contain these lines. There is little point in trying to restart a service before it’s ready. The default delay for restarts is just 100ms, extending that to 1s might result in some meaningful log messages when emonhub doesn’t start rather than just “too fast”. That will be why it help you find your issue and can also assist with other issues so I’ll flag this for @TrystanLea to cons… 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. ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [12 January 2021 16:08 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/6 "2021-01-12T16:08:22Z")
> [@Robert.Wall](#): > > “The nice thing about standards is that you have so many to choose from.” Then there’s the other end of the spectrum… The one standard is: _there is no standard!_ ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [12 January 2021 16:11 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/7 "2021-01-12T16:11:22Z")
> [@pb66](#): > > 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, Good to know > [@pb66](#): > > 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 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. ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [12 January 2021 18:04 UTC](https://community.openenergymonitor.org/t/emonhub-interfacer-interval-setting/16501/8 "2021-01-12T18:04:05Z")
> [@borpin](#): > > 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?