Differentiate the callback event for getScheduleData(0) vs (1) about node-screenlogic HOT 4 CLOSED

The issue here is that the library is as ignorant as the consumer w.r.t. what specifically the received callback is for. ScreenLogic sends a packet for getScheduleData's response and whatever it contains is what it contains. We can't add or remove context from it since we don't control the ScreenLogic system's code. If we provided a separate API for getRunOnceEvents, we would still, under the hood, be sending a getScheduleData packet and would, in turn, receive a getScheduleData response packet. We cannot guarantee that the packet is for recurring or run-once events unless the body of the message indicates such.

And to be clear, getScheduleData(1) is returning "run-once" events, not egg timer events.

My recommendation is to call them one at a time and not call one until you've received a response from the other.

from node-screenlogic.

Right... because the message IDs are the same... Duh.

That occurred to me about 20 minutes after opening the issue.
I'll just have to break the scheduling support code out of that polling loop and make it stand-alone. That's the way I was going originally, and then I changed course because I was trying to stay consistent in my methodology...

I thought that run-once events were the same as egg timers? Although I still don't understand Pentair's official app interface for egg timers.

Anyway, closing the issue. Thanks @parnic.

from node-screenlogic.

No, run-once events and egg timers are separate. The best place I know to see the two is in the Windows ScreenLogic app which separates them out. Egg timers define how long a circuit is allowed to stay on before the controller turns it off automatically. Run-once events are scheduled events that only fire once.

from node-screenlogic.

So, in thinking about this further, it occurs to me that there's an unused field in screenlogic messages called the "sender id". This ID is set by the caller and is provided by the device when the response is received. Currently the library always specifies a sender ID of 0. We could, potentially, offer a way of setting the sender ID for any given message which would allow for differentiating multiple messages of the same type.

The least destructive way to do this for the library is to either offer a function on the Unit that allows setting the sender ID to use. The use case would be something like

unit.setSenderID(42)
unit.getScheduleData(0)
unit.setSenderID(43)
unit.getScheduleData(1)

Then the object passed to the getScheduleData event would have a senderID property that could be inspected to tell them apart.

Another solution would be to modify every function signature such that the final argument is an optional value of the sender ID. This is a more invasive change, but would retain compatibility with existing users. Something like

unit.getScheduleData(0, 42)
unit.getScheduleData(1, 43)

from node-screenlogic.