Question: Polling vs Listening for an event on poolStatus changes

[pgregg88]

Parnic, thank you for this piece of work. It's great. I'm using node-screenlogic + google to learn node.js (and programming in general) so apologies in advance if I'm missing the obvious.

I'm treating my pool (via node-screenlogic) as a series of sensors and publish their status in JSON format via mqtt.js. I'm also using mqtt to change the state of various components (pumps, spa temp, lights, etc.).

Currently, I'm polling the poolStatus and controllerConfig via setInterval to refresh and publish status. It's working, but it doesn't feel like the most efficient or stable approach.

Also note, most of my code is based on your example.js, node.js official docs and various node.js tutorials I've found via Google... so my approach is definitely a victim of the last tutorial I read.

Questions:

• In this case is polling a valid strategy?
• If not, Is there a status change event that I could listen for vs polling?
• If so, do you happen to have additional code examples that might lead me down an appropriate path?

Eventually, I'd like to contribute a MQTT emitter to the project.

Thanks, pgregg

[parnic]

Hey there,

Glad you're able to find a good use for the project. Yes, the best strategy in this case is polling. There is no persistent connection available from the hardware, so the only way to get updates is to ask for them.

[pgregg88]

This thing is ROBUST. In test mode, I set my code (running on an rpi3) to poll The poolStatus and controllerConfig and publish a bunch of attribute values to MQTT every 5 seconds. It’s been running for 3 weeks without a hitch. I’m impressed. I never intended to poll this frequently. I was just looking for memory leaks or SL overload levels.