FYI : Faster socket.send(...

Discussions about Z-Way software and Z-Wave technology in general
Post Reply
anom3
Posts: 71
Joined: 21 Sep 2016 08:53

FYI : Faster socket.send(...

Post by anom3 »

Having recently swapped all my 433.92 inwall's to fibaros I am doing quite a bit of work on updating / cleaning up / speeding up my home auto setup.

I'll share some of the things I am doing since I am using z-way-server as the interface to my z-wave mesh.

Here's the first one:

I used socket.send(.... to send UDP datagrams to a nodejs backend. This works quite nicely to get things from my zwave into my OpenHAB setup. One of the issues I had is I found that sock.send(... (in z-way-server's JS engine) tends to be a bit slow... I am unsure where the bottleneck is, but there would be an about 0.5 to 1 second delay between when I logged on z-way-server via console.log and when the datagram would hit my nodejs backend.

I found a solution that is working quite nicely, use system(... to invoke socat and send the datagram that way.

Yeah, we are talking about 0.5 seconds here... But for anything motion sensor based, it makes the experience quite a bit nicer... Here is a dump of the command I am invoking instead of socket.send now... Beware, add printf to your .syscommands file or else z-way-server will not execute the command:

Code: Select all

system("printf '"+JSON.stringify(OBJECT TO SEND TO UDP BACKEND)+"' | socat -t 0 - UDP:TARGETIP:TARGETPORT");
If anyone sees any issues using this instead of socket.send let me know!
User avatar
PoltoS
Posts: 7579
Joined: 26 Jan 2011 19:36

Re: FYI : Faster socket.send(...

Post by PoltoS »

With UDP check that DNS is not resolving things.

My crazy suggestion is to use tcpdump and strace to monitor what is done by Z-Way
anom3
Posts: 71
Joined: 21 Sep 2016 08:53

Re: FYI : Faster socket.send(...

Post by anom3 »

Yes that is probably the way I would go, but for now I will leave this socat solution in place.

I am running my z-way-servers on fairly powerful machines (one on a i5 8250 and one on a VM on my APU2) so there is quite a bit of head room to spawn a few processes here and there.

After the sun went down yesterday I was able to test more since many of my motion rules kick in after LUX<20. And the difference is significant. Every rule executes much quicker now so something is going on with socket.send that is slowing things down.
Post Reply