Error on API after upgrade to 1.7

[zoic22]

It's seem OK now. So for other people the solution is :
- Force connection close
- Empty automation folder (leave main.js)

For the number of request I use /ZWaveAPI/Data/ with good datetime but I send also ,when alarm is on, ping paquet to node to see if there is no interference.

[pofs]

Typically the node itself should send you the alarm notification, so you see it changed in /ZWaveAPI/Data. If it is not, you'd better configure it to do so.
No need to poll them that much.

But even if the polling is really mandatory, you'd better make it on the server side with JS setInterval(). It will significantly reduce the number of requests.

[pofs]

Think we found an error in Home Automation UI, which sometimes caused event flood in JS and slowed down the server.
Fix will be available soon.

[PoltoS]

This fix is on github - you can checkout latest code. Or wait for the next release to have it togetheri with Z-Way updates.

[droll]

I can confirm that version 1.7 has an issue responding to HTTP requests, and I cannot see that the problem has been resolved with 1.7.2 (as indicated by PoltoS).
I am using a small application that performs some home automation tasks, very similar to OR. Every second my application gets from z-Way via a single HTTP request (JS API and vDev API) the states of all z-Way devices (OR uses one HTTP request for each device). The HTTP connection is closed by my application after each HTTP request. My application as well as the z-Way service are running on a Raspberry PI. My application's HTTP request timeout time has been set to 1s.
With z-Way 1.5.0 there are about 6 HTTP request timeouts per hour. Repeating the failing HTTP request the next request always succeeds.
With z-Way version 1.7.2 I observe more than 40 timeouts. For most of them also the repeated HTTP request are failing still a couple of times. Taking these repeated failouts into account, there are more than 220 failures per hour with z-Way 1.7.2!
It has been guessed that that the automation system of z-Way 1.7 is heavier than the one of 1.5 and that this may lead to delay in the responses to HTTP requests. For this reason I ran z-Way 1.5 with the 1.7 automation system (I copied simply the 1.7 automation folder into the 1.5 main directory). My observation is that the timeout rate was still very low (less than 6 single timeout failures per hour).
Here are the details of the measurements. 1x means that a failing HTTP request was successful the second trial. 2x means that also the repeated HTTP request was still failing, but the 3rd request was successful.

Code: Select all

+-----+--------+-----------------+----------+
| #cns| 1.5.0  | 1.7.2           | 1.5.0    |
| Err |        |                 | aut1.7.2 |
+-----+--------+-----------------+----------+
|  1x | ****** | *************** | *****    |
|  2x |        | ****            |          |
|  3x |        | **              |          |
|  4x |        | **              |          |
|  5x |        | **              |          |
|  6x |        | **              |          |
|  7x |        | ***             |          |
|  8x |        | *               |          |
|  9x |        | **              |          |
| 10x |        | **              |          |
| 11x |        | **              |          |
| 12x |        | **              |          |
| 13x |        | **              |          |
| 14x |        | **              |          |
| 15x |        | *               |          |
+-----+--------+-----------------+----------+
| #Err|  6.8   | 43.4            | 5.5      |
| #TE |  7.0   | 227.6           | 5.5      |
+-----+--------+-----------------+----------+

Since both my application as well as the z-Way service is running on the same Raspberry PI the HTTP communication happens only inside Raspberry. Latency of eventual network devices cannot be the root cause of the problem. The z-Way service uses about 6% and my application about 2% of the CPU time. There are no other applications or services that are using any relevant CPU time (no X server running). There are also no other HTTP requests others than the ones from my application (no z-Way web interface is open). We can therefore say that the reason for the HTTP request failures is not related to an overload of the CPU.
While the z-Way service uses usually about 6% of the CPU time, I could observe that z-Way loads the CPU to about 98% when HTTP timeouts are happening. Since most of the time multiple 1s-timeouts are happening the CPU can be loaded by z-Way for many seconds.
Hope you can find soon a root cause for this problem. I have also to switch back to z-Way 1.5, version 1.7 is unfortunately not usable for me.

[droll]

I did some additional HTTP response time measurements for z-Way 1.5.0-rc3 and 1.7.2. For both version more than 20'000 HTTP requests have been performed. The response time occurrence results are extrapolated to 1 mio HTTP requests.
For v1.5.0-rc3 it can be recognized that all requests are responded within 650ms. Interesting to see is that the occurrence distribution between 220ms and 640ms is pretty flat, but a mechanism seems to assure that the response time is never exceeding 650ms.
For v1.7.2 the response time is not limited to 650ms. The flat occurrence distribution goes up to 5 seconds. From 1 mio HTTP requests there are 7000 requests that have a respond time higher than 1 second, and about 4000 requests that have a respond time higher than 5 seconds!
Having these high respond time with version 1.7.2 is really a problem! I hope this can be addressed by the z-Way development team.

[pz1]

Interested in the Zwave.me's response on this and your previous post. This might be bugging my installation as well.

[PoltoS]

what are your HTTP requests?

[droll]

The application uses some helper JavaScript code running on the z-Way's JS engine (see attached). This helper code allows querying the states of all z-Way devices with a single HTTP request:

Code: Select all

http://localhost:8083/JS/Run/Get([["Control","DummyDevice_bn_5"],["Control","DummyDevice_bn_7"],["Control","DummyDevice_bn_6"],["SensorBinary","26"],["SensorBinary","25"],["SwitchBinary","3"],["SwitchBinary","8.1"],["SwitchBinary","8.2"],["SwitchBinary","7.1"],["SwitchBinary","7.2"],["SwitchBinary","16.0"],["TagReader","22"]])
-> [0,0,0,1,1,0,0,0,0,0,0,""]

This HTTP request is performed every second by the application. Since the application and z-Way is running on the same Raspberry PI the URL refers to 'localhost'. Advantage of this way of getting the states of all devices with a single HTTP request is that the number of interactions between the application and z-Way is heavily reduced, which should (hopefully) result in a higher reliability.

The 'Get' function, running on the z-Way server, accesses then via various sub-functions the public z-Way objects (server side JS access). Details can be taken from the attached JavaScript helper file.

[droll]

The HTTP response time issue of the z-Way server 1.7 seems be resolved with revision 2.0 (2.0.1-rc6). After running the z-Way server multiple days no HTTP timeout error could be observed.
Here is an update of the z-Way response time distribution, including now also the results from Z-Way 2.0. The result for this latest Z-Way revision is based on a 24 hour recording (one HTTP request per second).