This page last changed on Jul 22, 2014 by mcfanda.

I've been using Openremote with Z-way (from on raspberry for more than a year without a hitch. The system was updated several times and now runs OpenRemote-Controller-2.0.2, and z-way-server_2014-07-19-08-33-48. The openremote switches are all implemented using http protocol, pointing to the raspberry that holds the z-way server. For instance

It uses to work like a charm.

Sometimes ago I noticed that the response time of the OpenRemote switches associated with z-ware actuators became slower and slower. The exact symptom is that every now and then one command takes up to 20 seconds to apply (for instance light up a light from the Openremote interface). This happens mostly randomly, but it is more likely when I issue several commands in a row (like switching three lights off, the third takes 20 secs to switch off).

To debug I've tried several things and I can say that:
1) When the command issued by openremote switch is sent by firefox, also several times in a few seconds, not problem arises.
2) z-way web interface shows no problem, as I can switch stuff on and off very quickly from there.
3) If openremote and z-way are on the same raspberry or on two different raspberries the problem is the same.
4) No error is shown in the openremote logs or in z-way logs.
5) The problem arises also when I issue (say) three commands, 2 of which are not related with z-way (for instance two switches for starting a rule). OR waits for the z-way related command to finish before executing the other rules.
I really tried hard to solve this independently, but I did not succeed. Any hint on where to look?
thank you

It's me again!

after some more debugging I was able to pinpoint the moment when the communication between OR and Z-way gets stuck. Right after the 10/20 secs of halt I'm experiencing, I see this in the dev.log. When the command is executed with no delay, these messages do not appear.

2014-07-23 07:00:32,703 INFO [Polling thread for sensor: K2-Sensor]: received message: true
2014-07-23 07:00:32,705 TRACE [Polling thread for sensor: K2-Sensor]: Processed 'true', received 'on'
2014-07-23 07:00:32,708 INFO [HTTP-Thread-1]: Had waited the skipped sensor ids of statuses in ChangedStatusRecord:491889754295782383602151576191698023-[67, 68, 69, 70] sensorID:[67, 68, 69, 70] statusChangedSensorID:[67]
2014-07-23 07:00:32,709 INFO [HTTP-Thread-1]: Querying changed data from StatusCache...
2014-07-23 07:00:32,709 INFO [HTTP-Thread-1]: Have queried changed data from StatusCache.
2014-07-23 07:00:32,712 INFO [HTTP-Thread-1]: Return the polling status.
2014-07-23 07:00:32,718 INFO [HTTP-Thread-1]: Finished polling at 2014-07-23 07:00:32

2014-07-23 07:00:32,749 INFO [HTTP-Thread-4]: Querying changed state from ChangedStatus table...
2014-07-23 07:00:32,752 INFO [HTTP-Thread-4]: Found: [device => 491889754295782383602151576191698023, sensorIDs => [67, 68, 69, 70]] in ChangedStatus table.
2014-07-23 07:00:32,753 INFO [HTTP-Thread-4]: ChangedStatusRecord:491889754295782383602151576191698023-[67, 68, 69, 70] sensorID:[67, 68, 69, 70] statusChangedSensorID:[]Waiting...
2014-07-23 07:00:33,233 INFO [Polling thread for sensor: LD1-DimSensor]: received message: 0
2014-07-23 07:00:33,236 TRACE [Polling thread for sensor: LD1-DimSensor]: Processed '0', received '0'

This is run on a test system with only three switches. Any idea?

Posted by mcfanda at Jul 23, 2014 06:06
Document generated by Confluence on Jun 05, 2016 09:37