To me, the problem with queued output is that it then becomes useless for anything that requires a set of steps that need to be successful before you continue, effectively commands become asynchronous. Yeh, the user can manually wait for the expected result of a command before continuing, it's a lot nicer (and safer) if commands either work or don't proceed.
This is true. If you had a set of dependent steps and the first step fails, you want to stop the other steps. However, I can't think of a circumstance like this and haven't run into it. I also don't see any failures unless a node losses power.
Normal usage failure rates seem to be 1-5 failures out of 10000 commands as the Premise module has a burn-in test feature I added to test the VRC0Pv3 and the VRC0P. Since the VRC0P simplifies the z-wave command protocol, the likely hood of there being such a command depends on Leviton. Our free open-source module does have the node number embedded into each job queue object. If I remember correctly, the module will automatically delete all future queued jobs for a particular node if a failure occurs. This prevents what you are talking about and is possible because each command in the job queue is actually an object with attributes such as node, command, priority, etc...
Further, without a queue, what happens if someone sends discrete brightness up/down commands 50 times in a row as fast as the can press the up button, then press a down button? My guess is that a driver without a job queue would either have to introduce a noticeable delay between each packet transmission or simply send the command without waiting for X000. If a delay is not used, you could easily overload the VRC0Pv3's buffer by sending repeated commands. That said, a set delay is unnecessary and should always be avoided where possible. All you need is to wait for X000 and grab the next job from the job queue. No delays are required!
Please post a serial port spy log as I'm curious. It would be really helpful if the log showed system time wrt to each port spy log too. I know Premise easily handles this type of situation thanks to the VRC0P's job queue that user 123 designed.
In my view, any positives from using a job queue far outweigh the one negative situation you are describing (that may never occur).
Just because you don't get positive confirmation doesn't mean it didn't actually happen.
To my knowledge the receipt of X000 always guarantees the command was successfully received by the node. It is true that the actuator connected to the node could be bad, giving a false sense that an actuation occurred (e.g. a light turned off). This is the only good reason to append the request with ",UP," aside from the bigger negative of major delays in packets being processed. However, a lock is designed more robustly than a light and does have a way to sense its current state and if associated to the VRC0Pv3, will respond with its current state following actuation. Given this, I'm not too worried. If something is mission critical, it can always be polled more frequently to verify it's state (assuming it does not use the association class).
So you could end up bumping the thermo set point way more than you thought, for instance.
Depends on how you implement things. The UI could wait until the temperature is fully entered, then send on packet. If you don't do things this way, you would unnecessarily congest the network with multiple temperature change requests (e.g. 60, then 61, then 62, etc...) and the current state of the thermostat may not match what's stored in the HA program. However, due to the way the job queue works in Premise, the thermostat's set point will eventually match that of the HA program's once all job's in the queue are complete.
Polling is only done if the module is set up to require it. If it sends async notifications, the driver will poll it just to see if it's alive, but only if it hasn't heard anything from it one way or another in the last couple minutes, which isn't much load, even if you have quite a few modules.
If a large number of polls are sent before a user request, the user request will be delayed. This is where a smart job queue is useful.
I can certainly try to add an emergency reset if it seems to have stopped responding. Though, to be fair, that's not really the same as no freezeups, it's just trying to work around them.
This is true. All I will say is that with Premise and the free module several folks worked on I never have to unplug the VRC0P. I have also ran successful test runs with several thousand request sent in succession.
PS: I'm not a professional programmer, but have taught myself vbscript (for the sole purpose of building modules for Premise) and some Java. I know from real world usage the recommendations I've made work very well, but I don't mean any disrespect toward others.
