TCP time-out being set to an unreasonably long value unwittingly (as it was interpreted as being a connection establishment time-out, not a request time-out)
two unexplained network pings, followed by a ping meant to work around a specific device, all of which timed out
We can likely fix (1) by documentation -- leave the default of 4 seconds, but provide some guidance as to how this should be tuned, and most importantly, what the time-out is used for.
For (2), an options parameter is added to getData. This is optional, and if omitted, we assume default behaviour, which to avoid breaking existing networks, maintains the old behaviour.
options.pingFirst controls the behaviour first established in https://github.com/rscada/libmbus/pull/95 -- if pingFirst is false, we skip the initial pings (including those done in the undocumented init_slaves). The default is true in case existing networks using node-mbus rely on this behaviour.
Possibly breaking changes
The underlying get method of the mbusMaster property expects pingFirst to be supplied as a boolean parameter immediately before the callback parameter. -- as I suspect mbusMaster is effectively a "private" property, I do not anticipate this to cause issues downstream.
It appears the problem in Issue #101 is two-fold:
We can likely fix (1) by documentation -- leave the default of 4 seconds, but provide some guidance as to how this should be tuned, and most importantly, what the time-out is used for.
For (2), an
optionsparameter is added togetData. This is optional, and if omitted, we assume default behaviour, which to avoid breaking existing networks, maintains the old behaviour.options.pingFirstcontrols the behaviour first established in https://github.com/rscada/libmbus/pull/95 -- ifpingFirstisfalse, we skip the initial pings (including those done in the undocumentedinit_slaves). The default istruein case existing networks usingnode-mbusrely on this behaviour.Possibly breaking changes
getmethod of thembusMasterproperty expectspingFirstto be supplied as abooleanparameter immediately before thecallbackparameter. -- as I suspectmbusMasteris effectively a "private" property, I do not anticipate this to cause issues downstream.