Replies: 4 comments 5 replies
-
|
I have a couple thing in mind (e.g. querying non-sleeping devices first) which I'm soon going to discuss with an expert in these things. Just a few notes regarding your ideas:
We don't wait for the device itself to respond, we wait for a callback from the controller. That needs to happen or the internal state machine of controllers gets out of sync. I learned this the hard way. You don't ever want to start communication with another node while waiting for a controller callback. While we're actively communicating with a device and waiting for a response to a Get, it might be possible to communicate with another node in the meantime. I'm not sure though if we aren't making it less likely for the original response to come back. I'll definitely consider revisiting this.
This also requires us to wait for the callback of each single command. NoOps don't send replies, just acknowlegements.
Got a log for this? There are several things you could paraphrase with this.
Usually, the interview should be started once a battery-powered node wakes up. You might be seeing artifacts of what #1307 is trying to solve. Also there are two open issues (#903, #900) to convert the management of interview processes into a state machine to have better control about this stuff.
I don't agree 100% but I think we have some ways to get down from where we are now. We could be smarter, e.g. we probably do not need to do everything we currently do when restarting from a previous interview. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply. :)
I kinda get that the controller is more of an api, than a radio device. If it were more like a radio, it would send back messages as they were received - and not have any form of request-reply nature for any messages.
It sounds like the controller imposes a lot of these delays? That sucks :O
Is there a document on the serial protocol for the controllers? - I’d hoped it was possible to write and read asynchronously to it, and that there were message/transaction ids for each message. This would allow you to write messages to the controller, and then hand off the reply to a promise-like nature, where the reply comes later.
But that requires, as you mention, being able to hook up responses to requests.
What happens if, in these delays, a message arrives (like a light turns on)? Is it just delayed for seconds? :O
And wow. Do response messages / acknowledgements not include the source node? :O
…________________________________
From: AlCalzone <notifications@github.com>
Sent: Tuesday, January 12, 2021 12:31:46 AM
To: zwave-js/node-zwave-js <node-zwave-js@noreply.github.com>
Cc: Michael Bisbjerg <michael@mbwarez.dk>; Author <author@noreply.github.com>
Subject: Re: [zwave-js/node-zwave-js] Improve startup speeds (#1355)
I have a couple thing in mind (e.g. querying non-sleeping devices first) which I'm soon going to discuss with an expert in these things. Just a few notes regarding your ideas:
Why wait for devices to respond? ... A lot of devices will be battery operated and not respond before they wake
We don't wait for the device itself to respond, we wait for a callback from the controller. That needs to happen or the internal state machine of controllers gets out of sync. I learned this the hard way. You don't ever want to start communication with another node while waiting for a controller callback.
This callback usually comes pretty quickly (a few seconds), even if a device is asleep.
While we're actively communicating with a device and waiting for a response to a Get, it might be possible to communicate with another node in the meantime. I'm not sure though if we aren't making it less likely for the original response to come back. I'll definitely consider revisiting this.
A noop CC could be sent to all nodes, in parallel
Send a noop to all nodes on the list, do not wait for replies
This also requires us to wait for the callback of each single command. NoOps don't send replies, just acknowlegements.
Besides Multicast/Broadcast, there is no such thing as parallel. And I don't think pinging the entire network with multicast/broadcast is even possible, since we won't have the information which node responded.
On startup, I see a lot of "tried sending X message, waiting N ms" log messages.
Got a log for this? There are several things you could paraphrase with this.
under/overshooting the sleep interval is likely
Usually, the interview should be started once a battery-powered node wakes up. You might be seeing artifacts of what #1307<#1307> is trying to solve. Also there are two open issues (#903<#903>, #900<#900>) to convert the management of interview processes into a state machine to have better control about this stuff.
IMO, it should be possible to restart zwave-js, and not have any traffic at all.
I don't agree 100% but I think we have some ways to get down from where we are now. We could be smarter, e.g. we probably do not need to do everything we currently do when restarting from a previous interview.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#1355 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAH2YJ7YTDP5HWYBGAJYRHLSZOC6FANCNFSM4V6KIYEA>.
|
Beta Was this translation helpful? Give feedback.
-
https://github.com/zwave-js/node-zwave-js/tree/master/specs -> INS12350 and INS13954 Communication with the controller is somewhat weird. Responses cannot be matched to a request, but they come fairly quickly. Callbacks theoretically could be matched, but the specs explicitly mention that you must complete the REQ/RES/CB sequence before you can continue.
The controller will send us an unsolicited message we can handle immediately. But the message itself can arrive delayed if the controller is currently transmitting.
No, only the node response (Report in reply to a Get) contains that info. |
Beta Was this translation helpful? Give feedback.
-
|
Well crap. :| |
Beta Was this translation helpful? Give feedback.
-
|
This is a very interesting and important discussion to have. I guess there's a spectrum where on one end are those who believe a Z-Wave driver/library should collect and cache all the information in a Z-Wave network, and on the other those who believe information should only be collected as-needed and never cached. I lean more towards the latter end of the spectrum - but it really depends on what the topology of a Z-Wave network is, and that's unfortunately not something a general-purpose driver/library can plan for. Rather than try to sell anyone on what I think is a good idea, I'll just leave a couple of observations. As far as a host-controlled Z-Wave driver/library is concerned, it's entirely ready to service outgoing and incoming requests immediately after the serial link is established. It doesn't need any outside information to be able to service a client's request to send a Command Class frame to a Node or to forward an incoming frame from a Node to the client. The driver/library might want to know which devices are in the network, and whether they're listening or not, to avoid sending messages to devices that are sleeping - that information can be obtained straight from the Z-Wave protocol, without having to send a single RF frame, and is doable in under a second for even the largest possible Z-Wave network. I think the discussion on "interviewing" a device is better had separate from this, which is really "what's the minimum a driver/library needs to do on startup." Different clients are going to have different opinions on what they need at a minimum from the driver/library to be able to operate in a way that's useful for users - but their needs are separate from the driver/library's. Keep in mind that clients need to be prepared for having no information on any nodes, which is a very real scenario - for example, the very popular one where all the Z-Wave devices in a network are battery-powered sensors. |
Beta Was this translation helpful? Give feedback.
-
|
I'm from a world where we try to structure our libraries such that one takes care of the protocol (and just that), and another some business logic on top of the former. This allows others to make their own business logic with whatever they need, or maybe the library can be used to build debugging tools.. A good example of this from .NET is Elasticsearch.Net & NEST. The latter builds on the former and adds useful clients for end-users. If you use the former, you have the full power of the protocol at your disposal. Anyhoo. I'm not going to advocate for one over the other for existing projects :). What I do hope though, is that a library like this doesn't aim to "prepare" before being ready. I had some server issues yesterday and today, where I had to reboot a number of times. Each time, the z-wave network had to "restart", before it was fully functional. This was with open-zwave, but the same is true with this library - albeit a bit faster in my experience. So I sure hope that it ends with what you describe: opening a serial port to the controller, and then bam - ready to submit to any node previously known by the software. I had a phone call with one of the device manufacturers in Denmark, and it seems they too are quite dissatisfied with network boot times (on entirely different controllers / appliances). So maybe innovating here can lead to some innovations elsewhere :) |
Beta Was this translation helpful? Give feedback.
-
|
Putting aside the fact that we can probably get rid of a lot of queries on subsequent startups.
When we restart the network from a point where all devices have been interviewed previously, so the driver knows all necessary information about them, the I'm not sure which version you are running, but if the startup takes too long, you're probably affected by this bug where the status is determined much too late: #1387, fix at #1397 |
Beta Was this translation helpful? Give feedback.
-
I don't necessarily agree with this. I see it this way: if any one of those nodes had gone "down" while the library was running, neither the library nor its clients would've known about it going down until a transmission attempt to it was made - and that's perfectly fine. Sleeping devices won't answer this initial ping anyway (in the case where the library is blindly pinging them without checking if they're Always Listening or not) and will remain in the "unknown" state until they wake-up, so this case already needs to be handled. Making this the general case instead of one of the possible cases after startup simplifies things for everyone. If a client explicitly requests a device's state (hopefully only some of the state, instead of forcing an interrogation traffic storm), by all means send frames out the RF to fetch it - a client requesting it is a good reason to do it. Again, this is just my opinion, but preemptively going out and pinging devices just to put their reply into a cache (which for all the library knows is stale immediately after it has written it - a wall plug might be pulled out of the socket just after being pinged and it won't know about it until a transmission attempt) doesn't accomplish much other than generate traffic and delay startup.
If what you're interested in is knowing which nodes are Always Listening (AL), Frequently Listening (FL), and Non-Listening (NL), you can ask that of the Z-Wave protocol - like I mentioned in my first answer - without sending frames out the RF. |
Beta Was this translation helpful? Give feedback.
-
We already do that. The thought behind the ping is the following and stems from the expectation that we mirror the network state. Lets put aside the discussion around the necessity for a second:
In the case of zwave-js, the driver does a short interview of the controller stick to know what it is dealing with (capabilities, nodes in the network, etc.) and restores its cache. Afterwards, it emits the Theoretically you should now be able to send any command to any node (except that there will be an error thrown if you use a command that is not known to be supported). The interview is still going on in the background, but lets discuss this in another (focused) topic. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I'm slightly puzzled as to the startup speeds - ozw had similar speeds, so maybe I'm missing something. As I see it from the zwave2mqtt/zwavejs2mqtt project, z-wave networks will on restart:
My question / suggestion is regarding this. My thoughts are:
Ideally, IMO, it should be possible to restart zwave-js, and not have any traffic at all. I (arrogantly) imagine a startup process could be like this:
Then for each node
RestartedFromCachestate?), queue queries for all valuesIn both interview cases, if this becomes a congestion issue, it could be beneficial to put them on a queue so that only one interview process occurs at any one given time.
Mike.
Beta Was this translation helpful? Give feedback.
All reactions