stopID caching to prevent excessive findStop calls

[VDenisyuk]

The current implementation (IMHO) generates excessive requests to dvb.findStop() method, as it is not really required to search for a station ID during every update request.
As per my understanding, we need to get stopID when:

• The module is starting.
• A user has changed the config and inserted new/other stop.

Therefore, I added intermediate storing mechanism for stopID and stopName.
stopID searching is triggered only in above mentioned two cases, otherwise only dvb.monitor() is triggered.

[skastenholz]

Could you please verify how the module behaves in case multiple instances are configured? As per my understanding NodeHelper is a single instance per module type, i.e. notifications from different modules with potentially different stop ids will be received. Since the stop variable in the NodeHelper contains a single value it will be flipping and, finally, no calls to dvb.findStop will be avoided.

[VDenisyuk]

Good catch! Working on it.

[VDenisyuk]

So, now it seems to be solved and tested on two modules simultaneously.
To solve it, I've done:

1. Registration mechanism. Upon start, every module registers its ID to node_helper using a dedicated call (message label REGISTER-MODULE). The helper registers the module (creates an empty object with module ID) and replies with an acknowledgment (message label REGISTER-ACK). When the module receives the acknowledgment, it starts normal polling.
2. Separate stop ID and name for every module. The registration mechanism allows us to keep a stop ID and name separately for every registered module.

[skastenholz]

Thanks for your contribution!